Re: [Softwires] 4rd-u tunnels and stateful NAT64s

Rémi Després <despres.remi@laposte.net> Sat, 24 March 2012 08:24 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4B21F8688 for <softwires@ietfa.amsl.com>; Sat, 24 Mar 2012 01:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Twv1LhZsszYz for <softwires@ietfa.amsl.com>; Sat, 24 Mar 2012 01:24:48 -0700 (PDT)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1873421F8686 for <softwires@ietf.org>; Sat, 24 Mar 2012 01:24:47 -0700 (PDT)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id pLQm1i00G37Y3f403LQmkp; Sat, 24 Mar 2012 09:24:47 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-3--64515689"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqVaRv57TFDwVncXLYqYMFGV2kgU3WiX94deTcyMfrLwPg@mail.gmail.com>
Date: Sat, 24 Mar 2012 09:24:46 +0100
Message-Id: <33FA6DA8-2623-4C3D-9A07-A395894984F3@laposte.net>
References: <B509CB1C-4A0A-408B-9B4A-C0F847169431@juniper.net> <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net> <CAM+vMERsVz7cuC1C52gw12wySaEgw8=44JjS8AUygj0vJ899Cg@mail.gmail.com> <DDD20574-4ECD-4285-BB15-548628FB0425@laposte.net> <CAM+vMETahum9rB+fr=OHAmVobDZSzRRy9mUwkjryhqRvaJWe-Q@mail.gmail.com> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <CAAuHL_D68nkd36ifLzEeVR67Q124VH-pMhM1pkEE_PcLbGxBrw@mail.gmail.com> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <CAFUBMqX9dj8MSeZdJTic5iOT=Jjg4oihWs30FWVAca08v_3=7g@mail.gmail.com> <D476AFD2-3B6B-48A0-971D-C65CC2CFA46B@laposte.net> <CAFUBMqU1wtP5prSaLG8hDSuv-EGWP5Diqoj6WEMHb_q8hNVDdQ@mail.gmail.com> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <CAFUBMqVzbtZ7JxunHv7m1zgWjRa2sh7zZS+91aURAy8-xTZW8g@mail.gmail.com> <CAFUBMqXPAA7RjCzgvbuq0WqbKijXwuFebnmrL-zDx_XoZh=Xkg@mail.gmail.com> <FED38071-241D-480C-9A8A-CFA7A55A4F3B@laposte.net> <A4A7C9E3-DBA9-4AA5-A60B-E3D3A187BD7 F@laposte.net> <CAFUBMqVT=E=GqBG_-q458GCpYKLk66vuvE-cx81=eTdgyUbj7A@mail.gmail.com> <D1EF9447-336A-48B4-91F4-D514654AC93D@laposte.net> <CAFUBMqWTRb_pjV_VFEDpNof7H+AnOvRM_acQXZ4XRPzAG-865A@mail.gmail.com> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <CAFUBMqUVme5Vmm0QuJT4rcZeWo-CZyZoGBkq6RLjO=DRYLKYSg@mail.gmail.com> <AD2E97A4-98FF-4F00-BC28-44AB430870FB@laposte.net> <CAFUBMqXi02DcrTkJ3zjt4fv8EvVJPfAv=CTkM7gesi95jNQSQQ@mail.gmail.com> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <CAFUBMqXuvBt6DD8JpWt_5+JP33ETqTrz3KbSRm1Kp9ZQBjqs+w@mail.gmail.com> <F2C46FAE-30EF-4707-8680-F4CED8A3A7F9@free.fr> <CAFUBMqU_ggCiE1Jr=HEAY1a1sunNXQZu1Oi98Jaa7jfd_0puLg@mail.gmail.com> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <CAFUBMqU+Bv1L6b7BLOwYwACbma4nDhpq_5BziC_Y0qxvCGkJ_A@mail.gmail.com> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <A06E3FC4-5D3B-4027-9D38-B4E3397E9F99@laposte.net> <CAFUBMqXaja4XoGMCAcQbGOqKxkhbGEGWD9pgp26Btvub2RJWGA@mail.gmail.com> <533DDBBF-FE50-4BF 9-8554-58C1340CCDC6@laposte.net> <CAFUBMqV_0Bh1_uOitu+MQXSbuLm=NydQFg9j-J6S+SyXcG_6ww@mail.gmail.com> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <CAFUBMqWz+FKShTb3mB-00nzCEA1+ehtRjzPjC_PROiW7nSDxYA@mail.gmail.com> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> <CAFUBMqVV7Q=qnk=UoxBS8VKsjRffjgDM=z0vAGthrCEx0kZMGw@mail.gmail.com> <D748D3CB-3DDC-47BB-8A0C-130809A6B70C@laposte.net> <CAFUBMqXzUCQTe6wnVnN+u0r191m4UXdqyrb0Tx=vzRs943SEkw@mail.gmail.com> <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> <CAFUBMqVaRv57TFDwVncXLYqYMFGV2kgU3WiX94deTcyMfrLwPg@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] 4rd-u tunnels and stateful NAT64s
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2012 08:24:49 -0000

