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

["Dan Wing" <[e-mail]>]

 

> -----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
> 
>