Re: I-D draft-petersson-forwarded-for-00.txt

Hello Poul-Henning, others,

On making '[...]' mandatory, I agree. Moving from an X- header to a 
header without X- is often a very good place to clean up the syntax.

On 2011/04/07 21:24, Poul-Henning Kamp wrote:

> The matter of IPv6 address notation has been a total nightmare from day
> one, addressed by at least 11 RFC which do not agree on very much, leaving
> implementors with a nightmarish morass of code[1]

> [1]  From my own brief survey:
> 	RFC1884 ->  2373         1080::8:800:200C:417A
> 	RFC1884                 ::13.1.68.3
> 	RFC1884                 ::FFFF:129.144.52.38
> 	RFC2133 ->  2133
> 	RFC2292 ->  3542
> 	RFC2373 ->  3513
> 	RFC2428 EPRT |2|1080::8:800:200C:417A|5282|
> 	RFC2553 ->  RFC3493
> 	RFC2732 ->  3986 http://[3ffe:2a00:100:7031::1]:8080/
> 	RFC3493 "numeric format"
> 	RFC3513 ->  4291
> 	RFC3986 BNF form
> 	RFC3986 http://[3ffe:2a00:100:7031::1]:8080/
> 	RFC3986 http://[v%x.????]/

As the coauthor of RFC 3987, which copies all the relevant syntax from 
RFC 3986, I'm very familiar with the RFC 3986 syntax, but the last line 
look very suspicious.

There is indeed a syntax that uses a 'v' inside a '[', but it's 
currently not used. The intent is to use it for future versions of the 
IP protocol (just in case :-) and potentially for variants beyond the 
currently allowed syntax. The letter immediately following the 'v' is a 
simple hex digit, no '%' involved.

Here's the relevant text from the spec:

 >>>>
       IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

       IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

    The version flag does not indicate the IP version; rather, it
    indicates future versions of the literal format.  As such,
    implementations must not provide the version flag for the existing
    IPv4 and IPv6 literal address forms described below.  If a URI
    containing an IP-literal that starts with "v" (case-insensitive),
    indicating that the version flag is present, is dereferenced by an
    application that does not know the meaning of that version flag, then
    the application should return an appropriate error for "address
    mechanism not supported".
 >>>>


At one time, there has been a proposal to use one of the versions for an 
extended form of IPv6 addresses to include scope zone identifiers
http://tools.ietf.org/html/draft-fenner-literal-zone-02
(don't ask me what scope zone identifiers are, I was just working on the 
URI syntax side of the problem).


> 	RFC5952 [2001:db8::1]:80
>
> And it's really unfair to leave this one out:
> 	RFC1924 4)+k&C#VzJ4br>0wv%Yp
> Despite the fact that it is published on april 1st, it does not stick
> significantly out from the confusion of the rest.

Yes. And having an April fools' RFC on a topic may also indicate that 
there was a strong feeling of "too many, so why not one more".

Regards,    Martin.

Received on Friday, 8 April 2011 01:29:30 UTC