Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D.

Rémi Després <despres.remi@laposte.net> Wed, 22 February 2012 15:03 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50A921F880C for <v6ops@ietfa.amsl.com>; Wed, 22 Feb 2012 07:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.733
X-Spam-Level:
X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyzjq4G0Acy4 for <v6ops@ietfa.amsl.com>; Wed, 22 Feb 2012 07:03:42 -0800 (PST)
Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93521F87DF for <v6ops@ietf.org>; Wed, 22 Feb 2012 07:03:41 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id d33e1i00C37Y3f40333exT; Wed, 22 Feb 2012 16:03:39 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com>
Date: Wed, 22 Feb 2012 16:03:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net>
References: <BB119B6D-FC99-4637-988D-D17FBB50597A@laposte.net><CAD6AjGTdfGz1egdp3MpWPYBdzCM56aZejfG98pe+bWS4zf6cvA@mail.gmail.com><824829E9-2221-401B-8781-FEF9745B946B@laposte.net><CAD6AjGQSTE1VQyme50aY+Ki5_o57joay03KV=s7nDvm=gtm6Ag@mail.gmail.com><36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net><CAD6AjGR=bJ7jL6NQjbFPLw_MeEAx-N3Aj6wKzRsi-eYEQYxiEA@mail.gmail.com><76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net><CAD6AjGSahYF3MPi-V1NXnNrjs3TYNCa1a+u15aCb=uxutNfTag@mail.gmail.com><B8548E01-9B0D-4FB1-93A0-DAECCED48EE1@laposte.net><CAD6AjGSX9i+Rjccu+j2D_8JFB8MOPi10+Z_m8FJ2CcSKk9QrEw@mail.gmail.com> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com>
To: Rajiv Asati <rajiva@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: Russell Housley <housley@vigilsec.com>, v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 15:03:46 -0000

Le 2012-02-22 à 15:10, Rajiv Asati (rajiva) a écrit :

>>> Alternatively, we may view the CLAT in terms of proxy NDP
> 
> I think that pNDP is unnecessary. NDP is good enough here. 
> 
> Also, when we move to using DHCP-PD, then NDP on WAN int will not be necessary either.
> 
>>> NDP for a host address should not be new material.


>> Nothing is new in your proposal for hosts, right, but NDP operation IS modified
>> in CE routers.
> 
> Remi, what is modified in your view?

Compliance with the 464XLAT draft requires specific code that none of the referenced RFCs specifies.
This code is to prevent other LAN hosts not only to avoid the router's address, as usual, BUT all addresses starting with the chosen /95. 

Cheers,
RD


> 
> Cheers,
> Rajiv
> 
> 
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
>> Rémi Després
>> Sent: Wednesday, February 22, 2012 5:40 AM
>> To: Cameron Byrne
>> Cc: v6ops WG; Russell Housley
>> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an
>> ietf-v6ops I.D.
>> 
>> Cameron,
>> It seems we are close to common understanding.
>> More below.
>> 
>> Le 2012-02-21 à 20:34, Cameron Byrne a écrit :
>> ...
>>> On Tue, Feb 21, 2012 at 10:42 AM, Rémi Després
>> <despres.remi@laposte.net> wrote:
>> ...
>>>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all
>> scenarios of RFC6144?
>>>> 
>>>> An answer to this?
>>>> 
>>> 
>>> Sorry i missed this earlier.
>>> 
>>> In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64
>>> and NAT64 must be coupled to replace NAT-PT functions.
>>> 
>>> But, RFC6146 and RFC6147 stand on their own.  There is no explicit
>>> coupling required or shared state between NAT64 and DNS64 for them to
>>> perform their atomic functions.  Meaning, any conforming packet
>>> (Pref64+32bit IPv4 destination address) may be received by an RFC6146
>>> stateful NAT64 and be translated.  A properly configured CLAT that
>>> knows the Pref64 may received IPv4 packets and translate them via
>>> RFC6145 to a PLAT without any queries or interactions with the DNS64.
>> 
>> I don't think a NAT64 that wouldn't work for IPv6-only hosts is a scenario that
>> needs to be mentioned, especially since it contradicts an existing RFC.
>> IMHO, stating that, with a CE architecture like that of the 464XLAT draft, a
>> stateless CE can work with a stateful NAT64 is enough.
>> Adding that it can work without DNS64 is AFAIK at best unnecessary, at worst
>> confusing.
>> That could advantageously be deleted (IMHO).
>> 
>> ...
>>>>>>>> Why, then, say "In the best case, the CLAT will have a dedicated /64"
>>>>>>>> 
>>>>>>> 
>>>>>>> It just seems cleaner to me to have a dedicated /64 if it is
>>>>>>> available.  Operationally, aside from the NDP claiming the /96, there
>>>>>>> is no difference to have dedicated or not dedicated.
>>>>>> 
>>>>>> Understood, but:
>>>>>> - Claiming a /96 on a link seems new to me (is there an existing
>> reference?)
>>>>> 
>>>>> It does not need to claim the /96 as a whole.  The CLAT will do NDP
>>>>> with the idea that each /128 in the /96 is owned by the CLAT as a
>>>>> virtual address.
>>>> 
>>>> Was understood.
>>>> 
>>>>> I have seen this behavior in NAT-PT deployments, but i do not see it
>>>>> specifically declared in the NAT-PT RFC.
>>>> 
>>>> Right, it seems to be new material as far as IETF is concerned.
>>>> 
>>> 
>>> NDP for a host address should not be new material.
>> 
>> Nothing is new in your proposal for hosts, right, but NDP operation IS modified
>> in CE routers.
>> 
>>> As i mentioned
>>> before, we can treat each address in the /96 as a host address on the
>>> CLAT, and the interactions are normal for NDP host addresses.
>> 
>> Understood.
>> The fact that this is new in the router CE is not a problem AFAIAC, but provided
>> new pieces of design are clearly identified.
>> 
>>> Alternatively, we may view the CLAT in terms of proxy NDP
>>> http://tools.ietf.org/html/rfc4861#section-7.2.8
>> 
>> Doesn't this require support of RFC3810 (Multicast Listener Discovery Version 2
>> (MLDv2) for IPv6)?
>> That could be part of the specification, but would AFAIK would be a constraint.
>> 
>>> The CLAT is willing to accept packet destine to the /96 on behalf of
>>> the IPv4 internet, and the NDP actions are defined as existing Proxy
>>> NDP.
>>> 
>>> Thoughts on one verse the other?
>> 
>> My thought is that BOTH can be AVOIDED.
>> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs from all
>> valid native IPv6 prefixes.
>> This is easy to have, and is part of the 4rd-U proposal.
>> The architecture you propose can easily benefit from it, simply by adding its
>> scenario as a particular one of the 4rd-U general scheme.
>> 
>>>> I think I understand your motivations, and hope you can understand those of
>> draft-ietf-softwire-stateless-4v6-motivation.
>>>> 
>>> 
>>> Yes, and thanks again for your careful review and attention to the 464XLAT
>> draft
>> 
>> I confirm that IMHO your draft brings quite useful new material.
>> 
>> If you can take time to look at http://tools.ietf.org/html/draft-despres-softwire-
>> 4rd-u-03, my hope is that you will understand that coordination between its
>> contents and that of your draft should be useful.
>> 
>> Regards,
>> RD
>> 
>> 
>> 
>> 
>>> 
>>> CB
>>> 
>>>> Regards,
>>>> RD
>>>> 
>>>> 
>>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops