Subject: [Fwd: Re: Further Comment to RFC 5952]

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 15 Oct 2010 08:55:56 +0900

Thanks for the comments.
This also should go to the 6man list.

Regards,
Seiichi

- -------- Original Message --------
Subject: Re: Further Comment to RFC 5952
Date: Thu, 14 Oct 2010 17:02:10 +0200
From: Test <[email-masked]>
To: [email-masked],    [email-masked]
References: <[email-masked]>

Typos corrected. Sorry.

Test wrote:
> Sirs,
>
> Excuse me for bombarding you with questions and comments, but I think 
> that if I have questions there must be many other programmers out 
> there who are making dangerous assumptions and not asking you.
>
> I have come across another ambiguity whilst testing my library that is 
> not clarified by reading the RFC 5952.
>
> It regards the handling of prefixes in mixed representation of 
> addresses handled under section 5, such as IPv4-Mapped IPv6 addresses.
>
> The question is how to handle the mask length of prefixes in such cases.
>
> Is it correct to write an IPv4 mapped IPv6 address prefix 
> corresponding to the old Class A network 10.0.0.0 =  IPv4 CIDR 
> 10.0.0.0/8 as IPv4 mapped IPv6 with the notation
>
> ::FFFF:10.0.0.0/8 [prefix relative to 32 bits of IPv4 because the 
> mechanism clearly maps IPv4 into IPv6 notation]
>
> or should this be
>
> ::FFFF:10.0.0.0/104 [prefix relative to 128 bits of IPv6]
>
> This is of course has potentially an equivalent problem in pure IPv6 
> format with two options.
>
> ::ffff:0a00:0000/8
> or
> ::ffff:0a00:0000/104
>
> My gut feeling says less programmes will break with 
> ::ffff:10.0.0.0/104, but it is potentially more confusing to humans to 
> say the least.
>
> The hex representation of this IPv6 address ::ffff:0a00:0000/104 would 
> be handled correctly by all IPv6 programmes even if they do not 
> recognise all of the special embedded IPv4 mechanisms mentioned in 
> RFC4291.
>
> Whereas ::ffff:0a00:0000/8 would almost certainly break the programme 
> if it did not understand the specifics of IPv4 mapped IPv6 addresses, 
> as it would be interpreted as far too big a range.
>
> On the other hand, humans might get confused when they read 
> ::FFFF:10.0.0.0/104, and prefer ::FFFF:10.0.0.0/8 although potentially 
> less so than I would imagine.
>
> Tough call.
>
> I think some clarification text in Section 7 would be useful.