IPv6 address/port format

David Burgess burgess@mitre.org
Tue, 11 Jan 2000 09:47:46 -0600



Bill Sommerfeld wrote:
> 
> > "Dwayne C . Litzenberger" <dlitz@cheerful.com> said:
> > > I'm not really knowledgeable about this, but what is a good, standard way
> > > to show address/port shown in IPv4, IPv6, IPX, etc?  I would think
> > > address.:port (dot-colon) would be good (and it already works with domain
> > > names), but I haven't seen this done yet.
> >
> > > Any thoughts?
> >
> >   I've seen people use both "IPv6-addr port" (space sep.) and
> > "IPv6-addr/port".  I think I really like using '/', and haven't yet
> > found a place where that will cause problems except for in URIs.
> 
> It's too easily confused with network prefixes.. (IPv6-addr/prefixlen).
> 
> How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be
> parsed as an <address,port> pair or as a network prefix?
> 

The obvious answer is, of course, by context.  If I were to tell you to
connect to 3ffe:1ce1:0:b5::1/64, then you would connect to service 64. 
If I was talking about routing issues, then the 64 would be the prefix
length.

In spite of that, I think the slash is still too problematic once we
get into the WWW.  There are places where the context is ambiguous.  For
example, the following URI should be perfectly reasonable:

http://3ffe:1ce1:0:b5::1/1019/ 

Where 1019 is the directory on the web server that points to some
website I'm hosting.  The only tractable way to solve the problem is to
come up with a different service port method.

Since we're tossing suggestions around, how about putting the service
number is square brackets.  I can't think of a place where that would
hurt us (except at the Unix shell prompt).  Something like
3ffe:1ce1:0:b5::1[1019] would be doable....

Another suggestion would be to reverse the IPv4 semantics for dotted
quad:service.  For example, "3ffe:1ce1:0:b5::1.1019" might work.  Since
there are no valid v4 addresses in the 0.0.0.x or 0.0.1.x blocks, we
wouldn't even have to worry about 32 bit v4 address representations. 
Without at least one more '.', it's fairly obvious that the suffix isn't
an address component.