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

Xuewei Wang <wangxuewei@huawei.com> Wed, 27 May 2009 03:22 UTC

Return-Path: <wangxuewei@huawei.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CF33A6819 for <behave@core3.amsl.com>; Tue, 26 May 2009 20:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Level:
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oiq4vn07WNVo for <behave@core3.amsl.com>; Tue, 26 May 2009 20:22:09 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1D4E43A6D58 for <behave@ietf.org>; Tue, 26 May 2009 20:22:09 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKA00D139CBF4@szxga03-in.huawei.com> for behave@ietf.org; Wed, 27 May 2009 11:21:47 +0800 (CST)
Received: from w00104636 ([10.111.12.168]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKA00GCJ9CA03@szxga03-in.huawei.com> for behave@ietf.org; Wed, 27 May 2009 11:21:47 +0800 (CST)
Date: Wed, 27 May 2009 11:21:47 +0800
From: Xuewei Wang <wangxuewei@huawei.com>
To: Dan Wing <dwing@cisco.com>, 'Rémi Després' <remi.despres@free.fr>, 'Behave WG' <behave@ietf.org>
Message-id: <006a01c9de7a$44be0510$a80c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <4A02B8B9.1000905@free.fr> <021f01c9d2a5$778ee4e0$c5f0200a@cisco.com>
Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 03:22:10 -0000

hi,Dan,

If v4-mapped as the well-known prefix is not available for IPv6 only host, could we consider other well-known prefix which requires IANA allocates?

For DNSSEC we can cancel the DNS64, and make the DNS server synthesize AAAA RR using a well-known prefix for IPv4 only host, so DNSSEC can be implemented at IPv6 host.
For dual stack host in the IPv6 network, should upgrade them to make them to recognize the well-known prefix, and obtain the original IPv4 address from the synthesized IPv6 address.

Xuewei Wang
----- Original Message ----- 
From: "Dan Wing" <dwing@cisco.com>
To: "'Rémi Després'" <remi.despres@free.fr>; "'Behave WG'" <behave@ietf.org>
Sent: Tuesday, May 12, 2009 10:00 AM
Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64


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:dwing@cisco.com] 
> 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:remi.despres@free.fr] 
> > 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
> 

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave