Re: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-02

[Rémi Després <[e-mail]>]

marcelo bagnulo braun  -  le (m/j/a) 4/22/09 10:52 AM:

> Rémi Després escribió:
>> it is not clear, so far, that if we use 
>> the existing well known prefix ::FFFF:0:0/96 of IPv4 mapped addresses, 
>> rather than defining a new one, any RFC is offended.
>>
>> Pointing to an existing rule that forbids to use this prefix on the 
>> wire (if  it exists) would help clarifying this debate.
> 
> sigh, let me try one more time
> We tried to use this prefix in current implementations and they do not 
> use this prefix in the wire.
> If we use this prefix we need to change the implementations, beating one 
> of the key goals, which is to support unchanged IPv6 hosts
> 
> So, it is a non starter, really.
> 
> (BTW, we took the trouble of testing this because we would have liked 
> very much to be able to use it, but unfortunatelly, we can't)

OK, I get the point that tests you made showed that at least current 
implementations you tested couldn't work with the mapped address prefix 
used to reach NAT64s.

I also get the point that, with a different WKP, there would have been a 
very good chance that these same implementations could have worked.

The short term and easy conclusion seems then to be the definition of a 
new WKP.
But ALL CONSEQUENCES of having two ways to do essentially the same thing 
have to be anticipated.

Here is an example of a POSSIBLE PROBLEM (there may be others):
- An application that is both IPv4 and IPv6 capable is run in an 
IPv6-only host.
- It gets an A RR in response to a DNS query (obtained in IPv6).
- Then it presents the received IPv4 address at its PF_INET6 socket 
interface in mapped format, conforming in this to RFC2553 sec 3.7.
- If the stack is not capable to forward IPv6 packets with this 
destination address, connectivity is lost.

Of course, applications could be changed, e.g. to detect the lost 
connectivity and next try the other WKP, but is this to be suggested 
rather than fixing IPv6 stacks?

Please be sure that this discussion is not just for the sake of arguing. 
I may be wrong in this particular case, but I believe there may be 
significant operational consequences ahead when an existing 
specification, without being deprecated, is proposed to coexist with a 
new one to do the same thing.

Regards,

RD