2012-03-19 11:44, Maoke:
> 2012/3/19 Rémi Després <despres.remi@laposte.net>
> Le 2012-03-19 à 10:21, Maoke a écrit :
>> 2012/3/19 Rémi Després <despres.remi@laposte.net>
>> Le 2012-03-19 à 09:16, Maoke a écrit :
>>> 2012/3/16 Rémi Després <despres.remi@laposte.net>
>>> Maoke,
>>> 
>>> Let me try a more complete picture than before:
>>> 
>>> 
>>>     A1 -----.           
>>> RFC6145-host|           .-- 4rd BR --. 
>>>             |           |            |
>>>     A2 -----:--(v6net)--:            :--(v4 Internet)--- B 
>>>   4rd-CE    |           |            |             UDP Lite appli                   
>>> (no IPv4 @) |           '-- NAT64+ --' 
>>>             |          
>>>     A3 -----' 
>>>   4rd-CE                                                
>>> (IPv4 @, shared or not)
>>> 
>>> 
>>> NAT64+ is supposed to have a bindings for UDP Lite, either only for 4rd IPv6 addresses (the minimum), or also for native IPv6 addresses (the complete upgrade, with UDP-Lite checksum adjustment for these addresses)
>>> 
>>> Connectivities I get are: 
>>>  A2  => B (via NAT64+)
>>>  A3 <=> B (via 4rd BR)
>>> (There is no A1-B connectivity)
>>> 
...
>>  let me have the following propositions: 
>> 
>> a. NAT64 suitable for any case no matter A2 is assigned with any kind of address, but currently only works for TCP and UDP. 
> 
> Yes (but with the DF bit transparency limitation that is avoided in case of NAT64+)
> 
>> b. NAT64+ works for the cases where A2 is assigned with a special type of IPv6 address with the CNP, without need to update checksum for any L4 protocols.

Seems right: no L4 update for IPv6 addresses having 4rd-U format.

>>  
>> c. NAT64+ works like: 
>>    if A2 has a V-CNP-address, then it doesn't update the checksum for any L4 protocols; 
>>    if A2 has any other kind of native IPv6 address, then NAT64+ works just like NAT64, updating the checksum but also currently only works for TCP and UDP. 

Seems right too, and more precise. 


>> 
>> i think we are common that a. is true, right?
> 
> Right, with the caveat above.
> 
>> do you mean c. instead of b. ?
> 
> NAT64+ works like NAT64 in all cases, except for 4rd CEs that:
> - received a NAT64+ mapping rule
> - have IPv6 prefixes from which no IPv4 address can be derived.
> For them, better transparency is achieved by replacing double RFC6145 translation by a Reversible header mapping. 
> 
> not yet cleared. "receives a NAT64+ mapping rule" for what?

A CE receives the NAT64 mapping rule to know that, although it has no public IPv4 address, it can reach IPv4 servers via NAT64+, and thus avoid any v4/v6 translation (more transparent).

> is the NAT64+ mapping rule stateless or stateful?

The rule per se is neither. It just says what the CE has to do if having no public IPv4 address.
What the NAT64+ must be stateful, at least for IPv6 addresses that are not mapped to any public IPv4 address.

> what the behavior of NAT64+ in the case of "except"? is there "and" or "or" between the "received ..." and the "have IPv6 prefixes..." clauses?

Not understood.


> please answer directly: do you mean c. instead of b.? (or, if either is not applied, and you may have d.) 

If pressed to make a choice, c. seems a better expression of what is specified than b.  

Cheers,
RD


(Retransmitted with much unnecessary text deleted. The message was refused as being too long for the mailing list)