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

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

Dan,

At the end of a discussion in 2002 on Itojun's draft, Erik Nordmark 
wrote in www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00263:
"An implementation needs to be configured to either be IPv6-only or
dual stack.
In the dual stack case the mapped addresses at the API correspond
to IPv4 packets on the wire.
In the IPv6-only case the mapped addresses at the API correspond
to IPv6 packets on the wire next to the node, and on the other side of
the translator they correspond to IPv4 packets."

I agree with this.

Note that this statement received no objection in 2002, and that 
Itojun's didn't issue a -01 version of his draft.

Regards,

RD


Dan Wing  -  le (m/j/a) 4/27/09 7:52 PM:
>  
> 
>> -----Original Message-----
>> From: Rémi Després [mailto:[e-mail]] 
>> Sent: Monday, April 27, 2009 10:16 AM
>> To: Keith Moore; Dan Wing; Marcello Bagnulo Braun; Fred Baker
>> Cc: 'Iljitsch van Beijnum'; 'Behave WG'; Xing Li
>> Subject: Re: [BEHAVE] Question on embedded address format in 
>> draft-baker-behave-v4v6-framework-02
>>
>> Keith Moore  -  le (m/j/a) 4/25/09 2:56 AM:
>>>> That falls into the "well-known prefix causes harm" category.
>>>>
>>>> I recall that one of the presentations at the Google IPv6 
>>>> conference showed there were a lot of Teredo and 6to4
>>>> prefixes advertised in DNS.  If IANA assigns a well known 
>>>> prefix for 6/4 translation, we should expect some people
>>>> will stick that prefix into their DNS records.  Perhaps
>>>> out of incompetence, perhaps while debugging or learning, 
>>>> or perhaps because 'it works fine for my site that way'.
>>> I am becoming more and more convinced that a WKP for v4/v6 
>> translation
>>> is a Bad Idea.  That is, it is certain to cause harm, and 
>> it's hard to
>>> see how it will actually be of any significant benefit.
>> Very interesting debate.
>>
>> (A) Here is where, in my understanding, a WKP brings a 
>> significant benefit:
>> If DNS servers of IPv4-ony hosts contain the IPv6 addresses at which 
>> IPv6-only hosts can reach them, these hosts can be reached by 
>> IPv6-only 
>> hosts without sacrificing DNSsec (while RR translations in DNS64s 
>> prohibits the use of DNSsec).
>>
>>
>> (B) Now, here is how to avoid, in my understanding, any short 
>> term harm:
>>
>> 1. If the WKP is ::FFFF/96 (that of IPv4 mapped addresses), it is 
>> already harmful neither to _IPv4-only hosts_ (that don't see 
>> AAAAs) nor 
>> to _IPv4-enabled dual-stack hosts_ (according to RFC 2553 
>> they send in 
>> IPv4 packets that have mapped address destinations).
> 
> What of
> http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02, 
> or was it found that we could resolve that harm?  (I noticed
> draft-itojun-v6ops-v4mapped-harmful-02 appears to have not been
> published as an RFC.)
> 
> -d
> 
> 
>> The relevant quote from RFC 2553 sec3.7 is:
>> "Applications may use PF_INET6 sockets to open TCP connections to IPv4
>> nodes, or send UDP packets to IPv4 nodes, by simply encoding the 
>> destination's IPv4 address as an IPv4-mapped IPv6 address, and
>> passing that address, within a sockaddr_in6 structure, in the
>> connect() or sendto() call."
>>
>> 2. If an ISPs wants to offer IPv6-only addresses to its hosts 
>> (that have 
>> either IPv6-only stacks or dual stacks with IPv4 not enabled ), it is 
>> sufficient, to avoid suffering any harm, that its DNS64s 
>> _translate IPv4 
>> mapped address prefixes they receive into their ISP specific NAT64 
>> prefixes_.
>>
>> With DNS64s doing as proposed in 2., DNSsec compatibility is still 
>> broken, but not more than without a WKP.
>>
>> DNSsec deployment being likely to take enough time to prepare a more 
>> complete solution, as described below.
>>
>>
>> (C) Finally, here is how to eventually restore DNSsec compatibility.
>>
>> - Before DNSsec with NAT64s becomes important, make sure that:
>>   o TCP/IP dual stacks don't discard packets whose destination is the 
>> mapped address when IPv4 is not enabled, patching them where 
>> necessary. 
>>   (some stacks discarding these packets have been seen to exist).
>>   o firewalls that discard these packets by default can be configured 
>> not to do it.
>> - Then IPv6-only ISPs can:
>>   o ensure that routes to their NAT64s exist for the mapped 
>> address prefix
>>   o disable the translation of mapped addresses prefixes into 
>> ISP-specific prefixes.
>>
>> The end result is that IPv4-only servers, that have advertised their 
>> mapped address in their DNSsec capable DNS servers (possibly 
>> a long time 
>> ago) become accessible by IPv6-only hosts _that rely on DNSsec_.
>>
>> Isn't this an interesting promise?
>>
>> Regards,
>> RD
>>
>>
> 
>