Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64

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

Rémi,

I have one more question about using v4-mapped as the well-known prefix for
the 6/4 translator.  It appears, based on Iljitsh's testing last summer [1]
that when Windows Vista or MacOS Leopard are configured as IPv6-only (that is,
no IPv4 address), they won't send a v4-mapped IPv6 packet at all.  This seems
a problem for using v4-mapped as the well-known prefix of the IPv6/IPv4
translator.

[1] http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html


I do wonder, however, if configuring those hosts for IPv4 just to know about
127.0.0.1 would be sufficient for their IP stacks to emit v4-mapped IPv6
addresses.  

Iljitsch, would you have time to test that idea, or would you know off-hand
the answer from previous testing you did?

-d

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: Thursday, May 07, 2009 1:16 PM
> To: 'Rémi Després'; 'Behave WG'
> Subject: RE: DNSsec in IPv6-only-hosts & discarding mapped 
> AAAAs in DNS64
> 
>  
> 
> > -----Original Message-----
> > From: Rémi Després [mailto:[e-mail]] 
> > Sent: Thursday, May 07, 2009 3:32 AM
> > To: Dan Wing; Behave WG
> > Subject: Re: DNSsec in IPv6-only-hosts & discarding mapped 
> > AAAAs in DNS64
> > 
> > Dan Wing  -  le (m/j/a) 5/7/09 3:26 AM:
> > > So, this means
> > > 
> > > 1. all networks deploying a translator for IPv6-initiated 
> scenarios 
> > > (Scenario 1 and Scenario 5) would have to use the 
> well-known prefix
> > 
> > A.
> > The scenario being discussed is "connecting an IPv6 network 
> > to the IPv4
> > Internet", i.e. scenario (2) in Fred's draft on the Translation
> > Framework. (I must confess I am confused with scenarios 
> identified by
> > numbers: Fred has only 4 of them.)
> 
> Yes, sorry about that.
> 
> I was going with the 4 we have in the charter,
> http://www.ietf.org/html.charters/behave-charter.html, and the
> other two defined by Dave Thaler in the Doodle poll,
> http://www.doodle.com/participation.html?pollId=9qsdgt8r6kqk6zty
> 
> Our soon-to-be-updated charter will have all 6, because at
> the San Francisco meeting the clear consensus was to work on
> all 6.
> 
> > B.
> > A network deploying a translator for IPv6-initiated scenarios should
> > route to its NAT64s all packets whose destination start with:
> > - the prefix(es) chosen by the ISP for its NAT64s (an ISP-specific
> > prefix and/or, if a WKP different from that of mapped addresses is
> > standardized, this WKP )
> 
> Ok.
> 
> > - the mapped address prefix (or at least its 64 first bits, 
> > i.e. ::/64,
> > if /96 prefixes are not routed)
> >
> > > 2. all existing dual-stack hosts would see these published AAAA
> > > record, which would require those hosts to use a 
> translator if the 
> > > host OS or its application prefer IPv6 over IPv4.  What 
> happens if 
> > > there isn't a translator available to that user or its 
> > > performance is poor?
> > 
> > When mapped-address AAAAs start being published, dual-stack 
> hosts are
> > expected to send datagrams having mapped addresses as destinations:
> > - in IPv4 if an IPv4 address is available at the interface
> > - in IPv6 otherwise (and then require a NAT64 to be provided 
> > by the ISP)
> 
> Ok, thanks.  
> 
> So, I believe the timeframes would be aligned:  An ISP that offers
> only IPv6 addresses to subscribers will need to operate a translator
> to access IPv4 anyway.
> 
> > > Are there other impacts, too?
> > 
> > DNS64s:
> > -  as long as dual-stack hosts cannot be expected to act as 
> specified
> > above, MUST discard mapped address records;
> 
> We would like dual-stack hosts to prefer native connectivity (rather
> than translated connectivity).
> 
> > - after that, SHOULD forward them, at least if they are 
> DNSsec signed.
> > 
> > IPv6-only applications should not artificially block mapped 
> addresses
> > destinations.
> 
> So applications and host OSs should ignore 
> draft-itojun-v6ops-v4mapped-harmful, correct?
> 
> > Does this answer your questions?
> 
> Yes, thanks.  Much clearer now.
> 
> And I see how this could work now.
> 
> -d
>