IPv6 address/port format

[David Burgess]

"Michael H. Warfield" wrote:
> 
> On Tue, Jan 11, 2000 at 09:47:46AM -0600, David Burgess wrote:
> 
> > 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.
> 
>         Bzzzt...  Wrong answer...
> 
>         Firewall rule:
> 
>         Deny access to 3ffe:1ce1:0:b5::1/96
> 
>         Are you saying to restrict the rule to port 96 on that host or are
> you saying restrict the rule to any port on the /96 subnet.  It's ambigous
> to attempt to parse it without knowledge of the data contents you are
> attempting to parse and THAT'S unacceptable as a consequence.
> 
>         Overloading the '/' is going to be ambiguous in some contexts and
> I see no way to avoid that.
> 
>         [...]
> 

In the elided section, I bring up a different 'bad case', so I'd say I
agree here.  The more we think about it, the more it gets strange.  The
RFC based suggestion (putting the address in square brackets) seems to
be the least egregious of the choices I've seen so far.

BTW:  The NetBSD firewall system uses a separate port directive from the 
address component of the address, which would dis-ambiguate the event. 
Using the /nn directive there (in that particular implementation) would
still allow for the contextual clues required....

IN SPITE OF THAT I agree that overloading the '/' is genuinely a bad
idea.  The only two workable solutions that I would consider are to
actually adopt the RFC based solution or to do like I suggested before
and switch the v4 to v6 semantics for ':' and '.'