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 3:36 PM:
> Rémi Després escribió:

>> 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.
>>
> right, so what is the problem? I mean, in ths scenario it seems we have 
> an IPv6 only host that is trying to communicate to an IPv4 only host and 
> hast no NAT64 available (it there were, it would had received a 
> synthetic AAAA RR containing either the WK prefix or the LIR prefix 
> being used by the nat64 box and the communication would have been 
> established)
> 
> So, i am missing why is this a problem if there is a nat64 and if there 
> is a nat64 what are the problems that srping from having the WK prefix 
> being different from the IPv4 mapped prefix (i am sure you had something 
> in mind, just not clear to me from this example you provided)

OK, I understand the answer and, after the comment below, have no plan 
to  insist.

In my understanding, the following constraints result from the fact that 
IPv4 mapped addresses have been artificially excluded from valid 
destinations in IPv6-only environments:
- IPv6-only hosts MUST send ONLY recursive queries (as most host do, but 
so far without being obliged to).
- If these queries are not sent directly to DNS64 servers at 
v6only-v4only borders, intermediate servers MUST:
   . NOT be in dual stack clouds (there, they should not loose the 
ability to respond with As).
   . NOT handle recursive queries by themselves (although they typically 
do it)
   . instead, forward recursive queries to a v4-v6 border server, or to 
  intermediate servers having the same constraints.

These may not be the exact constraints, but should be close to reality.


If on the contrary mapped addresses would not have been artificially 
barred, and would have remained the ONLY way to express a v4 address in 
v6 format:
- The constraint above on DNSs would have not been needed.
- IPv4-only servers would have become accessible via NAT64s by IPv6-only 
applications, and by dual-stack applications in v6-only hosts, just by 
having their mapped addresses in AAAA RRs in their local DNSs.
- Compatibility between on the fly RR translations and DNSsec would NOT 
have been a problem.


Well, the past is the past, that's life :-(.

To be optimistic, that's one more reason to make IPv6 deployment 
everywhere as rapid as possible ;-).

Regards,

RD