From sunqi.csnet.thu@gmail.com Thu Mar 1 01:15:53 2012 Return-Path: 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 3934F21F8672 for ; Thu, 1 Mar 2012 01:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 ndoU8r2AeVhy for ; Thu, 1 Mar 2012 01:15:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84021F866C for ; Thu, 1 Mar 2012 01:15:51 -0800 (PST) Received: by iazz13 with SMTP id z13so628384iaz.31 for ; Thu, 01 Mar 2012 01:15:51 -0800 (PST) Received-SPF: pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.156.166 as permitted sender) client-ip=10.50.156.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.156.166 as permitted sender) smtp.mail=sunqi.csnet.thu@gmail.com; dkim=pass header.i=sunqi.csnet.thu@gmail.com Received: from mr.google.com ([10.50.156.166]) by 10.50.156.166 with SMTP id wf6mr9851igb.20.1330593351718 (num_hops = 1); Thu, 01 Mar 2012 01:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=l/BY4GBXATsbJwzQI4e3HMQEaCZXEtcDuvrzFLz8TaU=; b=xzjYYs0JRlw0hIixORGN+PTSQzCmYwoO8tQSkkWNIfj1VztnR4XV12yY8ZfO/S4AdA rreFz2ot3jm8rAV2h10ezj92lVNJA9UXs/42CWEbxkad4wo9wahVZ1JwuYEitlvnMV/x 5gzoiAQbgvB53zpsZHkrJLn1OH22pf/CaKH4E= Received: by 10.50.156.166 with SMTP id wf6mr7768igb.20.1330593351658; Thu, 01 Mar 2012 01:15:51 -0800 (PST) Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id hy6sm5876406igc.12.2012.03.01.01.15.48 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 01:15:51 -0800 (PST) Date: Thu, 1 Mar 2012 17:15:43 +0800 From: "Qi Sun" To: "Tetsuya Murakami" References: <2012022917183726704470@gmail.com>, X-Priority: 3 X-GUID: 30BC989E-02EB-48D7-8864-F26F614C6118 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012030117154299898339@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart041034177785_=----" Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:15:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart041034177785_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTXVyYWthbWksDQogICAgVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiBQbGVhc2Ugc2VlIG15 IGNvbW1lbnRzIGluIGxpbmVzLg0KDQoNCkZyb206IFRldHN1eWEgTXVyYWthbWkNCkRhdGU6IDIw MTItMDMtMDEgMTA6MTQNClRvOiBzdW5xaS5jc25ldC50aHUNCkNDOiBUZXRzdXlhIE11cmFrYW1p OyBzb2Z0d2lyZXMgV0cNClN1YmplY3Q6IFJlOiBDb21tZW50cyBvbiBNQVAtRSBkcmFmdA0KSGkg UWksDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IGNvbW1l bnRzIGluIGxpbmUuDQoNCg0KT24gMjAxMi8wMi8yOSwgYXQgMToxOCwgUWkgU3VuIHdyb3RlOg0K DQoNCkhpIE11cmFrYW1pLA0KICAgICBJdCdzIGEgZ29vZCBkcmFmdCBhbmQgbWFrZXMgYSBuaWNl IHN1cHBvcnQgZm9yIHRoZSBNQVAgbWVjaGFuaXNtLiBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBz b21lIGNvbW1lbnRzIG9uIHRoZSBkcmFmdChzb3JyeSBpZiB0aGV5J3ZlIGJlZW4gZGlzY3Vzc2Vk IGV2ZXIpLiBQbGVhc2UgY2hlY2sgYmVsb3cuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFNlY3Rpb24gIDUuMiBQYWNr ZXQgRm9yd2FyZGluZyBCZWhhdmlvciBvbiBNQVAtRSBCUg0KUGFydCAoYikgQlIgcmVjZXB0aW9u IG9mIGFuIElQdjYgcGFja2V0DQogICAgICAgICAgICBCUiBkZXJpdmVzIGEgQ0UgSVB2NiBhZGRy ZXNzIGZyb20NCiAgICAgICAgICAgIHRoZSBJUHY0IHNvdXJjZSBhZGRyZXNzIG9yIHRoZSBJUHY0 IHNvdXJjZQ0KICAgICAgICAgICAgYWRkcmVzcyBhbmQgdGhlIHNvdXJjZSBwb3J0IGluIHRoZSBl bmNhcHN1bGF0ZWQNCiAgICAgICAgICAgIElQdjQgcGFja2V0IGJhc2VkIG9uIHRoZSBCTVIuICBJ ZiB0aGUgQ0UgSVB2Ng0KICAgICAgICAgICAgYWRkcmVzcyBpcyBlcWF1bCB0byB0aGUgSVB2NiBz b3VyY2UgYWRkcmVzcyBpbg0KICAgICAgICAgICAgdGhlIHJlY2VpdmVkIElQdjYgcGFja2V0LCBC UiBkZWNhcHN1bGF0ZXMgdGhlDQogICAgICAgICAgICBJUHY0IHBhY2tldCBhbmQgdGhlbiBmb3J3 YXJkIGl0IHZpYSB0aGUgSVB2NA0KICAgICAgICAgICAgaW50ZXJmYWNlLg0KSSBoYXZlIGEgZmV3 IHF1ZXN0aW9ucyBoZXJlLg0KMS4gSG93IGNhbiB0aGUgQlIgZ2V0IGZyb20gYW4gSVB2NiBwYWNr ZXQgdGhlIElQdjQgc291cmNlIGFkZHJlc3Mgb3IgdGhlIElQdjQgc291cmNlIGFkZHJlc3MgYW5k IHRoZSBzb3VyY2UgcG9ydCBpbiB0aGUgZW5jYXBzdWxhdGVkIElQdjQgcGFja2V0Pw0KSW4gY2Fz ZSBvZiBNQVAtRSwgSVB2NCBwYWNrZXQgaXMgZW5jYXBzdWxhdGVkIGluIElQdjYuIFRoZSBhYm92 ZSB0ZXh0IGlzIGZvciBjaGVjayB0aGUgdmFsaWRhdGlvbiBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0 LiBJbiB0ZXJtcyBvZiBJUHY2IHBhY2tldCByZWNlaXZlZCBhdCBCUiwgdGhlIElQdjYgc291cmNl IGFkZHJlc3Mgc2hvdWxkIGJlIGJhc2VkIG9uIHRoZSBJUHY2IHByZWZpeCBkZWxlZ2F0ZWQgdG8g Q0UuIEFsc28sIGFjY29yZGluZyB0byB0aGUgTUFQIHJ1bGUsIElQdjQgYWRkcmVzcyBhbmQgcG9y dCBudW1iZXIgY2FuIGJlIGRlcml2ZWQgZnJvbSB0aGUgc2FtZSBkZWxlZ2F0ZWQgSVB2NiBwcmVm aXguIFNvLCBCUiBjYW4gY2FsY3VsYXRlIENFIElQdjYgYWRkcmVzcyBmcm9tIHRoZSBJUHY0IHNv dXJjZSBhZGRyZXNzIGFuZCBzb3VyY2UgcG9ydCBudW1iZXIgaW4gSVB2NCBwYWNrZXQgZW5jYXBz dWxhdGVkIGluIHRoZSByZWNlaXZlZCBJUHY2IHBhY2tldC4gSWYgdGhlIGNhbGN1bGF0aW9uIGlz IGZhaWxlZCwgdGhlbiB0aGUgcGFja2V0IGNvdWxkIGJlIGRyb3BwZWQuIElmIHRoZSBjYWxjdWxh dGlvbiBpcyBzdWNjZWVkZWQgYnV0IHRoZSBjYWxjdWxhdGVkIENFIElQdjYgYWRkcmVzcyBpcyBu b3QgbWF0Y2hlZCB0byB0aGUgc291cmNlIElQdjYgYWRkcmVzcyBpbiB0aGUgcmVjZWl2ZWQgSVB2 NiBwYWNrZXQsIHRoZW4gdGhlIHBhY2tldCBjb3VsZCBiZSBkcm9wcGVkLg0KDQpbUWkgU3VuXSAg SSBoYXZlIDIgcXVlc3Rpb25zIGhlcmUuDQpbUWkgU3VuXSAxLk15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCB0aGUgQlIgZ2V0IHRoZSBJUHY0IHJlbGF0ZWQgaW5mbyBmcm9tIHRoZSBJUHY2IHBhY2tl dCBieSByZWFkaW5nIHRoZSBzcGVjaWZpYyBiaXRzIGluIHRoZSBJUHY2IHBhY2tldCwgdGhhdCBp cyB0aGUgSVB2NCBhZGRyZXNzIGlzIHB1dCBpbiB0aGUgZXhhY3QgcG9zaXRpb24gaW4gdGhlIElQ djYgcGFja2V0LiBSaWdodD8NCltRaSBTdW5dICAyLllvdSBzYWlkLCdJZiB0aGUgY2FsY3VsYXRp b24gaXMgZmFpbGVkLCB0aGVuIHRoZSBwYWNrZXQgY291bGQgYmUgZHJvcHBlZC4nIEkgdGhpbmsg dGhpcyBhY3Rpb24gbWF5IGNhdXNlIHRoZSBkYXRhIGxvc3Mgb2Ygbm9ybWFsIElQdjYgZmxvdy4N Cg0KDQoyLiBJZiB0aGUgcmVjZWl2ZWQgSVB2NiBwYWNrZXQgaXMgYSBub3JtYWwgb25lLCBpbnN0 ZWFkIG9mIGFuIElQdjQtZW5jYXBzdWxhdGVkIHBhY2tldCwgd2hhdCB3aWxsIHRoZSBCUiBkbz8g IFRoYXQgaXMsIGRvc2UgdGhlIEJSIGNhbiBhY3QgYXMgYSBub3JtYWwgcm91dGVyPw0KDQoNCklu IHRoaXMgY2FzZSwgQlIgc2hvdWxkIGhhbmRsZSB0aGlzIElQdjYgcGFja2V0IGJhc2VkIG9uIHRo ZSBub3JtYWwgSVB2NiByb3V0aW5nIGJlY2F1c2UgdGhlIG5leHQgaGVhZGVyIGlzIG5vdCBJUHY0 IGluIHRoaXMgY2FzZS4NCg0KW1FpIFN1bl0gQWdyZWUgOikNCg0KMy4gV2hhdCBjYW4gY2F1c2Ug dGhlIGluZXF1YWxpdHkgYmV0d2VlbiB0aGUgZGVyaXZlZCBDRSBJUHY2IGFkZHJlc3MgYW5kIHRo ZSBJUHY2IHNvdXJjZSBhZGRyZXNzIGluIHRoZSByZWNlaXZlZCBJUHY2IHBhY2tldD8gQW5kIHdo YXQgd2lsbCBCUiBkbyB3aXRoIGl0LCBkaXNjYXJkIGl0ID8NCg0KDQpJdCBtaWdodCBkZXBlbmQg b24gdGhlIGltcGxlbWVudGF0aW9uLiBCdXQgdGhlIGRlcml2ZWQgQ0UgSVB2NiBhZGRyZXNzIG11 c3QgYmUgc2FtZSBhcyB0aGUgSVB2NiBzb3VyY2UgYWRkcmVzcyBpbiBjYXNlIG9mIE1BUC1FIGJl Y2F1c2UgdGhlIGRlcml2ZWQgQ0UgSVB2NiBhZGRyZXNzIHNob3VsZCBiZSB0aGUgdHVubmVsIGVu ZC1wb2ludCBhZGRyZXNzIG9uIHRoZSBDRS4gU28sIHRoZSByZWNlaXZlZCBwYWNrZXQgc2hvdWxk IGJlIGRpc2NhcmRlZCBvciBub3QgcHJvY2Vzc2VkIGFzIE1BUC1FIHBhY2tldC4NCg0KW1FpIFN1 bl0gIFlvdSBtZWFuLCBpbiB0aGUgTUFQLUUgY2FzZSwgdGhlIGluZXF1YWxpdHkgd29uJ3QgaGFw cGVuLCByaWdodD8gDQoNCk15IHF1ZXN0aW9uIGlzIHRoYXQgd2hldGhlciB0aGUgTUFQLUUgbm9k ZXMgY2FuIGJlIGRlcGxveWVkIHdpdGggdGhlIG5vcm1hbCBJUHY2IG5vZGVzLiBJZiBjYW4ndCwg d29uJ3QgaXQgY29zdCB0b28gbXVjaCB0byBkZXBsb3kgYnJhbmQgbmV3IE1BUC1FIGRvbWFpbnMg Zm9yIFNQPyBJZiBjYW4sIGlzIGl0IHBvc3NpYmxlIHRvIGJlIHN0YXRlZCBpbiB0aGUgZHJhZnQs IHdpdGggdGhlIGNvbnNpZGVyYXRpb25zIG9mIEJSIGhhbmRsaW5nIG5vbi1NQVAtRSBJUHY2IHBh Y2tldHMgPw0KDQpMb29raW5nIGZvcndhcmQgdG8gdXIgcmVwbHl+DQoNCltRaSBTdW5dIA0KQmVz dCBSZWdhcmRzLA0KUWkgU3VuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNClRoYW5rcywNClRldHN1eWEgTXVy YWthbWkNCg0KDQpJJ20gbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHl+DQoNCkJlc3QgUmVn YXJkcywNCg0KUWkgU3VuDQpUc2luZ2h1YSBVbml2ZXJzaXR5LCBCZWlqaW5nLCBDaGluYQ== ------=_001_NextPart041034177785_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Murakami,
    Thank you for your reply= . Please=20 see my comments in lines.
 
 
Date: 2012-03-01 10:14
To: sunqi.csnet.thu
Subject: Re: Comments on MAP-E draft
Hi Qi= ,

Thank you for your comments. Please see my comments in line.

On 2012/02/29, at 1:18, Qi Sun wrote:
Hi Murakami,
     It's a good draft and makes a nice support= for=20 the MAP mechanism. I would like to propose some comments on the draft(so= rry if=20 they've been discussed ever). Please check below.
-----------------------------------------------------------------
 Section =20 5.2 Packet Forwarding Behavior on MAP-E=20 BR
Part (b) BR reception of an IPv6 packet
           =
 BR derives a CE IPv6 address from
            the IPv4 source address or the IPv4 source
            address and the source port in the encapsulated
            IPv4 packet based on the BMR.  If the CE IPv6
            address is eqaul to the IPv6 source address in
            the received IPv6 packet, BR decapsulates the
            IPv4 packet and then forward it via the IPv4
            interface.
I have a few questions here.
1. How can the BR get from an IPv6 packet the IPv4 source addr= ess or=20 the IPv4 source address and the source port in the encapsulated IPv4=20 packet?
In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text= is=20 for check the validation of the received packet. In terms of IPv6 packet=20 received at BR, the IPv6 source address should be based on the IPv6 prefix= =20 delegated to CE. Also, according to the MAP rule, IPv4 address and port nu= mber=20 can be derived from the same delegated IPv6 prefix. So, BR can calculate C= E IPv6=20 address from the IPv4 source address and source port number in IPv4 packet= =20 encapsulated in the received IPv6 packet. If the calculation is failed, th= en the=20 packet could be dropped. If the calculation is succeeded but the calculate= d CE=20 IPv6 address is not matched to the source IPv6 address in the received IPv= 6=20 packet, then the packet could be dropped.

= [Qi=20 Sun]  I have 2 questions here.
= [Qi=20 Sun] 1.My understanding is that the BR get the IPv4=20 related info from the IPv6 packet by reading the specific bits in the= IPv6=20 packet, that is the IPv4 address is put in the exact position in the IPv6=20 packet. Right?
= [Qi=20 Sun]  2.You said,'If the=20 calculation is failed, then the packet could be dropped.' I th= ink=20 this action may cause the data loss of normal IPv6 flow.
=
2. If the received IPv6 packet is a normal one, instead of an=20 IPv4-encapsulated packet, what will the BR do?  That is, dose the B= R can=20 act as a normal router?

In this case, BR should handle this IPv6 packet based on the normal I= Pv6=20 routing because the next header is not IPv4 in this case.

<= FONT=20 style=3D"FONT-FAMILY: =CB=CE=CC=E5; COLOR: #1f497d; FONT-SIZE: 10.5pt">= [Qi=20 Sun] Agree :)
3. What can cause the inequality between the derived CE IPv6 addres= s and=20 the IPv6 source address in the received IPv6 packet? And what will BR do= with=20 it, discard it ?

It might depend on the implementation. But the derived CE IPv6 addres= s must=20 be same as the IPv6 source address in case of MAP-E because the derived CE= IPv6=20 address should be the tunnel end-point address on the CE. So, the received= =20 packet should be discarded or not processed as MAP-E packet.

= [Qi=20 Sun]  You mean, in the MAP-E case, the inequality won't happ= en,=20 right?

My question is that whether the MAP-E nodes can be deployed= with=20 the normal IPv6 nodes. If can't, won't it cost too much to deploy brand ne= w=20 MAP-E domains for SP? If can, is it possible to be stated in the draft, wi= th the=20 considerations of BR handling non-MAP-E IPv6 packets ?

Looking forw= ard to=20 ur reply~

= [Qi=20 Sun] 
Best Regards,
Qi=20 Sun

---------------------------------------------------------------= ---- 
Thanks,
Tetsuya Murakami

I'm looking forward to your reply~
 
Best Regards,
 
Qi Sun
Tsinghua University, Beijing, China
 

<= /DIV> ------=_001_NextPart041034177785_=------ From ichiroumakino@gmail.com Thu Mar 1 01:22:51 2012 Return-Path: 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 0D27B21F85F8 for ; Thu, 1 Mar 2012 01:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 9b4K2J7P133v for ; Thu, 1 Mar 2012 01:22:47 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCCE21F8682 for ; Thu, 1 Mar 2012 01:22:47 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so216061wgb.13 for ; Thu, 01 Mar 2012 01:22:46 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.101.72 as permitted sender) client-ip=10.180.101.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.101.72 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.101.72]) by 10.180.101.72 with SMTP id fe8mr8610759wib.4.1330593766429 (num_hops = 1); Thu, 01 Mar 2012 01:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rtnwsuKeTFkguZhWxpXZiuiKjuk8R1wh4M6YQqXwlmA=; b=ijKTamqSfff+wZ9FzfEn5/iBJMRFsmOdqweuOBj5bbKEOtoEaFaOG1dEfWB9HVKCYs wzN38KG45qpo9BHIUcvCZtmpxDiFnXfuXWM4oqeZeSKCj5Oq0eK0szgk/ZHrBq2L1/Qq 8sPQ3Xu+eKiycq7wUy3wkSP8QRtMpWfMsn3mQ= Received: by 10.180.101.72 with SMTP id fe8mr6894702wib.4.1330593766340; Thu, 01 Mar 2012 01:22:46 -0800 (PST) Received: from [173.38.129.239] ([173.38.129.239]) by mx.google.com with ESMTPS id dr5sm7008599wib.0.2012.03.01.01.22.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 01:22:45 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=GB2312 From: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Priority: 3 In-Reply-To: <2012030117154299898339@gmail.com> Date: Thu, 1 Mar 2012 10:22:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> References: <2012022917183726704470@gmail.com>, <2012030117154299898339@gmail.com> To: "sunqi.csnet.thu" X-Mailer: Apple Mail (2.1257) Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:22:51 -0000 Qi, >> It's a good draft and makes a nice support for the MAP = mechanism. I would like to propose some comments on the draft(sorry if = they've been discussed ever). Please check below. >> ----------------------------------------------------------------- >> Section=20 >> =20 >> =20 >> 5.2 >> Packet Forwarding Behavior on MAP-E=20 >> BR >>=20 >> Part (b) BR reception of an IPv6 packet >> BR derives a CE IPv6 address from >> the IPv4 source address or the IPv4 source >> address and the source port in the encapsulated >> IPv4 packet based on the BMR. If the CE IPv6 >> address is eqaul to the IPv6 source address in >> the received IPv6 packet, BR decapsulates the >> IPv4 packet and then forward it via the IPv4 >> interface. >>=20 >> I have a few questions here. >> 1. How can the BR get from an IPv6 packet the IPv4 source address or = the IPv4 source address and the source port in the encapsulated IPv4 = packet? > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text = is for check the validation of the received packet. In terms of IPv6 = packet received at BR, the IPv6 source address should be based on the = IPv6 prefix delegated to CE. Also, according to the MAP rule, IPv4 = address and port number can be derived from the same delegated IPv6 = prefix. So, BR can calculate CE IPv6 address from the IPv4 source = address and source port number in IPv4 packet encapsulated in the = received IPv6 packet. If the calculation is failed, then the packet = could be dropped. If the calculation is succeeded but the calculated CE = IPv6 address is not matched to the source IPv6 address in the received = IPv6 packet, then the packet could be dropped. >=20 > [Qi Sun] I have 2 questions here. > [Qi Sun] 1.My understanding is that the BR get the IPv4 related info = from the IPv6 packet by reading the specific bits in the IPv6 packet, = that is the IPv4 address is put in the exact position in the IPv6 = packet. Right? > [Qi Sun] 2.You said,'If the calculation is failed, then the packet = could be dropped.' I think this action may cause the data loss of normal = IPv6 flow. >=20 >> 2. If the received IPv6 packet is a normal one, instead of an = IPv4-encapsulated packet, what will the BR do? That is, dose the BR can = act as a normal router? >=20 > In this case, BR should handle this IPv6 packet based on the normal = IPv6 routing because the next header is not IPv4 in this case. >=20 > [Qi Sun] Agree :) >> 3. What can cause the inequality between the derived CE IPv6 address = and the IPv6 source address in the received IPv6 packet? And what will = BR do with it, discard it ? >=20 > It might depend on the implementation. But the derived CE IPv6 address = must be same as the IPv6 source address in case of MAP-E because the = derived CE IPv6 address should be the tunnel end-point address on the = CE. So, the received packet should be discarded or not processed as = MAP-E packet. >=20 > [Qi Sun] You mean, in the MAP-E case, the inequality won't happen, = right?=20 >=20 > My question is that whether the MAP-E nodes can be deployed with the = normal IPv6 nodes. If can't, won't it cost too much to deploy brand new = MAP-E domains for SP? If can, is it possible to be stated in the draft, = with the considerations of BR handling non-MAP-E IPv6 packets ? MAP-E is no different than any other tunnel in this regard. MAP-E = packets are terminated at a single IPv6 address on the BR. all other = IPv6 traffic will be forwarded like normal. i.e. traffic with a = destination address not being the BR's MAP-E IPv6 address. cheers, Ole From shtsuchi@cisco.com Thu Mar 1 05:47:15 2012 Return-Path: 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 6136F21E8488 for ; Thu, 1 Mar 2012 05:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CpkCIBlfTXhy for ; Thu, 1 Mar 2012 05:47:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6421E846C for ; Thu, 1 Mar 2012 05:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=441; q=dns/txt; s=iport; t=1330609635; x=1331819235; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IiQYg3LIxNlX7nDWizWF54qyMMzCW7mwNbFTrbNxBjY=; b=bVbnJr22VCWuhHGzkCbXzlYAWfvLmIZ6PR/Ca5zx+22h47fnXVx+4rAO XFqGW571yBFAUmaTKWxEpUgNxWeO3ValZUJAKfC+opMqvbEu+R8CqwqzN wqPPnXwzsW2P0+75XM4HYjWlSLy2zRfIR5u/6oDTvHUwUwxQHAuov1Wul Y=; X-IronPort-AV: E=Sophos;i="4.73,510,1325462400"; d="scan'208";a="62984118" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 01 Mar 2012 13:47:14 +0000 Received: from [10.82.232.231] (rtp-vpn5-231.cisco.com [10.82.232.231]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q21DlBJp013639; Thu, 1 Mar 2012 13:47:12 GMT Message-ID: <4F4F7DDE.9040805@cisco.com> Date: Thu, 01 Mar 2012 22:47:10 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: adurand@juniper.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 13:47:15 -0000 Alain and Yong I would like to request time slot for 6rd mib draft. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01 Regards, -Shishio (2012/03/01 0:16), Alain Durand wrote: > If you intend to present in Paris, please send Yong and I a request by 3/7. > > - Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From maxpassion@gmail.com Thu Mar 1 06:56:28 2012 Return-Path: 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 C266B21E833B for ; Thu, 1 Mar 2012 06:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 jzkXi7KyP17J for ; Thu, 1 Mar 2012 06:56:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5221E8317 for ; Thu, 1 Mar 2012 06:56:28 -0800 (PST) Received: by iazz13 with SMTP id z13so1102462iaz.31 for ; Thu, 01 Mar 2012 06:56:27 -0800 (PST) Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.186.198 as permitted sender) client-ip=10.50.186.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.186.198 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com Received: from mr.google.com ([10.50.186.198]) by 10.50.186.198 with SMTP id fm6mr4697388igc.40.1330613787784 (num_hops = 1); Thu, 01 Mar 2012 06:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nMp59cVC21fndhAqGchYoFQu7mSbv5qFFFmPsWe8e14=; b=WN8QmotGoltgQs7SHmYwEe4kP5nHHx/wtyZ9NdSUO0t+2BOGD//3ZBIJsNmiL91SMF yfs+qmR3Jauc29N6l92GlM8Qf8Ag2kOMmF5mlfJxUCh7F+PAhFnvO+SXxbM7lcYzllPJ yKaQdYNdrnGx+XuUT/BgLoiwQWujAfB/ulafo= MIME-Version: 1.0 Received: by 10.50.186.198 with SMTP id fm6mr3871296igc.40.1330613787740; Thu, 01 Mar 2012 06:56:27 -0800 (PST) Received: by 10.42.161.74 with HTTP; Thu, 1 Mar 2012 06:56:27 -0800 (PST) In-Reply-To: <941C4201-CC42-4E27-A1E1-7E3970FC6F77@laposte.net> References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr> <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net> <941C4201-CC42-4E27-A1E1-7E3970FC6F77@laposte.net> Date: Thu, 1 Mar 2012 22:56:27 +0800 Message-ID: From: liu dapeng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Softwire Chairs Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:56:28 -0000 2012/2/29, R=E9mi Despr=E9s : > > Le 2012-02-29 =E0 10:53, liu dapeng a =E9crit : > >> 2012/2/28, R=E9mi Despr=E9s : >>> >>> 2012-02-28 15:06, liu dapeng : >>> ... >>>> 2012/2/27, R=E9mi Despr=E9s : >>> ... >>>>> The draft only reflects the wish of an number of operators to have a >>>>> stateless solution standardized, acknowledging that this is in additi= on >>>>> to >>>>> the more advanced stateful solutions (it doesn't even include the wor= d >>>>> "superior"). >>> ... >>>> Thanks for the discussion but the fundamental question is: >>>> >>>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a >>>> stateless solution, >>>> >>>> then, why [CPE(stateless) + xlate(stateful)] is not a stateless >>>> solution? >>> >>> >>> What I see as important is that IPv6-only routing can be deployed ASAP >>> without sacrificing a good residual IPv4 service, including where ISPs >>> prefer per-user stateless operation. >>> >>> The point has already been made that functions are defined in the draft >>> as >>> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" stat= e. >>> A CE can therefore be considered stateless *in the draft* even if it ha= s >>> NAT44 (a function that is purely IPv4, and whose statefulness is per >>> session). >>> Because of that, the draft is self consistent an doesn't need to be >>> modified. >>> >>> I do hope that, with these additional explanations, and in order to avo= id >>> waste of energy, you can accept to join a consensus that it is time to >>> close >>> this discussion and accept the draft. >>> >>> >>> Looking forward to further discussions on solutions themselves, >>> Regards, >>> RD >>> >> Hello Remi >> >> Firstly, this draft will mis-lead other operators thinking that this >> is a pure stateless solution from the title and the document (maybe >> terminology such as "Maping" is better). IETF WG should not hurry up >> without the correct description on what the document is. For my >> understanding, both of above two solutions are stateful solution. Even >> in the first case of BR' side there are still stateful information for >> control plane. >> >> Secondly, since this is also stateful solution principally. Then why >> IETF need to invent a second wheel about the same scenario, > > >> should >> IETF obsolete previous one such as DS-Lite, then start to work on >> this? > > Surely not. > This debate has been finished when it was decided that Softwire would wor= k > ALSO on solutions that are stateless, at least in ISP gateways to the IPv= 4 > Internet. > > You may have not been personally part of this consensus, which is obvious= ly > your right, but the consensus remains. > Since no one prevents you from using stateful solutions of you choice, > trying to prevent those who want a more stateless solution to have a > specification isn't, IMHO, fair contribution to standardization. > > RD It=92s really a bad idea to invent two wheels for the same scenario. This is not IETF=92s spirit, It=92s a disaster for =93One Internet=94. I guess that it has been quite clear that this is not a =93stateless=94, whatever state is more or less, the current terminology is mis-leading.If you want, then maybe =93Mapping=94 is much better. IETF consensus has to happen multiple times during the process of the docu= ment. -Dapeng >> >> Thanks >> >> -Dapeng >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > --=20 ------ Best Regards, Dapeng Liu From cb.list6@gmail.com Thu Mar 1 07:52:05 2012 Return-Path: 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 D61A521E8209 for ; Thu, 1 Mar 2012 07:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 PiEYmeSiPG7U for ; Thu, 1 Mar 2012 07:52:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B63A21E8202 for ; Thu, 1 Mar 2012 07:52:04 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so1066141pbc.31 for ; Thu, 01 Mar 2012 07:52:04 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.232.42 as permitted sender) client-ip=10.68.232.42; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.232.42 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.232.42]) by 10.68.232.42 with SMTP id tl10mr4261206pbc.50.1330617124386 (num_hops = 1); Thu, 01 Mar 2012 07:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N4X1Mjj6vOOMsz7RDLbp36PcF0FgyraAxJr/PO6MXuw=; b=d1IjEWQOSOBMhiVFqilYZevr4Q57zpbgf2XBeNhlhIu/i730vQ7HReNs5MDPBzIcqF jNjVfAgySAmCtd/k6gF0BeN3WKOSVeJRiZvaG2o67Dt+J5aINUvyi6X01J85KtSS5gOQ S8IQbpGMJbEDkshXJeiockOfXoi3eAmp3TqLo= MIME-Version: 1.0 Received: by 10.68.232.42 with SMTP id tl10mr3602810pbc.50.1330617124167; Thu, 01 Mar 2012 07:52:04 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 1 Mar 2012 07:52:03 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 1 Mar 2012 07:52:03 -0800 (PST) In-Reply-To: <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> Date: Thu, 1 Mar 2012 07:52:03 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=047d7b33d868049e1f04ba30714a Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:52:06 -0000 --047d7b33d868049e1f04ba30714a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mar 1, 2012 1:22 AM, "Ole Tr=F8an" wrote: > > Qi, > > >> It's a good draft and makes a nice support for the MAP mechanism. I would like to propose some comments on the draft(sorry if they've been discussed ever). Please check below. > >> ----------------------------------------------------------------- > >> Section > >> > >> > >> 5.2 > >> Packet Forwarding Behavior on MAP-E > >> BR > >> > >> Part (b) BR reception of an IPv6 packet > >> BR derives a CE IPv6 address from > >> the IPv4 source address or the IPv4 source > >> address and the source port in the encapsulated > >> IPv4 packet based on the BMR. If the CE IPv6 > >> address is eqaul to the IPv6 source address in > >> the received IPv6 packet, BR decapsulates the > >> IPv4 packet and then forward it via the IPv4 > >> interface. > >> > >> I have a few questions here. > >> 1. How can the BR get from an IPv6 packet the IPv4 source address or the IPv4 source address and the source port in the encapsulated IPv4 packet= ? > > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text is for check the validation of the received packet. In terms of IPv6 packet received at BR, the IPv6 source address should be based on the IPv6 prefix delegated to CE. Also, according to the MAP rule, IPv4 address and port number can be derived from the same delegated IPv6 prefix. So, BR can calculate CE IPv6 address from the IPv4 source address and source port number in IPv4 packet encapsulated in the received IPv6 packet. If the calculation is failed, then the packet could be dropped. If the calculation is succeeded but the calculated CE IPv6 address is not matched to the source IPv6 address in the received IPv6 packet, then the packet could be dropped. > > > > [Qi Sun] I have 2 questions here. > > [Qi Sun] 1.My understanding is that the BR get the IPv4 related info from the IPv6 packet by reading the specific bits in the IPv6 packet, that is the IPv4 address is put in the exact position in the IPv6 packet. Right? > > [Qi Sun] 2.You said,'If the calculation is failed, then the packet could be dropped.' I think this action may cause the data loss of normal IPv6 flow. > > > >> 2. If the received IPv6 packet is a normal one, instead of an IPv4-encapsulated packet, what will the BR do? That is, dose the BR can act as a normal router? > > > > In this case, BR should handle this IPv6 packet based on the normal IPv6 routing because the next header is not IPv4 in this case. > > > > [Qi Sun] Agree :) > >> 3. What can cause the inequality between the derived CE IPv6 address and the IPv6 source address in the received IPv6 packet? And what will BR do with it, discard it ? > > > > It might depend on the implementation. But the derived CE IPv6 address must be same as the IPv6 source address in case of MAP-E because the derived CE IPv6 address should be the tunnel end-point address on the CE. So, the received packet should be discarded or not processed as MAP-E packet. > > > > [Qi Sun] You mean, in the MAP-E case, the inequality won't happen, right? > > > > My question is that whether the MAP-E nodes can be deployed with the normal IPv6 nodes. If can't, won't it cost too much to deploy brand new MAP-E domains for SP? If can, is it possible to be stated in the draft, with the considerations of BR handling non-MAP-E IPv6 packets ? > > MAP-E is no different than any other tunnel in this regard. MAP-E packets are terminated at a single IPv6 address on the BR. all other IPv6 traffic will be forwarded like normal. i.e. traffic with a destination address not being the BR's MAP-E IPv6 address. > What is the expected behavior when that address becomes unavailable? Cb > cheers, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --047d7b33d868049e1f04ba30714a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 1, 2012 1:22 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>
> Qi,
>
> >> =A0 =A0 =A0It's a good draft and makes a nice support for= the MAP mechanism. I would like to propose some comments on the draft(sorr= y if they've been discussed ever). Please check below.
> >> -------------------------------------------------------------= ----
> >> =A0Section
> >>
> >>
> >> 5.2
> >> =A0Packet Forwarding Behavior on MAP-E
> >> =A0 BR
> >>
> >> Part (b) BR reception of an IPv6 packet
> >> =A0 =A0 =A0 =A0 =A0 =A0 BR derives a CE IPv6 address from
> >> =A0 =A0 =A0 =A0 =A0 =A0 the IPv4 source address or the IPv4 s= ource
> >> =A0 =A0 =A0 =A0 =A0 =A0 address and the source port in the en= capsulated
> >> =A0 =A0 =A0 =A0 =A0 =A0 IPv4 packet based on the BMR. =A0If t= he CE IPv6
> >> =A0 =A0 =A0 =A0 =A0 =A0 address is eqaul to the IPv6 source a= ddress in
> >> =A0 =A0 =A0 =A0 =A0 =A0 the received IPv6 packet, BR decapsul= ates the
> >> =A0 =A0 =A0 =A0 =A0 =A0 IPv4 packet and then forward it via t= he IPv4
> >> =A0 =A0 =A0 =A0 =A0 =A0 interface.
> >>
> >> I have a few questions here.
> >> 1. How can the BR get from an IPv6 packet the IPv4 source add= ress or the IPv4 source address and the source port in the encapsulated IPv= 4 packet?
> > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above = text is for check the validation of the received packet. In terms of IPv6 p= acket received at BR, the IPv6 source address should be based on the IPv6 p= refix delegated to CE. Also, according to the MAP rule, IPv4 address and po= rt number can be derived from the same delegated IPv6 prefix. So, BR can ca= lculate CE IPv6 address from the IPv4 source address and source port number= in IPv4 packet encapsulated in the received IPv6 packet. If the calculatio= n is failed, then the packet could be dropped. If the calculation is succee= ded but the calculated CE IPv6 address is not matched to the source IPv6 ad= dress in the received IPv6 packet, then the packet could be dropped.
> >
> > [Qi Sun] =A0I have 2 questions here.
> > [Qi Sun] 1.My understanding is that the BR get the IPv4 related i= nfo from the IPv6 packet by reading the specific bits in the IPv6 packet, t= hat is the IPv4 address is put in the exact position in the IPv6 packet. Ri= ght?
> > [Qi Sun] =A02.You said,'If the calculation is failed, then th= e packet could be dropped.' I think this action may cause the data loss= of normal IPv6 flow.
> >
> >> 2. If the received IPv6 packet is a normal one, instead of an= IPv4-encapsulated packet, what will the BR do? =A0That is, dose the BR can= act as a normal router?
> >
> > In this case, BR should handle this IPv6 packet based on the norm= al IPv6 routing because the next header is not IPv4 in this case.
> >
> > [Qi Sun] Agree :)
> >> 3. What can cause the inequality between the derived CE IPv6 = address and the IPv6 source address in the received IPv6 packet? And what w= ill BR do with it, discard it ?
> >
> > It might depend on the implementation. But the derived CE IPv6 ad= dress must be same as the IPv6 source address in case of MAP-E because the = derived CE IPv6 address should be the tunnel end-point address on the CE. S= o, the received packet should be discarded or not processed as MAP-E packet= .
> >
> > [Qi Sun] =A0You mean, in the MAP-E case, the inequality won't= happen, right?
> >
> > My question is that whether the MAP-E nodes can be deployed with = the normal IPv6 nodes. If can't, won't it cost too much to deploy b= rand new MAP-E domains for SP? If can, is it possible to be stated in the d= raft, with the considerations of BR handling non-MAP-E IPv6 packets ?
>
> MAP-E is no different than any other tunnel in this regard. MAP-E pack= ets are terminated at a single IPv6 address on the BR. all other IPv6 traff= ic will be forwarded like normal. i.e. traffic with a destination address n= ot being the BR's MAP-E IPv6 address.
>

What is the expected behavior when that address becomes unavailable?

Cb

> cheers,
> Ole
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--047d7b33d868049e1f04ba30714a-- From cb.list6@gmail.com Thu Mar 1 08:14:20 2012 Return-Path: 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 0242921E8229 for ; Thu, 1 Mar 2012 08:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] 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 sLGUfM3lY2zq for ; Thu, 1 Mar 2012 08:14:19 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA16B21E8227 for ; Thu, 1 Mar 2012 08:14:17 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so1088397pbc.31 for ; Thu, 01 Mar 2012 08:14:17 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.229.104 as permitted sender) client-ip=10.68.229.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.229.104 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.229.104]) by 10.68.229.104 with SMTP id sp8mr4493710pbc.8.1330618457707 (num_hops = 1); Thu, 01 Mar 2012 08:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/0RwIki8FSwIHntdCzNYMvcZBNdbtPAZKVVx9kzOkXY=; b=u/LPvAwqJOCLPTLeevH+3Y2zJ2oFQCWMh8QWRtqdvoeZWcvLYedsNKntgO8JUqhWmV YVgwhut5geOskZp6eYkK0baZC/z0B9JDiZeWu83PbIBZEdn5A7NuC1ZVYEFyTBdG4+7G DfBQCXUnc64LDd+QI5rPZ3+m/0KJAIK2RpR58= MIME-Version: 1.0 Received: by 10.68.229.104 with SMTP id sp8mr3787719pbc.8.1330618457542; Thu, 01 Mar 2012 08:14:17 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 1 Mar 2012 08:14:17 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 1 Mar 2012 08:14:17 -0800 (PST) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr> <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net> <941C4201-CC42-4E27-A1E1-7E3970FC6F77@laposte.net> Date: Thu, 1 Mar 2012 08:14:17 -0800 Message-ID: From: Cameron Byrne To: liu dapeng Content-Type: multipart/alternative; boundary=e89a8ffba9b77e4ffe04ba30c040 Cc: Softwires WG , Softwire Chairs Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:14:20 -0000 --e89a8ffba9b77e4ffe04ba30c040 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mar 1, 2012 6:56 AM, "liu dapeng" wrote: > > 2012/2/29, R=E9mi Despr=E9s : > > > > Le 2012-02-29 =E0 10:53, liu dapeng a =E9crit : > > > >> 2012/2/28, R=E9mi Despr=E9s : > >>> > >>> 2012-02-28 15:06, liu dapeng : > >>> ... > >>>> 2012/2/27, R=E9mi Despr=E9s : > >>> ... > >>>>> The draft only reflects the wish of an number of operators to have = a > >>>>> stateless solution standardized, acknowledging that this is in addition > >>>>> to > >>>>> the more advanced stateful solutions (it doesn't even include the word > >>>>> "superior"). > >>> ... > >>>> Thanks for the discussion but the fundamental question is: > >>>> > >>>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a > >>>> stateless solution, > >>>> > >>>> then, why [CPE(stateless) + xlate(stateful)] is not a stateless > >>>> solution? > >>> > >>> > >>> What I see as important is that IPv6-only routing can be deployed ASA= P > >>> without sacrificing a good residual IPv4 service, including where ISP= s > >>> prefer per-user stateless operation. > >>> > >>> The point has already been made that functions are defined in the draft > >>> as > >>> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state. > >>> A CE can therefore be considered stateless *in the draft* even if it has > >>> NAT44 (a function that is purely IPv4, and whose statefulness is per > >>> session). > >>> Because of that, the draft is self consistent an doesn't need to be > >>> modified. > >>> > >>> I do hope that, with these additional explanations, and in order to avoid > >>> waste of energy, you can accept to join a consensus that it is time t= o > >>> close > >>> this discussion and accept the draft. > >>> > >>> > >>> Looking forward to further discussions on solutions themselves, > >>> Regards, > >>> RD > >>> > >> Hello Remi > >> > >> Firstly, this draft will mis-lead other operators thinking that this > >> is a pure stateless solution from the title and the document (maybe > >> terminology such as "Maping" is better). IETF WG should not hurry up > >> without the correct description on what the document is. For my > >> understanding, both of above two solutions are stateful solution. Even > >> in the first case of BR' side there are still stateful information for > >> control plane. > >> > >> Secondly, since this is also stateful solution principally. Then why > >> IETF need to invent a second wheel about the same scenario, > > > > > >> should > >> IETF obsolete previous one such as DS-Lite, then start to work on > >> this? > > > > Surely not. > > This debate has been finished when it was decided that Softwire would work > > ALSO on solutions that are stateless, at least in ISP gateways to the IPv4 > > Internet. > > > > You may have not been personally part of this consensus, which is obviously > > your right, but the consensus remains. > > Since no one prevents you from using stateful solutions of you choice, > > trying to prevent those who want a more stateless solution to have a > > specification isn't, IMHO, fair contribution to standardization. > > > > RD > > It=92s really a bad idea to invent two wheels for the same scenario. > This is not IETF=92s spirit, It=92s a disaster for =93One Internet=94. > The internet is a very diverse place. In fact, most networks that make up the internet are very unique. For this reason, there must be multiple solutions. It would be very unfortunate for the ietf to say there will be only one solution to the ipv4 to ipv6 transition. In fact, the ietf tried this for 10 years by saying dual stack is the ONE solution, and it is an embarrassing failure for all involved. Hopefully, the ietf has learned from this failure which has resulted in layers of NAT and other painful side effects....including both stateful and stateless solutions in equal part. The ietf must not slow progress on moving towards ipv6 transition, and this explicitly means vetting all possible solutions that may support the cause of meaningful ipv6 transition. And as always, we believe in running code. Cb > I guess that it has been quite clear that this is not a =93stateless=94, > whatever state is more or less, the current terminology is > mis-leading.If you want, then maybe =93Mapping=94 is much better. > > IETF consensus has to happen multiple times during the process of the document. > > -Dapeng > > > > >> > >> Thanks > >> > >> -Dapeng > >> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --e89a8ffba9b77e4ffe04ba30c040 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mar 1, 2012 6:56 AM, "liu dapeng" <maxpassion@gmail.com> wrote:
>
> 2012/2/29, R=E9mi Despr=E9s <despres.remi@laposte.net>:
> >
> > Le 2012-02-29 =E0 10:53, liu dapeng a =E9crit :
> >
> >> 2012/2/28, R=E9mi Despr=E9s <despres.remi@laposte.net>:
> >>>
> >>> 2012-02-28 15:06, liu dapeng :
> >>> ...
> >>>> 2012/2/27, R=E9mi Despr=E9s <despres.remi@laposte.net>:
> >>> ...
> >>>>> The draft only reflects the wish of an number of = operators to have a
> >>>>> stateless solution standardized, acknowledging th= at this is in addition
> >>>>> to
> >>>>> the more advanced stateful solutions (it doesn= 9;t even include the word
> >>>>> "superior").
> >>> ...
> >>>> Thanks for the discussion but the fundamental questio= n is:
> >>>>
> >>>> If we consider [CPE(stateful) + BR(partially stateles= s maybe)] as a
> >>>> stateless solution,
> >>>>
> >>>> then, why =A0[CPE(stateless) + xlate(stateful)] is no= t a stateless
> >>>> solution?
> >>>
> >>>
> >>> What I see as important is that IPv6-only routing can be = deployed ASAP
> >>> without sacrificing a good residual IPv4 service, includi= ng where ISPs
> >>> prefer per-user stateless operation.
> >>>
> >>> The point has already been made that functions are define= d in the draft
> >>> as
> >>> "stateless" if they don't need (for IPv4 ov= er IPv6) any "per-user" state.
> >>> A CE can therefore be considered stateless *in the draft*= even if it has
> >>> NAT44 (a function that is purely IPv4, and whose stateful= ness is per
> >>> session).
> >>> Because of that, the draft is self consistent an doesn= 9;t need to be
> >>> modified.
> >>>
> >>> I do hope that, with these additional explanations, and i= n order to avoid
> >>> waste of energy, you can accept to join a consensus that = it is time to
> >>> close
> >>> this discussion and accept the draft.
> >>>
> >>>
> >>> Looking forward to further discussions on solutions thems= elves,
> >>> Regards,
> >>> RD
> >>>
> >> Hello Remi
> >>
> >> Firstly, this draft will mis-lead other operators thinking th= at this
> >> is a pure stateless solution from the title and the document = (maybe
> >> terminology such as "Maping" is better). IETF WG sh= ould not hurry up
> >> without the correct description on what the document is. For = my
> >> understanding, both of above two solutions are stateful solut= ion. Even
> >> in the first case of BR' side there are still stateful in= formation for
> >> control plane.
> >>
> >> Secondly, since this is also stateful solution principally. T= hen why
> >> IETF need to invent a second wheel about the same scenario, > >
> >
> >> should
> >> IETF obsolete previous one such as DS-Lite, then start to wor= k on
> >> this?
> >
> > Surely not.
> > This debate has been finished when it was decided that Softwire w= ould work
> > ALSO on solutions that are stateless, at least in ISP gateways to= the IPv4
> > Internet.
> >
> > You may have not been personally part of this consensus, which is= obviously
> > your right, but the consensus remains.
> > Since no one prevents you from using stateful solutions of you ch= oice,
> > trying to prevent those who want a more stateless solution to hav= e a
> > specification isn't, IMHO, fair contribution to standardizati= on.
> >
> > RD
>
> It=92s really a bad idea to invent two wheels for the same scenario. > This is not IETF=92s spirit, It=92s a disaster for =93One Internet=94.=
>

The internet is a very diverse place.=A0 In fact, most networks that mak= e up the internet are very unique.

For this reason, there must be multiple solutions.=A0 It would be very u= nfortunate for the ietf to say there will be only one solution to the ipv4 = to ipv6 transition.

In fact, the ietf tried this for 10 years by saying dual stack is the ON= E solution, and it is an embarrassing failure for all involved.=A0

Hopefully, the ietf has learned from this failure which has resulted in = layers of NAT and other painful side effects....including both stateful and= stateless solutions in equal part.
The ietf must not slow progress on moving towards ipv6 transition, and this= explicitly means vetting all possible solutions that may support the cause= of meaningful ipv6 transition. And as always, we believe in running code. =

Cb
> I guess that it has been quite clear that this is not a =93stateless= =94,
> whatever state is more or less, the current terminology is
> mis-leading.If you want, then maybe =93Mapping=94 is much better.
>
> IETF consensus has =A0to happen multiple times during the process of t= he document.
>
> -Dapeng
>
>
>
> >>
> >> Thanks
> >>
> >> -Dapeng
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>
> --
>
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--e89a8ffba9b77e4ffe04ba30c040-- From ichiroumakino@gmail.com Thu Mar 1 09:02:55 2012 Return-Path: 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 04CF921F89A7 for ; Thu, 1 Mar 2012 09:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 zJh3s7fL0QiN for ; Thu, 1 Mar 2012 09:02:49 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF23321F8935 for ; Thu, 1 Mar 2012 09:02:47 -0800 (PST) Received: by wicr5 with SMTP id r5so118272wic.31 for ; Thu, 01 Mar 2012 09:02:47 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.134.136 as permitted sender) client-ip=10.216.134.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.134.136 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.216.134.136]) by 10.216.134.136 with SMTP id s8mr3289892wei.6.1330621367055 (num_hops = 1); Thu, 01 Mar 2012 09:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vA5aynVcHODkQu+ma0bX9EwBaO8/tLVs27g7JdexzfI=; b=kvPXdAAkUa9pKPf2la9V8NcH+GZmtck0k3x215Yby+D+07LlRVfpW2U1F2OL5oRCNe U0WsU90skq1Q3H+jduF1a3ct9F/Z7pzTayIlid9nzTth66XlRhHTIPxjx9hSR46joQS8 TetmhS4bWIl06HC144p4B5Xt5tZaWecI8mXjc= Received: by 10.216.134.136 with SMTP id s8mr2649577wei.6.1330621366935; Thu, 01 Mar 2012 09:02:46 -0800 (PST) Received: from dhcp-10-61-99-57.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id m16sm12346187wie.9.2012.03.01.09.02.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 09:02:45 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 1 Mar 2012 18:02:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:02:55 -0000 > What is the expected behavior when that address becomes unavailable? reliability is achieved through anycast. there are multiple BRs = advertising the same address into the IGP. did that address your question? cheers, Ole= From cb.list6@gmail.com Thu Mar 1 10:28:56 2012 Return-Path: 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 477EC21E8116 for ; Thu, 1 Mar 2012 10:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 fIEY9MS89Im9 for ; Thu, 1 Mar 2012 10:28:55 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C109D21E815A for ; Thu, 1 Mar 2012 10:28:55 -0800 (PST) Received: by dakl33 with SMTP id l33so1245685dak.31 for ; Thu, 01 Mar 2012 10:28:55 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.229.104 as permitted sender) client-ip=10.68.229.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.229.104 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.229.104]) by 10.68.229.104 with SMTP id sp8mr5918060pbc.8.1330626535663 (num_hops = 1); Thu, 01 Mar 2012 10:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1QxiXxHPwktjTtEtntbjbzgHSO96sjo4C/RQUgqrXo8=; b=fYLIp3WjK+owK4hK0MNpEhG6JKSPwLVinEIR3p7GPFuLIoF+PN6fINWAVEDm2IwjQy RuFJqY6tSdZGxA4cTfoFnsMVGHPgDadLtLfColEoPPfLhpVycTUc4A2kbf/7zCFJLZkg LNg7Umnsoq+D7zDJeAGoEzGanNUs/KJzfUtqU= MIME-Version: 1.0 Received: by 10.68.229.104 with SMTP id sp8mr4915844pbc.8.1330626535554; Thu, 01 Mar 2012 10:28:55 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 1 Mar 2012 10:28:55 -0800 (PST) In-Reply-To: <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> Date: Thu, 1 Mar 2012 10:28:55 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:28:56 -0000 On Thu, Mar 1, 2012 at 9:02 AM, Ole Tr=F8an wrote: >> What is the expected behavior when that address becomes unavailable? > > reliability is achieved through anycast. there are multiple BRs advertisi= ng the same address into the IGP. > did that address your question? > Sorry, i have not really been able to find this out on my own. But, i thought there was tight coupling of the BR address resources and CPE address assignments. Meaning BR1 has for me (the subscriber) the public address 1.1.1.1 with ports 2000-3000 and that is communicated to CPE1 BR1 goes has a fault, goes off line. BR2 is now the closest anycast path to CPE1 My CPE is sending packets to BR2 (as anycast) assuming BR2 owns 1.1.1.1 and port set 2000-3000. But, how does BR2 know anything about 1.1.1.1? Does BR2 now announce in BGP to the world it owns 1.1.1.1? Is that going to work? If so, where is it documented? Or, does the CPE have to reboot and get some new config assignment based on BR2 now being the closest? How does this oscillating load (BR failure, shortest path changes, ... ) associated with anycast bode for the IPv4 address reserves ? Seems like the public IPv4 address pool on each BR would have to be over-provisioned to handle some N*X level of load. Sorry if i am missing something obvious. Cameron From ichiroumakino@gmail.com Thu Mar 1 11:43:42 2012 Return-Path: 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 2521521F8B11 for ; Thu, 1 Mar 2012 11:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Zoo7tOuCTevH for ; Thu, 1 Mar 2012 11:43:41 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D923421F86F2 for ; Thu, 1 Mar 2012 11:43:38 -0800 (PST) Received: by wicr5 with SMTP id r5so238651wic.31 for ; Thu, 01 Mar 2012 11:43:38 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.135.199 as permitted sender) client-ip=10.216.135.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.135.199 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.216.135.199]) by 10.216.135.199 with SMTP id u49mr3547004wei.7.1330631018167 (num_hops = 1); Thu, 01 Mar 2012 11:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dKx14ZLItP3S6J+/3jpA5twhqkHKvxbkuuKCT/iEFmw=; b=n79VWY9tNja5/kRYXYr5SNUPqzH5vT0Jyfs1bHJW6wrQuN8C6qNVphWBGBcSryPVNi is+8xM07JE4G0l80dth1fVn0qsLvjwcKNRmmPVkFj6ylYNjmE3a+WAldyHpYDCLnLNcx YfHaSfIABJBetEjd+aT71Ea2KB73rzslYTknsT473wHBMhKGKnzREd8yZnk5xt+/kJtA qWbC4Ir8LqcdfWc5/l7HJhpYmi+w9+N+yHsH45Bt/ticmOLPsxABGH8b52Ta5gHwFO2w Ju8FkAvRM+UPHCSbOm04mqJG1MTHBZMHDsf5DDpB7JWhf4bJHpjS4jkMdVaJKXGPyUSO QtLA== Received: by 10.216.135.199 with SMTP id u49mr2850127wei.7.1330631018072; Thu, 01 Mar 2012 11:43:38 -0800 (PST) Received: from dhcp-10-61-99-57.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id hb10sm14446570wib.10.2012.03.01.11.43.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 11:43:37 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 1 Mar 2012 20:43:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 19:43:42 -0000 Cameron, >>> What is the expected behavior when that address becomes unavailable? >>=20 >> reliability is achieved through anycast. there are multiple BRs = advertising the same address into the IGP. >> did that address your question? >>=20 >=20 > Sorry, i have not really been able to find this out on my own. >=20 > But, i thought there was tight coupling of the BR address resources > and CPE address assignments. >=20 > Meaning BR1 has for me (the subscriber) the public address 1.1.1.1 > with ports 2000-3000 and that is communicated to CPE1 >=20 > BR1 goes has a fault, goes off line. >=20 > BR2 is now the closest anycast path to CPE1 >=20 > My CPE is sending packets to BR2 (as anycast) assuming BR2 owns > 1.1.1.1 and port set 2000-3000. the BR doesn't really have any port sets, although it could. the anycast address is an IPv6 address. >=20 > But, how does BR2 know anything about 1.1.1.1? Does BR2 now announce > in BGP to the world it owns 1.1.1.1? >=20 > Is that going to work? If so, where is it documented? >=20 > Or, does the CPE have to reboot and get some new config assignment > based on BR2 now being the closest? >=20 > How does this oscillating load (BR failure, shortest path changes, ... > ) associated with anycast bode for the IPv4 address reserves ? Seems > like the public IPv4 address pool on each BR would have to be > over-provisioned to handle some N*X level of load. >=20 > Sorry if i am missing something obvious. sounds like we need to make this a little clearer in the draft. it isn't quite like you describe. the BR is used for out of domain traffic. other traffic is 'on-link'. e.g. the CE has a default route: 0.0.0.0/0 -> 2001::1, MAP0. 2001::1 is advertised from every BR. cheers, Ole From tetsuya@ipinfusion.com Thu Mar 1 20:42:41 2012 Return-Path: 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 D54A021E80A1 for ; Thu, 1 Mar 2012 20:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 n9nlH0IL0+Vu for ; Thu, 1 Mar 2012 20:42:41 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E63E021E8032 for ; Thu, 1 Mar 2012 20:42:40 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so1749871pbc.31 for ; Thu, 01 Mar 2012 20:42:40 -0800 (PST) Received-SPF: pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.217.65 as permitted sender) client-ip=10.68.217.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.217.65 as permitted sender) smtp.mail=tetsuya@ipinfusion.com Received: from mr.google.com ([10.68.217.65]) by 10.68.217.65 with SMTP id ow1mr8625432pbc.144.1330663360522 (num_hops = 1); Thu, 01 Mar 2012 20:42:40 -0800 (PST) Received: by 10.68.217.65 with SMTP id ow1mr7071270pbc.144.1330663360433; Thu, 01 Mar 2012 20:42:40 -0800 (PST) Received: from [192.168.0.6] (c-76-102-170-31.hsd1.ca.comcast.net. [76.102.170.31]) by mx.google.com with ESMTPS id l1sm3921321pbe.54.2012.03.01.20.42.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 20:42:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A3FE05E-5F93-4939-B19F-6A0CF92DCB21" From: Tetsuya Murakami X-Priority: 3 In-Reply-To: <2012030117154299898339@gmail.com> Date: Thu, 1 Mar 2012 20:42:35 -0800 Message-Id: <61A74B41-80C3-423F-9E69-09296DA579F2@ipinfusion.com> References: <2012022917183726704470@gmail.com>, <2012030117154299898339@gmail.com> To: sunqi.csnet.thu X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmGXhQ8vnEl6fg8Wj5FFuZDbhQ4QoNjQAJZ4Z3z2uLUSuKsUzwHdB1fCVgEiZpOJvR/flpx Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 04:42:41 -0000 --Apple-Mail=_0A3FE05E-5F93-4939-B19F-6A0CF92DCB21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Qi, > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text = is for check the validation of the received packet. In terms of IPv6 = packet received at BR, the IPv6 source address should be based on the = IPv6 prefix delegated to CE. Also, according to the MAP rule, IPv4 = address and port number can be derived from the same delegated IPv6 = prefix. So, BR can calculate CE IPv6 address from the IPv4 source = address and source port number in IPv4 packet encapsulated in the = received IPv6 packet. If the calculation is failed, then the packet = could be dropped. If the calculation is succeeded but the calculated CE = IPv6 address is not matched to the source IPv6 address in the received = IPv6 packet, then the packet could be dropped. >=20 > [Qi Sun] I have 2 questions here. > [Qi Sun] 1.My understanding is that the BR get the IPv4 related info = from the IPv6 packet by reading the specific bits in the IPv6 packet, = that is the IPv4 address is put in the exact position in the IPv6 = packet. Right? > [Qi Sun] 2.You said,'If the calculation is failed, then the packet = could be dropped.' I think this action may cause the data loss of normal = IPv6 flow. EA-bits can be gotten from IPv6 prefix. In case of MAP-E, it is based on = the encapsulation. Similar to other tunnel, IPv4 packet is encapsulated = in IPv6. As Ole mentioned, there is no difference than any other tunnel. Only if = the IPv6 packet can be terminated at a tunnel end-point address, the = packet can be processed as MAP-E packet. In other cases, the IPv6 packet = can be processed normally. If the IPv6 packet is terminated at the tunnel end-point address, the = packet can be processed as MAP-E packet. At this time, if the = encapsulated IPv4 packet has invalid address as its source address, it = could be a invalid MAP-E packet. >> 2. If the received IPv6 packet is a normal one, instead of an = IPv4-encapsulated packet, what will the BR do? That is, dose the BR can = act as a normal router? >=20 > In this case, BR should handle this IPv6 packet based on the normal = IPv6 routing because the next header is not IPv4 in this case. >=20 > [Qi Sun] Agree :) >> 3. What can cause the inequality between the derived CE IPv6 address = and the IPv6 source address in the received IPv6 packet? And what will = BR do with it, discard it ? >=20 > It might depend on the implementation. But the derived CE IPv6 address = must be same as the IPv6 source address in case of MAP-E because the = derived CE IPv6 address should be the tunnel end-point address on the = CE. So, the received packet should be discarded or not processed as = MAP-E packet. >=20 > [Qi Sun] You mean, in the MAP-E case, the inequality won't happen, = right?=20 >=20 > My question is that whether the MAP-E nodes can be deployed with the = normal IPv6 nodes. If can't, won't it cost too much to deploy brand new = MAP-E domains for SP? If can, is it possible to be stated in the draft, = with the considerations of BR handling non-MAP-E IPv6 packets ? As Ole mentioned, if the IPv6 packet can not be terminated at the tunnel = end-point address of MAP-E, this packet can be processed as the normal = IPv6 packet. Thanks, Tetsuya Murakami= --Apple-Mail=_0A3FE05E-5F93-4939-B19F-6A0CF92DCB21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Qi,

In case of MAP-E, IPv4 packet is = encapsulated in IPv6. The above text is for check the validation of the = received packet. In terms of IPv6 packet received at BR, the IPv6 source = address should be based on the IPv6 prefix delegated to CE. Also, = according to the MAP rule, IPv4 address and port number can be derived = from the same delegated IPv6 prefix. So, BR can calculate CE IPv6 = address from the IPv4 source address and source port number in IPv4 = packet encapsulated in the received IPv6 packet. If the calculation is = failed, then the packet could be dropped. If the calculation is = succeeded but the calculated CE IPv6 address is not matched to the = source IPv6 address in the received IPv6 packet, then the packet could = be dropped.

[Qi = Sun]  I have 2 questions = here.
[Qi = Sun] 1.My understanding is that the BR get the IPv4 = related info from the IPv6 packet by reading the specific bits in = the IPv6 packet, that is the IPv4 address is put in the exact position = in the IPv6 packet. Right?
[Qi Sun]  2.You said,'If the = calculation is failed, then the packet could be dropped.' I = think this action may cause the data loss of normal IPv6 = flow.
<= div>
EA-bits can be gotten from IPv6 prefix. In case of = MAP-E, it is based on the encapsulation. Similar to other tunnel, IPv4 = packet is encapsulated in IPv6.

As Ole = mentioned, there is no difference than any other tunnel. Only if the = IPv6 packet can be terminated at a tunnel end-point address, the packet = can be processed as MAP-E packet. In other cases, the IPv6 packet can be = processed normally.

If the IPv6 packet is = terminated at the tunnel end-point address, the packet can be processed = as MAP-E packet. At this time, if the encapsulated IPv4 packet has = invalid address as its source address, it could be a invalid MAP-E = packet.

2. If the = received IPv6 packet is a normal one, instead of an IPv4-encapsulated = packet, what will the BR do?  That is, dose the BR can act as a = normal = router?

In this = case, BR should handle this IPv6 packet based on the normal IPv6 routing = because the next header is not IPv4 in this case.

[Qi Sun] Agree = :)
3. What can = cause the inequality between the derived CE IPv6 address and the IPv6 = source address in the received IPv6 packet? And what will BR do with it, = discard it ?

It = might depend on the implementation. But the derived CE IPv6 address must = be same as the IPv6 source address in case of MAP-E because the derived = CE IPv6 address should be the tunnel end-point address on the CE. So, = the received packet should be discarded or not processed as MAP-E = packet.

[Qi = Sun]  You mean, in the MAP-E case, the inequality won't = happen, right? 

My question is that = whether the MAP-E nodes can be deployed with the normal IPv6 nodes. If = can't, won't it cost too much to deploy brand new MAP-E domains for SP? = If can, is it possible to be stated in the draft, with the = considerations of BR handling non-MAP-E IPv6 packets = ?

As Ole mentioned, if the IPv6 packet can not = be terminated at the tunnel end-point address of MAP-E, this packet can = be processed as the normal IPv6 = packet.

Thanks,
Tetsuya = Murakami
= --Apple-Mail=_0A3FE05E-5F93-4939-B19F-6A0CF92DCB21-- From sunqi.csnet.thu@gmail.com Fri Mar 2 00:52:19 2012 Return-Path: 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 D4BFD21F8C65 for ; Fri, 2 Mar 2012 00:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 fFgFRiy69cLP for ; Fri, 2 Mar 2012 00:52:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0330821F8C64 for ; Fri, 2 Mar 2012 00:52:18 -0800 (PST) Received: by iazz13 with SMTP id z13so2350645iaz.31 for ; Fri, 02 Mar 2012 00:52:18 -0800 (PST) Received-SPF: pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.77.170 as permitted sender) client-ip=10.50.77.170; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.77.170 as permitted sender) smtp.mail=sunqi.csnet.thu@gmail.com; dkim=pass header.i=sunqi.csnet.thu@gmail.com Received: from mr.google.com ([10.50.77.170]) by 10.50.77.170 with SMTP id t10mr1021179igw.35.1330678338564 (num_hops = 1); Fri, 02 Mar 2012 00:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=wUbJZBHB6OialWMDsHvs1tskpBiqtQCDJfV/F5CmUf8=; b=UsB82wnUw4q8yer6mvKZFOur/HbF1fSgyH0CGRN0/zPy2Re0pz36tRbrXc5CpmZ+dr Q6f1c1nQB1Y5ZYLheJr9Xqi2E/TD60bm1mEFh9IXsp8gSSyZgWVrEeE0EyUGnAHy8e17 xwqHE+xCdpg+evRloxjkpt8dj/tVTLkFYC25LEW5YRTejT4qEuTEQSQeL9s9oSgrTrIl AzxJYNzjTJObDJ5uD5eRuFGFdeuO5esBY41ZnJ0E7vHuuluCDqSo0FBJfuGMkrdYJx1B IYkyrrIRvfrbI7zcRx1TCx/QKWYC55NO1IbrG0lu/2pMxqFQIQRO2VGIBLMBMa7htu62 A6Vg== Received: by 10.50.77.170 with SMTP id t10mr836542igw.35.1330678338520; Fri, 02 Mar 2012 00:52:18 -0800 (PST) Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id s3sm1248134igw.17.2012.03.02.00.52.14 (version=SSLv3 cipher=OTHER); Fri, 02 Mar 2012 00:52:17 -0800 (PST) Date: Fri, 2 Mar 2012 16:52:07 +0800 From: "Qi Sun" To: =?utf-8?B?T2xlIFRy6bSEbg==?= References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> , X-Priority: 3 X-GUID: F53AD090-936E-4535-ADA6-9A7CD497FA2F X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012030216520770474620@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart413286050771_=----" Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 08:52:19 -0000 This is a multi-part message in MIME format. ------=_001_NextPart413286050771_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQogICAgVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5fg0KICAgIEhlcmUgaXMgbXkgdW5kZXJz dGFuZGluZyBhbmQgaSdtIG5vdCBzdXJlIGlmIGl0J3MgcmlnaHQuDQogICAgV2hlbiBCUjEgaXMg ZG93biBhbmQgdGhlIElQdjQtZW5jYXBzdWxhdGVkIHBhY2tldCBjb21lcyB0byBCUjIsIEJSMiBj YW4gaGFuZGxlIHRoZSBwYWNrZXQgcHJvcGVybHkgdXNpbmcgdGhlIHNhbWUgTUFQIHJ1bGVzIHdp dGggQ0UxIGJlY2F1c2UgdGhleSBhcmUgaW4gdGhlIHNhbWUgZG9tYWluLiBCUjIgZG9lc24ndCBo YXZlIHRvIGhhbmRsZSB0aGUgc291cmNlIElQdjQgYWRkcmVzcywgc2F5aW5nIDEuMS4xLjEuIFJp Z2h0Pw0KDQogICBMb29raW5nIGZvcndhcmQgdG8gdXIgcmVwbHl+DQoNCkJlc3QgUmVnYXJkcywN Cg0KDQoNCg0KUWkgU3VuDQoNCkZyb206IE9sZSBUcum0hG4NCkRhdGU6IDIwMTItMDMtMDIgMDM6 NDMNClRvOiBDYW1lcm9uIEJ5cm5lDQpDQzogc29mdHdpcmVzIFdHOyBzdW5xaS5jc25ldC50aHUN ClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBDb21tZW50cyBvbiBNQVAtRSBkcmFmdA0KQ2FtZXJv biwNCg0KPj4+IFdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIHdoZW4gdGhhdCBhZGRyZXNz IGJlY29tZXMgdW5hdmFpbGFibGU/DQo+PiANCj4+IHJlbGlhYmlsaXR5IGlzIGFjaGlldmVkIHRo cm91Z2ggYW55Y2FzdC4gdGhlcmUgYXJlIG11bHRpcGxlIEJScyBhZHZlcnRpc2luZyB0aGUgc2Ft ZSBhZGRyZXNzIGludG8gdGhlIElHUC4NCj4+IGRpZCB0aGF0IGFkZHJlc3MgeW91ciBxdWVzdGlv bj8NCj4+IA0KPiANCj4gU29ycnksIGkgaGF2ZSBub3QgcmVhbGx5IGJlZW4gYWJsZSB0byBmaW5k IHRoaXMgb3V0IG9uIG15IG93bi4NCj4gDQo+IEJ1dCwgaSB0aG91Z2h0IHRoZXJlIHdhcyB0aWdo dCBjb3VwbGluZyBvZiB0aGUgQlIgYWRkcmVzcyByZXNvdXJjZXMNCj4gYW5kIENQRSBhZGRyZXNz IGFzc2lnbm1lbnRzLg0KPiANCj4gTWVhbmluZyBCUjEgaGFzIGZvciBtZSAodGhlIHN1YnNjcmli ZXIpIHRoZSBwdWJsaWMgYWRkcmVzcyAxLjEuMS4xDQo+IHdpdGggcG9ydHMgMjAwMC0zMDAwIGFu ZCB0aGF0IGlzIGNvbW11bmljYXRlZCB0byBDUEUxDQo+IA0KPiBCUjEgZ29lcyBoYXMgYSBmYXVs dCwgZ29lcyBvZmYgbGluZS4NCj4gDQo+IEJSMiBpcyBub3cgdGhlIGNsb3Nlc3QgYW55Y2FzdCBw YXRoIHRvIENQRTENCj4gDQo+IE15IENQRSBpcyBzZW5kaW5nIHBhY2tldHMgdG8gQlIyIChhcyBh bnljYXN0KSBhc3N1bWluZyBCUjIgb3ducw0KPiAxLjEuMS4xIGFuZCBwb3J0IHNldCAyMDAwLTMw MDAuDQoNCnRoZSBCUiBkb2Vzbid0IHJlYWxseSBoYXZlIGFueSBwb3J0IHNldHMsIGFsdGhvdWdo IGl0IGNvdWxkLg0KdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBhbiBJUHY2IGFkZHJlc3MuDQoNCj4g DQo+IEJ1dCwgaG93IGRvZXMgQlIyIGtub3cgYW55dGhpbmcgYWJvdXQgMS4xLjEuMT8gIERvZXMg QlIyIG5vdyBhbm5vdW5jZQ0KPiBpbiBCR1AgdG8gdGhlIHdvcmxkIGl0IG93bnMgMS4xLjEuMT8N Cj4gDQo+IElzIHRoYXQgZ29pbmcgdG8gd29yaz8gIElmIHNvLCB3aGVyZSBpcyBpdCBkb2N1bWVu dGVkPw0KPiANCj4gT3IsIGRvZXMgdGhlIENQRSBoYXZlIHRvIHJlYm9vdCBhbmQgZ2V0IHNvbWUg bmV3IGNvbmZpZyBhc3NpZ25tZW50DQo+IGJhc2VkIG9uIEJSMiBub3cgYmVpbmcgdGhlIGNsb3Nl c3Q/DQo+IA0KPiBIb3cgZG9lcyB0aGlzIG9zY2lsbGF0aW5nIGxvYWQgKEJSIGZhaWx1cmUsIHNo b3J0ZXN0IHBhdGggY2hhbmdlcywgLi4uDQo+ICkgYXNzb2NpYXRlZCB3aXRoIGFueWNhc3QgYm9k ZSBmb3IgdGhlIElQdjQgYWRkcmVzcyByZXNlcnZlcyA/ICBTZWVtcw0KPiBsaWtlIHRoZSBwdWJs aWMgSVB2NCBhZGRyZXNzIHBvb2wgb24gZWFjaCBCUiB3b3VsZCBoYXZlIHRvIGJlDQo+IG92ZXIt cHJvdmlzaW9uZWQgdG8gaGFuZGxlIHNvbWUgTipYIGxldmVsIG9mIGxvYWQuDQo+IA0KPiBTb3Jy eSBpZiBpIGFtIG1pc3Npbmcgc29tZXRoaW5nIG9idmlvdXMuDQoNCnNvdW5kcyBsaWtlIHdlIG5l ZWQgdG8gbWFrZSB0aGlzIGEgbGl0dGxlIGNsZWFyZXIgaW4gdGhlIGRyYWZ0Lg0KDQppdCBpc24n dCBxdWl0ZSBsaWtlIHlvdSBkZXNjcmliZS4NCnRoZSBCUiBpcyB1c2VkIGZvciBvdXQgb2YgZG9t YWluIHRyYWZmaWMuDQpvdGhlciB0cmFmZmljIGlzICdvbi1saW5rJy4NCg0KZS5nLiB0aGUgQ0Ug aGFzIGEgZGVmYXVsdCByb3V0ZToNCjAuMC4wLjAvMCAtPiAyMDAxOjoxLCBNQVAwLg0KDQoyMDAx OjoxIGlzIGFkdmVydGlzZWQgZnJvbSBldmVyeSBCUi4NCg0KY2hlZXJzLA0KT2xl ------=_001_NextPart413286050771_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,
    Thank you for your reply~
    Here is my understanding and i'm not sure if = it's=20 right.
    When BR1 is down and the IPv4-encapsulated packet = comes=20 to BR2, BR2 can handle the packet properly using the same MAP rules with C= E1=20 because they are in the same domain. BR2 doesn't have to handle the s= ource=20 IPv4 address, saying 1.1.1.1. Right?
 
   Looking forward to ur reply~
 
Best Regards,
 
Qi Sun<= /DIV>
 
Date: 2012-03-02 03:43
Subject: Re: [Softwires] Comments on MAP-E=20 draft
Cameron,
 
>>> What is the expected behavior&n= bsp;when that address becomes unavailable?
>> 
>> reliability is achieved through any= cast. there are multiple BRs advertising the=  same address into the IGP.
>> did that address your question?
>> 
> 
> Sorry, i have not really been = ;able to find this out on my own.
> 
> But, i thought there was tight&nbs= p;coupling of the BR address resources
> and CPE address assignments.
> 
> Meaning BR1 has for me (the s= ubscriber) the public address 1.1.1.1
> with ports 2000-3000 and that is&n= bsp;communicated to CPE1
> 
> BR1 goes has a fault, goes of= f line.
> 
> BR2 is now the closest anycast&nbs= p;path to CPE1
> 
> My CPE is sending packets to = BR2 (as anycast) assuming BR2 owns
> 1.1.1.1 and port set 2000-3000.
 
the BR doesn't really have any port&nbs= p;sets, although it could.
the anycast address is an IPv6 address.=
 
> 
> But, how does BR2 know anything&nb= sp;about 1.1.1.1?  Does BR2 now announce
> in BGP to the world it owns&n= bsp;1.1.1.1?
> 
> Is that going to work?  If&nb= sp;so, where is it documented?
> 
> Or, does the CPE have to rebo= ot and get some new config assignment
> based on BR2 now being the cl= osest?
> 
> How does this oscillating load (BR=  failure, shortest path changes, ...
> ) associated with anycast bode for=  the IPv4 address reserves ?  Seems
> like the public IPv4 address pool&= nbsp;on each BR would have to be
> over-provisioned to handle some N*X&nbs= p;level of load.
> 
> Sorry if i am missing something&nb= sp;obvious.
 
sounds like we need to make this a=  little clearer in the draft.
 
it isn't quite like you describe.
the BR is used for out of domain&n= bsp;traffic.
other traffic is 'on-link'.
 
e.g. the CE has a default route:
0.0.0.0/0 -> 2001::1, MAP0.
 
2001::1 is advertised from every BR.
 
cheers,
Ole
 
------=_001_NextPart413286050771_=------ From Tina.Tsou.Zouting@huawei.com Fri Mar 2 07:35:58 2012 Return-Path: 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 86F9421F8671 for ; Fri, 2 Mar 2012 07:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1tGut5+6xLl3 for ; Fri, 2 Mar 2012 07:35:58 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EB21D21F863F for ; Fri, 2 Mar 2012 07:35:57 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0900DCRKNPRK@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 02 Mar 2012 23:35:50 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M09003COKNPP2@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 02 Mar 2012 23:35:49 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHF07044; Fri, 02 Mar 2012 23:35:49 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 23:35:36 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 02 Mar 2012 23:36:30 +0800 Date: Fri, 02 Mar 2012 15:35:37 +0000 From: Tina TSOU X-Originating-IP: [10.212.245.46] To: "softwires@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Port Set Definition Algorithms Analysis Thread-index: AQHM+Iod6SRBB91o0kWXL4mv1Pb6XQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:35:58 -0000 Dear all, You may be interested to comment on http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/ Abstract: This memo analyses some port set definition algorithms which encode port set information into IPv6 address so as to support stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. Tetsuya, Simon and Tina From tetsuya@ipinfusion.com Fri Mar 2 11:28:58 2012 Return-Path: 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 0909221E8050 for ; Fri, 2 Mar 2012 11:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 2u4r+XiO6u3D for ; Fri, 2 Mar 2012 11:28:57 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3521E8048 for ; Fri, 2 Mar 2012 11:28:56 -0800 (PST) Received: by dakl33 with SMTP id l33so2579098dak.31 for ; Fri, 02 Mar 2012 11:28:56 -0800 (PST) Received-SPF: pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.229.67 as permitted sender) client-ip=10.68.229.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.229.67 as permitted sender) smtp.mail=tetsuya@ipinfusion.com Received: from mr.google.com ([10.68.229.67]) by 10.68.229.67 with SMTP id so3mr19775944pbc.163.1330716536668 (num_hops = 1); Fri, 02 Mar 2012 11:28:56 -0800 (PST) Received: by 10.68.229.67 with SMTP id so3mr16469806pbc.163.1330716536322; Fri, 02 Mar 2012 11:28:56 -0800 (PST) Received: from [10.70.2.197] ([12.248.239.142]) by mx.google.com with ESMTPS id u8sm5709977pbr.53.2012.03.02.11.28.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 11:28:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A526F769-4E9B-4762-A101-B41F694409EA" From: Tetsuya Murakami X-Priority: 3 In-Reply-To: <2012030216520770474620@gmail.com> Date: Fri, 2 Mar 2012 11:28:52 -0800 Message-Id: <6FF7F782-2EB5-4A06-9E56-34EE8A0FA011@ipinfusion.com> References: <2012022917183726704470@gmail.com> <2012030117154299898339@gmail.com> <90BF8B4A-BBA6-451C-A5ED-41878A45FC25@employees.org> <4EAAB10C-DBCC-47FE-9B3D-6304ED687701@employees.org> , <2012030216520770474620@gmail.com> To: sunqi.csnet.thu X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkIbXs7ezfUSoAVt3Aj6sEtgsOzDSH9fCX22IB6uTcrrViBi8cwajPAWp9GVxBEwXUB6sOH Cc: softwires WG Subject: Re: [Softwires] Comments on MAP-E draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:28:58 -0000 --Apple-Mail=_A526F769-4E9B-4762-A101-B41F694409EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Qi, BR1 and BR2 have an same IPv6 anycast address. CE can send out BR = anycast IPv6 packet where IPv4 packet is encapsulated. So, when BR1 is = going down, BR2 can receive the packet from CE. =46rom CE perspective, as Ole mentions, CE needs to maintain a default = route toward to MAP in order to forward IPv4 packet over MAP domain. At = CE, IPv4 packet is encapsulated in IPv6 and then IPv6 packet is reached = to BR. If this IPv6 packet is terminated on the tunnel end-point address = at BR, MAP in BR can process this packet. On the other hand, when BR receives IPv4 packet from IPv4 network, BR = needs to forward the IPv4 packet over MAP domain. For this, BR needs to = maintain an IPv4 route corresponding to Rule IPv4 prefix. For example, BR has a following IPv4 route. 1.1.0.0/16 -> MAP0 In the above example, I assume 1.1.0.0/16 is used for Rule IPv4 prefix. Thanks, Tetsuya Murakami On 2012/03/02, at 0:52, Qi Sun wrote: > Hi, > Thank you for your reply~ > Here is my understanding and i'm not sure if it's right. > When BR1 is down and the IPv4-encapsulated packet comes to BR2, = BR2 can handle the packet properly using the same MAP rules with CE1 = because they are in the same domain. BR2 doesn't have to handle the = source IPv4 address, saying 1.1.1.1. Right? > =20 > Looking forward to ur reply~ > =20 > Best Regards, > =20 > Qi Sun > =20 > From: Ole Tr=E9=B4=84n > Date: 2012-03-02 03:43 > To: Cameron Byrne > CC: softwires WG; sunqi.csnet.thu > Subject: Re: [Softwires] Comments on MAP-E draft > Cameron, > =20 > >>> What is the expected behavior when that address becomes = unavailable? > >>=20 > >> reliability is achieved through anycast. there are multiple BRs = advertising the same address into the IGP. > >> did that address your question? > >>=20 > >=20 > > Sorry, i have not really been able to find this out on my own. > >=20 > > But, i thought there was tight coupling of the BR address resources > > and CPE address assignments. > >=20 > > Meaning BR1 has for me (the subscriber) the public address 1.1.1.1 > > with ports 2000-3000 and that is communicated to CPE1 > >=20 > > BR1 goes has a fault, goes off line. > >=20 > > BR2 is now the closest anycast path to CPE1 > >=20 > > My CPE is sending packets to BR2 (as anycast) assuming BR2 owns > > 1.1.1.1 and port set 2000-3000. > =20 > the BR doesn't really have any port sets, although it could. > the anycast address is an IPv6 address. > =20 > >=20 > > But, how does BR2 know anything about 1.1.1.1? Does BR2 now = announce > > in BGP to the world it owns 1.1.1.1? > >=20 > > Is that going to work? If so, where is it documented? > >=20 > > Or, does the CPE have to reboot and get some new config assignment > > based on BR2 now being the closest? > >=20 > > How does this oscillating load (BR failure, shortest path changes, = ... > > ) associated with anycast bode for the IPv4 address reserves ? = Seems > > like the public IPv4 address pool on each BR would have to be > > over-provisioned to handle some N*X level of load. > >=20 > > Sorry if i am missing something obvious. > =20 > sounds like we need to make this a little clearer in the draft. > =20 > it isn't quite like you describe. > the BR is used for out of domain traffic. > other traffic is 'on-link'. > =20 > e.g. the CE has a default route: > 0.0.0.0/0 -> 2001::1, MAP0. > =20 > 2001::1 is advertised from every BR. > =20 > cheers, > Ole > =20 --Apple-Mail=_A526F769-4E9B-4762-A101-B41F694409EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Qi,

BR1 and BR2 have an same = IPv6 anycast address. CE can send out BR anycast IPv6 packet where IPv4 = packet is encapsulated. So, when BR1 is going down, BR2 can receive the = packet from CE.

=46rom CE perspective, as Ole = mentions, CE needs to maintain a default route toward to MAP in order to = forward IPv4 packet over MAP domain. At CE, IPv4 packet is encapsulated = in IPv6 and then IPv6 packet is reached to BR. If this IPv6 packet is = terminated on the tunnel end-point address at BR, MAP in BR can process = this packet.

On the other hand, when BR = receives IPv4 packet from IPv4 network, BR needs to forward the IPv4 = packet over MAP domain. For this, BR needs to maintain an IPv4 route = corresponding to Rule IPv4 prefix. For = example,

BR has a following IPv4 = route.

1.1.0.0/16 -> = MAP0

In the above example, I assume 1.1.0.0/16 = is used for Rule IPv4 = prefix.

Thanks,
Tetsuya = Murakami

On 2012/03/02, at 0:52, Qi Sun = wrote:

Qi = Sun
 
Date: 2012-03-02 03:43
To: Cameron = Byrne
Subject: Re: [Softwires] Comments on MAP-E = draft
Cameron,
 
>&= gt;> What is the expected behavior when&n= bsp;that address becomes unavailable?
>>&nb= sp;
>> reliability is achieved through=  anycast. there are multiple BRs advertising=  the same address into the IGP.
&g= t;> did that address your question?
= >> 
> 
> Sorry, i = ;have not really been able to find this=  out on my own.
> 
>&nb= sp;But, i thought there was tight coupling&n= bsp;of the BR address resources
> an= d CPE address assignments.
> 
&= gt; Meaning BR1 has for me (the subscri= ber) the public address 1.1.1.1
> wi= th ports 2000-3000 and that is communicated&= nbsp;to CPE1
> 
> BR1 goes&n= bsp;has a fault, goes off line.
>&nb= sp;
> BR2 is now the closest an= ycast path to CPE1
> 
> = ;My CPE is sending packets to BR2 (as&n= bsp;anycast) assuming BR2 owns
> 1.1.1.1&= nbsp;and port set 2000-3000.
 
the=  BR doesn't really have any port sets,&= nbsp;although it could.
the anycast address&= nbsp;is an IPv6 address.
 
>&nb= sp;
> But, how does BR2 know an= ything about 1.1.1.1?  Does BR2 now ann= ounce
> in BGP to the world it&= nbsp;owns 1.1.1.1?
> 
> Is t= hat going to work?  If so, where i= s it documented?
> 
> Or,&nb= sp;does the CPE have to reboot and get&= nbsp;some new config assignment
> based&n= bsp;on BR2 now being the closest?
>&= nbsp;
> How does this oscillating lo= ad (BR failure, shortest path changes, ...
> ) associated with anycast bode = ;for the IPv4 address reserves ?  Seems=
> like the public IPv4 address = ;pool on each BR would have to be
=
> over-provisioned to handle some N*X&nbs= p;level of load.
> 
> Sorry&= nbsp;if i am missing something obvious.
 
sounds like we need to make&nbs= p;this a little clearer in the draft.
<= div> 
it isn't quite like you desc= ribe.
the BR is used for out of&nb= sp;domain traffic.
other traffic is 'on-link= '.
 
e.g. the CE has a d= efault route:
0.0.0.0/0 -> 2001::1, MAP0.=
 
2001::1 is advertised from = ;every BR.
 
cheers,
Ole
 

= --Apple-Mail=_A526F769-4E9B-4762-A101-B41F694409EA-- From sarikaya2012@gmail.com Fri Mar 2 11:43:01 2012 Return-Path: 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 11B7C21E8062 for ; Fri, 2 Mar 2012 11:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FRqr2XBv3tdq for ; Fri, 2 Mar 2012 11:43:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8721E8058 for ; Fri, 2 Mar 2012 11:42:56 -0800 (PST) Received: by yenm5 with SMTP id m5so1088872yen.31 for ; Fri, 02 Mar 2012 11:42:55 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.173.132 as permitted sender) client-ip=10.236.173.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.173.132 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.173.132]) by 10.236.173.132 with SMTP id v4mr15472126yhl.78.1330717375955 (num_hops = 1); Fri, 02 Mar 2012 11:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=aNMi4lYS0aw9kYoNUCCxto15I7VwbcLiZBZjiynv7K0=; b=sEdQV5DJ9hKh7QDS7XljCZuD3w1gCKFoizGOO1rhTl3HEz1KFYYVr1349HQDg6A1oJ DHHcJJf6UwsoUcMNxXBx68BGRvuxvEDzRhhOTvB49pkuXgQaP+CVi7INBMK6saPA9H66 E/BcCNjWDdeQTw+bXzAHouPhV6+FwYmre+djmNEWarC5qw/THA5zZs/Lp4/0BOqYpX6d Py0SPDy/WIZf3Qp5kyyghqVyE8nI/K3S+bjIfGKQ9Zc9/nHTzorxRo0EYt1Ivx7epv+Y 9vNRbCSDK9gx7htAldMEbnAwsG9yVzF3fbSkMuFFOfFc0dPxPn1eK/H+GE4GKa0oy++c Vlrg== MIME-Version: 1.0 Received: by 10.236.173.132 with SMTP id v4mr12248908yhl.78.1330717375850; Fri, 02 Mar 2012 11:42:55 -0800 (PST) Received: by 10.236.9.73 with HTTP; Fri, 2 Mar 2012 11:42:55 -0800 (PST) In-Reply-To: References: Date: Fri, 2 Mar 2012 13:42:55 -0600 Message-ID: From: Behcet Sarikaya To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:43:01 -0000 Hi Chairs, I would like to present my draft on 6rd multicast http://tools.ietf.org/html/draft-sarikaya-softwire-6rdmulticast-02 Thank God 6rd does not have two names :-). Regards, Behcet On Wed, Feb 29, 2012 at 9:16 AM, Alain Durand wrote: > If you intend to present in Paris, please send Yong and I a request by 3/= 7. > > =A0 - Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sw3588@att.com Fri Mar 2 12:06:20 2012 Return-Path: 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 4C1C521E8034 for ; Fri, 2 Mar 2012 12:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fhqPcNupf2jP for ; Fri, 2 Mar 2012 12:06:19 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AB21E8027 for ; Fri, 2 Mar 2012 12:06:19 -0800 (PST) X-Env-Sender: sw3588@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1330718777!51738645!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1006 invoked from network); 2 Mar 2012 20:06:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2012 20:06:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q22K4iFH005666 for ; Fri, 2 Mar 2012 15:04:44 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q22K4fSm005570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Mar 2012 15:04:41 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor) for ; Fri, 2 Mar 2012 15:06:08 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([169.254.4.62]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 15:06:08 -0500 From: "WRIGHT, STEVEN A" To: "softwires@ietf.org" Thread-Topic: Regarding draft-sarikaya-softwire-6rdmulticast-02.txt Thread-Index: Acz4r+W+TzNuIbKBR8CZPNX2txygng== Date: Fri, 2 Mar 2012 20:06:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.5.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [Softwires] Regarding draft-sarikaya-softwire-6rdmulticast-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 20:06:20 -0000 There is no address shortage in the IPv4 multicast address space, though it= is nice to see completeness of support for multicast in 6rd.If I understan= d this correctly, this draft tunnels the IPv6 multicast stream as an AMT tu= nnel riding over the 6rd tunnel between the RG and 6rd BR. This has the dis= advantage that it cannot leverage packet replication the in access network,= which is potentially inefficient. It might be helpful if the document poin= ted out that limitation. As a transition strategy that inefficiency may be ok, or if it is some new = low bandwidth service. Current access equipment like DSLAMs do not support = layer 3 Multicast completely, but it typically does support snooping on the= IGMP messages and packet replication at layer 2. I believe some of the BBF= specs provide a more complete description of this behavior. Steven Wright, MBA, PhD. Lead Member of Technical Staff AT&T Services Inc. Architecture & Planning 1057 Lenox Park Blvd NE, STE 4D28 Atlanta, GA 30319 P: 404.499.7030 sw3588@att.com From despres.remi@laposte.net Sat Mar 3 06:09:01 2012 Return-Path: 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 8B10021F876D for ; Sat, 3 Mar 2012 06:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ioKmkgY4NFQ7 for ; Sat, 3 Mar 2012 06:09:01 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id F225F21F8769 for ; Sat, 3 Mar 2012 06:08:59 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id h28w1i00837Y3f40328woa; Sat, 03 Mar 2012 15:08:58 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 3 Mar 2012 15:08:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9891705D-9B04-4D01-9832-8C7B48616632@laposte.net> References: To: Alain Durand , Yong Cui X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 14:09:01 -0000 Le 2012-02-29 =E0 16:16, Alain Durand a =E9crit : > If you intend to present in Paris, please send Yong and I a request by = 3/7. I plan to send, in a few days, an updated version of = draft-despres-softwire-stateless-analysis-tool. While -00 was up to date for the Beijing interim meeting, this one will = be in line with the latest MAPT, MAP-E and 4rd documents. I would like a time slot for its presentation. Thanks, RD >=20 > - Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Sat Mar 3 20:04:59 2012 Return-Path: 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 2679F21F8534 for ; Sat, 3 Mar 2012 20:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 cctE1hTT+NJv for ; Sat, 3 Mar 2012 20:04:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92021F8577 for ; Sat, 3 Mar 2012 20:04:58 -0800 (PST) Received: by iazz13 with SMTP id z13so4763071iaz.31 for ; Sat, 03 Mar 2012 20:04:58 -0800 (PST) Received-SPF: pass (google.com: domain of bingxuere@gmail.com designates 10.50.202.69 as permitted sender) client-ip=10.50.202.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bingxuere@gmail.com designates 10.50.202.69 as permitted sender) smtp.mail=bingxuere@gmail.com; dkim=pass header.i=bingxuere@gmail.com Received: from mr.google.com ([10.50.202.69]) by 10.50.202.69 with SMTP id kg5mr2879346igc.7.1330833898156 (num_hops = 1); Sat, 03 Mar 2012 20:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zcy+O4iEfBlD/RAFrAn1OOj+vZcO1p8PU6tNGSN6N2o=; b=OKUz2ZJNyW5g3vmPAIJsCCdxJhcLjn5qBLQNnLRFywD3FSVmxItIFANazwdjNZ7LDa 8VeK4SQ680e8rbeff3YQlxkUiyEEp59C2efb2COkXvHZiO552sd3MHapqGu4NZ71xldO 5MIsdgjISiGZVkB0xm+odZorj8jh31bRnNnFMmy3zpz1A7fD88QU/GP7b1b5tMSbael1 7FF/dPAYFtjlSsyUww9N0rDiG3Ijum1eevt7Y7bATy9GxM3u217AhqNd4IaVEiUSlPWT fJocWwnpbiW94K0S+YcOGlv/vfUhlanZH5uErknlIz9QffMhWp3NffDre/v5qpHRKjUq SJJA== Received: by 10.50.202.69 with SMTP id kg5mr2389330igc.7.1330833898098; Sat, 03 Mar 2012 20:04:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.145.138 with HTTP; Sat, 3 Mar 2012 20:04:17 -0800 (PST) In-Reply-To: References: From: Qiong Date: Sun, 4 Mar 2012 12:04:17 +0800 Message-ID: To: Alain Durand Content-Type: multipart/alternative; boundary=f46d0447a259c04eba04ba62e9a4 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 04:04:59 -0000 --f46d0447a259c04eba04ba62e9a4 Content-Type: text/plain; charset=UTF-8 Dear Chairs, On behalf of our co-authors, I would like to have a time slot for our merged version of lightweight 4over6 (http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt) and another deployment document coming soon. Thanks in advance! Best wishes Qiong On Wed, Feb 29, 2012 at 11:16 PM, Alain Durand wrote: > If you intend to present in Paris, please send Yong and I a request by 3/7. > > - Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d0447a259c04eba04ba62e9a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Chairs,

On behalf of our co-authors, I would like to have a tim= e slot for our merged version of lightweight 4over6
(http://www.= ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt) and anothe= r deployment document coming soon.

Thanks in advance!

Best wishes

Qiong


On Wed, Feb 29, 2012 at 11:16 PM, Alain Durand <adurand@juniper.net= > wrote:
If you intend to present in Paris, please se= nd Yong and I a request by 3/7.

=C2=A0 - Alain.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d0447a259c04eba04ba62e9a4-- From james.huang@huawei.com Sun Mar 4 10:19:20 2012 Return-Path: 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 E8BF321F86A0 for ; Sun, 4 Mar 2012 10:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 9-cLJEFDHkG3 for ; Sun, 4 Mar 2012 10:19:19 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 980EC21F8686 for ; Sun, 4 Mar 2012 10:19:19 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0D006TGHK5EU@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 05 Mar 2012 02:19:17 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0D003GZHK5ID@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 05 Mar 2012 02:19:17 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHO52866; Mon, 05 Mar 2012 02:19:06 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 05 Mar 2012 02:18:26 +0800 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.80]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 05 Mar 2012 02:19:03 +0800 Date: Sun, 04 Mar 2012 18:19:02 +0000 From: Huangjing In-reply-to: X-Originating-IP: [172.24.1.69] To: Reinaldo Penno , Ralph Droms , Alain Durand Message-id: <774B240D54DAB844B37EE80C2DD8E8BC1C772108@szxeml522-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [Softwires] MAP and 4rd-U Thread-index: AQHM5SirTDS0G7LoZE660KnpZ1mbwJYwB34AgAEaL4CAKXkF0w== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Softwires WG , Yong Cui Subject: [Softwires] =?gb2312?b?tPC4tDogIE1BUCBhbmQgNHJkLVU=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 18:19:21 -0000 CkkgYWxzbyB0aGluayBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kZXNwcmVzLXNv ZnR3aXJlLTRyZC11LTAzIG1ha2VzIHNlbnNlLgoKVGhhbmtzIQoKSmFtZXMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kt6K8/sjLOiBzb2Z0d2lyZXMtYm91bmNlc0Bp ZXRmLm9yZyBbc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUmVpbmFsZG8gUGVubm8g W3JwZW5ub0BqdW5pcGVyLm5ldF0Kt6LLzcqxvOQ6IDIwMTLE6jLUwjjI1SAwOjUzCrW9OiBSYWxw aCBEcm9tczsgQWxhaW4gRHVyYW5kCkNjOiBTb2Z0d2lyZXMgV0c7IFlvbmcgQ3VpCtb3zOI6IFJl OiBbU29mdHdpcmVzXSBNQVAgYW5kIDRyZC1VCgpIZWxsbyBDaGFpcnMvQUQsCgpJJ3ZlIGJlZW4g Zm9sbG93aW5nIHRoaXMgZGlzY3Vzc2lvbiBhbmQgYmVsaWV2ZSBib3RoIDRyZC1VIGFuZCBNQVAg c2hvdWxkIGJlCmdpdmVuIGEgZmFpciBhbmQgaW1wYXJ0aWFsIGV2YWx1YXRpb24uIElNTyB3ZSBz aG91bGQgYWxzbyBhdm9pZCAnZGVzaWduaW5nCmJ5IGNvbW1pdHRlZScgYW5kIG1hc2hpbmcgZXZl cnl0aGluZyB0b2dldGhlciBqdXN0IGluIGFuIGVmZm9ydCB0byBwbGVhc2UKZXZlcnlib2R5LgoK VGhhbmtzLAoKUmVpbmFsZG8KCgpPbiAyLzYvMTIgNDowMyBQTSwgIlJhbHBoIERyb21zIiA8cmRy b21zQGNpc2NvLmNvbT4gd3JvdGU6Cgo+IEkgd2lsbCBiZSBpbiBQYXJpcyBhcyB3ZWxsOyBob3Bp bmcgSSBjYW4gam9pbiB0aGUgY29udmVyc2F0aW9uLi4uCj4KPiAtIFJhbHBoCj4KPiBPbiBGZWIg NiwgMjAxMiwgYXQgMzozOSBQTSAyLzYvMTIsIEFsYWluIER1cmFuZCB3cm90ZToKPgo+PiBSqKZt aSwgT2xlOgo+Pgo+PiBJJ2xsIGJlIGluIFBhcmlzIHRoaXMgd2VlayBmb3IgdjYgd29ybGQgY29u Z3JlcywgYW5kIEknbSBwbGFubmluZyB0byBzcGVuZAo+PiB0aW1lIHdpdGggdGhlIHR3byBvZiB5 b3UgdG8gbWFrZSBwcm9ncmVzcyBvbiB0aGlzIGlzc3VlLgo+PiBIb3BlZnVsbHkgd2Ugd2lsbCBo YXZlIGdvb2QgbmV3cyBmb3IgdGhlIHdnIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsuCj4+Cj4+ICAt IEFsYWluLgo+Pgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0Cj4gU29mdHdpcmVzQGlldGYub3JnCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClNvZnR3aXJlcyBtYWlsaW5nIGxp c3QKU29mdHdpcmVzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVzCg== From internet-drafts@ietf.org Sun Mar 4 12:42:02 2012 Return-Path: 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 196AC21F85D1; Sun, 4 Mar 2012 12:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Lqc4bg-O0Z+7; Sun, 4 Mar 2012 12:42:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F4321F850B; Sun, 4 Mar 2012 12:42:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304204201.9081.10601.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2012 12:42:01 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:42:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Deployment Considerations for Dual-Stack Lite Author(s) : Yiu L. Lee Roberta Maglione Carl Williams Christian Jacquenet Mohamed Boucadair Filename : draft-ietf-softwire-dslite-deployment-02.txt Pages : 14 Date : 2012-03-04 This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment-02= .txt From yiu_lee@cable.comcast.com Sun Mar 4 12:44:50 2012 Return-Path: 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 3B83721F84B9 for ; Sun, 4 Mar 2012 12:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.407 X-Spam-Level: X-Spam-Status: No, score=-101.407 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] 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 mM-imh1XWZ+r for ; Sun, 4 Mar 2012 12:44:49 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3521F84B6 for ; Sun, 4 Mar 2012 12:44:49 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.8003862; Sun, 04 Mar 2012 13:33:47 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Sun, 4 Mar 2012 15:44:47 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-02.txt Thread-Index: AQHM+keic7lODlYPi0O1GI1pqWLtjQ== Date: Sun, 4 Mar 2012 20:44:30 +0000 Message-ID: In-Reply-To: <20120304204201.9081.10601.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3413720685_10120073" MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:44:50 -0000 --B_3413720685_10120073 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, We posted a newer version of the dslite-deployment draft. Comments are welcome. Yiu On 3/4/12 3:42 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Softwires Working Group of >the IETF. > > Title : Deployment Considerations for Dual-Stack Lite > Author(s) : Yiu L. Lee > Roberta Maglione > Carl Williams > Christian Jacquenet > Mohamed Boucadair > Filename : draft-ietf-softwire-dslite-deployment-02.txt > Pages : 14 > Date : 2012-03-04 > > This document discusses the deployment issues and describes > requirements for the deployment and operation of Dual-Stack Lite. > This document describes the various deployment considerations and > applicability of the Dual-Stack Lite architecture. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment- >02.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment-0 >2.txt > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3413720685_10120073 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSPzygA hi5azA58oVrzFwZw44VXNTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMDQyMDQ0NDRaMA0GCSqGSIb3DQEBAQUABIIBALxhYb/lcAZW64JHsZE9xSK+ 6F5OhdToEXUwIY6it/3tlkAaWQ0V8WCmmQH9BBBlzOwRcSJsfUcdrsSJUvf+LIJIlVuFR4jS vF156dXfId/086OhgxiAIueP2UK6vNMBL1NStfQcKPF1Pz5Q/A9AW3Rb34eMVb+BVq/zQ5fF 2vKSomqDTqfzker1lr0BweufPN0LGaeYgtJW2/hgx0Q51+GIKrz7UPHIp2sGj7CZVAOwj/xG o37ipBdXhF0An0EOOw7YEXuL71GiGp3PYy8vmdbArJwDftVstxsrlS0nVWrY054KvmZ5GGfh ztHAA81BmRrq64kIGROJrjorSDwGU28= --B_3413720685_10120073-- From bingxuere@gmail.com Mon Mar 5 09:37:37 2012 Return-Path: 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 9AD7A21F88AD for ; Mon, 5 Mar 2012 09:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 smvwoYeI1q9N for ; Mon, 5 Mar 2012 09:37:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEDC521F8893 for ; Mon, 5 Mar 2012 09:37:36 -0800 (PST) Received: by yenm5 with SMTP id m5so1996388yen.31 for ; Mon, 05 Mar 2012 09:37:36 -0800 (PST) Received-SPF: pass (google.com: domain of bingxuere@gmail.com designates 10.50.202.69 as permitted sender) client-ip=10.50.202.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bingxuere@gmail.com designates 10.50.202.69 as permitted sender) smtp.mail=bingxuere@gmail.com; dkim=pass header.i=bingxuere@gmail.com Received: from mr.google.com ([10.50.202.69]) by 10.50.202.69 with SMTP id kg5mr7490331igc.7.1330969056319 (num_hops = 1); Mon, 05 Mar 2012 09:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=zr/tZ7dBCk8XtgujxvAuM6T9mZr1Q7XgRjCTbb1+FgI=; b=mymfDEkAKjlA9ZSsWEEjwNgzP2VPk2aW/nWVlq4xEXTLvIsTYpicu7ZLXkmcMIqJ71 WJCljwwV/Q2M9S2dP5F3IruUutvKclzfTjemdvHwoFD2JgdhGzHpleh8PxfBn0utaS3n CnMoKPKRD+nxklojFMQ+3SR3MtkqoQ/9sdi7fjd38SlSwRg6UpePDf0X6H0EI6yEhF5M 3orq9MppulItWfrFLdBCfBK0kPiz+/R6NH1mfRxr3vJlnxQF8hVx9FVFYdZDpzKEEiAV KNKIFNGq9gEnEbQMcz5YQAzASvCmbfqmz14csdhcfmwSe6paJ2fkwrxJeIscs591Jn94 Q+cQ== Received: by 10.50.202.69 with SMTP id kg5mr6205209igc.7.1330969056235; Mon, 05 Mar 2012 09:37:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.145.138 with HTTP; Mon, 5 Mar 2012 09:36:56 -0800 (PST) In-Reply-To: References: From: Qiong Date: Tue, 6 Mar 2012 01:36:56 +0800 Message-ID: To: Alain Durand , Yong Cui , Softwires WG , =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=f46d0447a259cdcfb104ba826194 Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:37:37 -0000 --f46d0447a259cdcfb104ba826194 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Chairs, With the newly published map-d document, we also would like to apply for a slot on: http://www.ietf.org/id/draft-mdt-softwire-map-deployment-00.txt Thanks in advance! Qiong On Thu, Mar 1, 2012 at 1:09 AM, Ole Tr=C3=B8an wrote= : > Chairs, > > > If you intend to present in Paris, please send Yong and I a request by > 3/7. > > on behalf of the MAP design team I would like to request a set of slots t= o > present the results of the DT effort. > draft-mdt-softwire-mapping-address-and-port-03 > draft-mdt-softwire-map-dhcp-option-02 > draft-mdt-softwire-map-encapsulation-00 > draft-mdt-softwire-map-translation-00 > > cheers, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d0447a259cdcfb104ba826194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Chairs,

With the newly published map-d document, we also would = like to apply for a slot on:
http://www.ietf.org/id/draft-mdt-softwire-= map-deployment-00.txt

Thanks in advance!

Qiong

On T= hu, Mar 1, 2012 at 1:09 AM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
Chairs,

> If you intend to present in Paris, please send Yong and I a request by= 3/7.

on behalf of the MAP design team I would like to request a set of slo= ts to present the results of the DT effort.
=C2=A0draft-mdt-softwire-mapping-address-and-port-03
=C2=A0draft-mdt-softwire-map-dhcp-option-02
=C2=A0draft-mdt-softwire-map-encapsulation-00
=C2=A0draft-mdt-softwire-map-translation-00

cheers,
Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d0447a259cdcfb104ba826194-- From despres.remi@laposte.net Mon Mar 5 13:33:27 2012 Return-Path: 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 3753B21F8929 for ; Mon, 5 Mar 2012 13:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OdJ6glLKEnOK for ; Mon, 5 Mar 2012 13:33:26 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 792E721F8928 for ; Mon, 5 Mar 2012 13:33:19 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id hxZF1i00337Y3f403xZF7X; Mon, 05 Mar 2012 22:33:17 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> Date: Mon, 5 Mar 2012 22:33:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> To: Softwires WG X-Mailer: Apple Mail (2.1084) Cc: Yong Cui Subject: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:33:27 -0000 Hello all, The new version of the unified 4rd proposal is now available at:=20 http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 A summarized comparison of its features with those of MAP-T and MAP-E is = about to be posted in draft-despres-softwire-stateless-analysis-tool-01.=20= All questions and comments are most welcome. Regards, Remi, Reinaldo, Jacni, Yiu From sarikaya2012@gmail.com Mon Mar 5 13:57:24 2012 Return-Path: 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 43E2021F87D3 for ; Mon, 5 Mar 2012 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 q+ygjHTkcCsP for ; Mon, 5 Mar 2012 13:57:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A380D21F8797 for ; Mon, 5 Mar 2012 13:57:23 -0800 (PST) Received: by yenm5 with SMTP id m5so2177343yen.31 for ; Mon, 05 Mar 2012 13:57:23 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.101.6.38 as permitted sender) client-ip=10.101.6.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.101.6.38 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.101.6.38]) by 10.101.6.38 with SMTP id j38mr8993767ani.11.1330984643359 (num_hops = 1); Mon, 05 Mar 2012 13:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=foVEG+yrddmeWZey7EaoZCGpEoVgL4z7rSf0QEi7aJQ=; b=JbN+MVdwoQcuqppWtd1+3x69qXYk/SPWcntl/Xvkfb5Ejfaa5bfBJWnxFpM22qU9u4 rBpgod/jVIKWvmnDKXtX2UVRYjqnBL3dCkRyYU7MBM2giF3K+fCh1qOlTrU2EwsxmAhK SL4leWy0bMLjalddFGs9SsECVHtuASci2AjrfP5nZ6CDxmmmAzKdCexF3VTryrMx53Av 2PXl7C0YYCxW05CGamTz7tASfIzGej1++AbWSdh7EWhCXYYjFYAuBmZbQDx1HGav5c2C tLgsice13XAYm8YOgFC0XGsxfzZad0lChSVK8Q0CdeLRiG1xjDJ9tjojUdfT2z+KbJxZ D2Ew== MIME-Version: 1.0 Received: by 10.101.6.38 with SMTP id j38mr7098162ani.11.1330984643257; Mon, 05 Mar 2012 13:57:23 -0800 (PST) Received: by 10.236.9.73 with HTTP; Mon, 5 Mar 2012 13:57:23 -0800 (PST) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> Date: Mon, 5 Mar 2012 15:57:23 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:57:24 -0000 Hi Remi, Why is this draft informational? Behcet On Mon, Mar 5, 2012 at 3:33 PM, R=E9mi Despr=E9s = wrote: > Hello all, > > The new version of the unified 4rd proposal is now available at: > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 > > A summarized comparison of its features with those of MAP-T and MAP-E is = about to be posted in draft-despres-softwire-stateless-analysis-tool-01. > > All questions and comments are most welcome. > > Regards, > Remi, Reinaldo, Jacni, Yiu > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From matsuhira@jp.fujitsu.com Mon Mar 5 21:14:11 2012 Return-Path: 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 6922821F85D8 for ; Mon, 5 Mar 2012 21:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.09 X-Spam-Level: X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ox2M1K53XWfk for ; Mon, 5 Mar 2012 21:14:10 -0800 (PST) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id C279021F85CD for ; Mon, 5 Mar 2012 21:14:10 -0800 (PST) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id D68203EE0B5 for ; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id BF9B945DE5B for ; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id A954145DE58 for ; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 9E0711DB8049 for ; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from m001.s.css.fujitsu.com (m001.s.css.fujitsu.com [10.23.4.39]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 5B7ED1DB8040 for ; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from m001.css.fujitsu.com (m001 [127.0.0.1]) by m001.s.css.fujitsu.com (Postfix) with ESMTP id 179642E044E; Tue, 6 Mar 2012 14:14:09 +0900 (JST) Received: from localhost.localdomain (sw05.s.css.fujitsu.com [10.240.81.45]) by m001.s.css.fujitsu.com (Postfix) with ESMTP id 7C0622E0472; Tue, 6 Mar 2012 14:14:05 +0900 (JST) Date: Tue, 06 Mar 2012 14:14:05 +0900 From: Naoki Matsuhira To: Alain Durand Message-Id: <1331010845386415.matsuhira@jp.fujitsu.com> In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 X-Mailer: SYNCDOT/WebMailer Ver2.6 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-SecurityPolicyCheck-FJ: OK by SYNCDOT/WebMailer Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:14:11 -0000 Hi, Alain and Yong, I would like to present SA46T interoperability test results. 5min is enough. Naoki Matsuhira On Wed, 29 Feb 2012 07:16:38 -0800 Alain Durand wrote: > If you intend to present in Paris, please send Yong and I a request by 3/7. > > - Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From cb.list6@gmail.com Mon Mar 5 21:46:04 2012 Return-Path: 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 4DB9521F8585 for ; Mon, 5 Mar 2012 21:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TdrB6EWQuYcR for ; Mon, 5 Mar 2012 21:45:59 -0800 (PST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7040121F8577 for ; Mon, 5 Mar 2012 21:45:59 -0800 (PST) Received: by daec6 with SMTP id c6so7112709dae.27 for ; Mon, 05 Mar 2012 21:45:59 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.166 as permitted sender) client-ip=10.68.234.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.166 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.234.166]) by 10.68.234.166 with SMTP id uf6mr26079574pbc.148.1331012759270 (num_hops = 1); Mon, 05 Mar 2012 21:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F8QL2u5DkRJf10x+yVMeaXyGyqBSOAEYhIxJgqjQHls=; b=fOe22gRxDTPwetvZU749Ot1Rt5Cv048Wh1kl8ytMFspsWScutDlbgtqQuQ7gAE8Wao t6SPpSERpoUXNX/HAHLF0zvwFI5i9FqnNgz6gvR6wgDbFntqi5FWHrmzmz4D/VfHrjQ8 F33yz77dtIg5ridVSUekV0dB15YNviTTtcHrgZkeMYVIu9rsSS3lI/dxLMSAcFm3I1Nb poj/TBGTsIrbIWOc0vfWqSORGuqQczkndezod6kEGsGFSAt+N9pnnoea8BnhDC0Nw1lw NMwvQsRlPkT1eZ3d7VNufwnu5DQ3R7UaTVYvwqbEJAQCbCB7DzVgF6Ua//UtoUI7qCAd tFmQ== MIME-Version: 1.0 Received: by 10.68.234.166 with SMTP id uf6mr22538202pbc.148.1331012759190; Mon, 05 Mar 2012 21:45:59 -0800 (PST) Received: by 10.142.163.16 with HTTP; Mon, 5 Mar 2012 21:45:59 -0800 (PST) Date: Mon, 5 Mar 2012 21:45:59 -0800 Message-ID: From: Cameron Byrne To: softwires@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:46:04 -0000 Thanks for submitting this help draft. I have a few questions. Is it the case that MAP deployments require DHCPv6 and therefore for mobile the solution is scoped only for 3GPP release 10 and beyond networks? In figure #2, from which interface does the IPv6 UE source packets towards the BR to reach the IPv4 internet? Is it from one of the /56 interfaces since they are the ones assigned via DHCPv6? CB From phdgang@gmail.com Mon Mar 5 22:43:53 2012 Return-Path: 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 0C8E421E807E for ; Mon, 5 Mar 2012 22:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ldImT9CiFkH3 for ; Mon, 5 Mar 2012 22:43:52 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4278721E8052 for ; Mon, 5 Mar 2012 22:43:52 -0800 (PST) Received: by wicr5 with SMTP id r5so2343550wic.31 for ; Mon, 05 Mar 2012 22:43:51 -0800 (PST) Received-SPF: pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) client-ip=10.180.83.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) smtp.mail=phdgang@gmail.com; dkim=pass header.i=phdgang@gmail.com Received: from mr.google.com ([10.180.83.97]) by 10.180.83.97 with SMTP id p1mr20536675wiy.19.1331016231563 (num_hops = 1); Mon, 05 Mar 2012 22:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=baG7lwtctM6T5Gzr6zWOLq5bZ2OvZyp0hAwV4OqXIlw=; b=sO+B66ML9X555ZBUTQo47sgjkbOn2vhSkGzbLVe23OuC+1u96ZiGNw7mTVTAiSmjUS ZqUcV9c1xBWUlARkzJ6wor3JybczkSDGqYbZGkILKTm8ltnaK+/oo48cQgaCsfg84L04 SASxAxHALwZQpTvWUGIxvuvxpuWwDhVpL4mEzqjFVL+zuYno/lA4Lb9sLhk1XRrP6jXJ ArwrwleU/Mq9Ppek4LP1nMZoDu1HDakeaZwdK5oWWV42OSFRNpPzyfORpzcjFAwtz64E 5AXgEpbnp5XDiF2ptPSZ4fBgYhqg9qaHLNSgnHScY3HpWV5pTyLoNMfrn8Ct19Jt+P8b txjw== MIME-Version: 1.0 Received: by 10.180.83.97 with SMTP id p1mr16342661wiy.19.1331016231523; Mon, 05 Mar 2012 22:43:51 -0800 (PST) Received: by 10.180.7.105 with HTTP; Mon, 5 Mar 2012 22:43:51 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 14:43:51 +0800 Message-ID: From: GangChen To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:43:53 -0000 Hello Cameron, 2012/3/6, Cameron Byrne : > Thanks for submitting this help draft. I have a few questions. > > Is it the case that MAP deployments require DHCPv6 and therefore for > mobile the solution is scoped only for 3GPP release 10 and beyond > networks? I guess R10 and beyond is desirable. Otherwise, MAP parameters should be configured in an another way, e.g. TR069 > In figure #2, from which interface does the IPv6 UE source packets > towards the BR to reach the IPv4 internet? Is it from one of the /56 > interfaces since they are the ones assigned via DHCPv6? That is correct Gang From despres.remi@laposte.net Mon Mar 5 22:46:55 2012 Return-Path: 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 3E3E321E8024 for ; Mon, 5 Mar 2012 22:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xDqIldifmvVz for ; Mon, 5 Mar 2012 22:46:54 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5C41021F878B for ; Mon, 5 Mar 2012 22:46:54 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id i6mG1i00737Y3f4036mrYz; Tue, 06 Mar 2012 07:46:52 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 6 Mar 2012 07:46:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCC8803-9C77-4B4B-B13E-248E0B078EC2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:46:55 -0000 Le 2012-03-05 =E0 22:57, Behcet Sarikaya a =E9crit : > Hi Remi, >=20 > Why is this draft informational? An enormous typo!!! Will for sure be corrected in -05. Thanks, RD >=20 > Behcet >=20 > On Mon, Mar 5, 2012 at 3:33 PM, R=E9mi Despr=E9s = wrote: >> Hello all, >>=20 >> The new version of the unified 4rd proposal is now available at: >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 >>=20 >> A summarized comparison of its features with those of MAP-T and MAP-E = is about to be posted in = draft-despres-softwire-stateless-analysis-tool-01. >>=20 >> All questions and comments are most welcome. >>=20 >> Regards, >> Remi, Reinaldo, Jacni, Yiu >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From dxhbupt@gmail.com Tue Mar 6 01:35:19 2012 Return-Path: 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 0C42721F8805 for ; Tue, 6 Mar 2012 01:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 264fm4DcQBjG for ; Tue, 6 Mar 2012 01:35:18 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4666C21F8800 for ; Tue, 6 Mar 2012 01:35:18 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3022842wgb.13 for ; Tue, 06 Mar 2012 01:35:17 -0800 (PST) Received-SPF: pass (google.com: domain of dxhbupt@gmail.com designates 10.180.86.105 as permitted sender) client-ip=10.180.86.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dxhbupt@gmail.com designates 10.180.86.105 as permitted sender) smtp.mail=dxhbupt@gmail.com; dkim=pass header.i=dxhbupt@gmail.com Received: from mr.google.com ([10.180.86.105]) by 10.180.86.105 with SMTP id o9mr21816235wiz.4.1331026517573 (num_hops = 1); Tue, 06 Mar 2012 01:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+NnTv4wiTwl84GiXAbVTDq3uIrgwiSTNeNkThxGaddg=; b=Bh27NyqCDoYt+BQS0e+sK//cxhNiYu0UTU7wQdTuIMYExloMuqKhc3U01gAwt14YsE OWbhEdZXFxpf8476JP22LZIHhd2P+MuVvt/CFKdjrzJtLpSNg0hsoKjcjyeQxwE/Zu51 kBjQOYNXsYDxblgyTVmH3ja68h+QnLkc906bTCRXxOmsTWbmhEM4qhO002Bg9ynmCdox J+tMi3+PJzaKd/5X10NQaSnaYYdxdRfVG8nP2GE5MV04n/jGGNoF4vqxtHwmlL5IpgZQ GYHTXwn5KFvbc9YvGyfRiwDs7dt296HsWryz8UXuOJVD0yqD4VEIh+37PxE902KjpliO W1Qw== MIME-Version: 1.0 Received: by 10.180.86.105 with SMTP id o9mr17295113wiz.4.1331026517390; Tue, 06 Mar 2012 01:35:17 -0800 (PST) Received: by 10.180.89.2 with HTTP; Tue, 6 Mar 2012 01:35:17 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 17:35:17 +0800 Message-ID: From: Xiaohong Deng To: adurand@juniper.net, cuiyong@tsinghua.edu.cn Content-Type: multipart/alternative; boundary=f46d04182662c1748c04ba8fc2b1 Cc: softwires@ietf.org Subject: Re: [Softwires] Softwires Digest, Vol 76, Issue 7 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:35:19 -0000 --f46d04182662c1748c04ba8fc2b1 Content-Type: text/plain; charset=ISO-8859-1 Dear Chairs, We would like to request a slot to present development and test results of two I-Ds: draft-qin-softwire-multicast-prefix-optionand draft-ietf-softwire-dslite-multicast. Thanks, Xiaohong On Wed, Feb 29, 2012 at 11:16 PM, Alain Durand wrote: > > > If you intend to present in Paris, please send Yong and I a request by > 3/7. > > > > - Alain. > > > --f46d04182662c1748c04ba8fc2b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Chairs,

We would like to request a slot to present development = and test results of two I-Ds: draft-qin-softwire-multicast-pref= ix-option and draft-ietf-softwire-dslite-multicast .

Thanks,
Xiaohong

On Wed, Feb 29, 2012 at 11:16 PM, Alain Durand <adurand@juniper.net> wrote:

> If you intend to present in Paris, please send Yong and I a request by= 3/7.
>
> =A0 - Alain.
>

--f46d04182662c1748c04ba8fc2b1-- From phdgang@gmail.com Tue Mar 6 02:09:57 2012 Return-Path: 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 206DA21F8549 for ; Tue, 6 Mar 2012 02:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 wHFctgP8CYTt for ; Tue, 6 Mar 2012 02:09:56 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 596AA21F85C5 for ; Tue, 6 Mar 2012 02:09:55 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3045221wgb.13 for ; Tue, 06 Mar 2012 02:09:54 -0800 (PST) Received-SPF: pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) client-ip=10.180.83.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) smtp.mail=phdgang@gmail.com; dkim=pass header.i=phdgang@gmail.com Received: from mr.google.com ([10.180.83.97]) by 10.180.83.97 with SMTP id p1mr21792733wiy.19.1331028594626 (num_hops = 1); Tue, 06 Mar 2012 02:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=je7wMesb2jiDUD22wSW353dX2VnEjFQC5hHzHiGUAY0=; b=fZsPeOS1UGUqAL8khNrNa4IeTERXza2yBCN/2eWfzqKE5+0Kn7/w+y2sKzP06kviId Wm59fRR0OVmIRLJ0CTtkIUZ+4uJlnsAaTx655CNywZYtG+ymPnS6SjYyEYtQSanwe+fU syxhesulHCdoIfPl2z8/a4rDX5uRaS7WkHlNc7ZD6F6T/ev0MlqQrPNau7Jja18xnAAY 0SDandoPGB9NUYLBA/urH9N2cTAvwjsAqnfv0Cl1NbUx02rOtOTUqc0E/YNCKJPS2b3b 9pt94hSRTOYofExm4LeodYOSfjMAs/K/yEBqBex1W3hbcoytUaa5LW7uHMj5g+UJG+ie eZJg== MIME-Version: 1.0 Received: by 10.180.83.97 with SMTP id p1mr17324349wiy.19.1331028594525; Tue, 06 Mar 2012 02:09:54 -0800 (PST) Received: by 10.180.7.105 with HTTP; Tue, 6 Mar 2012 02:09:54 -0800 (PST) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> Date: Tue, 6 Mar 2012 18:09:54 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:09:57 -0000 Hello Remi, Here are few comments for the draft. Generally speaking, I'm not sure always carrying fragmentation header in 4rd domain is a good idea. Since the receiver always treat that as regular fragments. That means it tries to reassembly on the BRs and cause some potential risks= . Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt Secondly, -04 added NAT64+ parts. If I understood correctly, there are no additional requirements for NAT64 b= oxes. The only change is to add NAT64+ mapping rule into the domain. I guess the intention is to let 4rd-u become friendly to NAT64, since some operators already deployed it. IMHO, that seems unnecessary. NAT64 is another standalone system. 4rd-U could naturally coexist with NAT64 by taking proper routing planning. And, you have a good designing on V bits. There should be no additional works requested to make these two sets into unified one. Besides, I guess NAT64+ mapping rule in some sense would do same thing in I-D.ietf-behave-nat64-discovery-heuristic Going into more detailed, I guess there are some editorial suggestions. In Table 2: I guess the field of IDENTIFICATION is missing In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule IPv6 suffix" In R-7, it uses the indicator of k. I guess that is different meaning with k in R-5? In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it would be duplicated with sixth column I might back with more comments after my second review. Many thanks Gang 2012/3/6, R=E9mi Despr=E9s : > Hello all, > > The new version of the unified 4rd proposal is now available at: > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 > > A summarized comparison of its features with those of MAP-T and MAP-E is > about to be posted in draft-despres-softwire-stateless-analysis-tool-01. > > All questions and comments are most welcome. > > Regards, > Remi, Reinaldo, Jacni, Yiu > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From phdgang@gmail.com Tue Mar 6 02:24:37 2012 Return-Path: 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 EF34B21F885D for ; Tue, 6 Mar 2012 02:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8lLCAp5S2p56 for ; Tue, 6 Mar 2012 02:24:36 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A836B21F871E for ; Tue, 6 Mar 2012 02:24:35 -0800 (PST) Received: by werb10 with SMTP id b10so3859511wer.31 for ; Tue, 06 Mar 2012 02:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rzn0+gjxxIBPpxyaVmPKjao6zAyhjQA25g5NuVYKIug=; b=zBUiF9a1VYrzubUJneprCS18Xl7CRVMDJNAm3J9ChHnA7rv03MHSdJ2OJJ26QygRiI jbvySrJz/sh5c5a0jPyu0ncEc68veHoZ2u7tzwb5wFMCl/ApGs85i0bJchrzVI+UVLYg tyLJBk9RuQNPp/zZopBOVOi5ikGe3eGgKx1mY9X9P643NzWdbm7MTcK/rUpQLrUiST7r Ze2JMOqlHzLpPZG+h/PaUm5p7cxQREhJjzurv70LsdffQGIZq5A5s9U79u2mSWtHExTo TnByC2u8zVDgn8GeGxldERRahI5HERwhKO+x8OpsI/Ifm/o/XJY0lO0/MrEFBJKrQplC SocA== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr17325590wib.22.1331029474823; Tue, 06 Mar 2012 02:24:34 -0800 (PST) Received: by 10.180.7.105 with HTTP; Tue, 6 Mar 2012 02:24:34 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 18:24:34 +0800 Message-ID: From: GangChen To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:24:37 -0000 Hello Tina, Could you help to clarify the sentence: *1 MAP and divi-pd provide better security than 4rd-U, because they provide more variation in port set definition. I guess they should have similar features on security Gang 2012/3/2, Tina TSOU : > Dear all, > You may be interested to comment on > http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/ > > Abstract: > This memo analyses some port set definition algorithms which > encode port set information into IPv6 address so as to support > stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. > > > Tetsuya, Simon and Tina > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Tue Mar 6 02:59:29 2012 Return-Path: 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 7EE8521F889B for ; Tue, 6 Mar 2012 02:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jBaDO64Ewnzp for ; Tue, 6 Mar 2012 02:59:28 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18521F8898 for ; Tue, 6 Mar 2012 02:59:28 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id iAzR1i00837Y3f403AzRNQ; Tue, 06 Mar 2012 11:59:26 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 6 Mar 2012 11:59:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:59:29 -0000 Hi Gang, Thanks a lot for for the quick and detailed review. More comments below. Le 2012-03-06 =E0 11:09, GangChen a =E9crit : > Hello Remi, >=20 > Here are few comments for the draft. > Generally speaking, I'm not sure always carrying fragmentation header > in 4rd domain is a good idea. > Since the receiver always treat that as regular fragments. > That means it tries to reassembly on the BRs and cause some potential = risks. A receiver that receives a fragment header showing that the packet is = compete (Offset=3DO, M=3D0) has no reassembly to perform. No new risk is therefore introduced. =20 > Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt Note that in the 4rd case, the only destinations of Tunnel packets are = CEs or BRs (or also NAT64+ as discussed below). No conflict can exist with hosts that might have a provisional = difficulty with a received fragment header having Offset=3D0 and M=3D0.=20= > Secondly, -04 added NAT64+ parts. > If I understood correctly, there are no additional requirements for = NAT64 boxes. Well, NAT64 boxes remain what they are. Any host can use BIH to look like an IPv6-only host in the NAT64 = although it has a dual stack. But the advantage of 4rd tunneling over RFC6145 double translation is = better IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may use the TCP checksum algorithms) For an ISP to extend this advantage to its stateful NAT64, it need to be = 4rd aware (become a NAT64+). NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a = V octet instead of a "u" octet), use the 4rd header mapping instead of = RFC6145 translation. =20 > The only change is to add NAT64+ mapping rule into the domain. > I guess the intention is to let 4rd-u become friendly to NAT64, since > some operators already deployed it. It is to extend advantages of full transparency of header mapping to = ISPs that deploy stateful NAT64s. > IMHO, that seems unnecessary. NAT64 is another standalone system. > 4rd-U could naturally coexist with NAT64 by taking proper routing = planning. > And, you have a good designing on V bits. > There should be no additional works requested to make these two sets > into unified one. > Besides, I guess NAT64+ mapping rule in some sense would do same thing > in I-D.ietf-behave-nat64-discovery-heuristic Only almost the same thing, a MAP64+ mapping rule must be announced ONLY = with NAT64s that are upgraded to be NAT64+s. =20 > Going into more detailed, I guess there are some editorial = suggestions. > In Table 2: > I guess the field of IDENTIFICATION is missing Not understood: +---------------------+-----------------------------------------+ | IPv4 FIELDS | VALUES SET AT DOMAIN EXIT | +---------------------+-----------------------------------------+ ... | Identification | IPv4 ID | ... Table 2 > In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule > IPv6 suffix" Yes, thanks. > In R-7, it uses the indicator of k. I guess that is different meaning > with k in R-5? Yes Was supposed to be clear enough, but will replace k by s in R-5, no = problem. =20 > In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it > would be duplicated with sixth column Good catch, thanks. > I might back with more comments after my second review. > Many thanks Kind regards, RD >=20 > Gang >=20 >=20 > 2012/3/6, R=E9mi Despr=E9s : >> Hello all, >>=20 >> The new version of the unified 4rd proposal is now available at: >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 >>=20 >> A summarized comparison of its features with those of MAP-T and MAP-E = is >> about to be posted in = draft-despres-softwire-stateless-analysis-tool-01. >>=20 >> All questions and comments are most welcome. >>=20 >> Regards, >> Remi, Reinaldo, Jacni, Yiu >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 From ichiroumakino@gmail.com Tue Mar 6 03:56:59 2012 Return-Path: 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 503D321F88CC for ; Tue, 6 Mar 2012 03:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kY5q0zvF7qTa for ; Tue, 6 Mar 2012 03:56:58 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86BA821F88BF for ; Tue, 6 Mar 2012 03:56:58 -0800 (PST) Received: by wicr5 with SMTP id r5so2559423wic.31 for ; Tue, 06 Mar 2012 03:56:57 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.90.212 as permitted sender) client-ip=10.180.90.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.90.212 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.90.212]) by 10.180.90.212 with SMTP id by20mr22907199wib.12.1331035017806 (num_hops = 1); Tue, 06 Mar 2012 03:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1iqeF5NmEe/rI/TpqrD9ehya36HqN6PUgUhrDaJdZtY=; b=LbXc9JdmEfpfMMxPbZlW07pn9Co+kah6pZOEYKV8nHQM9081P2bmubtKFWG/DJNeXS VPgbo2C+0OXJh4PFBXZtsU2Vg9qN/MNBf+AW+iEe55zgGl14QLHokEUyxS9tkpIyMFyQ Sn4F5DaxInCObQSatLKr9cZCXzOMYR26YOEj3a4AXcQvNaqH3h75oqpOA7otBjF84GJ2 HHvl5+4C0DmQQptG84sAsFMsw0u1kZ8GzY+D1Pm28U/sWGJLTUV9HiKc2Ps+gtCFvWK7 lF8rtTgUEdaagloKUkasXHMucwdvx1qTCWx9fasEhqpwPn8sT4BBP88gf1dCKVAafwk/ iG6Q== Received: by 10.180.90.212 with SMTP id by20mr18172935wib.12.1331035017767; Tue, 06 Mar 2012 03:56:57 -0800 (PST) Received: from [10.147.13.93] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h19sm27645467wiw.9.2012.03.06.03.56.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 03:56:56 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 6 Mar 2012 12:56:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:56:59 -0000 Cameron, > Is it the case that MAP deployments require DHCPv6 and therefore for > mobile the solution is scoped only for 3GPP release 10 and beyond > networks? MAP could be provisioned with whatever protocol you like. DHCPv6 is kind = of the obvious one and the one IETF controls. which one would fit best in a 3GPP environment? GTP (or DNS)? cheers, Ole= From cb.list6@gmail.com Tue Mar 6 04:43:50 2012 Return-Path: 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 6870521F88C0 for ; Tue, 6 Mar 2012 04:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 aU7k8rTkkr-H for ; Tue, 6 Mar 2012 04:43:49 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E021F88E8 for ; Tue, 6 Mar 2012 04:43:49 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so4272741pbb.31 for ; Tue, 06 Mar 2012 04:43:49 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.228.103 as permitted sender) client-ip=10.68.228.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.228.103 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.228.103]) by 10.68.228.103 with SMTP id sh7mr60934494pbc.106.1331037829083 (num_hops = 1); Tue, 06 Mar 2012 04:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pbq2uqOifBh2YxM5y4O9njsjzUF9EkN+EhqqM9nNMQU=; b=SX2ifCCx+yr1+93AWou4qoCPqYuzHJVafK80b4xHnh+NZhNl+xh+yEKnoAI8suyeuR R1NWjuDRFvfUW2GkvO9YXgiVLy1js/TDYaOCy1s4o7TPq4zHXNrphPtc6cOUZ2YsexN8 SadwkQZlOyW70dPVQMIDq+yGzmg3l8ZApFtoPRg9V3A9/iMFDqf00D9OHWNF/sGAfm4j ct1Hz5vp/S1HGBuKrU/RBR1G+ufpWB7fhHw1umvKwvx9PJf/BUlpTcceKW40EmGj95+8 3i7tkdVzAqZ2lmoUxqNSm9AjgtdLMbhNmytbQyAOGntEyJPgaUQDtoey/0ymHTn+3J8w L0rQ== MIME-Version: 1.0 Received: by 10.68.228.103 with SMTP id sh7mr52092650pbc.106.1331037828935; Tue, 06 Mar 2012 04:43:48 -0800 (PST) Received: by 10.142.163.16 with HTTP; Tue, 6 Mar 2012 04:43:48 -0800 (PST) Received: by 10.142.163.16 with HTTP; Tue, 6 Mar 2012 04:43:48 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 04:43:48 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=e89a8ff254faf9f0f004ba926455 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 12:43:50 -0000 --e89a8ff254faf9f0f004ba926455 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: > > Cameron, > > > Is it the case that MAP deployments require DHCPv6 and therefore for > > mobile the solution is scoped only for 3GPP release 10 and beyond > > networks? > > MAP could be provisioned with whatever protocol you like. DHCPv6 is kind of the obvious one and the one IETF controls. > which one would fit best in a 3GPP environment? GTP (or DNS)? > None come to mind. GTP with PCO might work, but I think it would end up being a lot of sdo heavy lifting to make that work and the timeline would be long. I am still unclear on how MAP works. Is it a /128 that the CE must use so that magic happens ? If so, I am not even sure that is scoped currently in 3gpp since the use case is pd with dhcpv6 For someone who wants MAP to work in 3gpp, the best path may be to hold out for dhcpv6 and make specific requirements on how the ue must source traffic from an address acquired from dhcpv6 when MAP is the transition solution. But, it may end up looking like a square peg pounded into a round hole. But, such is life in transition Cb On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: > Cameron, > > > Is it the case that MAP deployments require DHCPv6 and therefore for > > mobile the solution is scoped only for 3GPP release 10 and beyond > > networks? > > MAP could be provisioned with whatever protocol you like. DHCPv6 is kind > of the obvious one and the one IETF controls. > which one would fit best in a 3GPP environment? GTP (or DNS)? > > cheers, > Ole --e89a8ff254faf9f0f004ba926455 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>
> Cameron,
>
> > Is it the case that MAP deployments require DHCPv6 and therefore = for
> > mobile the solution is scoped only for 3GPP release 10 and beyond=
> > networks?
>
> MAP could be provisioned with whatever protocol you like. DHCPv6 is ki= nd of the obvious one and the one IETF controls.
> which one would fit best in a 3GPP environment? GTP (or DNS)?
>

None come to mind.

GTP with PCO might work, but I think it would end up being a lot of sdo = heavy lifting to make that work and the timeline would be long.

I am still unclear on how MAP works.=A0 Is it a /128 that the CE must us= e so that magic happens ? If so, I am not even sure that is scoped currentl= y in 3gpp since the use case is pd with dhcpv6

For someone who wants MAP to work in 3gpp, the best path may be to hold = out for dhcpv6 and make specific requirements on how the ue must source tra= ffic from an address acquired from dhcpv6 when MAP is the transition soluti= on.

But, it may end up looking like a square peg pounded into a round hole. = But, such is life in transition

Cb

On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" = <otroan@employees.org> wr= ote:
Cameron,

> Is it the case that MAP deployments require DHCPv6 and therefore for > mobile the solution is scoped only for 3GPP release 10 and beyond
> networks?

MAP could be provisioned with whatever protocol you like. DHCPv6 is kind of= the obvious one and the one IETF controls.
which one would fit best in a 3GPP environment? GTP (or DNS)?

cheers,
Ole
--e89a8ff254faf9f0f004ba926455-- From ichiroumakino@gmail.com Tue Mar 6 04:51:54 2012 Return-Path: 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 C183821F8777 for ; Tue, 6 Mar 2012 04:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 pmqWfULkl+Nz for ; Tue, 6 Mar 2012 04:51:54 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB89F21F8751 for ; Tue, 6 Mar 2012 04:51:53 -0800 (PST) Received: by wicr5 with SMTP id r5so2602748wic.31 for ; Tue, 06 Mar 2012 04:51:53 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.89.66 as permitted sender) client-ip=10.180.89.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.89.66 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.89.66]) by 10.180.89.66 with SMTP id bm2mr756581wib.0.1331038313147 (num_hops = 1); Tue, 06 Mar 2012 04:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Bc5LB/v7CKQDqxc8AOZUF6jY+XCHgMs4Q/FonpbEoaw=; b=BvSJs6BVacKYEMM5IFN+hm0qh9YGZmtIK8sA00YHSQPgp3PFkOrdkznd3nTKebZUws HWLUNSBODt/NiJN9JKn6k1OKgBUi7VnvYrJU058NS2CtGvDvD2JYBCT9MEIu7FUirOim HJ5G85CkaceyCzym+bDPtJhEh/afa+CMJSv5wjYMRTt1SbTjj4WLhjXEdGH4fcIFb6rH Jubjen1+aA3s2g8Nz6mIOOrbQqCRcdvtShxc1bglDsHvNmxkhTR8nIDyGn24GQCHGU9v /G4Kzk4wfkJ3BiynikmcOxCn/2fQ4z2KaSZsjlBxruT5yg8xce/JfEH+hwL6dLpN/Ui9 fC1g== Received: by 10.180.89.66 with SMTP id bm2mr581148wib.0.1331038313115; Tue, 06 Mar 2012 04:51:53 -0800 (PST) Received: from [10.147.13.93] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ep17sm26801992wid.2.2012.03.06.04.51.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 04:51:52 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 6 Mar 2012 13:51:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA22D49-358F-4B51-88ED-A4853F55CF72@employees.org> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 12:51:54 -0000 Cameron, > > > Is it the case that MAP deployments require DHCPv6 and therefore = for > > > mobile the solution is scoped only for 3GPP release 10 and beyond > > > networks? > > > > MAP could be provisioned with whatever protocol you like. DHCPv6 is = kind of the obvious one and the one IETF controls. > > which one would fit best in a 3GPP environment? GTP (or DNS)? > > >=20 > None come to mind. >=20 > GTP with PCO might work, but I think it would end up being a lot of = sdo heavy lifting to make that work and the timeline would be long. >=20 > I am still unclear on how MAP works. Is it a /128 that the CE must = use so that magic happens ? If so, I am not even sure that is scoped = currently in 3gpp since the use case is pd with dhcpv6 do you know how 6to4 or ISATAP works? it works pretty much just like that, but with the forwarding mapping = being from IPv4 address to IPv6 address instead of from an IPv6 address to an IPv4 tunnel end point address. > For someone who wants MAP to work in 3gpp, the best path may be to = hold out for dhcpv6 and make specific requirements on how the ue must = source traffic from an address acquired from dhcpv6 when MAP is the = transition solution. there isn't any specific requirements as such. for MAP-E all traffic is = terminated at a single address that the CE has to 'configure' for itself = based on the delegated prefix / assigned address. > But, it may end up looking like a square peg pounded into a round = hole. But, such is life in transition indeed. of course in 3GPP where you already have a tunnel, one would = think you could take advantage of that. cheers, Ole= From mohamed.boucadair@orange.com Tue Mar 6 05:32:05 2012 Return-Path: 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 6917621F8751 for ; Tue, 6 Mar 2012 05:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 OuBjkewBZN07 for ; Tue, 6 Mar 2012 05:32:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD421F8743 for ; Tue, 6 Mar 2012 05:32:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F06973B44D9 for ; Tue, 6 Mar 2012 14:32:02 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id CC40527C064; Tue, 6 Mar 2012 14:32:02 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 6 Mar 2012 14:32:02 +0100 From: To: "softwires@ietf.org" Date: Tue, 6 Mar 2012 14:32:01 +0100 Thread-Topic: DS-Lite & HOST_ID: experimentation results Thread-Index: Acz7nYLPivfjoQYLStGQ+dFcpN3hAw== Message-ID: <94C682931C08B048B7A8645303FDC9F36748838197@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36748838197PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.6.121218 Subject: [Softwires] DS-Lite & HOST_ID: experimentation results X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:32:05 -0000 --_000_94C682931C08B048B7A8645303FDC9F36748838197PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We made some experiments using new TCP options to assess whether it mitigat= es some of the issues documented in RFC6269. The results of these experimen= ts are available at: http://tools.ietf.org/html/draft-abdo-hostid-tcpopt-im= plementation-02 This effort focused also on DS-Lite (See Section 7); in particular to check= if there is any performance impact. Comments and questions about this effort is more than welcome. For those who want to play with a modified AFTR supporting these options, m= odified iptables module or modified Linux Kernel, you can direct your e-mai= l to me. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36748838197PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear all,=20
 
W= e made some=20 experiments using new TCP options to assess whether it mitigates some = of=20 the issues documented in RFC6269. The results of these experiments are= =20 available at: http://tools.ietf.org/html/draft-abdo-hostid-tcpopt-implementation-02
 
T= his effort=20 focused also on DS-Lite (See Section 7); in particular to check if there is= any=20 performance impact.
C= omments and=20 questions about this effort is more than welcome.
 
<= SPAN=20 class=3D717144812-06032012>For those who want to play with a modified AFTR= =20 supporting these options, modified iptables module or modified Linux=20 Kernel, you can direct your e-mail to me.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36748838197PUEXCB1Bnante_-- From despres.remi@laposte.net Tue Mar 6 06:29:21 2012 Return-Path: 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 3445221F8862 for ; Tue, 6 Mar 2012 06:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ceBAelmUJxNv for ; Tue, 6 Mar 2012 06:29:20 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id F064421F85B7 for ; Tue, 6 Mar 2012 06:29:14 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id iEVB1i00637Y3f403EVB94; Tue, 06 Mar 2012 15:29:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-64-549633291 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 6 Mar 2012 15:29:11 +0100 Message-Id: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:29:21 -0000 --Apple-Mail-64-549633291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Cameron, Le 2012-03-06 =E0 13:43, Cameron Byrne a =E9crit : > On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: > > > > Cameron, > > > > > Is it the case that MAP deployments require DHCPv6 and therefore = for > > > mobile the solution is scoped only for 3GPP release 10 and beyond > > > networks? > > > > MAP could be provisioned with whatever protocol you like. DHCPv6 is = kind of the obvious one and the one IETF controls. > > which one would fit best in a 3GPP environment? GTP (or DNS)? > > >=20 > None come to mind. >=20 > GTP with PCO might work, but I think it would end up being a lot of = sdo heavy lifting to make that work and the timeline would be long. >=20 > I am still unclear on how MAP works. Is it a /128 that the CE must = use so that magic happens ? If so, I am not even sure that is scoped = currently in 3gpp since the use case is pd with dhcpv6 >=20 > For someone who wants MAP to work in 3gpp, the best path may be to = hold out for dhcpv6 and make specific requirements on how the ue must = source traffic from an address acquired from dhcpv6 when MAP is the = transition solution. >=20 > But, it may end up looking like a square peg pounded into a round = hole. But, such is life in transition >=20 Any idea why it would be so difficult to have DHVPv6 in Android phones, = noting that it would NOT imply support of many DHCPv6 options. In the context of your question, MAP options should be sufficient. (Note that the same comment applies to 4rd if retained as unified = standard, but this is a separate discussion.) RD > Cb > On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: > Cameron, >=20 > > Is it the case that MAP deployments require DHCPv6 and therefore for > > mobile the solution is scoped only for 3GPP release 10 and beyond > > networks? >=20 > MAP could be provisioned with whatever protocol you like. DHCPv6 is = kind of the obvious one and the one IETF controls. > which one would fit best in a 3GPP environment? GTP (or DNS)? >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-64-549633291 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Cameron,

Le 2012-03-06 =E0 13:43, Cameron Byrne a = =E9crit :

On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" <otroan@employees.org> = wrote:
>
> Cameron,
>
> > Is it the case that MAP deployments require DHCPv6 and = therefore for
> > mobile the solution is scoped only for 3GPP release 10 and = beyond
> > networks?
>
> MAP could be provisioned with whatever protocol you like. DHCPv6 is = kind of the obvious one and the one IETF controls.
> which one would fit best in a 3GPP environment? GTP (or DNS)?
>

None come to mind.

GTP with PCO might work, but I = think it would end up being a lot of sdo heavy lifting to make that work = and the timeline would be long.

I am still unclear on how MAP = works.  Is it a /128 that the CE must use so that magic happens ? = If so, I am not even sure that is scoped currently in 3gpp since the use = case is pd with dhcpv6

For = someone who wants MAP to work in 3gpp, the best path may be to hold out = for dhcpv6 and make specific requirements on how the ue must source = traffic from an address acquired from dhcpv6 when MAP is the transition = solution.

But, it may end up looking like a square peg pounded = into a round hole. But, such is life in = transition

Any idea why it would be so difficult to have = DHVPv6 in Android phones, noting that it would NOT imply support of = many DHCPv6 options.

In the context of your = question, MAP options should be sufficient.
(Note that the = same comment applies to 4rd if retained as unified standard, but this is = a separate = discussion.)

RD


Cb

On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" <otroan@employees.org> = wrote:
Cameron,

> Is it the case that MAP deployments require DHCPv6 and therefore = for
> mobile the solution is scoped only for 3GPP release 10 and = beyond
> networks?

MAP could be provisioned with whatever protocol you like. DHCPv6 is kind = of the obvious one and the one IETF controls.
which one would fit best in a 3GPP environment? GTP (or DNS)?

cheers,
Ole
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-64-549633291-- From cb.list6@gmail.com Tue Mar 6 08:00:56 2012 Return-Path: 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 0366621F89C6 for ; Tue, 6 Mar 2012 08:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 IE3lri1TE+VV for ; Tue, 6 Mar 2012 08:00:54 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32E21F89BF for ; Tue, 6 Mar 2012 08:00:54 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so4435612pbb.31 for ; Tue, 06 Mar 2012 08:00:53 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.217.104 as permitted sender) client-ip=10.68.217.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.217.104 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.217.104]) by 10.68.217.104 with SMTP id ox8mr62135940pbc.43.1331049653270 (num_hops = 1); Tue, 06 Mar 2012 08:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KOEa5rv1+Q6eIVNoFL38W15Jyh3e4rsvpyEp2XMCOic=; b=mzHCMJokd6nXqhLcKnOjdnF4oA1T0LxgxTLQSpkPUVIXk7suRY53smQv4Xqo6mseap lUQ+k+WirZEBzX3m2P0OUxAsMFK7xfwLLA4ktYyx5Njn2tDYtbz+cZEyE8k7H0fDIYuG SLn7TRSDXoCmFhRCO1por1xPs8nAvtTgzLHWXJAcp4mWY72LxB8tDxIhpH7oGKrMUgOl Rqk0qSkPw/V9g7htuSwAMpgTH0lmeO6LFcPVtV9Ij6CfSBBnSvHyJEIoqFCFSIvVJtG9 6e44vt8eFch3WhQcqqBysL2ycBQp7R+IfbJB5N8Iv3HAYAKv4EvoNnlEBXVSxkYS5PPr Xc/Q== MIME-Version: 1.0 Received: by 10.68.217.104 with SMTP id ox8mr53009031pbc.43.1331049653185; Tue, 06 Mar 2012 08:00:53 -0800 (PST) Received: by 10.142.163.16 with HTTP; Tue, 6 Mar 2012 08:00:53 -0800 (PST) Received: by 10.142.163.16 with HTTP; Tue, 6 Mar 2012 08:00:53 -0800 (PST) In-Reply-To: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> References: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> Date: Tue, 6 Mar 2012 08:00:53 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8ff2447fc1ad3b04ba952518 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:00:56 -0000 --e89a8ff2447fc1ad3b04ba952518 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mar 6, 2012 6:29 AM, "R=E9mi Despr=E9s" wrote= : > > Hi, Cameron, > > Le 2012-03-06 =E0 13:43, Cameron Byrne a =E9crit : > >> On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: >> > >> > Cameron, >> > >> > > Is it the case that MAP deployments require DHCPv6 and therefore for >> > > mobile the solution is scoped only for 3GPP release 10 and beyond >> > > networks? >> > >> > MAP could be provisioned with whatever protocol you like. DHCPv6 is kind of the obvious one and the one IETF controls. >> > which one would fit best in a 3GPP environment? GTP (or DNS)? >> > >> >> None come to mind. >> >> GTP with PCO might work, but I think it would end up being a lot of sdo heavy lifting to make that work and the timeline would be long. >> >> I am still unclear on how MAP works. Is it a /128 that the CE must use so that magic happens ? If so, I am not even sure that is scoped currently in 3gpp since the use case is pd with dhcpv6 >> >> For someone who wants MAP to work in 3gpp, the best path may be to hold out for dhcpv6 and make specific requirements on how the ue must source traffic from an address acquired from dhcpv6 when MAP is the transition solution. >> >> But, it may end up looking like a square peg pounded into a round hole. But, such is life in transition > > Any idea why it would be so difficult to have DHVPv6 in Android phones, noting that it would NOT imply support of many DHCPv6 options. > I don't know. In 2012, it is not there yet in either the handsets or any of the mobile infrastructure components, Afaik. Cb > In the context of your question, MAP options should be sufficient. > (Note that the same comment applies to 4rd if retained as unified standard, but this is a separate discussion.) > > RD > > >> Cb >> >> On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" wrote: >>> >>> Cameron, >>> >>> > Is it the case that MAP deployments require DHCPv6 and therefore for >>> > mobile the solution is scoped only for 3GPP release 10 and beyond >>> > networks? >>> >>> MAP could be provisioned with whatever protocol you like. DHCPv6 is kind of the obvious one and the one IETF controls. >>> which one would fit best in a 3GPP environment? GTP (or DNS)? >>> >>> cheers, >>> Ole >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > --e89a8ff2447fc1ad3b04ba952518 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 6, 2012 6:29 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
> Hi, Cameron,
>
> Le 2012-03-06 =E0 13:43, Cameron Byrne a =E9crit :
>
>> On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>> >
>> > Cameron,
>> >
>> > > Is it the case that MAP deployments require DHCPv6 and t= herefore for
>> > > mobile the solution is scoped only for 3GPP release 10 a= nd beyond
>> > > networks?
>> >
>> > MAP could be provisioned with whatever protocol you like. DHC= Pv6 is kind of the obvious one and the one IETF controls.
>> > which one would fit best in a 3GPP environment? GTP (or DNS)?=
>> >
>>
>> None come to mind.
>>
>> GTP with PCO might work, but I think it would end up being a lot o= f sdo heavy lifting to make that work and the timeline would be long.
>>
>> I am still unclear on how MAP works.=A0 Is it a /128 that the CE m= ust use so that magic happens ? If so, I am not even sure that is scoped cu= rrently in 3gpp since the use case is pd with dhcpv6
>>
>> For someone who wants MAP to work in 3gpp, the best path may be to= hold out for dhcpv6 and make specific requirements on how the ue must sour= ce traffic from an address acquired from dhcpv6 when MAP is the transition = solution.
>>
>> But, it may end up looking like a square peg pounded into a round = hole.=A0But, such is life in transition
>
> Any idea why it would be so difficult to have DHVPv6 in Android phones= , noting that=A0it would NOT imply support of many DHCPv6 options.
>

I don't know.=A0 In 2012, it is not there yet in either the handsets= or any of the mobile infrastructure components, Afaik.

Cb

> In the context of your question, MAP options should be sufficient.<= br> > (Note that the same comment applies to 4rd if retained as unified stan= dard, but this is a separate discussion.)
>
> RD
>
>
>> Cb
>>
>> On Mar 6, 2012 3:56 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>>>
>>> Cameron,
>>>
>>> > Is it the case that MAP deployments require DHCPv6 and th= erefore for
>>> > mobile the solution is scoped only for 3GPP release 10 an= d beyond
>>> > networks?
>>>
>>> MAP could be provisioned with whatever protocol you like. DHCP= v6 is kind of the obvious one and the one IETF controls.
>>> which one would fit best in a 3GPP environment? GTP (or DNS)?<= br> >>>
>>> cheers,
>>> Ole
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/softwires
>
>

--e89a8ff2447fc1ad3b04ba952518-- From pengwu.thu@gmail.com Tue Mar 6 08:04:16 2012 Return-Path: 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 D941021F8956 for ; Tue, 6 Mar 2012 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] 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 7KwCQqHGMLx0 for ; Tue, 6 Mar 2012 08:04:16 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4521F8916 for ; Tue, 6 Mar 2012 08:04:16 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so4438393pbb.31 for ; Tue, 06 Mar 2012 08:04:16 -0800 (PST) Received-SPF: pass (google.com: domain of pengwu.thu@gmail.com designates 10.68.73.234 as permitted sender) client-ip=10.68.73.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pengwu.thu@gmail.com designates 10.68.73.234 as permitted sender) smtp.mail=pengwu.thu@gmail.com; dkim=pass header.i=pengwu.thu@gmail.com Received: from mr.google.com ([10.68.73.234]) by 10.68.73.234 with SMTP id o10mr61510700pbv.90.1331049856013 (num_hops = 1); Tue, 06 Mar 2012 08:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=n/UVkYf4Ml1cnlY5WDJdO7hqZlQS+e1nMEKlkm6QFos=; b=Ta9hN9J0C4piV4sOCXKAAUfcATcXnHZ1OCxGKdv7eOPHylK00/qgeUei8t7hQ5pUgF +7oqSvyqn/glRWF3xku+51xYHmTWguBQ8Yfu4ep83ddoOfNKxp/TFd1nGNsrjiLqNRG8 Z20QXMQusBsfIcl+TQuSvDL1E8mrSmtQ1rFfBUYI2+5baQEb3GLbOPvkiSdmTnYw/UMu vV4onrX4bgPz07yCI4ry5t7popEyDI6txGQKeYylaPqAH9XMJQ3WTLisT11Nbr7QLQzv gb2k51Xis5Nuyc6FP+O1nS0eiODMV/hQ1Och1TyjCac4eQXgCAZmZFRQau4gD74P3LbE W+5A== MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr52466367pbv.90.1331049855963; Tue, 06 Mar 2012 08:04:15 -0800 (PST) Received: by 10.68.130.197 with HTTP; Tue, 6 Mar 2012 08:04:15 -0800 (PST) In-Reply-To: <1331010845386415.matsuhira@jp.fujitsu.com> References: <1331010845386415.matsuhira@jp.fujitsu.com> Date: Wed, 7 Mar 2012 00:04:15 +0800 Message-ID: From: Peng Wu To: Softwires WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:04:17 -0000 Dear Chairs, We would like to present two drafts:Public 4over6 & softwire mesh mib https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ https://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ Thanks! //Email account switching, apologize for the possible duplication... --Peng Wu On Wed, 29 Feb 2012 07:16:38 -0800 Alain Durand wrote: > If you intend to present in Paris, please send Yong and I a request by > 3/7. > > =A0 =A0- Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From despres.remi@laposte.net Tue Mar 6 10:03:34 2012 Return-Path: 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 9D71711E8076 for ; Tue, 6 Mar 2012 10:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 0N4mUED3YDFd for ; Tue, 6 Mar 2012 10:03:34 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9511E8075 for ; Tue, 6 Mar 2012 10:03:33 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id iJ3X1i00837Y3f403J3XrH; Tue, 06 Mar 2012 19:03:32 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 6 Mar 2012 19:03:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis (4rd-u not GMA) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:03:34 -0000 Hi Tina, In this analysis, the 4rd-u port-set algorithm is presented as an = instance of GMA algorithm (i.e. Generalized Modulus Algorithm). I think it would be more appropriate to have it in its own category, = e.g. that of "parameter-less" algorithms (it has no reference to any = modulo operator, and isn't intended to generalize anything) It happens to to be alone in this parameter-less category but, since the = goal is standardization, isn't this more good than evil?=20 If you would have plan for a new version, this could maybe be taken care = of. Otherwise, this can be taken as just a comment inspired by your = interesting document. Thanks, RD Le 2012-03-02 =E0 16:35, Tina TSOU a =E9crit : > Dear all, > You may be interested to comment on > = http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-an= alysis/ >=20 > Abstract: > This memo analyses some port set definition algorithms which > encode port set information into IPv6 address so as to support > stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. >=20 >=20 > Tetsuya, Simon and Tina >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Tue Mar 6 10:24:36 2012 Return-Path: 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 1919721F8900 for ; Tue, 6 Mar 2012 10:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7slBb5-xLm8v for ; Tue, 6 Mar 2012 10:24:35 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CBE9821F88FE for ; Tue, 6 Mar 2012 10:24:27 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H004FU74I05@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 07 Mar 2012 02:24:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H00CTM74GIQ@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 07 Mar 2012 02:24:18 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH00937; Wed, 07 Mar 2012 02:24:18 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 02:23:38 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 02:24:07 +0800 Date: Tue, 06 Mar 2012 18:24:06 +0000 From: Tina TSOU In-reply-to: To: GangChen Message-id: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Softwires] Port Set Definition Algorithms Analysis Thread-index: AQHM+Iod6SRBB91o0kWXL4mv1Pb6XZZcj3UAgAEMGB4= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:24:36 -0000 Sent from my iPad On Mar 6, 2012, at 2:24 AM, "GangChen" wrote: > Hello Tina, > > Could you help to clarify the sentence: > > *1 MAP and divi-pd provide better security than 4rd-U, because they > provide more variation in port set definition. > > I guess they should have similar features on security Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to security. So I propose to remove this sentence. > > Gang > > 2012/3/2, Tina TSOU : >> Dear all, >> You may be interested to comment on >> http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/ >> >> Abstract: >> This memo analyses some port set definition algorithms which >> encode port set information into IPv6 address so as to support >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. >> >> >> Tetsuya, Simon and Tina >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> From simon.perreault@viagenie.ca Tue Mar 6 10:30:16 2012 Return-Path: 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 2E66A21E80C9 for ; Tue, 6 Mar 2012 10:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 EcG2Uksh8oBF for ; Tue, 6 Mar 2012 10:30:15 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E114621F84F1 for ; Tue, 6 Mar 2012 10:28:58 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:a11b:9b29:9caf:fd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1CD6721CC2 for ; Tue, 6 Mar 2012 13:28:57 -0500 (EST) Message-ID: <4F565768.5050402@viagenie.ca> Date: Tue, 06 Mar 2012 13:28:56 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Port Set Definition Algorithms Analysis (4rd-u not GMA) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:30:16 -0000 On 2012-03-06 13:03, Rémi Després wrote: > In this analysis, the 4rd-u port-set algorithm is presented as an instance of GMA algorithm (i.e. Generalized Modulus Algorithm). > I think it would be more appropriate to have it in its own category, e.g. that of "parameter-less" algorithms (it has no reference to any modulo operator, and isn't intended to generalize anything) > It happens to to be alone in this parameter-less category but, since the goal is standardization, isn't this more good than evil? I'm not sure moving 4rd-U to its own section would be useful for the purposes of the document. What's important here is the similarity between 4rd-U, MAP, and divi-pd, not the number of parameters that they use. This similarity allows us to derive a single summary table containing properties shared by all of them (section 3.1.4). Note that the draft says "GMA-style" algorithms, which gives us some leeway... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From phdgang@gmail.com Tue Mar 6 23:33:41 2012 Return-Path: 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 8927121E807D for ; Tue, 6 Mar 2012 23:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ryKuIhvBGa43 for ; Tue, 6 Mar 2012 23:33:40 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 609E121E804E for ; Tue, 6 Mar 2012 23:33:40 -0800 (PST) Received: by werb10 with SMTP id b10so4653276wer.31 for ; Tue, 06 Mar 2012 23:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=32o6blm71hAuHFKYTz2/t20VPufD5PSuq3zvuRipmCk=; b=i+Fj46yA3VLh/8ZiIoLtU1p9Npd5DR8p/CFu+OSCJNJ0GCtErtPNmsUdYWHJLmMLoe sTopLWDvLLrrZMQlQGzQ6lfOxTBhKoIqsXrlwzun/qO/gJqgogcVjfrgX6ZY/ADujZww AJbcclkqYQVAlYc9gNWu3CaygM/oZcukf6zt1MPV9nQ7o1cQ0PaQxET2AAEKMj27Ebw1 RxaRsLKBq+MuaEFiZ6VD/tmtRWY/EkeMeBwZsMmYu2jW2cJw9r40MzSrkSBrMO3KHlj+ BAMlgpt+z6I3C1buSeSo9I7XRv+/GRS5r/MNcpNh99gSaK9r/SKfkMozQJfizpwr9RlC eTGA== MIME-Version: 1.0 Received: by 10.180.87.100 with SMTP id w4mr1727044wiz.22.1331105619431; Tue, 06 Mar 2012 23:33:39 -0800 (PST) Received: by 10.180.7.105 with HTTP; Tue, 6 Mar 2012 23:33:39 -0800 (PST) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> Date: Wed, 7 Mar 2012 15:33:39 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:33:41 -0000 2012/3/6, R=E9mi Despr=E9s : > >> Generally speaking, I'm not sure always carrying fragmentation header >> in 4rd domain is a good idea. >> Since the receiver always treat that as regular fragments. >> That means it tries to reassembly on the BRs and cause some potential >> risks. > > A receiver that receives a fragment header showing that the packet is > compete (Offset=3DO, M=3D0) has no reassembly to perform. > No new risk is therefore introduced. I guess that meet the definition of so-called "atomic fragment". It's better to involve some discussions with 6man >> Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt > > Note that in the 4rd case, the only destinations of Tunnel packets are CE= s > or BRs (or also NAT64+ as discussed below). > No conflict can exist with hosts that might have a provisional difficulty > with a received fragment header having Offset=3D0 and M=3D0. How about the two CPE sharing one IPv4 address in hub&spoke mode? Are there some risks if CPEs send packages with identical ID in IPv6 fragmentation header? >> Secondly, -04 added NAT64+ parts. >> If I understood correctly, there are no additional requirements for NAT6= 4 >> boxes. > > Well, NAT64 boxes remain what they are. > Any host can use BIH to look like an IPv6-only host in the NAT64 although= it > has a dual stack. > > But the advantage of 4rd tunneling over RFC6145 double translation is bet= ter > IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that = may > use the TCP checksum algorithms) > For an ISP to extend this advantage to its stateful NAT64, it need to be = 4rd > aware (become a NAT64+). > NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a = V > octet instead of a "u" octet), use the 4rd header mapping instead of RFC6= 145 > translation. I perfer to leave NAT64 out of scope. Such transparency could be achieved by whther to add fragmentation header. Anyway, let's hear some comments from the group >> The only change is to add NAT64+ mapping rule into the domain. >> I guess the intention is to let 4rd-u become friendly to NAT64, since >> some operators already deployed it. > > It is to extend advantages of full transparency of header mapping to ISPs > that deploy stateful NAT64s. > > >> IMHO, that seems unnecessary. NAT64 is another standalone system. >> 4rd-U could naturally coexist with NAT64 by taking proper routing >> planning. >> And, you have a good designing on V bits. >> There should be no additional works requested to make these two sets >> into unified one. > >> Besides, I guess NAT64+ mapping rule in some sense would do same thing >> in I-D.ietf-behave-nat64-discovery-heuristic > > Only almost the same thing, a MAP64+ mapping rule must be announced ONLY > with NAT64s that are upgraded to be NAT64+s. > >> Going into more detailed, I guess there are some editorial suggestions. >> In Table 2: >> I guess the field of IDENTIFICATION is missing > > Not understood: > > +---------------------+-----------------------------------------+ > | IPv4 FIELDS | VALUES SET AT DOMAIN EXIT | > +---------------------+-----------------------------------------+ > ... > | Identification | IPv4 ID | > ... > Table 2 > Ok. I missed that. This comment is withdrawed BRs Gang >> In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule >> IPv6 suffix" > > Yes, thanks. > > >> In R-7, it uses the indicator of k. I guess that is different meaning >> with k in R-5? > > Yes > Was supposed to be clear enough, but will replace k by s in R-5, no probl= em. > >> In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it >> would be duplicated with sixth column > > Good catch, thanks. > > >> I might back with more comments after my second review. >> Many thanks > > > Kind regards, > RD > > > >> >> Gang >> >> >> 2012/3/6, R=E9mi Despr=E9s : >>> Hello all, >>> >>> The new version of the unified 4rd proposal is now available at: >>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 >>> >>> A summarized comparison of its features with those of MAP-T and MAP-E i= s >>> about to be posted in draft-despres-softwire-stateless-analysis-tool-01= . >>> >>> All questions and comments are most welcome. >>> >>> Regards, >>> Remi, Reinaldo, Jacni, Yiu >>> >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> > > From despres.remi@laposte.net Wed Mar 7 00:21:05 2012 Return-Path: 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 586FF21E80D1 for ; Wed, 7 Mar 2012 00:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 pL6C4UqKmK78 for ; Wed, 7 Mar 2012 00:21:04 -0800 (PST) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 65C5221E80AF for ; Wed, 7 Mar 2012 00:21:03 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id iYM11i00437Y3f403YM10Q; Wed, 07 Mar 2012 09:21:02 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 7 Mar 2012 09:21:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:21:05 -0000 Ole, I just discovered that my previous email didn't have, by mistake, the = Softwire ML as destination. Since the subject is clearly of common interest, and has nothing secret, = I correct now the mistake. =20 Comments in line. 2012-03-06 21:28, Ole Tr=F8an: > Remi, >=20 >> Trying to figure out what the MAP port-set algorithm is, I was = confused: >> (a) According to MAP dhcp-option-02, parameters are AFAIK: >> - the PSID length (implicit, derived from ea-len and prefix4-len) >> - excluded-ports >> - offset >> (b) According to MAP address-and-port-03 parameters are: >> - Sharing ratio R=20 >> - Maximum number of contiguous ports M >> - an apparently fixed set of excluded ports (0-4095) >> Could you clarify what is proposed? >=20 > sharing ratio can be derived from the PSID length. M can be derived = from 16 - offset - PSID length. > PSID length is derived from EA-bits length. > the only specific to the algorithm that may be provisioned (it is = optional) is the offset. > and in theory the excluded ports. "in theory" doesn't really clarify. Is it a parameter? - If yes, the MAP-address-and-port draft needs AFAIK an update - If no, the MAP-dhcp-02 draft needs AFAIK to be modified If I missed something, thanks for an explanation. =20 > my personal view, is that we should drop the optional parameters too. Sees (*) below. > the algorithm would still be the same though. See (**) below >> 2. >> Detailed MAP examples you give have excluded ports 0-4095, offset=3D4, = and no M. >> This is exactly what 4rd has without needing any parameter, and with = a trivial algorithm instead of the somewhat brain-teasing algorithm = copied below. >> Could you clarify which use cases you see that would justify such = complexity? (*) So, you don't personally see any use case than would justify a = PSID-algorithm parameter. We both agree on this. > I think you misunderstand. what you see below is the 4rd algorithm. ??? (see below) > please write an implementation of your version of the algorithm, and = see if you don't end up with pretty much the same as is shown below. (**) 4rd derives a port set from a PSID as shown in the picture below. I = would implement it with masks and shifts rather than with = multiplications and divisions and, in any case, without needing to think = of any "Maximum number of contiguous ports" and a "Sharing ratio". : 4 : =20 +---+----+---------+ Ports in the CE port set |> 0|PSID|any value| +---+----+---------+ : 16 : Cheers, RD >=20 >> Copied of your section 4.1: >> The port number (P) of a given PSID (K) is composed of: P =3D R * M * = j + M * K + i Where:=20 >> * PSID: K =3D 0 to R - 1 >> * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, = if the well-known port numbers (0 - 4096) are excluded. >> * Contiguous Port index: i =3D 0 to M - 1" >=20 > cheers, > Ole From fibrib@gmail.com Wed Mar 7 00:58:19 2012 Return-Path: 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 5CF9121F8773 for ; Wed, 7 Mar 2012 00:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 L+EzT8eHv9Ms for ; Wed, 7 Mar 2012 00:58:18 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF55621F8768 for ; Wed, 7 Mar 2012 00:58:17 -0800 (PST) Received: by qcsq13 with SMTP id q13so3786671qcs.31 for ; Wed, 07 Mar 2012 00:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eh46mAbuGeUCPa/yjtG8oP20fYRon3siDFDLkLhdxP8=; b=Su9a22wyghUgRKKMI1f/8mYKZo5iFRO1T5R0zMZNtNzzsTZRw2l6kvzarKCeiaLJYT IkZm5xTtD1fMeYmGgMjLHYH5Fu5BYLpLcJ2BHxVXFyaYPQyqDF2N6N0i9g/9inFJMc72 C25BUt9K+UEJrbGkNBTUoryYOAnIxXHSODiuX83x6y97wYBw89KqQHj6BYWfjv3t+b8V dsDRzBL60JRc++C/sQylzEQTL+vg2F8+TRzmDqDJoLaDrBKtDLdd7JqmHoxh+Sem/hhq 3kx2rQYhIW04o5Rv3DLpiOdn61qUJ+VugI3nc+dgpaUfrjmUb2Er/DuIuTK07IJlwgHQ xmag== MIME-Version: 1.0 Received: by 10.224.59.194 with SMTP id m2mr586864qah.46.1331110697382; Wed, 07 Mar 2012 00:58:17 -0800 (PST) Received: by 10.229.34.19 with HTTP; Wed, 7 Mar 2012 00:58:17 -0800 (PST) In-Reply-To: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> References: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> Date: Wed, 7 Mar 2012 17:58:17 +0900 Message-ID: From: Maoke To: Tina TSOU Content-Type: multipart/alternative; boundary=20cf306f77b446347904baa35cb4 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:58:19 -0000 --20cf306f77b446347904baa35cb4 Content-Type: text/plain; charset=ISO-8859-1 2012/3/7 Tina TSOU > > > Sent from my iPad > > On Mar 6, 2012, at 2:24 AM, "GangChen" wrote: > > > Hello Tina, > > > > Could you help to clarify the sentence: > > > > *1 MAP and divi-pd provide better security than 4rd-U, because they > > provide more variation in port set definition. > > > > I guess they should have similar features on security > Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to > security. So I propose to remove this sentence. > well, *better security* might be an inaccurate expresssion. i suppose MAP provides better flexibility than 4rd-U. personally, i understand the reason of 4rd-U requiring fixed offset (4bits) is to support the longest-match of port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a tradeoff. without the fixed offset, longest-match fails for the PSID matching and there must be a way of distributing CE's PSID to other CEs. however, it does also confuses me that the newest 4rd-U draft doesn't mention the MAX PSID feature (or maybe i missed something). > > > > Gang > > > > 2012/3/2, Tina TSOU : > >> Dear all, > >> You may be interested to comment on > >> > http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/ > >> > >> Abstract: > >> This memo analyses some port set definition algorithms which > >> encode port set information into IPv6 address so as to support > >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. > >> > >> > >> Tetsuya, Simon and Tina > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf306f77b446347904baa35cb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/7 Tina TSOU <= ;Tina.Tsou.Zouting@huawei.c= om>


Sent from my iPad

On Mar 6, 2012, at 2:24 AM, "GangChen" <phdgang@gmail.com> wrote:

> Hello Tina,
>
> Could you help to clarify the sentence:
>
> =A0 *1 MAP and divi-pd provide better security than 4rd-U, because the= y
> =A0 provide more variation in port set definition.
>
> I guess they should have similar features on security
Agreed. No much difference between MAP, divi-pd, and 4rd-U with regar= d to security. So I propose to remove this sentence.
=A0
well, *better securit= y* might be an inaccurate expresssion. i suppose MAP provides better flexib= ility than 4rd-U. personally, i understand the reason of 4rd-U requiring fi= xed offset (4bits) is to support the longest-match of port for CE-finding i= n the mesh mode (i.e., the MAX PSID). it is a tradeoff. without the fixed o= ffset, longest-match fails for the PSID matching and there must be a way of= distributing CE's PSID to other CEs. however, it does also confuses me= that the newest 4rd-U draft doesn't mention the MAX PSID feature (or m= aybe i missed something).
=A0
>
> Gang
>
> 2012/3/2, Tina TSOU <Tina.Tsou.Zouting@huawei.com>:
>> Dear all,
>> You may be interested to comment on
>> http://datatracker.ietf.org/d= oc/draft-tsou-softwire-port-set-algorithms-analysis/
>>
>> Abstract:
>> =A0This memo analyses some port set definition algorithms which >> =A0encode port set information into IPv6 address so as to support<= br> >> =A0stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and = MAP.
>>
>>
>> Tetsuya, Simon and Tina
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf306f77b446347904baa35cb4-- From despres.remi@laposte.net Wed Mar 7 02:03:09 2012 Return-Path: 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 35ED021F87A8 for ; Wed, 7 Mar 2012 02:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MvjEB6nzlAE6 for ; Wed, 7 Mar 2012 02:03:08 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37E21F86E4 for ; Wed, 7 Mar 2012 02:03:07 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id ia351i00237Y3f403a35xl; Wed, 07 Mar 2012 11:03:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F565768.5050402@viagenie.ca> Date: Wed, 7 Mar 2012 11:03:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <904D861D-CCAB-41EC-98C9-ED2C602B4162@laposte.net> References: <4F565768.5050402@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Port Set Definition Algorithms Analysis (4rd-u not GMA) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:03:09 -0000 Le 2012-03-06 =E0 19:28, Simon Perreault a =E9crit : > On 2012-03-06 13:03, R=E9mi Despr=E9s wrote: >> In this analysis, the 4rd-u port-set algorithm is presented as an = instance of GMA algorithm (i.e. Generalized Modulus Algorithm). >> I think it would be more appropriate to have it in its own category, = e.g. that of "parameter-less" algorithms (it has no reference to any = modulo operator, and isn't intended to generalize anything) >> It happens to to be alone in this parameter-less category but, since = the goal is standardization, isn't this more good than evil? >=20 > I'm not sure moving 4rd-U to its own section would be useful for the = purposes of the document. What's important here is the similarity = between 4rd-U, MAP, and divi-pd, not the number of parameters that they = use. This similarity allows us to derive a single summary table = containing properties shared by all of them (section 3.1.4). No problem > Note that the draft says "GMA-style" algorithms, which gives us some = leeway... Well, no big concern. Just making the point that there is no need to understand GMA to = understand 4rd-u. Thanks, RD >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Mar 7 02:24:17 2012 Return-Path: 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 94D8721F87DD for ; Wed, 7 Mar 2012 02:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 2APXLJ+U347F for ; Wed, 7 Mar 2012 02:24:16 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0F521F87C7 for ; Wed, 7 Mar 2012 02:24:15 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id iaQB1i00837Y3f403aQCM8; Wed, 07 Mar 2012 11:24:12 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-72-621333388 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 7 Mar 2012 11:24:11 +0100 Message-Id: <3BF7F61A-3D68-40DC-A0E2-E358093B152A@laposte.net> References: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:24:17 -0000 --Apple-Mail-72-621333388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Tina, Le 2012-03-07 =E0 09:58, Maoke a =E9crit : >=20 >=20 > 2012/3/7 Tina TSOU >=20 >=20 > Sent from my iPad >=20 > On Mar 6, 2012, at 2:24 AM, "GangChen" wrote: >=20 > > Hello Tina, > > > > Could you help to clarify the sentence: > > > > *1 MAP and divi-pd provide better security than 4rd-U, because = they > > provide more variation in port set definition. > > > > I guess they should have similar features on security > Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard = to security. So I propose to remove this sentence. +1 (see below) >=20 > well, *better security* might be an inaccurate expresssion. i suppose = MAP provides better flexibility than 4rd-U. personally, i understand the = reason of 4rd-U requiring fixed offset (4bits) is to support the = longest-match of port for CE-finding in the mesh mode (i.e., the MAX = PSID). it is a tradeoff. without the fixed offset, longest-match fails = for the PSID matching and there must be a way of distributing CE's PSID = to other CEs. however, > it does also confuses me that the newest 4rd-U draft doesn't mention = the MAX PSID feature (or maybe i missed something). The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF 82), = was abandoned during the Taipei meeting (November 2011) It no longer appeared in -02 (December 29). Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of -04): "NOTE: The choice of the PSID position in Port fields has been guided by = the following objectives: (1) for fairness, avoid having any of the = well-known ports 0-1023 in the port set specified by any PSID value = (these ports have more value than others); (2) for compatibility = RTP/RTCP [RFC4961], include in each port set pairs of consecutive ports; = (3) in order to facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to facilitate documentation = in hexadecimal notation, and to facilitate operation and training, have = the PSID at a fixed position in port fields; (4) in order to facilitate = documentation in hexadecimal notation, and to facilitate operation and = training, have the PSID at a fixed position in port fields; (4) in order = to facilitate documentation in hexadecimal notation, and to facilitate." Hope it clarifies. Regards, RD > =20 > > > > Gang > > > > 2012/3/2, Tina TSOU : > >> Dear all, > >> You may be interested to comment on > >> = http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-an= alysis/ > >> > >> Abstract: > >> This memo analyses some port set definition algorithms which > >> encode port set information into IPv6 address so as to support > >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and = MAP. > >> > >> > >> Tetsuya, Simon and Tina > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-72-621333388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Tina,

Le 2012-03-07 =E0 09:58, Maoke a =E9crit = :



2012/3/7 Tina TSOU = <Tina.Tsou.Zouting@huawei.com<= /a>>


Sent from my iPad

On Mar 6, 2012, at 2:24 AM, "GangChen" <phdgang@gmail.com> wrote:

> Hello Tina,
>
> Could you help to clarify the sentence:
>
>   *1 MAP and divi-pd provide better security than 4rd-U, = because they
>   provide more variation in port set definition.
>
> I guess they should have similar features on security
Agreed. No much difference between MAP, divi-pd, and 4rd-U with = regard to security. So I propose to remove this = sentence.

+1 (see = below)


well, *better = security* might be an inaccurate expresssion. i suppose MAP provides = better flexibility than 4rd-U. personally, i understand the reason of = 4rd-U requiring fixed offset (4bits) is to support the longest-match of = port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a = tradeoff. without the fixed offset, longest-match fails for the PSID = matching and there must be a way of distributing CE's PSID to other CEs. = however,


it does also confuses me = that the newest 4rd-U draft doesn't mention the MAX PSID feature (or = maybe i missed something). =

The max PSID feature, = present in 4rd-u-00 and -01 (i.e. before IETF 82), was abandoned during = the Taipei meeting (November 2011)
It no longer appeared in = -02 (December 29).

Reasons of the 4rd-u fixed = offset are (ref. sec 4.3 of -04):
"NOTE: The choice of = the PSID position in Port fields has been guided by the following = objectives: (1) for fairness, avoid having any of the well-known = ports 0-1023 in the port set specified by any PSID value (these = ports have more value than others); (2) for compatibility RTP/RTCP = [RFC4961], include in each port set pairs of consecutive ports; (3) = in order to facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to = facilitate documentation in hexadecimal notation, and to = facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to = facilitate documentation in hexadecimal notation, and to = facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to = facilitate documentation in hexadecimal notation, and to = facilitate."

Hope it = clarifies.

Regards,
RD



 
>
> Gang
>
> 2012/3/2, Tina TSOU <Tina.Tsou.Zouting@huawei.com<= /a>>:
>> Dear all,
>> You may be interested to comment on
>> http://datatracker.ietf.org/doc/draft-tsou-softwire-port= -set-algorithms-analysis/
>>
>> Abstract:
>>  This memo analyses some port set definition algorithms = which
>>  encode port set information into IPv6 address so as to = support
>>  stateless IPv4 to IPv6 transition technologies, e.g. = 4rd-U and MAP.
>>
>>
>> Tetsuya, Simon and Tina
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-72-621333388-- From despres.remi@laposte.net Wed Mar 7 02:53:39 2012 Return-Path: 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 2C16E21F870F for ; Wed, 7 Mar 2012 02:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_61=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 Dg3jgmum++Wy for ; Wed, 7 Mar 2012 02:53:38 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2C21F86C2 for ; Wed, 7 Mar 2012 02:53:37 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id iatZ1i00J37Y3f403atZBc; Wed, 07 Mar 2012 11:53:35 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 7 Mar 2012 11:53:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:53:39 -0000 Gang, Le 2012-03-07 =E0 08:33, GangChen a =E9crit : > 2012/3/6, R=E9mi Despr=E9s : >>=20 >>> Generally speaking, I'm not sure always carrying fragmentation = header >>> in 4rd domain is a good idea. >>> Since the receiver always treat that as regular fragments. >>> That means it tries to reassembly on the BRs and cause some = potential >>> risks. >>=20 >> A receiver that receives a fragment header showing that the packet is >> compete (Offset=3DO, M=3D0) has no reassembly to perform. >> No new risk is therefore introduced. >=20 > I guess that meet the definition of so-called "atomic fragment". Yes, AKA single-fragment packet. =20 > It's > better to involve some discussions with 6man 6man needs not being concerned in this particular instance, because the = fragment header of single-fragment packets only concerns 4rd-aware = nodes (4rd CEs, 4rd BRs, NAT64+s). Note also that the usual rule which says "be strict in what you send and = tolerant in what you receive" is sufficient to imply that all hosts = should accept IPv6 packets with fragment header having Offset=3DO and = M=3D0 (without obligation to send any). =20 >>> Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt >>=20 >> Note that in the 4rd case, the only destinations of Tunnel packets = are CEs >> or BRs (or also NAT64+ as discussed below). >> No conflict can exist with hosts that might have a provisional = difficulty >> with a received fragment header having Offset=3D0 and M=3D0. >=20 > How about the two CPE sharing one IPv4 address in hub&spoke mode? > Are there some risks if CPEs send packages with identical ID in IPv6 > fragmentation header? Section 5.5.1 of 4rd-u-04 makes it impossible. >>> Secondly, -04 added NAT64+ parts. >>> If I understood correctly, there are no additional requirements for = NAT64 >>> boxes. >>=20 >> Well, NAT64 boxes remain what they are. >> Any host can use BIH to look like an IPv6-only host in the NAT64 = although it >> has a dual stack. >>=20 >> But the advantage of 4rd tunneling over RFC6145 double translation is = better >> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols = that may >> use the TCP checksum algorithms) >> For an ISP to extend this advantage to its stateful NAT64, it need to = be 4rd >> aware (become a NAT64+). >> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address = (with a V >> octet instead of a "u" octet), use the 4rd header mapping instead of = RFC6145 >> translation. >=20 > I perfer to leave NAT64 out of scope. NAT64 as is remains out of scope. What is in scope is only the possibility to improve IPv4 transparency of = NAT64 nodes by using transparent tunneling, instead of double = translation, when reached by 4rd CEs (making them NAT64+ nodes). This new capability, introduced in -04, is derived from the 464XLAT = proposal.=20 With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks = can communicate via NAT64s, but IPv4 transparency has limitations which = can be eliminated by upgrading NAT64s to NAT64+ status (a backward = compatible evolution).=20 > Such transparency could be achieved by whther to add fragmentation = header. > Anyway, let's hear some comments from the group OK Thanks, RD >>> The only change is to add NAT64+ mapping rule into the domain. >>> I guess the intention is to let 4rd-u become friendly to NAT64, = since >>> some operators already deployed it. >>=20 >> It is to extend advantages of full transparency of header mapping to = ISPs >> that deploy stateful NAT64s. >>=20 >>=20 >>> IMHO, that seems unnecessary. NAT64 is another standalone system. >>> 4rd-U could naturally coexist with NAT64 by taking proper routing >>> planning. >>> And, you have a good designing on V bits. >>> There should be no additional works requested to make these two sets >>> into unified one. >>=20 >>> Besides, I guess NAT64+ mapping rule in some sense would do same = thing >>> in I-D.ietf-behave-nat64-discovery-heuristic >>=20 >> Only almost the same thing, a MAP64+ mapping rule must be announced = ONLY >> with NAT64s that are upgraded to be NAT64+s. >=20 >>=20 >>> Going into more detailed, I guess there are some editorial = suggestions. >>> In Table 2: >>> I guess the field of IDENTIFICATION is missing >>=20 >> Not understood: >>=20 >> +---------------------+-----------------------------------------+ >> | IPv4 FIELDS | VALUES SET AT DOMAIN EXIT | >> +---------------------+-----------------------------------------+ >> ... >> | Identification | IPv4 ID | >> ... >> Table 2 >>=20 > Ok. I missed that. This comment is withdrawed >=20 > BRs >=20 > Gang >=20 >=20 >>> In R-5, there is term "Domain-IPv6-suffix". I guess it should be = "Rule >>> IPv6 suffix" >>=20 >> Yes, thanks. >>=20 >>=20 >>> In R-7, it uses the indicator of k. I guess that is different = meaning >>> with k in R-5? >>=20 >> Yes >> Was supposed to be clear enough, but will replace k by s in R-5, no = problem. >>=20 >>> In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it >>> would be duplicated with sixth column >>=20 >> Good catch, thanks. >>=20 >>=20 >>> I might back with more comments after my second review. >>> Many thanks >>=20 >>=20 >> Kind regards, >> RD >>=20 >>=20 >>=20 >>>=20 >>> Gang >>>=20 >>>=20 >>> 2012/3/6, R=E9mi Despr=E9s : >>>> Hello all, >>>>=20 >>>> The new version of the unified 4rd proposal is now available at: >>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04 >>>>=20 >>>> A summarized comparison of its features with those of MAP-T and = MAP-E is >>>> about to be posted in = draft-despres-softwire-stateless-analysis-tool-01. >>>>=20 >>>> All questions and comments are most welcome. >>>>=20 >>>> Regards, >>>> Remi, Reinaldo, Jacni, Yiu >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>=20 >>=20 From bingxuere@gmail.com Wed Mar 7 05:53:10 2012 Return-Path: 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 B537821F87AB for ; Wed, 7 Mar 2012 05:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zh4XpD1BKICr for ; Wed, 7 Mar 2012 05:53:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6321F87A9 for ; Wed, 7 Mar 2012 05:53:09 -0800 (PST) Received: by iazz13 with SMTP id z13so10099973iaz.31 for ; Wed, 07 Mar 2012 05:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vfQkxH8DQWUvvClUBFrTzhmCDlBHEaRABUhTbf/tPos=; b=jKiy3NzdSB4bGfdregrjifyuDsA0RmyhfaBVydReVbH/0zkUiyWdPauCQi0vcq7NM4 D+ER8BUe9ihVOcM8TFWUpmsduCsdr9cILndBPfxeJfen5OudpmDbGi/4R0oSnF9Km7Oc ISjITlPUGoadJKAcWHl/aEQBqw/caTwBwBFqhMsZRo4vHtAj6qdQTz1abcEURuJ6mCSR lcyO/8v/hLtSs79NwuckDGaV46gUayi1zzkg+MpNr4xklg4Xi1EQDzFCrSrWDdAjYSXN TJKvGZtwbQUZIKAUHtSAKT593x/hJxNOgZRPUCPiSN8G+BqTHS3OYizPefl7ihi+DzmH Mm1g== Received: by 10.42.108.6 with SMTP id f6mr1481935icp.7.1331128389488; Wed, 07 Mar 2012 05:53:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.145.138 with HTTP; Wed, 7 Mar 2012 05:52:29 -0800 (PST) In-Reply-To: References: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> From: Qiong Date: Wed, 7 Mar 2012 21:52:29 +0800 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf303639b1ce508804baa77a8e Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:53:10 -0000 --20cf303639b1ce508804baa77a8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Cameron, With regard to DHCPv6 patch for Andorid, we have implemented one and have succeed in IPv6 trail for several CDMA phones including Moto XT800, ME811, etc. It is not so difficult : ) Best wishes Qiong On Wed, Mar 7, 2012 at 12:00 AM, Cameron Byrne wrote: > > On Mar 6, 2012 6:29 AM, "R=C3=A9mi Despr=C3=A9s" wrote: > > > > Hi, Cameron, > > > > Le 2012-03-06 =C3=A0 13:43, Cameron Byrne a =C3=A9crit : > > > >> On Mar 6, 2012 3:56 AM, "Ole Tr=C3=B8an" wrote: > >> > > >> > Cameron, > >> > > >> > > Is it the case that MAP deployments require DHCPv6 and therefore f= or > >> > > mobile the solution is scoped only for 3GPP release 10 and beyond > >> > > networks? > >> > > >> > MAP could be provisioned with whatever protocol you like. DHCPv6 is > kind of the obvious one and the one IETF controls. > >> > which one would fit best in a 3GPP environment? GTP (or DNS)? > >> > > >> > >> None come to mind. > >> > >> GTP with PCO might work, but I think it would end up being a lot of sd= o > heavy lifting to make that work and the timeline would be long. > >> > >> I am still unclear on how MAP works. Is it a /128 that the CE must us= e > so that magic happens ? If so, I am not even sure that is scoped currentl= y > in 3gpp since the use case is pd with dhcpv6 > >> > >> For someone who wants MAP to work in 3gpp, the best path may be to hol= d > out for dhcpv6 and make specific requirements on how the ue must source > traffic from an address acquired from dhcpv6 when MAP is the transition > solution. > >> > >> But, it may end up looking like a square peg pounded into a round > hole. But, such is life in transition > > > > Any idea why it would be so difficult to have DHVPv6 in Android phones, > noting that it would NOT imply support of many DHCPv6 options. > > > > I don't know. In 2012, it is not there yet in either the handsets or any > of the mobile infrastructure components, Afaik. > > Cb > > > In the context of your question, MAP options should be sufficient. > > (Note that the same comment applies to 4rd if retained as unified > standard, but this is a separate discussion.) > > > > RD > > > > > >> Cb > >> > >> On Mar 6, 2012 3:56 AM, "Ole Tr=C3=B8an" wrote: > >>> > >>> Cameron, > >>> > >>> > Is it the case that MAP deployments require DHCPv6 and therefore fo= r > >>> > mobile the solution is scoped only for 3GPP release 10 and beyond > >>> > networks? > >>> > >>> MAP could be provisioned with whatever protocol you like. DHCPv6 is > kind of the obvious one and the one IETF controls. > >>> which one would fit best in a 3GPP environment? GTP (or DNS)? > >>> > >>> cheers, > >>> Ole > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf303639b1ce508804baa77a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Cameron,

With regard to DHCPv6 patch for Andorid, we have impleme= nted one and have succeed in IPv6 trail for several CDMA phones including M= oto XT800, ME811, etc. It is not so difficult : )

Best wishes

Qiong

On Wed, Mar 7, 2012 at 12:00 AM= , Cameron Byrne <cb.list6@gmail.com> wrote:


On Mar 6, 2012 6:29 AM, "R=C3=A9mi Despr=C3=A9s" <despres.remi@laposte.net<= /a>> wrote:
>
> Hi, Cameron,
>
> Le 2012-03-06 =C3=A0 13:43, Cameron Byrne a =C3=A9crit :
>
>> On Mar 6, 2012 3:56 AM, "Ole Tr=C3=B8an" <otroan@employees.org>= wrote:
>> >
>> > Cameron,
>> >
>> > > Is it the case that MAP deployments require DHCPv6 and t= herefore for
>> > > mobile the solution is scoped only for 3GPP release 10 a= nd beyond
>> > > networks?
>> >
>> > MAP could be provisioned with whatever protocol you like. DHC= Pv6 is kind of the obvious one and the one IETF controls.
>> > which one would fit best in a 3GPP environment? GTP (or DNS)?=
>> >
>>
>> None come to mind.
>>
>> GTP with PCO might work, but I think it would end up being a lot o= f sdo heavy lifting to make that work and the timeline would be long.
>>
>> I am still unclear on how MAP works.=C2=A0 Is it a /128 that the C= E must use so that magic happens ? If so, I am not even sure that is scoped= currently in 3gpp since the use case is pd with dhcpv6
>>
>> For someone who wants MAP to work in 3gpp, the best path may be to= hold out for dhcpv6 and make specific requirements on how the ue must sour= ce traffic from an address acquired from dhcpv6 when MAP is the transition = solution.
>>
>> But, it may end up looking like a square peg pounded into a round = hole.=C2=A0But, such is life in transition
>
> Any idea why it would be so difficult to have DHVPv6 in Android phones= , noting that=C2=A0it would NOT imply support of many DHCPv6 options.
>

I don't know.=C2=A0 In 2012, it is not there yet in either the= handsets or any of the mobile infrastructure components, Afaik.

Cb

> In the context of your question, MAP options should be sufficient.<= br> > (Note that the same comment applies to 4rd if retained as unified stan= dard, but this is a separate discussion.)
>
> RD
>
>
>> Cb
>>
>> On Mar 6, 2012 3:56 AM, "Ole Tr=C3=B8an" <otroan@employees.org>= wrote:
>>>
>>> Cameron,
>>>
>>> > Is it the case that MAP deployments require DHCPv6 and th= erefore for
>>> > mobile the solution is scoped only for 3GPP release 10 an= d beyond
>>> > networks?
>>>
>>> MAP could be provisioned with whatever protocol you like. DHCP= v6 is kind of the obvious one and the one IETF controls.
>>> which one would fit best in a 3GPP environment? GTP (or DNS)?<= br> >>>
>>> cheers,
>>> Ole
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@= ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--20cf303639b1ce508804baa77a8e-- From ot@cisco.com Wed Mar 7 06:27:43 2012 Return-Path: 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 4DC0C21F862F for ; Wed, 7 Mar 2012 06:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 z2zApaT07wke for ; Wed, 7 Mar 2012 06:27:42 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BC21F85DB for ; Wed, 7 Mar 2012 06:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=3235; q=dns/txt; s=iport; t=1331130462; x=1332340062; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=v6TLQDW7esJzpjNqxgqhhAcDlTjKIilA1fT1p9VRX04=; b=kZ9tVmHTpVca8YldrEOQARwfRetELHH2Cz3RK8h6fllqplFM7dR2Zf2o 0fE5dkj7s85V8oFxUlqYIcUi3DM6MXXwJh1vStszbmPW/cLMUMuscM6SV yXFB06Xh/akAGUMrv0R2f4IrFM3VZ3bt7U6fzqDS0A8XXU/U4fKu9GQDN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkGAN9vV0+Q/khR/2dsb2JhbABDgwmyDoEHggoBAQEDARIBZhALRlcGLgeHYQWaFAGfLpAMYwSVQYVkijOCZA X-IronPort-AV: E=Sophos;i="4.73,546,1325462400"; d="scan'208";a="67900225" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 14:27:41 +0000 Received: from [10.147.12.146] ([10.147.12.146]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q27ERejN009436; Wed, 7 Mar 2012 14:27:41 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> Date: Wed, 7 Mar 2012 15:27:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:27:43 -0000 Remi, >>> Trying to figure out what the MAP port-set algorithm is, I was = confused: >>> (a) According to MAP dhcp-option-02, parameters are AFAIK: >>> - the PSID length (implicit, derived from ea-len and prefix4-len) >>> - excluded-ports >>> - offset >>> (b) According to MAP address-and-port-03 parameters are: >>> - Sharing ratio R=20 >>> - Maximum number of contiguous ports M >>> - an apparently fixed set of excluded ports (0-4095) >>> Could you clarify what is proposed? >>=20 >> sharing ratio can be derived from the PSID length. M can be derived = from 16 - offset - PSID length. >> PSID length is derived from EA-bits length. >=20 >> the only specific to the algorithm that may be provisioned (it is = optional) is the offset. >> and in theory the excluded ports. >=20 > "in theory" doesn't really clarify. > Is it a parameter? > - If yes, the MAP-address-and-port draft needs AFAIK an update > - If no, the MAP-dhcp-02 draft needs AFAIK to be modified >=20 > If I missed something, thanks for an explanation. you are likely right, that there is some discrepancy between the two. offset versus excluded ports may be an open issue. e.g an offset of 0, = implies that the system ports are included. should we allow that also = for offset > 0. (I would prefer not.) >> my personal view, is that we should drop the optional parameters too. >=20 > Sees (*) below. >=20 >> the algorithm would still be the same though. >=20 > See (**) below >=20 >=20 >>> 2. >>> Detailed MAP examples you give have excluded ports 0-4095, offset=3D4,= and no M. >>> This is exactly what 4rd has without needing any parameter, and with = a trivial algorithm instead of the somewhat brain-teasing algorithm = copied below. >=20 >=20 >>> Could you clarify which use cases you see that would justify such = complexity? >=20 > (*) So, you don't personally see any use case than would justify a = PSID-algorithm parameter. > We both agree on this. my personal preference is for fixed offset, and that the only way to = assign system ports is by assigning a full IPv4 address. the design team = reached a compromise on allowing the algorithm to be tunable though. >> I think you misunderstand. what you see below is the 4rd algorithm. >=20 > ??? (see below) >=20 >> please write an implementation of your version of the algorithm, and = see if you don't end up with pretty much the same as is shown below. >=20 > (**) 4rd derives a port set from a PSID as shown in the picture below. = I would implement it with masks and shifts rather than with = multiplications and divisions and, in any case, without needing to think = of any "Maximum number of contiguous ports" and a "Sharing ratio". >=20 > : 4 : =20 > +---+----+---------+ > Ports in the CE port set |> 0|PSID|any value| > +---+----+---------+ > : 16 : ehem, "any value" is what we call "Maximum number of contiguous ports". = that we chose to label the field, can hardly be an argument for it being = more complex. all shared IP address solution has a notion of sharing ratio. cheers, Ole From despres.remi@laposte.net Wed Mar 7 07:32:14 2012 Return-Path: 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 DEA1E21E80A7 for ; Wed, 7 Mar 2012 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 XtrPyq8ob9pY for ; Wed, 7 Mar 2012 07:32:14 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id EB13921E80A2 for ; Wed, 7 Mar 2012 07:32:12 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id D5A4F940011; Wed, 7 Mar 2012 16:32:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> Date: Wed, 7 Mar 2012 16:32:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:32:15 -0000 Le 2012-03-07 =E0 15:27, Ole Tr=F8an a =E9crit : > Remi, >=20 >>>> Trying to figure out what the MAP port-set algorithm is, I was = confused: >>>> (a) According to MAP dhcp-option-02, parameters are AFAIK: >>>> - the PSID length (implicit, derived from ea-len and prefix4-len) >>>> - excluded-ports >>>> - offset >>>> (b) According to MAP address-and-port-03 parameters are: >>>> - Sharing ratio R=20 >>>> - Maximum number of contiguous ports M >>>> - an apparently fixed set of excluded ports (0-4095) >>>> Could you clarify what is proposed? >>>=20 >>> sharing ratio can be derived from the PSID length. M can be derived = from 16 - offset - PSID length. >>> PSID length is derived from EA-bits length. >>=20 >>> the only specific to the algorithm that may be provisioned (it is = optional) is the offset. >>> and in theory the excluded ports. >>=20 >> "in theory" doesn't really clarify. >> Is it a parameter? >> - If yes, the MAP-address-and-port draft needs AFAIK an update >> - If no, the MAP-dhcp-02 draft needs AFAIK to be modified >>=20 >> If I missed something, thanks for an explanation. >=20 > you are likely right, that there is some discrepancy between the two. > offset versus excluded ports may be an open issue. e.g an offset of 0, = implies that the system ports are included. should we allow that also = for offset > 0. (I would prefer not.) Well, if offset=3D0, it depends the PSID length whether some of of the = 0-1023 ports are distributed among several CEs (only one CE gets, for = example, port 80, or all assigned to a single CE.=20 This is a complexity for which, again, I cannot see a real use case.=20 >=20 >>> my personal view, is that we should drop the optional parameters = too. >>=20 >> Sees (*) below. >>=20 >>> the algorithm would still be the same though. >>=20 >> See (**) below >>=20 >>=20 >>>> 2. >>>> Detailed MAP examples you give have excluded ports 0-4095, = offset=3D4, and no M. >>>> This is exactly what 4rd has without needing any parameter, and = with a trivial algorithm instead of the somewhat brain-teasing algorithm = copied below. >>=20 >>=20 >>>> Could you clarify which use cases you see that would justify such = complexity? >>=20 >> (*) So, you don't personally see any use case than would justify a = PSID-algorithm parameter. >> We both agree on this. >=20 > my personal preference is for fixed offset, and that the only way to = assign system ports is by assigning a full IPv4 address. the design team = reached a compromise on allowing the algorithm to be tunable though. A compromise between what and what? Since there is no MAP-discussion archive, it's hard to guess what the = issue has been. Since we both believe no parameter is needed, can we consider this is = the WG provisional as long as no significant use case is provided? =20 >>> I think you misunderstand. what you see below is the 4rd algorithm. >>=20 >> ??? (see below) >>=20 >>> please write an implementation of your version of the algorithm, and = see if you don't end up with pretty much the same as is shown below. >>=20 >> (**) 4rd derives a port set from a PSID as shown in the picture = below. I would implement it with masks and shifts rather than with = multiplications and divisions and, in any case, without needing to think = of any "Maximum number of contiguous ports" and a "Sharing ratio". >>=20 >> : 4 : =20 >> +---+----+---------+ >> Ports in the CE port set |> 0|PSID|any value| >> +---+----+---------+ >> : 16 : >=20 >=20 > ehem, "any value" is what we call "Maximum number of contiguous = ports". You explanation is still confusing: - Maximum number of contiguous ports is of course NOT "any value". - It should be AFAIK 2^(12 - PSID length). I agree however that, with adequate parameter values, a non ambiguous = Generalized Modulus Algorithm could create port of the PSID-derived port = set above, but all the algorithmic complexity below (copied again since = you deleted it from your response) is completely SUPERFLUOUS to specify = this port set. "The port number (P) of a given PSID (K) is composed of: P =3D R * M * j = + M * K + i Where:=20 * PSID: K =3D 0 to R - 1 * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, if = the well-known port numbers (0 - 4096) are excluded. * Contiguous Port index: i =3D 0 to M - 1" BTW, j is very indirectly defined if excluded ports are different from = 0-4096 (actually 0-4095). Leaving this discussion at this point would be OK for me until a = justification for a flexible algorithm is provided. Cheers, RD =20 > that we chose to label the field, can hardly be an argument for it = being more complex. > all shared IP address solution has a notion of sharing ratio. >=20 > cheers, > Ole >=20 From cb.list6@gmail.com Wed Mar 7 07:33:07 2012 Return-Path: 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 CEDAF21E80A2 for ; Wed, 7 Mar 2012 07:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SkekTVu+e7pJ for ; Wed, 7 Mar 2012 07:33:07 -0800 (PST) Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0421E80B5 for ; Wed, 7 Mar 2012 07:33:07 -0800 (PST) Received: by dang27 with SMTP id g27so7947857dan.15 for ; Wed, 07 Mar 2012 07:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JV3XCOp3rGp/KeC+xL0RWA1AENhhaCIdly/0hdurFzg=; b=RiDSyYoToWyoUjK/zeI7L0Qw1XIPEawYL7rl4lM8xDwdV9ByvS6CFNoogJ+aeW/uU3 /cQDOLfG9/necFFlB3lT1GLbhlY/Hr7fpTa2PUdjAREoh7v+2axA4wCOtIhedRRstwRi tcdDIliHVZVHXs5ugtWq+X4t13I89QPdG36wLXtdAvZR4nVJNcAgLn1LNzPDF0yD1MJW 1LLb4vxSJyWeRZWknTiW7lxh58hLkUkHw+2C4fqPrbH4mGXPZnGjXHNhDXFmkmFOyGke z8lFOxYizDwn1avsn2ykoT6KsK2HtJjm0y943jcXvF5T26kZXqmXVNrRN7mDIrsJyv5S HFpg== MIME-Version: 1.0 Received: by 10.68.225.231 with SMTP id rn7mr4147868pbc.64.1331134387046; Wed, 07 Mar 2012 07:33:07 -0800 (PST) Received: by 10.142.163.16 with HTTP; Wed, 7 Mar 2012 07:33:06 -0800 (PST) In-Reply-To: References: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> Date: Wed, 7 Mar 2012 07:33:06 -0800 Message-ID: From: Cameron Byrne To: Qiong Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:33:07 -0000 On Wed, Mar 7, 2012 at 5:52 AM, Qiong wrote: > Hi Cameron, > > With regard to DHCPv6 patch for Andorid, we have implemented one and have > succeed in IPv6 trail for several CDMA phones including Moto XT800, ME811, > etc. It is not so difficult : ) > Excellent, any chance that patch is being pushed upstream into Android for general use? From mohamed.boucadair@orange.com Wed Mar 7 07:59:39 2012 Return-Path: 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 966EA21E80D9 for ; Wed, 7 Mar 2012 07:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] 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 lenRqvKeKdo6 for ; Wed, 7 Mar 2012 07:59:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7521E80A7 for ; Wed, 7 Mar 2012 07:59:34 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B548D2DC727; Wed, 7 Mar 2012 16:59:33 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 96FB44C096; Wed, 7 Mar 2012 16:59:33 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 7 Mar 2012 16:59:33 +0100 From: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Wed, 7 Mar 2012 16:59:32 +0100 Thread-Topic: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? Thread-Index: Acz8d3ucSG/SmWlxTaSFqUjV+f8VJwAAlL6g Message-ID: <94C682931C08B048B7A8645303FDC9F36748838639@PUEXCB1B.nanterre.francetelecom.fr> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> In-Reply-To: <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.7.140034 Cc: Softwires WG Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:59:39 -0000 Hi R=E9mi, all, During the MAP discussion, we identified the following requirements: R-4: MAP must allow service providers to define their own address sharing ratio. MAP MUST NOT in particular restrict by design the possible address sharing ratio; ideally 1:1 and 1:65536 should be supported. The mapping must at least support a sharing ratio of 64, 1024 ports per end-user. R-7: The MAP solution should support excluding the well known ports 0-1023. R-8: It MUST be possible to assign well known ports to a CE. The offset has been proposed as a flexible means to meet the requirements a= bove. Cheers, Med =20 > -----Message d'origine----- > De : softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] De la part de R=E9mi Despr=E9s > Envoy=E9 : mercredi 7 mars 2012 16:32 > =C0 : Ole Tr=F8an > Cc : Softwires WG > Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 > it? Why so complex? > >=20 > > my personal preference is for fixed offset, and that the=20 > only way to assign system ports is by assigning a full IPv4=20 > address. the design team reached a compromise on allowing the=20 > algorithm to be tunable though. >=20 > A compromise between what and what? > Since there is no MAP-discussion archive, it's hard to guess=20 > what the issue has been. > Since we both believe no parameter is needed, can we consider=20 > this is the WG provisional as long as no significant use case=20 > is provided? From bingxuere@gmail.com Wed Mar 7 08:19:17 2012 Return-Path: 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 8355921F8599 for ; Wed, 7 Mar 2012 08:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.703 X-Spam-Level: X-Spam-Status: No, score=-3.703 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oj9Dp0Ajne9G for ; Wed, 7 Mar 2012 08:19:17 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F251D21F8596 for ; Wed, 7 Mar 2012 08:19:16 -0800 (PST) Received: by iazz13 with SMTP id z13so10279987iaz.31 for ; Wed, 07 Mar 2012 08:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9co3cXJQR5Sc9lMyxDkJ/Kf6ecij6fcXBg9mvIsSvAA=; b=O3hr4k4GIH8IRqftzfwfqoSE1uuNQ7VjqtcPYlH39EjAd8LSGwKOJrD/X3YNY0n3Xu iS+wH5svKszU73gm7XVgKNVkVznRZUimxfZAdX2T6VTpL1d0Hxk1K0lQBLFzhnPFXaMq frnuxb6lY3fALxokoHF4qq72T567uCT8afFOCcq0TqMGueY1WumD5GefOxrJcgsAvXHC Miu7Makq0lR6fG4eokOPO48Max94D4YbndCGarmBJIMjlw7j9ZYsnAHYxQtxnnlMTZO0 /NrNYgEwyO9yrH+Tn9WwWjEJTuqewJONA/oJeSQecYPckf1m+32C1AX3TSmnxojPJACP 7R5A== Received: by 10.50.89.137 with SMTP id bo9mr2340276igb.7.1331137156375; Wed, 07 Mar 2012 08:19:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.145.138 with HTTP; Wed, 7 Mar 2012 08:18:35 -0800 (PST) In-Reply-To: References: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> From: Qiong Date: Thu, 8 Mar 2012 00:18:35 +0800 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f234bd35a632e04baa985d8 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:19:17 -0000 --e89a8f234bd35a632e04baa985d8 Content-Type: text/plain; charset=UTF-8 We have submitted it to google, but google has not finished reviewing it. btw, is there any possible way to accelerate its reviewing process ? It has passed more than half a year. Is there anyone who can help ? Thanks a lot! Best wishes Qiong On Wed, Mar 7, 2012 at 11:33 PM, Cameron Byrne wrote: > On Wed, Mar 7, 2012 at 5:52 AM, Qiong wrote: > > Hi Cameron, > > > > With regard to DHCPv6 patch for Andorid, we have implemented one and have > > succeed in IPv6 trail for several CDMA phones including Moto XT800, > ME811, > > etc. It is not so difficult : ) > > > > Excellent, any chance that patch is being pushed upstream into Android > for general use? > --e89a8f234bd35a632e04baa985d8 Content-Type: text/html; charset=UTF-8 We have submitted it to google, but google has not finished reviewing it.

btw, is there any possible way to accelerate its reviewing process ? It has passed more than half a year. Is there anyone who can help ?

Thanks a lot!

Best wishes

Qiong

On Wed, Mar 7, 2012 at 11:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Wed, Mar 7, 2012 at 5:52 AM, Qiong <bingxuere@gmail.com> wrote:
> Hi Cameron,
>
> With regard to DHCPv6 patch for Andorid, we have implemented one and have
> succeed in IPv6 trail for several CDMA phones including Moto XT800, ME811,
> etc. It is not so difficult : )
>

Excellent, any chance that patch is being pushed upstream into Android
for general use?

--e89a8f234bd35a632e04baa985d8-- From despres.remi@laposte.net Wed Mar 7 08:29:29 2012 Return-Path: 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 A7A3221F8644 for ; Wed, 7 Mar 2012 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 loknSBv39ROH for ; Wed, 7 Mar 2012 08:29:29 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB521F863F for ; Wed, 7 Mar 2012 08:29:28 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id igVS1i00237Y3f403gVSWm; Wed, 07 Mar 2012 17:29:27 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36748838639@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 7 Mar 2012 17:29:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> <94C682931C08B048B7A8645303FDC9F36748838639@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , =?iso-8859-1?Q?Ole_Tr=F8an?= Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:29:29 -0000 Hi Med, I am, as you remember, well aware of these rules.=20 But the fact is that, with the fixed PSID offset =3D 4 of 4rd-u (which = could easily also apply to MAP), we have the following: R-4: sharing ratios are from 1 to 2048 (PSID length limited to 11 for = odd-even pairs always be in port sets) =3D> OK R-7: ports 0-1023 are excluded for sharing ratios 2 to 2048 =3D> OK R-8: well-known ports can be assigned to CEs with sharing ratio 1 =3D> = OK So far, this seems to me so completely sufficient. Yet, if some ISP has a deployment plan where it is convincingly = necessary to have more flexibility, that is of course worth discussing.=20= But if there is none, time has come IMHO to simplify what can be = simplified. Cheers, RD Le 2012-03-07 =E0 16:59, a =E9crit : > Hi R=E9mi, all, >=20 > During the MAP discussion, we identified the following requirements: >=20 > R-4: MAP must allow service providers to define their own address > sharing ratio. MAP MUST NOT in particular restrict by design > the possible address sharing ratio; ideally 1:1 and 1:65536 > should be supported. The mapping must at least support a > sharing ratio of 64, 1024 ports per end-user. >=20 > R-7: The MAP solution should support excluding the well known = ports > 0-1023. >=20 > R-8: It MUST be possible to assign well known ports to a CE. >=20 > The offset has been proposed as a flexible means to meet the = requirements above. >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de R=E9mi Despr=E9s >> Envoy=E9 : mercredi 7 mars 2012 16:32 >> =C0 : Ole Tr=F8an >> Cc : Softwires WG >> Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 >> it? Why so complex? >=20 >>>=20 >>> my personal preference is for fixed offset, and that the=20 >> only way to assign system ports is by assigning a full IPv4=20 >> address. the design team reached a compromise on allowing the=20 >> algorithm to be tunable though. >>=20 >> A compromise between what and what? >> Since there is no MAP-discussion archive, it's hard to guess=20 >> what the issue has been. >> Since we both believe no parameter is needed, can we consider=20 >> this is the WG provisional as long as no significant use case=20 >> is provided? From cb.list6@gmail.com Wed Mar 7 08:57:23 2012 Return-Path: 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 6898321E8017 for ; Wed, 7 Mar 2012 08:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 nebKG6AJekv1 for ; Wed, 7 Mar 2012 08:57:22 -0800 (PST) Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id C688821F8767 for ; Wed, 7 Mar 2012 08:57:21 -0800 (PST) Received: by dang27 with SMTP id g27so8255636dan.15 for ; Wed, 07 Mar 2012 08:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yU4l5wIu9m6+7OKpoD+VEFYZrrY4tX4sfPYic2kFKYY=; b=OvXH5IeV16Ppww53AAjA7Hr02k2J9wisFeuEo93ah6jGvB9q5wWkYfAQCIBDaoMfDR JD5nT48NM0Gg8RRpfvHdHJOxD/HgSVfl4d8FrhF0R8Rm/8vJcp3k5bFD1zUHhf6p9oNz LIo/Pxlt+aJwWx5XlqKBZ/SMrb90YwwMaHhfCEE+8nqUxiJ4dR5uKO2yKrZDbB2yl5wD Rjedw5wLNkwgxpuy8/7vQTwxylVal7INsnvN1dXBCQ3qd4M7y1UhwNLmSV/tVnoU+yt/ DwtR8lOTUWCvphjFZsJ9/Gt+RVfdkftRo3Hv5ua4YcczfRC+GuyzXwoCUamoqYMtdIZA z3ew== MIME-Version: 1.0 Received: by 10.68.228.103 with SMTP id sh7mr4433109pbc.106.1331139441503; Wed, 07 Mar 2012 08:57:21 -0800 (PST) Received: by 10.142.163.16 with HTTP; Wed, 7 Mar 2012 08:57:21 -0800 (PST) Received: by 10.142.163.16 with HTTP; Wed, 7 Mar 2012 08:57:21 -0800 (PST) In-Reply-To: References: <953ABDDC-6D2F-4923-88FC-024711CD1415@laposte.net> Date: Wed, 7 Mar 2012 08:57:21 -0800 Message-ID: From: Cameron Byrne To: Qiong Content-Type: multipart/alternative; boundary=e89a8ff254fa8eacf204baaa0d24 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-mdt-softwire-map-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:57:23 -0000 --e89a8ff254fa8eacf204baaa0d24 Content-Type: text/plain; charset=ISO-8859-1 On Mar 7, 2012 8:19 AM, "Qiong" wrote: > > We have submitted it to google, but google has not finished reviewing it. > That is good you have submitted it to Google Just to set context, this was setup for cdma ... not GSM/UMTS/LTE As stated here http://tools.ietf.org/html/rfc6459#section-5.4 3gpp networks do not support stateful dhcpv6 for assignment to the ue, dhcpv6 is only for prefix delegation and only in release 10+ networks (things that are not deployed anywhere today) Cb > btw, is there any possible way to accelerate its reviewing process ? It has passed more than half a year. Is there anyone who can help ? > > Thanks a lot! > > Best wishes > > Qiong > > > On Wed, Mar 7, 2012 at 11:33 PM, Cameron Byrne wrote: >> >> On Wed, Mar 7, 2012 at 5:52 AM, Qiong wrote: >> > Hi Cameron, >> > >> > With regard to DHCPv6 patch for Andorid, we have implemented one and have >> > succeed in IPv6 trail for several CDMA phones including Moto XT800, ME811, >> > etc. It is not so difficult : ) >> > >> >> Excellent, any chance that patch is being pushed upstream into Android >> for general use? > > --e89a8ff254fa8eacf204baaa0d24 Content-Type: text/html; charset=ISO-8859-1


On Mar 7, 2012 8:19 AM, "Qiong" <bingxuere@gmail.com> wrote:
>
> We have submitted it to google, but google has not finished reviewing it.
>

That is good you have submitted it to Google

Just to set context, this was setup for cdma ... not GSM/UMTS/LTE

As stated here http://tools.ietf.org/html/rfc6459#section-5.4

3gpp networks do not support stateful dhcpv6 for assignment to the ue, dhcpv6 is only for prefix delegation and only in release 10+ networks (things that are not deployed anywhere today)

Cb

> btw, is there any possible way to accelerate its reviewing process ? It has passed more than half a year. Is there anyone who can help ?
>
> Thanks a lot!
>
> Best wishes
>
> Qiong
>
>
> On Wed, Mar 7, 2012 at 11:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> On Wed, Mar 7, 2012 at 5:52 AM, Qiong <bingxuere@gmail.com> wrote:
>> > Hi Cameron,
>> >
>> > With regard to DHCPv6 patch for Andorid, we have implemented one and have
>> > succeed in IPv6 trail for several CDMA phones including Moto XT800, ME811,
>> > etc. It is not so difficult : )
>> >
>>
>> Excellent, any chance that patch is being pushed upstream into Android
>> for general use?
>
>

--e89a8ff254fa8eacf204baaa0d24-- From washam.fan@gmail.com Wed Mar 7 18:47:03 2012 Return-Path: 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 2C17521F85D4 for ; Wed, 7 Mar 2012 18:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 m4Tf0PKJkjr0 for ; Wed, 7 Mar 2012 18:47:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3D21F85D3 for ; Wed, 7 Mar 2012 18:47:02 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so16041wgb.13 for ; Wed, 07 Mar 2012 18:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OQi8BKcyv11yXOqTxanR1YJk/C/AnbMTHqdBDwKDOIA=; b=sMQksIOWIyNDJOvWAX/ys8hWs+3wT0w3XkzVm5AkfYAp/D1NJ31SU1l++lu/LW/Db9 BZoYZFKcDcdsOI3lURg+/ty6rTWo8d3oUeZw2xIRpxQ3iz68bGNqQ/2uvnNyMktOMQ/S 08JyA4ONx6TehSsvxThDXz2F+Y8k52ElsqACXQWoiLj+cL2fjfu/RTKAKysQ9YRCgl5g zOdwu+y68perBkISfdC2ptUozWhvHnGe5g2a9/TEftwLJT8VTaJ6QM59CohdfFMnDDYl WGMnfkFw4KY/itvnXmCZ7F7wrkVeTbPJ1IeIjdR4yPQyRj6cvNVi4A3AKhkNw6j+qjhW E8qQ== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr8544282wib.15.1331174821554; Wed, 07 Mar 2012 18:47:01 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 18:47:01 -0800 (PST) In-Reply-To: <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> Date: Thu, 8 Mar 2012 10:47:01 +0800 Message-ID: From: Washam Fan To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:47:03 -0000 Hi Remi, >>>> Secondly, -04 added NAT64+ parts. >>>> If I understood correctly, there are no additional requirements for NAT64 >>>> boxes. >>> >>> Well, NAT64 boxes remain what they are. >>> Any host can use BIH to look like an IPv6-only host in the NAT64 although it >>> has a dual stack. >>> >>> But the advantage of 4rd tunneling over RFC6145 double translation is better >>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that may >>> use the TCP checksum algorithms) >>> For an ISP to extend this advantage to its stateful NAT64, it need to be 4rd >>> aware (become a NAT64+). >>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a V >>> octet instead of a "u" octet), use the 4rd header mapping instead of RFC6145 >>> translation. >> >> I perfer to leave NAT64 out of scope. > > NAT64 as is remains out of scope. > What is in scope is only the possibility to improve IPv4 transparency of NAT64 nodes by using transparent tunneling, instead of double translation, when reached by 4rd CEs (making them NAT64+ nodes). Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a new term NAT64+ invented? > This new capability, introduced in -04, is derived from the 464XLAT proposal. > With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks can communicate via NAT64s, but IPv4 transparency has limitations which can be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible evolution). > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? Thanks, washam >> Such transparency could be achieved by whther to add fragmentation header. >> Anyway, let's hear some comments from the group > > OK From fibrib@gmail.com Thu Mar 8 02:01:22 2012 Return-Path: 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 BF24D21F8688 for ; Thu, 8 Mar 2012 02:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ozph1AjW2RH5 for ; Thu, 8 Mar 2012 02:01:21 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8421F8687 for ; Thu, 8 Mar 2012 02:01:21 -0800 (PST) Received: by qcsq13 with SMTP id q13so239619qcs.31 for ; Thu, 08 Mar 2012 02:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e29w+Xh/UPy0kNNSXkNMLT48x4vX9sXMppOx8+DOwE0=; b=w9TjF5KyZXTvJ4MBc4is8bksA3JCrpexLAjOv0jmMyUcvRq0KTsz51TTKpjs7udz1h JPocL0KIfOkebrBizMuzbudalisEzLSB+CpdvZFXveafW89meRMFPCYvCcULiWWpGtbX rzyR0yuJi+6Hsg6Xeu/5iD+4TERPJ8uhloj676h7lbG+SQ1omBbloKuft8s4hYiEAZk6 Kd4vO3bm0NNVz8QAmX7LAdwjNCCq9Tg6b2VKPLDC2cMK09y6k9zgLjOmisevCqA6V0uw pmA3nK5vtBKZqjbBRUqCvbrJHW5cluY/CQALYZkRlrRGrLo0k9+niclAe/eqIm2mv7Sh S/cQ== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr3778737qab.13.1331200880866; Thu, 08 Mar 2012 02:01:20 -0800 (PST) Received: by 10.229.98.21 with HTTP; Thu, 8 Mar 2012 02:01:20 -0800 (PST) In-Reply-To: <3BF7F61A-3D68-40DC-A0E2-E358093B152A@laposte.net> References: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> <3BF7F61A-3D68-40DC-A0E2-E358093B152A@laposte.net> Date: Thu, 8 Mar 2012 19:01:20 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef7a0f51a04bab85b00 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:01:22 -0000 --20cf30363ef7a0f51a04bab85b00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/7 R=E9mi Despr=E9s > Hi Tina, > > Le 2012-03-07 =E0 09:58, Maoke a =E9crit : > > > > 2012/3/7 Tina TSOU > >> >> >> Sent from my iPad >> >> On Mar 6, 2012, at 2:24 AM, "GangChen" wrote: >> >> > Hello Tina, >> > >> > Could you help to clarify the sentence: >> > >> > *1 MAP and divi-pd provide better security than 4rd-U, because they >> > provide more variation in port set definition. >> > >> > I guess they should have similar features on security >> Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard t= o >> security. So I propose to remove this sentence. >> > > +1 (see below) > > > > well, *better security* might be an inaccurate expresssion. i suppose MAP > provides better flexibility than 4rd-U. personally, i understand the reas= on > of 4rd-U requiring fixed offset (4bits) is to support the longest-match o= f > port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a > tradeoff. without the fixed offset, longest-match fails for the PSID > matching and there must be a way of distributing CE's PSID to other CEs. > however, > > > > it does also confuses me that the newest 4rd-U draft doesn't mention the > MAX PSID feature (or maybe i missed something). > > > The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF 82), > was abandoned during the Taipei meeting (November 2011) > It no longer appeared in -02 (December 29). > > Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of -04): > "NOTE: The choice of the PSID position in Port fields has been guided by > the following objectives: (1) for fairness, avoid having any of the > well-known ports 0-1023 in the port set specified by any PSID value (thes= e > ports have more value than others); (2) for compatibility RTP/RTCP > [RFC4961], include in each port set pairs of consecutive ports; (3) in > order to facilitate operation and training, have the PSID at a > fixed position in port fields; (4) in order to facilitate documentation i= n > hexadecimal notation, and to facilitate operation and training, have the > PSID at a fixed position in port fields." > > Remi, point (1) is qualified for the individual use case but not available for the enterprise environment, where surely it is possible that one put all well know services under a same CE. but if MAP or 4rd-U states enterprise use case is NOT to be supported, it is fine. point (2) is qualified but not a sufficient condition to derive the fixed position of PSID. point (3) and (4) is about the human reading on the PSID. however, the MAP or 4rd-U address has been human-unfriendly. i don't see training and operation on easy-to-read PSID is significant. therefore i think MAXPSID, though it is abandoned, is a convincing reason of having fixed position of PSID. - maoke > > > Hope it clarifies. > > Regards, > RD > > > > > >> > >> > Gang >> > >> > 2012/3/2, Tina TSOU : >> >> Dear all, >> >> You may be interested to comment on >> >> >> http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-= analysis/ >> >> >> >> Abstract: >> >> This memo analyses some port set definition algorithms which >> >> encode port set information into IPv6 address so as to support >> >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. >> >> >> >> >> >> Tetsuya, Simon and Tina >> >> >> >> _______________________________________________ >> >> Softwires mailing list >> >> Softwires@ietf.org >> >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --20cf30363ef7a0f51a04bab85b00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/7 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>
Hi Tina,

Le 2012-03-0= 7 =E0 09:58, Maoke a =E9crit :



2012/3/7 Tina TSOU <Tina.Tsou.Zouting@huawei.com>


Sent from my iPad

On Mar 6, 2012, at 2:24 AM, "GangChen" <phdgang@gmail.com> wrote:

> Hello Tina,
>
> Could you help to clarify the sentence:
>
> =A0 *1 MAP and divi-pd provide better security than 4rd-U, because the= y
> =A0 provide more variation in port set definition.
>
> I guess they should have similar features on security
Agreed. No much difference between MAP, divi-pd, and 4rd-U with regar= d to security. So I propose to remove this sentence.
=

+1 (see below)



well, *better securi= ty* might be an inaccurate expresssion. i suppose MAP provides better flexi= bility than 4rd-U. personally, i understand the reason of 4rd-U requiring f= ixed offset (4bits) is to support the longest-match of port for CE-finding = in the mesh mode (i.e., the MAX PSID). it is a tradeoff. without the fixed = offset, longest-match fails for the PSID matching and there must be a way o= f distributing CE's PSID to other CEs. however,


it does also confuses me that the newest 4rd-U draft = doesn't mention the MAX PSID feature (or maybe i missed something).

The max PSID feature, present = in 4rd-u-00 and -01 (i.e. before IETF 82), was abandoned during the Taipei = meeting (November 2011)
It no longer appeared in -02 (December 29= ).

Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of = -04):
"NOTE: The choice of the PSID position in Port fi= elds has been=A0guided by the following objectives: (1) for fairness, avoid= =A0having any of the well-known ports 0-1023 in the port set=A0specified by= any PSID value (these ports have more value than=A0others); (2) for compat= ibility RTP/RTCP [RFC4961], include in=A0each port set pairs of consecutive= ports; (3) in order to=A0facilitate operation and training, have the PSID = at a fixed=A0position in port fields; (4) in order to facilitate=A0document= ation in hexadecimal notation, and to facilitate=A0operation and training, = have the PSID at a fixed=A0position in port fields."
=A0
=A0
Remi,=
=A0
point (1) is qualified for the individual use case= =A0but not available for the enterprise environment, where surely it is pos= sible that one put all well know services under a same CE. but if MAP or 4r= d-U states enterprise use case is NOT to be supported, it is fine. point (2= ) is=A0qualified but not a sufficient condition to derive the fixed positio= n of PSID. point (3) and (4) is about the human reading on the PSID. howeve= r, the MAP or 4rd-U address has been human-unfriendly. i don't see trai= ning and operation on easy-to-read PSID is significant.
=A0
therefore i think MAXPSID, though it is abandoned, is a = convincing reason of having fixed position of PSID.
=A0
- maoke
=A0
=A0

<= /div>
Hope it clarifies.

Regards,
<= div>RD



=A0
>
> Gang
>
> 2012/3/2, Tina TSOU <Tina.Tsou.Zouting@huawei.com>:
>> Dear all,
>> You may be interested to comment on
>> http://datatracker.ietf.org/d= oc/draft-tsou-softwire-port-set-algorithms-analysis/
>>
>> Abstract:
>> =A0This memo analyses some port set definition algorithms which >> =A0encode port set information into IPv6 address so as to support<= br> >> =A0stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and = MAP.
>>
>>
>> Tetsuya, Simon and Tina
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@= ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


--20cf30363ef7a0f51a04bab85b00-- From despres.remi@laposte.net Thu Mar 8 06:04:54 2012 Return-Path: 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 E23CC21F86DF for ; Thu, 8 Mar 2012 06:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 bymVZWoCp6C1 for ; Thu, 8 Mar 2012 06:04:54 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0731621F86C4 for ; Thu, 8 Mar 2012 06:04:53 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id j24q1i00537Y3f40324qAt; Thu, 08 Mar 2012 15:04:52 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 8 Mar 2012 15:04:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> To: Washam Fan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:04:55 -0000 Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : > Hi Remi, >=20 >>>>> Secondly, -04 added NAT64+ parts. >>>>> If I understood correctly, there are no additional requirements = for NAT64 >>>>> boxes. >>>>=20 >>>> Well, NAT64 boxes remain what they are. >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 = although it >>>> has a dual stack. >>>>=20 >>>> But the advantage of 4rd tunneling over RFC6145 double translation = is better >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols = that may >>>> use the TCP checksum algorithms) >>>> For an ISP to extend this advantage to its stateful NAT64, it need = to be 4rd >>>> aware (become a NAT64+). >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address = (with a V >>>> octet instead of a "u" octet), use the 4rd header mapping instead = of RFC6145 >>>> translation. >>>=20 >>> I perfer to leave NAT64 out of scope. >>=20 >> NAT64 as is remains out of scope. >> What is in scope is only the possibility to improve IPv4 transparency = of NAT64 nodes by using transparent tunneling, instead of double = translation, when reached by 4rd CEs (making them NAT64+ nodes). >=20 > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a > new term NAT64+ invented? NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 = needs to be upgraded to replace RFC5145 translation by header mapping = when IPv6 addresses it deals with are 4rd addresses (have the V octet).=20= >=20 >> This new capability, introduced in -04, is derived from the 464XLAT = proposal. >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only = networks can communicate via NAT64s, but IPv4 transparency has = limitations which can be eliminated by upgrading NAT64s to NAT64+ status = (a backward compatible evolution). >>=20 >=20 > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? To take advantage, for customers that are 4rd capable, of better IPv4 = transparency than with double translation, the NAT64 MUST be upgraded.=20= Naturally, this has no impact on other NAT64 users (e.g. IPv6-only = hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue = to use the NAT64+ as an ordinary NAT64. Regards, RD >=20 > Thanks, > washam >>> Such transparency could be achieved by whther to add fragmentation = header. >>> Anyway, let's hear some comments from the group >>=20 >> OK From mohamed.boucadair@orange.com Thu Mar 8 06:51:18 2012 Return-Path: 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 2A4BD21F8724 for ; Thu, 8 Mar 2012 06:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] 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 j8w2Ck8EyvgY for ; Thu, 8 Mar 2012 06:51:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D744C21F8722 for ; Thu, 8 Mar 2012 06:51:16 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 23E21264383; Thu, 8 Mar 2012 15:51:16 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 07E8E27C107; Thu, 8 Mar 2012 15:51:16 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 8 Mar 2012 15:51:16 +0100 From: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 8 Mar 2012 15:51:13 +0100 Thread-Topic: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? Thread-Index: Acz8f3dE3rZmPkcXRLKWOt0ERKQuYAAuwnMw Message-ID: <94C682931C08B048B7A8645303FDC9F367488389B5@PUEXCB1B.nanterre.francetelecom.fr> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> <94C682931C08B048B7A8645303FDC9F36748838639@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.8.135418 Cc: Softwires WG , =?iso-8859-1?Q?Ole_Tr=F8an?= Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:51:18 -0000 Hi R=E9mi, I have explained my views (which is shared by other WG members) about this = point in this mailing list. Below a pointer to that discussion:=20 http://www.ietf.org/mail-archive/web/softwires/current/msg02873.html Cheers, Med=20 > -----Message d'origine----- > De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 > Envoy=E9 : mercredi 7 mars 2012 17:29 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Ole Tr=F8an; Softwires WG > Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 > it? Why so complex? >=20 > Hi Med, >=20 > I am, as you remember, well aware of these rules.=20 >=20 > But the fact is that, with the fixed PSID offset =3D 4 of 4rd-u=20 > (which could easily also apply to MAP), we have the following: > R-4: sharing ratios are from 1 to 2048 (PSID length limited=20 > to 11 for odd-even pairs always be in port sets) =3D> OK > R-7: ports 0-1023 are excluded for sharing ratios 2 to 2048 =3D> OK > R-8: well-known ports can be assigned to CEs with sharing=20 > ratio 1 =3D> OK >=20 > So far, this seems to me so completely sufficient. >=20 > Yet, if some ISP has a deployment plan where it is=20 > convincingly necessary to have more flexibility, that is of=20 > course worth discussing.=20 > But if there is none, time has come IMHO to simplify what can=20 > be simplified. >=20 > Cheers, > RD >=20 >=20 > Le 2012-03-07 =E0 16:59, a =E9crit : >=20 > > Hi R=E9mi, all, > >=20 > > During the MAP discussion, we identified the following requirements: > >=20 > > R-4: MAP must allow service providers to define their=20 > own address > > sharing ratio. MAP MUST NOT in particular=20 > restrict by design > > the possible address sharing ratio; ideally 1:1 and 1:65536 > > should be supported. The mapping must at least support a > > sharing ratio of 64, 1024 ports per end-user. > >=20 > > R-7: The MAP solution should support excluding the well=20 > known ports > > 0-1023. > >=20 > > R-8: It MUST be possible to assign well known ports to a CE. > >=20 > > The offset has been proposed as a flexible means to meet=20 > the requirements above. > >=20 > > Cheers, > > Med > >=20 > >=20 > >> -----Message d'origine----- > >> De : softwires-bounces@ietf.org=20 > >> [mailto:softwires-bounces@ietf.org] De la part de R=E9mi Despr=E9s > >> Envoy=E9 : mercredi 7 mars 2012 16:32 > >> =C0 : Ole Tr=F8an > >> Cc : Softwires WG > >> Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 > >> it? Why so complex? > >=20 > >>>=20 > >>> my personal preference is for fixed offset, and that the=20 > >> only way to assign system ports is by assigning a full IPv4=20 > >> address. the design team reached a compromise on allowing the=20 > >> algorithm to be tunable though. > >>=20 > >> A compromise between what and what? > >> Since there is no MAP-discussion archive, it's hard to guess=20 > >> what the issue has been. > >> Since we both believe no parameter is needed, can we consider=20 > >> this is the WG provisional as long as no significant use case=20 > >> is provided? >=20 > = From despres.remi@laposte.net Thu Mar 8 07:43:18 2012 Return-Path: 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 499AA21F8701 for ; Thu, 8 Mar 2012 07:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.050, 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 pX8kdnf3aBCZ for ; Thu, 8 Mar 2012 07:43:17 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0AC21F8702 for ; Thu, 8 Mar 2012 07:43:16 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id j3jE1i00837Y3f4033jEqD; Thu, 08 Mar 2012 16:43:15 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-85-726876299 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 8 Mar 2012 16:43:14 +0100 Message-Id: <448C7B66-7741-40B2-9A47-3B4CD98D07E6@laposte.net> References: <3A42E1F9-CB6F-422C-ACA6-89EDE2DDEAD3@huawei.com> <3BF7F61A-3D68-40DC-A0E2-E358093B152A@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Port Set Definition Algorithms Analysis X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:43:18 -0000 --Apple-Mail-85-726876299 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Thanks for the discussion (valuable a usual). More below. Le 2012-03-08 =E0 11:01, Maoke a =E9crit : > 2012/3/7 R=E9mi Despr=E9s >=20 > The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF = 82), was abandoned during the Taipei meeting (November 2011) > It no longer appeared in -02 (December 29). >=20 > Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of -04): > "NOTE: The choice of the PSID position in Port fields has been guided = by the following objectives: (1) for fairness, avoid having any of the = well-known ports 0-1023 in the port set specified by any PSID value = (these ports have more value than others); (2) for compatibility = RTP/RTCP [RFC4961], include in each port set pairs of consecutive ports; = (3) in order to facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to facilitate documentation = in hexadecimal notation, and to facilitate operation and training, have = the PSID at a fixed position in port fields." > =20 > =20 > Remi, > =20 > point (1) is qualified for the individual use case but not available = for the enterprise environment, where surely it is possible that one put = all well know services under a same CE. > but if MAP or 4rd-U states enterprise use case is NOT to be supported, = it is fine. Actually, enterprise are in scope (last sentence of the ISP definition). The point that enterprise environments may have specific use cases is = therefore valuable. To keep nibble alignment, and avoid unnecessary flexibility, while = permitting some assignment(s) of ports 0-1023, would a rule parameter = with the following two values cover your point?=20 - Full fairness (=3D> offset =3D 4) - WKPs assignable to one CE per address (=3D> offset =3D 0) > point (2) is qualified but not a sufficient condition to derive the = fixed position of PSID. point (3) and (4) is about the human reading on = the PSID. however, the MAP or 4rd-U address has been human-unfriendly. i = don't see training and operation on easy-to-read PSID is significant. > =20 > therefore i think MAXPSID, though it is abandoned, is a convincing = reason of having fixed position of PSID. While I understand the previous point, I don't get this one: MaxPsid = could AFAIK work as well with rule-dependent offsets. This comment is just in view of keeping common understanding of issues = but, since MaxPsid is now out of scope, I will have no problem if we = leave the subject for the time being. RD > =20 > - maoke > =20 > =20 >=20 > Hope it clarifies. >=20 > Regards, > RD >=20 >=20 >=20 >> =20 >> > >> > Gang >> > >> > 2012/3/2, Tina TSOU : >> >> Dear all, >> >> You may be interested to comment on >> >> = http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-an= alysis/ >> >> >> >> Abstract: >> >> This memo analyses some port set definition algorithms which >> >> encode port set information into IPv6 address so as to support >> >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and = MAP. >> >> >> >> >> >> Tetsuya, Simon and Tina >> >> >> >> _______________________________________________ >> >> Softwires mailing list >> >> Softwires@ietf.org >> >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-85-726876299 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/7 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

The max PSID feature, = present in 4rd-u-00 and -01 (i.e. before IETF 82), was abandoned during = the Taipei meeting (November 2011)
It no longer appeared in = -02 (December 29).

Reasons of the 4rd-u fixed offset are (ref. sec 4.3 = of -04):
"NOTE: The choice of the PSID position in Port = fields has been guided by the following objectives: (1) for = fairness, avoid having any of the well-known ports 0-1023 in the = port set specified by any PSID value (these ports have more value = than others); (2) for compatibility RTP/RTCP [RFC4961], include = in each port set pairs of consecutive ports; (3) in order = to facilitate operation and training, have the PSID at a = fixed position in port fields; (4) in order to = facilitate documentation in hexadecimal notation, and to = facilitate operation and training, have the PSID at a = fixed position in port fields."
=
 
 
Remi,
 
point (1) is qualified for the = individual use case but not available for the enterprise = environment, where surely it is possible that one put all well know = services under a same CE.

but if MAP or 4rd-U states = enterprise use case is NOT to be supported, it is fine. =

Actually, = enterprise are in scope (last sentence of the ISP = definition).
The point that enterprise environments may have = specific use cases is therefore valuable.

To = keep nibble alignment, and avoid unnecessary flexibility, while = permitting some assignment(s) of ports 0-1023, would a rule parameter = with the following two values cover your point? 
- Full = fairness  (=3D> offset =3D 4)
- WKPs assignable to one = CE per address (=3D> offset =3D = 0)

point (2) is qualified but not a = sufficient condition to derive the fixed position of PSID. point (3) and = (4) is about the human reading on the PSID. however, the MAP or 4rd-U = address has been human-unfriendly. i don't see training and operation on = easy-to-read PSID is significant.
 
therefore i think MAXPSID, though it is abandoned, = is a convincing reason of having fixed position of PSID. =

While I understand the = previous point, I don't get this one:  MaxPsid could AFAIK work as = well with rule-dependent offsets.
This comment is just in view = of keeping common understanding of issues but, since MaxPsid is now out = of scope, I will have no problem if we leave the subject for the time = being.

RD


 
- = maoke
 
 

Hope it = clarifies.

Regards,
RD



 
>
> Gang
>
> 2012/3/2, Tina TSOU <Tina.Tsou.Zouting@huawei.com>:
>> Dear all,
>> You may be interested to comment on
>> http://datatracker.ietf.org/doc/draft-tsou-softwire-port= -set-algorithms-analysis/
>>
>> Abstract:
>>  This memo analyses some port set definition algorithms = which
>>  encode port set information into IPv6 address so as to = support
>>  stateless IPv4 to IPv6 transition technologies, e.g. = 4rd-U and MAP.
>>
>>
>> Tetsuya, Simon and Tina
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-85-726876299-- From despres.remi@laposte.net Thu Mar 8 09:02:19 2012 Return-Path: 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 B520921F86BB for ; Thu, 8 Mar 2012 09:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 Xr3Gbpu3hrxI for ; Thu, 8 Mar 2012 09:02:19 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1721F86BA for ; Thu, 8 Mar 2012 09:02:18 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id j5281i00437Y3f403528pB; Thu, 08 Mar 2012 18:02:09 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F367488389B5@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 8 Mar 2012 18:02:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3349EA47-B36C-4F03-B704-3A44C07F609B@laposte.net> References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> <85DDCD56-71B0-4091-9426-6FB3DB940F64@cisco.com> <0552E21D-8867-4410-9EEF-FE1ADD4607AC@laposte.net> <94C682931C08B048B7A8645303FDC9F36748838639@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F367488389B5@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , =?iso-8859-1?Q?Ole_Tr=F8an?= Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:02:19 -0000 Le 2012-03-08 =E0 15:51, = a =E9crit : > Hi R=E9mi, >=20 > I have explained my views (which is shared by other WG members) about = this point in this mailing list. Below a pointer to that discussion:=20 >=20 > http://www.ietf.org/mail-archive/web/softwires/current/msg02873.html Thanks. Please see my answer to Maoke: - A Rule parameter to request "WKP Assignability" is IMHO an approach = worth considering (=3D> no PSID offset instead of the default offset). Cheers, RD > Cheers, > Med=20 >=20 >=20 >> -----Message d'origine----- >> De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 >> Envoy=E9 : mercredi 7 mars 2012 17:29 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : Ole Tr=F8an; Softwires WG >> Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 >> it? Why so complex? >>=20 >> Hi Med, >>=20 >> I am, as you remember, well aware of these rules.=20 >>=20 >> But the fact is that, with the fixed PSID offset =3D 4 of 4rd-u=20 >> (which could easily also apply to MAP), we have the following: >> R-4: sharing ratios are from 1 to 2048 (PSID length limited=20 >> to 11 for odd-even pairs always be in port sets) =3D> OK >> R-7: ports 0-1023 are excluded for sharing ratios 2 to 2048 =3D> OK >> R-8: well-known ports can be assigned to CEs with sharing=20 >> ratio 1 =3D> OK >>=20 >> So far, this seems to me so completely sufficient. >>=20 >> Yet, if some ISP has a deployment plan where it is=20 >> convincingly necessary to have more flexibility, that is of=20 >> course worth discussing.=20 >> But if there is none, time has come IMHO to simplify what can=20 >> be simplified. >>=20 >> Cheers, >> RD >>=20 >>=20 >> Le 2012-03-07 =E0 16:59, a =E9crit : >>=20 >>> Hi R=E9mi, all, >>>=20 >>> During the MAP discussion, we identified the following requirements: >>>=20 >>> R-4: MAP must allow service providers to define their=20 >> own address >>> sharing ratio. MAP MUST NOT in particular=20 >> restrict by design >>> the possible address sharing ratio; ideally 1:1 and 1:65536 >>> should be supported. The mapping must at least support a >>> sharing ratio of 64, 1024 ports per end-user. >>>=20 >>> R-7: The MAP solution should support excluding the well=20 >> known ports >>> 0-1023. >>>=20 >>> R-8: It MUST be possible to assign well known ports to a CE. >>>=20 >>> The offset has been proposed as a flexible means to meet=20 >> the requirements above. >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org=20 >>>> [mailto:softwires-bounces@ietf.org] De la part de R=E9mi Despr=E9s >>>> Envoy=E9 : mercredi 7 mars 2012 16:32 >>>> =C0 : Ole Tr=F8an >>>> Cc : Softwires WG >>>> Objet : Re: [Softwires] Port-set algorithm of MAP - what is=20 >>>> it? Why so complex? >>>=20 >>>>>=20 >>>>> my personal preference is for fixed offset, and that the=20 >>>> only way to assign system ports is by assigning a full IPv4=20 >>>> address. the design team reached a compromise on allowing the=20 >>>> algorithm to be tunable though. >>>>=20 >>>> A compromise between what and what? >>>> Since there is no MAP-discussion archive, it's hard to guess=20 >>>> what the issue has been. >>>> Since we both believe no parameter is needed, can we consider=20 >>>> this is the WG provisional as long as no significant use case=20 >>>> is provided? >>=20 From matsuhira@jp.fujitsu.com Thu Mar 8 16:37:47 2012 Return-Path: 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 D807221E8058 for ; Thu, 8 Mar 2012 16:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.346 X-Spam-Level: X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 R8ruL40H9Ub1 for ; Thu, 8 Mar 2012 16:37:47 -0800 (PST) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id DA76921E8048 for ; Thu, 8 Mar 2012 16:37:43 -0800 (PST) Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id B86C93EE0B5 for ; Fri, 9 Mar 2012 09:37:42 +0900 (JST) Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id A241145DE4D for ; Fri, 9 Mar 2012 09:37:42 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 89FBD45DE4E for ; Fri, 9 Mar 2012 09:37:42 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 7AECD1DB802C for ; Fri, 9 Mar 2012 09:37:42 +0900 (JST) Received: from m003.s.css.fujitsu.com (m003.s.css.fujitsu.com [10.23.4.33]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 364771DB803C for ; Fri, 9 Mar 2012 09:37:42 +0900 (JST) Received: from m003.css.fujitsu.com (m003 [127.0.0.1]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 8C9052E052E; Fri, 9 Mar 2012 09:37:41 +0900 (JST) Received: from [127.0.0.1] (kurokawa-san.ntp.net.fujitsu.co.jp [10.17.194.166]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 9E1122E0532; Fri, 9 Mar 2012 09:37:40 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4F595132.8020201@jp.fujitsu.com> Date: Fri, 09 Mar 2012 09:39:14 +0900 From: Naoki Matsuhira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alain Durand References: <1331010845386415.matsuhira@jp.fujitsu.com> In-Reply-To: <1331010845386415.matsuhira@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires WG , Yong Cui , Ryo Nakamura Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:37:48 -0000 Hi, Alain and Yong, I would like to update the title of our presentation request. Naoki Matsuhira, Ryo Nakamura "SA46T interoperability test report" (5min) Best Regards, Naoki Matsuhira (2012/03/06 14:14), Naoki Matsuhira wrote: > Hi, Alain and Yong, > > I would like to present SA46T interoperability test results. > > 5min is enough. > > Naoki Matsuhira > > > > On Wed, 29 Feb 2012 07:16:38 -0800 > Alain Durand wrote: > >> If you intend to present in Paris, please send Yong and I a request by 3/7. >> >> - Alain. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From fibrib@gmail.com Thu Mar 8 18:15:02 2012 Return-Path: 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 BC11911E8075 for ; Thu, 8 Mar 2012 18:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 byTj6FIql9iN for ; Thu, 8 Mar 2012 18:15:01 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1788E11E8072 for ; Thu, 8 Mar 2012 18:14:48 -0800 (PST) Received: by qcsq13 with SMTP id q13so968179qcs.31 for ; Thu, 08 Mar 2012 18:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CDs8jPm9RrNX6vp42HLHqPDf+j1A9o4TFG1j3qzUXQw=; b=suxRcxH+2Bj77H90YBl/Ez0TX0MoGCfg6AYQJj8dIuNpgpya2HWLNMMFgHc6bKfXJV /6zlg0/EOKfcvWF8a3NwqPN7LP64peC1NCZMhqa+DFnkKZeoDQm+sForIJPfSQVwOEwH EnYvJwFrdWDnxM8US9aD/Xh+zrCYaXAJnYUkFRop3P/dR8iaAaty3JlkkTIy5uCf7GVO LjaRC6BdjxgU5Lm9vlPq3W1QxCNeGPfYdefIW4YBSlhxpABZ7d0peXOpG834Wg/RVfaR N9RdImGyVexrBYsNg+gtWh3C9sUzXJiK8s5rcUWzMtuysZSjPHa0CE3gBaC5HSGeQ98D hRbA== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr34789qct.9.1331259287457; Thu, 08 Mar 2012 18:14:47 -0800 (PST) Received: by 10.229.98.21 with HTTP; Thu, 8 Mar 2012 18:14:47 -0800 (PST) In-Reply-To: <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> Date: Fri, 9 Mar 2012 02:14:47 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=002354530350eecfc604bac5f4eb Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:15:02 -0000 --002354530350eecfc604bac5f4eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, sorry but i follow this late. something not clear to me, according to our earlier discussions. 2012/3/8 R=E9mi Despr=E9s > > Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : > > > Hi Remi, > > > >>>>> Secondly, -04 added NAT64+ parts. > >>>>> If I understood correctly, there are no additional requirements for > NAT64 > >>>>> boxes. > >>>> > >>>> Well, NAT64 boxes remain what they are. > >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 > although it > >>>> has a dual stack. > >>>> > >>>> But the advantage of 4rd tunneling over RFC6145 double translation i= s > better > >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols > that may > >>>> use the TCP checksum algorithms) > to clarify my understanding: 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the DF=3D1/MF=3D1 cases 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message directly as IPv6 payload is a wise idea. lack of address consistency ensurance mechanism (i.e. no header checksum in IPv6 header no pseudo-header checksum in ICMPv4 message) 3. for the "future protocols", i remember our earlier discussion concluded that CNP can free the code change with ALREADY KNOWN tcp-checksumed protocols. am i wrong here? > >>>> For an ISP to extend this advantage to its stateful NAT64, it need t= o > be 4rd > >>>> aware (become a NAT64+). > >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address > (with a V > >>>> octet instead of a "u" octet), use the 4rd header mapping instead of > RFC6145 > >>>> translation. > questions: 1. NAT64+ here refers to stateful case only, right? 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let me use this term because i argue it does not conform to the behavior of encapsulation) and NAT64 translation? (as we have neither V nor U in the IPv4 addresses). > >>> > >>> I perfer to leave NAT64 out of scope. > >> > >> NAT64 as is remains out of scope. > >> What is in scope is only the possibility to improve IPv4 transparency > of NAT64 nodes by using transparent tunneling, instead of double > translation, when reached by 4rd CEs (making them NAT64+ nodes). > > > > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a > > new term NAT64+ invented? > > > NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs > to be upgraded to replace RFC5145 translation by header mapping when IPv6 > addresses it deals with are 4rd addresses (have the V octet). > > > > > >> This new capability, introduced in -04, is derived from the 464XLAT > proposal. > >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only network= s > can communicate via NAT64s, but IPv4 transparency has limitations which c= an > be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible > evolution). > >> > > > > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? > > To take advantage, for customers that are 4rd capable, of better IPv4 > transparency than with double translation, the NAT64 MUST be upgraded. > may i add that it (4rd-U) provides better IPv4 transparency than double translation but less simplicity in the term of layering architecture than encapsulation? (here i avoid sticking things on my understanding to "transparency"). personally i don't think transparency is the most important reason that generally operators prefer encapsulation rather than translation. simplicity and clear concept in architecture is the reason. no matter how much we keep IPv4 information unchanged across the IPv6 domain, as long as the IPv4 header is destroyed, it is a solution of "translation" rather than of "encapsulation". i don't incline to use the term "tunneling" since tunnel could have a variety of forms, among which encapsulation is one but not the only one. cheers, maoke > Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, > or dual-stack hosts supporting BIH of RFC6535): they can continue to use > the NAT64+ as an ordinary NAT64. > > Regards, > RD > > > > > Thanks, > > washam > >>> Such transparency could be achieved by whther to add fragmentation > header. > >>> Anyway, let's hear some comments from the group > >> > >> OK > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --002354530350eecfc604bac5f4eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,

sorry but i follow this late. so= mething not clear to me, according to our earlier discussions.

2012/3/8 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional req= uirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in the= NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double tra= nslation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may
>>>> use the TCP checksum algorithms)

to clarify my understanding:
1. DF transparency = is kept totally in 4rd-U but RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 messag= e directly as IPv6 payload is a wise idea. lack of address consistency ensu= rance mechanism (i.e. no header checksum in IPv6 header no pseudo-header ch= ecksum in ICMPv4 message)
3. for the "future protocols", i remember our earlier discus= sion concluded that CNP can free the code change with ALREADY KNOWN tcp-che= cksumed protocols. am i wrong here?=A0
=A0
>>>> For an ISP to extend this advantage to its stateful NAT64,= it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 a= ddress (with a V
>>>> octet instead of a "u" octet), use the 4rd heade= r mapping instead of RFC6145
>>>> translation.

que= stions: 1. NAT64+ here refers to stateful case only, right? 2. for the IPv4= -to-IPv6 directly, how does the 4rd-aware box make decision between 4rd-U p= seudo-encapsulation (let me use this term because =A0i argue it does not co= nform to the behavior of encapsulation) and NAT64 translation? (as we have = neither V nor U in the IPv4 addresses).
=A0
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 transpare= ncy of NAT64 nodes by using transparent tunneling, instead of double transl= ation, when reached by 4rd CEs (making them NAT64+ nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a=
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 n= eeds to be upgraded to replace RFC5145 translation by header mapping when I= Pv6 addresses it deals with are 4rd addresses (have the V octet).


>
>> This new capability, introduced in -04, is derived from the 464XLA= T proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only net= works can communicate via NAT64s, but IPv4 transparency has limitations whi= ch can be eliminated by upgrading NAT64s to NAT64+ status (a backward compa= tible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?
To take advantage, for customers that are 4rd capable, of better IPv4= transparency than with double translation, the NAT64 MUST be upgraded.
=

may i add that it (4rd-U) provides better = IPv4 transparency than double translation but less simplicity in the term o= f layering architecture than encapsulation? (here i avoid sticking things o= n my understanding to "transparency"). personally i don't thi= nk transparency is the most important reason that generally operators prefe= r encapsulation rather than translation. simplicity and clear concept in ar= chitecture is the reason. no matter how much we keep IPv4 information uncha= nged across the IPv6 domain, as long as the IPv4 header is destroyed, it is= a solution of "translation" rather than of "encapsulation&q= uot;.=A0

i don't incline to use the term "tunneling&quo= t; since tunnel could have a variety of forms, among which encapsulation is= one but not the only one.=A0

cheers,
maoke
=A0
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, o= r dual-stack hosts supporting BIH of RFC6535): they can continue to use the= NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add fragmenta= tion header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--002354530350eecfc604bac5f4eb-- From xing@cernet.edu.cn Thu Mar 8 23:17:27 2012 Return-Path: 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 ABBA521F85BB for ; Thu, 8 Mar 2012 23:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.414 X-Spam-Level: X-Spam-Status: No, score=-101.414 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 OltPnNdOzdr8 for ; Thu, 8 Mar 2012 23:17:27 -0800 (PST) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1255221F85AE for ; Thu, 8 Mar 2012 23:17:25 -0800 (PST) Received: from [127.0.0.1] (unknown [202.38.102.1]) by centos (Coremail) with SMTP id AQAAf3ArUQPGrVlPHkMQAA--.3219S2; Fri, 09 Mar 2012 15:14:15 +0800 (CST) Message-ID: <4F59AE74.4090204@cernet.edu.cn> Date: Fri, 09 Mar 2012 15:17:08 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> In-Reply-To: <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> Content-Type: multipart/alternative; boundary="------------020104050001070803070303" X-CM-TRANSID: AQAAf3ArUQPGrVlPHkMQAA--.3219S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tF4xKF4xCw4rKF18tFWUJwb_yoW8CF4fpF W3GrsYya9rKr40yrnruw4fCw1rAFWkK3y5Jw1UGw1vyws8WayjvrW5KF9Ik3yfXr1rXw1j q3yjkrs8Xan5AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUhE14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjc xK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28E F7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4 xG6c804VAFz4xC04v7McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mx8GjcxK6IxK0xIIj40E5I8Crw CYjI0SjxkI62AI1cAE67vIY487MxkIecxEwVAFwVW8CwCF04k20xvY0x0EwIxGrwC20s02 6c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF 0_Jw1lIxkGc2Ij64vIr41lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280 aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0x ZFpf9x0JUt8n5UUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 07:17:27 -0000 This is a multi-part message in MIME format. --------------020104050001070803070303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Remi, 于 2012/2/10 18:23, Rémi Després 写é“: > Hi Xing, > Good to have you coming in the (unfinished) technical analysis. > > I answered to Ole on his remarks, which you support, but not on > the following: > > You propose to have a line on "IPv4 to IPv6 communication (single > translation) supported", wit > > Let me therefore reiterate the wish to see an ISP use case, with its > Mapping rules, and with IPv6 prefixes of CEs that illustrate the > problem you see. The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 translation between CERNET2 and the IPv4 core network (CERNET). The users can either use single translation directly, or add their own IPv4/IPv6 translor if double translation is required. Is this answer your question? Regards, xing > > Regards, > RD > > > > > Le 2012-02-10 à 04:28, Xing Li a écrit : > ...| | | | | >>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | >>>> | | packets | | | | | >>> suggest you rename to "IPv4 to IPv6 communication (single translation) supported" >>> >> >> (2) More clarification should be added here. I am not sure 4rd-H can >> support single translation. >> >> (a) According to (1), 4rd-H does not perform header translation >> defined by RFC6145. >> >> (b) In the softwire mailing list, it seems that 4rd-H cannot support >> single translation. See the thread containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html >> and other posts. >> >> (c) If 4rd-H cannot support single translation, then "IPv6 web caches >> work for IPv4 packets" requires special configurations, it cannot do >> IPv6 web caches for non 4rd-H packets. > > ... > >> (5) I would like to see the details of how 4rd-H handles ICMP and >> ICMP error messages. In the softwire mailing list there were some >> discussions. See the thread containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html >> and other posts.Please add >> >> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | > ... > --------------020104050001070803070303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Remi,

于 2012/2/10 18:23, Rémi Després 写é“:
Hi Xing,
Good to have you coming in the (unfinished) technical analysis.

I answered to Ole on his remarks, which you support, but not on the following:

You propose to have a line on "IPv4 to IPv6 communication (single translation) supported", wit 

Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see.

The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 translation between CERNET2 and the IPv4 core network (CERNET). The users can either use single translation directly, or add their own IPv4/IPv6 translor if double translation is required.

Is this answer your question?

Regards,

xing



Regards,
RD
 




Le 2012-02-10 à 04:28, Xing Li a écrit :
... | | | | |
  |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |
...


--------------020104050001070803070303-- From xing@cernet.edu.cn Thu Mar 8 23:36:53 2012 Return-Path: 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 0231021F8631 for ; Thu, 8 Mar 2012 23:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.112 X-Spam-Level: X-Spam-Status: No, score=-101.112 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 0MUwrR0O36Zl for ; Thu, 8 Mar 2012 23:36:52 -0800 (PST) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B921F8629 for ; Thu, 8 Mar 2012 23:36:50 -0800 (PST) Received: from [127.0.0.1] (unknown [202.38.102.1]) by centos (Coremail) with SMTP id AQAAf3A7YQNgsllPN0QQAA--.3036S2; Fri, 09 Mar 2012 15:33:52 +0800 (CST) Message-ID: <4F59B30D.8060302@cernet.edu.cn> Date: Fri, 09 Mar 2012 15:36:45 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <25A25F1D-3987-4B96-8EE4-17814F639041@laposte.net> <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> In-Reply-To: <443C6D88-917F-4FAD-ABC8-846A965369A2@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf3A7YQNgsllPN0QQAA--.3036S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5Q7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E 6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l84ACjcxK6xIIjxv20xvE14 v26r1I6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07 x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15 McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7 I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xFo4CEbIxvr21lc2xSY4AK67AK6r4x MxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_Jr I_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v2 6r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj4 0_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8 Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUPb18UUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 07:36:53 -0000 Hi, Remi, > (**) 4rd derives a port set from a PSID as shown in the picture below. I would implement it with masks and shifts rather than with multiplications and divisions and, in any case, without needing to think of any "Maximum number of contiguous ports" and a "Sharing ratio". > > : 4 : > +---+----+---------+ > Ports in the CE port set |> 0|PSID|any value| > +---+----+---------+ > : 16 : > > > Cheers, > RD > > Note that if the ratio is bitwise, the multiplications and divisions are shift operations, and the module is mask operation. Therefore, no computational complexity is introduced. xing From despres.remi@laposte.net Fri Mar 9 00:49:43 2012 Return-Path: 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 1DC6D21F85F4 for ; Fri, 9 Mar 2012 00:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.042, 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 GaBkI2-XyvfU for ; Fri, 9 Mar 2012 00:49:41 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 458A621F8527 for ; Fri, 9 Mar 2012 00:49:40 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id jLpc1i00137Y3f403LpcYb; Fri, 09 Mar 2012 09:49:38 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-86-788457828 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 9 Mar 2012 09:49:35 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 08:49:43 -0000 --Apple-Mail-86-788457828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Maoke for the opportunity to clarify some of the points below. 2012-03-09 03:14, Maoke: > hi Remi, >=20 > sorry but i follow this late. something not clear to me, according to = our earlier discussions. >=20 > 2012/3/8 R=E9mi Despr=E9s >=20 > Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : >=20 > > Hi Remi, > > > >>>>> Secondly, -04 added NAT64+ parts. > >>>>> If I understood correctly, there are no additional requirements = for NAT64 > >>>>> boxes. > >>>> > >>>> Well, NAT64 boxes remain what they are. > >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 = although it > >>>> has a dual stack. > >>>> > >>>> But the advantage of 4rd tunneling over RFC6145 double = translation is better > >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may > >>>> use the TCP checksum algorithms) >=20 > to clarify my understanding: > 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies = the DF=3D1/MF=3D1 cases > 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 = message directly as IPv6 payload is a wise idea. lack of address = consistency ensurance mechanism (i.e. no header checksum in IPv6 header = no pseudo-header checksum in ICMPv4 message) The 4rd ICMPv4 error message has as only purpose to be delivered to a = 4rd-aware node. There, it will be treated as an ICMPv4 error. It is assumed that no DPI in some middle box will need to interpret = ICMPv4 error messages.=20 > 3. for the "future protocols", i remember our earlier discussion = concluded that CNP can free the code change with ALREADY KNOWN = tcp-checksumed protocols. am i wrong here?=20 I think you are. As the 4rd-u-04 says (sec 4.4): "NOTE: This guarantees that, for all protocols that use the same = checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and = this independently from where the checksum field is placed for each = protocol. Today, such protocols are UDP [RFC0768], TCP [RFC0793], = UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, = BRs will support them without needing an update." > >>>> For an ISP to extend this advantage to its stateful NAT64, it = need to be 4rd > >>>> aware (become a NAT64+). > >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address = (with a V > >>>> octet instead of a "u" octet), use the 4rd header mapping instead = of RFC6145 > >>>> translation. >=20 > questions: 1. NAT64+ here refers to stateful case only, right? > 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make = decision between 4rd-U pseudo-encapsulation (let me use this term = because i argue it does not conform to the behavior of encapsulation) = and NAT64 translation? (as we have neither V nor U in the IPv4 = addresses). a) Note that there is no claim that 4rd-u would be an encapsulation = solution (it isn't!). What is claimed is that it is a transparent-tunnel = solution (same IPv4 packet received by destinations as sent by sources, = except for TTL which progress, and for ECNs that may be changed if = congestion is met between source and destination). b) In draft -04, R-7 (8) says: "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST = derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): = take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 = address; append the CNP. <----------- Rule IPv6 prefix --------->: +-------------------------------+---+---+-------------+------+ | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | +-------------------------------+---+---+-------------+------+ : 64 : 8 : 8 : 32 : 16 : Figure 6 " =20 > >>> > >>> I perfer to leave NAT64 out of scope. > >> > >> NAT64 as is remains out of scope. > >> What is in scope is only the possibility to improve IPv4 = transparency of NAT64 nodes by using transparent tunneling, instead of = double translation, when reached by 4rd CEs (making them NAT64+ nodes). > > > > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify = a > > new term NAT64+ invented? >=20 >=20 > NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 = needs to be upgraded to replace RFC5145 translation by header mapping = when IPv6 addresses it deals with are 4rd addresses (have the V octet). >=20 >=20 > > > >> This new capability, introduced in -04, is derived from the 464XLAT = proposal. > >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only = networks can communicate via NAT64s, but IPv4 transparency has = limitations which can be eliminated by upgrading NAT64s to NAT64+ status = (a backward compatible evolution). > >> > > > > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >=20 > To take advantage, for customers that are 4rd capable, of better IPv4 = transparency than with double translation, the NAT64 MUST be upgraded. >=20 > may i add that it (4rd-U) provides better IPv4 transparency than = double translation but less simplicity in the term of layering = architecture than encapsulation? (here i avoid sticking things on my = understanding to "transparency"). personally i don't think transparency = is the most important reason that generally operators prefer = encapsulation rather than translation. simplicity and clear concept in = architecture is the reason. no matter how much we keep IPv4 information = unchanged across the IPv6 domain, as long as the IPv4 header is = destroyed, it is a solution of "translation" rather than of = "encapsulation".=20 Different view here. a) Ole had a nice slide in the interim meeting about how double = translation tends to break transparency. I use "reversible header = mapping" which I find intuitive, or just "header mapping", but = "reversible header translation" could be OK.=20 A key difference, is that payloads are transparently tunneled in 4rd = while they are processed, with dependence of upper layer protocols in = double translation. This is AFAIK an important difference. (To take an = example, RFC6145 requires to discard UDP-lite packets (RFC3828) while = they are tunneled with 4rd) b) As said in Sec 1 of draft -04: " While IPv6 headers are too long to be mapped into IPv4 headers, so = that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, = IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd = tunnel packets can be designed to be valid IPv6 packets, thus ensuring = compatibility with IPv6-only middle boxes that perform = deep-packet-inspection." I see no real complexity in noting that IPv4 headers are small enough = to be reversibly mapped in IPv6 headers. Of course this still requires careful technical verification, but once = done, it's done once and for all.=20 > i don't incline to use the term "tunneling" since tunnel could have a = variety of forms, among which encapsulation is one but not the only one.=20= Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation = tunnels. Cheers, RD >=20 > cheers, > maoke > =20 > Naturally, this has no impact on other NAT64 users (e.g. IPv6-only = hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue = to use the NAT64+ as an ordinary NAT64. >=20 > Regards, > RD >=20 > > > > Thanks, > > washam > >>> Such transparency could be achieved by whther to add fragmentation = header. > >>> Anyway, let's hear some comments from the group > >> > >> OK >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-86-788457828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi Remi,

sorry but i = follow this late. something not clear to me, according to our earlier = discussions.

2012/3/8 R=E9mi Despr=E9s= <despres.remi@laposte.net><= /span>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional = requirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in = the NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double = translation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and = future protocols that may
>>>> use the TCP checksum = algorithms)

to clarify my = understanding:
1. DF transparency is kept totally in 4rd-U but = RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 = message directly as IPv6 payload is a wise idea. lack of address = consistency ensurance mechanism (i.e. no header checksum in IPv6 header = no pseudo-header checksum in ICMPv4 = message)

The 4rd ICMPv4 = error message has as only purpose to be delivered to a 4rd-aware node. = There, it will be treated as an ICMPv4 error.
It is assumed = that no DPI in some middle box will need to interpret ICMPv4 error = messages. 

3. for the "future protocols", i remember our earlier discussion = concluded that CNP can free the code change with ALREADY KNOWN = tcp-checksumed protocols. am i wrong = here? 

I think you are. = As the 4rd-u-04 says (sec 4.4):
"NOTE: This guarantees = that, for all protocols that use the same checksum algorithm as = TCP, Tunnel packets are valid IPv6 packets, and this independently = from where the checksum field is placed for each protocol. =  Today, such protocols are UDP [RFC0768], TCP [RFC0793], = UDP-Lite [RFC3828], and DCCP [RFC5595].  Should new ones = be specified, BRs will support them without needing = an update."


>>>> For an ISP to extend this advantage to its stateful = NAT64, it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd = IPv6 address (with a V
>>>> octet instead of a "u" octet), use the 4rd header = mapping instead of RFC6145
>>>> = translation.

questions: 1. = NAT64+ here refers to stateful case only, = right?

2. for the IPv4-to-IPv6 directly, how does = the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let = me use this term because  i argue it does not conform to the = behavior of encapsulation) and NAT64 translation? (as we have neither V = nor U in the IPv4 = addresses).

a) Note that = there is no claim that 4rd-u would be an encapsulation solution (it = isn't!). What is claimed is that it is a transparent-tunnel solution = (same IPv4 packet received by destinations as sent by sources, except = for TTL which progress, and for ECNs that may be changed if congestion = is met between source and destination).

b) In = draft -04, R-7 (8) says:
"CEs that are assigned unspecified = IPv4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from = 4rd IPv4 addresses as follows (Figure 6): take the Rule = IPv6 prefix of the NAT64+ mapping rue; append the IPv4 = address; append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              =
"
 
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 = transparency of NAT64 nodes by using transparent tunneling, instead of = double translation, when reached by 4rd CEs (making them NAT64+ = nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What = justify a
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the = NAT64 needs to be upgraded to replace RFC5145 translation by header = mapping when IPv6 addresses it deals with are 4rd addresses (have the V = octet).


>
>> This new capability, introduced in -04, is derived from the = 464XLAT proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only = networks can communicate via NAT64s, but IPv4 transparency has = limitations which can be eliminated by upgrading NAT64s to NAT64+ status = (a backward compatible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it = is?

To take advantage, for customers that are 4rd capable, of better = IPv4 transparency than with double translation, the NAT64 MUST be = upgraded.

may i add that it (4rd-U) = provides better IPv4 transparency than double translation but less = simplicity in the term of layering architecture than encapsulation? = (here i avoid sticking things on my understanding to "transparency"). = personally i don't think transparency is the most important reason that = generally operators prefer encapsulation rather than translation. = simplicity and clear concept in architecture is the reason. no matter = how much we keep IPv4 information unchanged across the IPv6 domain, as = long as the IPv4 header is destroyed, it is a solution of "translation" = rather than of = "encapsulation". 

Differe= nt view here.
a) Ole had a nice slide in the interim meeting = about how double translation tends to break transparency. I use = "reversible header mapping" which I find intuitive, or just "header = mapping", but "reversible header translation" could be = OK. 
 A key difference, is that payloads are = transparently tunneled in 4rd while they are processed, with dependence = of upper layer protocols in double translation. This is AFAIK an = important difference. (To take an example, RFC6145 requires to discard = UDP-lite packets (RFC3828) while they are tunneled with = 4rd)

b) As said in Sec 1 of draft = -04:
 " While IPv6 headers are too long to be = mapped into IPv4 headers, so that 6rd requires encapsulation of = full IPv6 packets in IPv4 packets, IPv4 headers can be reversibly = mapped into IPv6 headers so that 4rd tunnel packets can be designed = to be valid IPv6 packets, thus ensuring compatibility with = IPv6-only middle boxes that perform = deep-packet-inspection."
 I see no real complexity in = noting that IPv4 headers are small enough to be reversibly mapped in = IPv6 headers.
 Of course this still requires careful = technical verification, but once done, it's done once and for = all. 

i don't incline to use the term "tunneling" = since tunnel could have a variety of forms, among which encapsulation is = one but not the only = one. 

Exactly: 4rd uses = header-mapping tunnels, and MAP-E uses encapsulation = tunnels.


Cheers,
RD





cheers,
maoke
 
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only = hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue = to use the NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add = fragmentation header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-86-788457828-- From fibrib@gmail.com Fri Mar 9 03:04:49 2012 Return-Path: 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 85FD721F85F9 for ; Fri, 9 Mar 2012 03:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oagns6HWwpsv for ; Fri, 9 Mar 2012 03:04:47 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 612F321F8642 for ; Fri, 9 Mar 2012 03:04:47 -0800 (PST) Received: by qcsq13 with SMTP id q13so1239308qcs.31 for ; Fri, 09 Mar 2012 03:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ovBky/K/6VFeXtuZqcsPzXPDRfk4E0209LiDbZdYmxo=; b=ybamp3owPA4cagPssu+A2jgJcs9vHkqlbsYoMoKS8NySKzcVAh6u8ONqYTvr8/wQgG n3Uw8hNVMsy2WT6HJq4S2/kpWag+LU5LJufdcg/oXG9RGvDH82gX0KO1XZ26PqBZ+RQv qON/ICNLTSMt7SHD3CWTd/K26fzUKfEocEz5Rme28jP9PLaLMGiofLLxjvKP7SM1YN5G ChLbTAHfEWkQMj7aLVhdwvlbEqj4TjrDBBJqFywx0NYmn1XtiHC2tn41q0160+1q1eSM kVYHJc+a/6rwA/LpLIxPTVmqRdIBMFE9Z9ipfU13EkKMBKyzZyG7bxe8rzKIml9U6FPe MO0A== MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr168240qct.49.1331291086672; Fri, 09 Mar 2012 03:04:46 -0800 (PST) Received: by 10.229.98.21 with HTTP; Fri, 9 Mar 2012 03:04:46 -0800 (PST) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> Date: Fri, 9 Mar 2012 11:04:46 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c767e9650523904bacd5cff Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:04:49 -0000 --00248c767e9650523904bacd5cff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/9 R=E9mi Despr=E9s > Thanks Maoke for the opportunity to clarify some of the points below. > > > 2012-03-09 03:14, Maoke: > > hi Remi, > > sorry but i follow this late. something not clear to me, according to our > earlier discussions. > > 2012/3/8 R=E9mi Despr=E9s > >> >> Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : >> >> > Hi Remi, >> > >> >>>>> Secondly, -04 added NAT64+ parts. >> >>>>> If I understood correctly, there are no additional requirements fo= r >> NAT64 >> >>>>> boxes. >> >>>> >> >>>> Well, NAT64 boxes remain what they are. >> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 >> although it >> >>>> has a dual stack. >> >>>> >> >>>> But the advantage of 4rd tunneling over RFC6145 double translation >> is better >> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols >> that may >> >>>> use the TCP checksum algorithms) >> > > to clarify my understanding: > 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the > DF=3D1/MF=3D1 cases > 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message > directly as IPv6 payload is a wise idea. lack of address consistency > ensurance mechanism (i.e. no header checksum in IPv6 header no > pseudo-header checksum in ICMPv4 message) > > > The 4rd ICMPv4 error message has as only purpose to be delivered to a > 4rd-aware node. There, it will be treated as an ICMPv4 error. > It is assumed that no DPI in some middle box will need to interpret ICMPv= 4 > error messages. > > 3. for the "future protocols", i remember our earlier discussion conclude= d > that CNP can free the code change with ALREADY KNOWN tcp-checksumed > protocols. am i wrong here? > > > I think you are. As the 4rd-u-04 says (sec 4.4): > "NOTE: This guarantees that, for all protocols that use the same checksum > algorithm as TCP, Tunnel packets are valid IPv6 packets, and this > independently from where the checksum field is placed for each protocol. > Today, such protocols are UDP [RFC0768], TCP [RFC0793], > UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, BR= s > will support them without needing an update." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ exactly here it is the point of disagreement. here the "update" refers to implementation, right? then what is the BR's logic? A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) { calculate IPv6 address for dst, taking the port from L4_proto.header; /* do nothing with checksum, CNP applied for the LIST */ } else { discard; } B. if (1) { calculate MAP IPv6 address for dst, supposing dst port is always there; /* do nothing with checksum suppose CNP applied to all protocols */ } if you refer to logic B, the "BR will support them without needing an update" is true. however, the risk is should new ones specified but not having the tcp-like layout or the tcp-checksum may fail to become a valid IPv6 packet and (because of the layout difference) it is possible that the destination IPv6 address is wrong. if you refer to logic A, the BR must be updated whenever any new protocol is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, when applied with MAP, is: A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) { calculate IPv6 address for dst, taking the port (or equivalent field when ICMP) from Payload_Proto.header; recalculate the checksum in Payload_Proto.header; } else { discard; } both A and A' has no risk as B has. > > >>>> For an ISP to extend this advantage to its stateful NAT64, it need >> to be 4rd >> >>>> aware (become a NAT64+). >> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address >> (with a V >> >>>> octet instead of a "u" octet), use the 4rd header mapping instead o= f >> RFC6145 >> >>>> translation. >> > > questions: 1. NAT64+ here refers to stateful case only, right? > > > 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decisio= n > between 4rd-U pseudo-encapsulation (let me use this term because i argue > it does not conform to the behavior of encapsulation) and NAT64 > translation? (as we have neither V nor U in the IPv4 addresses). > > > a) Note that there is no claim that 4rd-u would be an encapsulation > solution (it isn't!). What is claimed is that it is a transparent-tunnel > solution (same IPv4 packet received by destinations as sent by sources, > except for TTL which progress, and for ECNs that may be changed if > congestion is met between source and destination). > yes. TTL is progressing as if it were in translation. ECN is another topic: it changes even in the encapsulation. > > b) In draft -04, R-7 (8) says: > "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST > derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): > take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 > address; append the CNP. > > <----------- Rule IPv6 prefix --------->: > +-------------------------------+---+---+-------------+------+ > | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | > +-------------------------------+---+---+-------------+------+ > : 64 : 8 : 8 : 32 : 16 : > > Figure 6 " > > what do you mean with the unspecified IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? reading your example in 5.1, i understand your point: the above picture describes the mapping for the source address if the packet is sent to the IPv6 world through BR but without the inverse-header-mapping. in this case the U-octet is applied and the CE-delegated prefix plays also the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i'm right, it is clear. but i haven't seen the necessity of defining the V-octet here. with the V, BR seeing the V does the header mapping while seeing the U does nothing but only the regular routing. without the V, BR seeing the CE-delegated /64 does the header mapping while seeing another prefix (no matter how long the length is) does nothing but only the regular routing. the V-attached stuff in fact makes another, more-specific prefix under the delegated prefix of a CE. > >>> >> >>> I perfer to leave NAT64 out of scope. >> >> >> >> NAT64 as is remains out of scope. >> >> What is in scope is only the possibility to improve IPv4 transparency >> of NAT64 nodes by using transparent tunneling, instead of double >> translation, when reached by 4rd CEs (making them NAT64+ nodes). >> > >> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a >> > new term NAT64+ invented? >> >> >> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 need= s >> to be upgraded to replace RFC5145 translation by header mapping when IPv= 6 >> addresses it deals with are 4rd addresses (have the V octet). >> > confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgraded at all. > >> >> > >> >> This new capability, introduced in -04, is derived from the 464XLAT >> proposal. >> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only >> networks can communicate via NAT64s, but IPv4 transparency has limitatio= ns >> which can be eliminated by upgrading NAT64s to NAT64+ status (a backward >> compatible evolution). >> >> >> > >> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >> >> To take advantage, for customers that are 4rd capable, of better IPv4 >> transparency than with double translation, the NAT64 MUST be upgraded. >> > Remi didn't answer this question of Washam. 4rd-U keeps only stateful NAT64 as it is at CE, to my understanding. > > may i add that it (4rd-U) provides better IPv4 transparency than double > translation but less simplicity in the term of layering architecture than > encapsulation? (here i avoid sticking things on my understanding to > "transparency"). personally i don't think transparency is the most > important reason that generally operators prefer encapsulation rather tha= n > translation. simplicity and clear concept in architecture is the reason. = no > matter how much we keep IPv4 information unchanged across the IPv6 domain= , > as long as the IPv4 header is destroyed, it is a solution of "translation= " > rather than of "encapsulation". > > > Different view here. > a) Ole had a nice slide in the interim meeting about how double > translation tends to break transparency. I use "reversible header mapping= " > which I find intuitive, or just "header mapping", but "reversible header > translation" could be OK. > A key difference, is that payloads are transparently tunneled in 4rd > while they are processed, with dependence of upper layer protocols in > double translation. This is AFAIK an important difference. (To take an > example, RFC6145 requires to discard UDP-lite packets (RFC3828) while the= y > are tunneled with 4rd) > where is it stated in RFC6145 that it requires to DISCARD UDP-lite packets? > > b) As said in Sec 1 of draft -04: > " While IPv6 headers are too long to be mapped into IPv4 headers, so tha= t > 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 > headers can be reversibly mapped into IPv6 headers so that 4rd tunnel > packets can be designed to be valid IPv6 packets, thus ensuring > compatibility with IPv6-only middle boxes that perform > deep-packet-inspection." > I see no real complexity in noting that IPv4 headers are small enough to > be reversibly mapped in IPv6 headers. > our terminologies are biased. i emphasize the simplicity is in the term of architecture. encapsulation is a widely used concept in the networking, making one protocol as an underlay of another. we may have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but re-ordered and re-organized, into, e.g., a super L2-U. it is surely a reversible header mapping but we can't say that of either encapsulation or the (narrow-sense) tunneling. this is my point. from the operator's view, once it is not the simple layered encapsulation, i cannot see it as a substitute for the encapsulation, but see it as a substitute of other translations, if i see this is a more gentle translation than others and this gentleness costs little. > Of course this still requires careful technical verification, but once > done, it's done once and for all. > > i don't incline to use the term "tunneling" since tunnel could have a > variety of forms, among which encapsulation is one but not the only one. > > > Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation > tunnels. > well, in general sense "tunnel" means a source route essentially (RFC1241 made a very good summary about variety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in general sense of the term "source route"). but we never call it like that, because, when most people are talking about "tunnel" today, we refers to the narrow sense "tunnel", which means the encapsulation. it is fine that 4rd-U call itself as a tunnel solution but it should be pointed out that this is a tunnel in the general sense. therefore i emphasize that, maybe too academic, the counterpart of translation is encapsulation but not the "tunneling". in the architecture, we have either the building block of making an underlay protocol as a virtual link or the building block of making another protocol as a participant in the path of end-to-end delivery. although you argued this is *ONLY* the understanding of some diffserv guys, i don't think this understanding is not generic. for the simplicity in operation, we often think in such a way: if we would like to hide the underlay and make a protocol as an underlay or we would like to expose the things out. both have their use cases. if 4rd-U is said it fills some important gaps between the two, it would be great. if 4rd-U is said it replaces the both, i doubt it can. once we want to make a stuff having advantage of this and that, we often make out a stuff also having disadvantage of both. for me, i prefer if 4rd-U is moderately defined with specific use-case and fully description on its pros/cons, features/limitations, approaches/tradeoffs. cheers, maoke > > > Cheers, > RD > > > > > > cheers, > maoke > > >> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts= , >> or dual-stack hosts supporting BIH of RFC6535): they can continue to use >> the NAT64+ as an ordinary NAT64. >> >> Regards, >> RD >> >> > >> > Thanks, >> > washam >> >>> Such transparency could be achieved by whther to add fragmentation >> header. >> >>> Anyway, let's hear some comments from the group >> >> >> >> OK >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --00248c767e9650523904bacd5cff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/9 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>
Thanks Maoke for the opportunity to cla= rify some of the points below.



hi Remi,

sorry but i follow this late. something not clear to me, ac= cording to our earlier discussions.

201= 2/3/8 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional req= uirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in the= NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double tra= nslation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may
>>>> use the TCP checksum algorithms)

to clarify my understanding:
1. DF transparency = is kept totally in 4rd-U but RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 messag= e directly as IPv6 payload is a wise idea. lack of address consistency ensu= rance mechanism (i.e. no header checksum in IPv6 header no pseudo-header ch= ecksum in ICMPv4 message)

The 4rd ICMPv4 error message h= as as only purpose to be delivered to a 4rd-aware node. There, it will be t= reated as an ICMPv4 error.
It is assumed that no DPI in some midd= le box will need to interpret ICMPv4 error messages.=A0

3. for the "future protocols", i remember our earlier discus= sion concluded that CNP can free the code change with ALREADY KNOWN tcp-che= cksumed protocols. am i wrong here?=A0

I think you are. As the 4rd-u-04 says (sec 4.4):
"NOTE: This guarantees that, for all protocols that use the=A0sa= me checksum algorithm as TCP, Tunnel packets are valid=A0IPv6 packets, and = this independently from where the=A0checksum field is placed for each proto= col. =A0Today, such=A0protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite= =A0[RFC3828], and DCCP [RFC5595]. =A0Should new ones be=A0specified, BRs wi= ll support them without needing an=A0update."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^
exactly here it is the point of disagreement. here the "update&qu= ot; refers to implementation, right? then what is the BR's logic?=A0

A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {=
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port from L4_pr= oto.header;=A0
=A0 =A0 =A0 /* do nothing with checksum, CNP appli= ed for the LIST */
=A0 =A0} else {
=A0 =A0 =A0 discard;=
=A0 =A0}

B. if (1) {
=A0 =A0 =A0 calculate MAP IPv6 ad= dress for dst, supposing dst port is always there;
=A0 =A0 =A0 /*= do nothing with checksum suppose CNP applied to all protocols */
=A0 =A0}

if you refer to logic B, the "BR will support them= without needing an update" is true. however, the risk is should new o= nes specified but not having the tcp-like layout or the tcp-checksum may fa= il to become a valid IPv6 packet and (because of the layout difference) it = is possible that the destination IPv6 address is wrong.=A0

if you refer to logic A, the BR must be updated wheneve= r any new protocol is added to the LIST. this is the same as RFC6145. btw, = RFC6145's logic, when applied with MAP, is:
A'. if (= Payload_Proto in LIST{UDP, TCP, ICMP}) {
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port (or equiva= lent field when ICMP) from Payload_Proto.header;=A0
=A0 =A0 =A0 r= ecalculate the checksum in Payload_Proto.header;
=A0 =A0} else {<= /div>
=A0 =A0 =A0 discard;
=A0 =A0}


both A and A' has= no risk as B has.=A0



>>>> For an ISP to extend this advantage to its stateful NAT64,= it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 a= ddress (with a V
>>>> octet instead of a "u" octet), use the 4rd heade= r mapping instead of RFC6145
>>>> translation.

que= stions: 1. NAT64+ here refers to stateful case only, right?

2. = for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision bet= ween 4rd-U pseudo-encapsulation (let me use this term because =A0i argue it= does not conform to the behavior of encapsulation) and NAT64 translation? = (as we have neither V nor U in the IPv4 addresses).

a) Note that there is no claim= that 4rd-u would be an encapsulation solution (it isn't!). What is cla= imed is that it is a transparent-tunnel solution (same IPv4 packet received= by destinations as sent by sources, except for TTL which progress, and for= ECNs that may be changed if congestion is met between source and destinati= on).=A0

yes. TTL is progressing = as if it were in translation. ECN is another topic: it changes even in the = encapsulation.=A0
=A0

b) In dra= ft -04, R-7 (8) says:
"CEs that are assigned unspecified IPv= 4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd=A0IPv4 a= ddresses as follows (Figure 6): take the Rule IPv6=A0prefix of the NAT64+ m= apping rue; append the IPv4 address;=A0append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              "
what do you mean with the unspecifi= ed IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? =A0

reading your example in 5.1, i understand your point: t= he above picture describes the mapping for the source address if the packet= is sent to the IPv6 world through BR but without the inverse-header-mappin= g. in this case the U-octet is applied and the CE-delegated prefix plays al= so the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE= . right? if i'm right, it is clear.=A0

but i haven't seen the necessity of defining the V-= octet here. with the V, BR seeing the V does the header mapping while seein= g the U does nothing but only the regular routing. without the V, BR seeing= the CE-delegated /64 does the header mapping while seeing another prefix (= no matter how long the length is) does nothing but only the regular routing= .=A0

the V-attached stuff in fact makes another, more-specif= ic prefix under the delegated prefix of a CE.=A0
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 transpare= ncy of NAT64 nodes by using transparent tunneling, instead of double transl= ation, when reached by 4rd CEs (making them NAT64+ nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a=
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 n= eeds to be upgraded to replace RFC5145 translation by header mapping when I= Pv6 addresses it deals with are 4rd addresses (have the V octet).
confused. how = does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgra= ded at all.=A0


>
>> This new capability, introduced in -04, is derived from the 464XLA= T proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only net= works can communicate via NAT64s, but IPv4 transparency has limitations whi= ch can be eliminated by upgrading NAT64s to NAT64+ status (a backward compa= tible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?
To take advantage, for customers that are 4rd capable, of better IPv4= transparency than with double translation, the NAT64 MUST be upgraded.
=

Remi didn't answer this question of Washam. 4rd-U keeps = only stateful NAT64 as it is at CE, to my understanding.=A0
=A0

may i add tha= t it (4rd-U) provides better IPv4 transparency than double translation but = less simplicity in the term of layering architecture than encapsulation? (h= ere i avoid sticking things on my understanding to "transparency"= ). personally i don't think transparency is the most important reason t= hat generally operators prefer encapsulation rather than translation. simpl= icity and clear concept in architecture is the reason. no matter how much w= e keep IPv4 information unchanged across the IPv6 domain, as long as the IP= v4 header is destroyed, it is a solution of "translation" rather = than of "encapsulation".=A0

Different view here.
a) Ole had a nice slide in the interim meeting about how double translatio= n tends to break transparency. I use "reversible header mapping" = which I find intuitive, or just "header mapping", but "rever= sible header translation" could be OK.=A0
=A0A key difference, is that payloads are transparently tunneled in 4r= d while they are processed, with dependence of upper layer protocols in dou= ble translation. This is AFAIK an important difference. (To take an example= , RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tun= neled with 4rd)

where is it stated in RF= C6145 that it requires to DISCARD UDP-lite packets?=A0
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

b) As sai= d in Sec 1 of=A0draft -04:
=A0"=A0While IPv6 headers are too= long to be mapped=A0into IPv4 headers, so that 6rd requires encapsulation = of full IPv6=A0packets in IPv4 packets, IPv4 headers can be reversibly mapp= ed into=A0IPv6 headers so that 4rd tunnel packets can be designed to be val= id=A0IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes= =A0that perform deep-packet-inspection."
=A0I see no real complexity in noting that IPv4 headers are small enou= gh to be reversibly mapped in IPv6 headers.

our terminologies are biased. i emphasize the simp= licity is in the term of architecture. encapsulation is a widely used conce= pt in the networking, making one protocol as an underlay of another. we may= have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP fra= mework plus but re-ordered and re-organized, into, e.g., a super L2-U. it i= s surely a reversible header mapping but we can't say that of either en= capsulation or the (narrow-sense) tunneling. this is my point. from the ope= rator's view, once it is not the simple layered encapsulation, i cannot= see it as a substitute for the encapsulation, but see it as a substitute o= f other translations, if i see this is a more gentle translation than other= s and this gentleness costs little.=A0
=A0
=A0Of course this still requires careful technical ver= ification, but once done, it's done once and for all.=A0

i don't incline to use the term "tunneling" s= ince tunnel could have a variety of forms, among which encapsulation is one= but not the only one.=A0

Exactly: 4rd uses header-mappi= ng tunnels, and MAP-E uses encapsulation tunnels.

well, in general sense "tunnel" me= ans a source route essentially (RFC1241 made a very good summary about vari= ety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in ge= neral sense of the term "source route"). but we never call it lik= e that, because, when most people are talking about "tunnel" toda= y, we refers to the narrow sense "tunnel", which means the encaps= ulation. it is fine that 4rd-U call itself as a tunnel solution but it shou= ld be pointed out that this is a tunnel in the general sense.=A0

therefore i emphasize that, maybe too academic, the cou= nterpart of translation is encapsulation but not the "tunneling".= in the architecture, we have either the building block of making an underl= ay protocol as a virtual link or the building block of making another proto= col as a participant in the path of end-to-end delivery. although you argue= d this is *ONLY* the understanding of some diffserv guys, i don't think= this understanding is not generic.=A0

for the simplicity in operation, we often think in such= a way: if we would like to hide the underlay and make a protocol as an und= erlay or we would like to expose the things out. both have their use cases.= if 4rd-U is said it fills some important gaps between the two, it would be= great. if 4rd-U is said it replaces the both, i doubt it can. once we want= to make a stuff having advantage of this and that, we often make out a stu= ff also having disadvantage of both. for me, i prefer if 4rd-U is moderatel= y defined with specific use-case and fully description on its pros/cons, fe= atures/limitations, approaches/tradeoffs.=A0

cheers,
maoke
=A0

=

Cheers,
RD

<= div>



cheers,
maoke
=A0
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, o= r dual-stack hosts supporting BIH of RFC6535): they can continue to use the= NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add fragmenta= tion header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--00248c767e9650523904bacd5cff-- From cuiyong@tsinghua.edu.cn Fri Mar 9 04:07:33 2012 Return-Path: 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 4069521F8658 for ; Fri, 9 Mar 2012 04:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495] 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 SlPuNad8Fs4P for ; Fri, 9 Mar 2012 04:07:32 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8407A21F860D for ; Fri, 9 Mar 2012 04:07:32 -0800 (PST) Received: from [219.143.133.70] (helo=[192.168.0.155]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1S5ybW-0005M1-Dp; Fri, 09 Mar 2012 20:07:26 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 09 Mar 2012 20:07:23 +0800 From: Yong Cui To: Message-ID: Thread-Topic: IPR issue on draft-ietf-softwire-gateway-init-ds-lite Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui , Ralph Droms Subject: [Softwires] IPR issue on draft-ietf-softwire-gateway-init-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:07:33 -0000 Hi folks, We Softwire WG submitted draft-ietf-softwire-gateway-init-ds-lite-05 and this draft was last-called during the end of last year. However, there are related IPR disclosures and one of them is a patent application in Chinese language. We contacted the IPR owner, Huawei, and found that there's no official English translation to be provided to us for now. This Chinese application may enter into Europe via PCT. This means that an English PCT version might be available in November 2012. To facilitate our evaluation, Huawei would like to accelerate the translation process internally, hopefully in July, if we need. Our ADs would like to ask our WG to see if we have any opinion regarding the advancement of this I-D. Please reply by this Sunday night. Yong From despres.remi@laposte.net Fri Mar 9 05:14:30 2012 Return-Path: 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 7CBCA21F860E for ; Fri, 9 Mar 2012 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001] 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 2LzJSVEUeAAR for ; Fri, 9 Mar 2012 05:14:28 -0800 (PST) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id BA62E21F8613 for ; Fri, 9 Mar 2012 05:14:27 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id jREP1i00837Y3f403REP4M; Fri, 09 Mar 2012 14:14:25 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-87-804345445 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 9 Mar 2012 14:14:23 +0100 Message-Id: <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:14:30 -0000 --Apple-Mail-87-804345445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Thanks for the detailed question. Clarification below. 2012-03-09 12:04, Maoke : > 2012/3/9 R=E9mi Despr=E9s > Thanks Maoke for the opportunity to clarify some of the points below. >=20 >=20 > 2012-03-09 03:14, Maoke: >=20 >> hi Remi, >>=20 >> sorry but i follow this late. something not clear to me, according to = our earlier discussions. >>=20 >> 2012/3/8 R=E9mi Despr=E9s >>=20 >> Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : >>=20 >> > Hi Remi, >> > >> >>>>> Secondly, -04 added NAT64+ parts. >> >>>>> If I understood correctly, there are no additional requirements = for NAT64 >> >>>>> boxes. >> >>>> >> >>>> Well, NAT64 boxes remain what they are. >> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 = although it >> >>>> has a dual stack. >> >>>> >> >>>> But the advantage of 4rd tunneling over RFC6145 double = translation is better >> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may >> >>>> use the TCP checksum algorithms) >>=20 >> to clarify my understanding: >> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies = the DF=3D1/MF=3D1 cases >> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 = message directly as IPv6 payload is a wise idea. lack of address = consistency ensurance mechanism (i.e. no header checksum in IPv6 header = no pseudo-header checksum in ICMPv4 message) >=20 > The 4rd ICMPv4 error message has as only purpose to be delivered to a = 4rd-aware node. There, it will be treated as an ICMPv4 error. > It is assumed that no DPI in some middle box will need to interpret = ICMPv4 error messages.=20 >=20 >> 3. for the "future protocols", i remember our earlier discussion = concluded that CNP can free the code change with ALREADY KNOWN = tcp-checksumed protocols. am i wrong here?=20 >=20 > I think you are. As the 4rd-u-04 says (sec 4.4): > "NOTE: This guarantees that, for all protocols that use the same = checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and = this independently from where the checksum field is placed for each = protocol. Today, such protocols are UDP [RFC0768], TCP [RFC0793], = UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, = BRs will support them without needing an update." > = = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > exactly here it is the point of disagreement. here the "update" refers = to implementation, right? then what is the BR's logic?=20 >=20 > A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) { > calculate IPv6 address for dst, taking the port from = L4_proto.header;=20 > /* do nothing with checksum, CNP applied for the LIST */ > } else { > discard; > } No. R-7 (3) isn't ambiguous about this. > B. if (1) { > calculate MAP IPv6 address for dst, supposing dst port is always = there; > /* do nothing with checksum suppose CNP applied to all protocols = */ > } Yes, as specified in R-7 (3). As a matter of fact, it doesn't "suppose dst port is always there".=20 It just takes bits that are the right ones if dst port (or ICMPv4 ID) is = present, unless a source has, by mistake, sent a port-less packet to a = shared IPv4 address. What happens in this mistake case is detailed below. =20 > if you refer to logic B, the "BR will support them without needing an = update" is true. Right. > however, the risk is should new ones specified but not having the = tcp-like layout or the tcp-checksum may fail to become a valid IPv6 = packet and (because of the layout difference) it is possible that the = destination IPv6 address is wrong.=20 If a source sends to a shared IPv4 address with a port-less protocol, it = will receive a "destination unreachable" ICMPv4 packet. Its code will be either "network unreachable", because no CE had the = derived IPv6 address (sec. 4.7), or "protocol unreachable", because the = reached CE NAT44 cannot process this port-less protocol. The usual error-signalling mechanism works as it has to. > if you refer to logic A, the BR must be updated whenever any new = protocol is added to the LIST. this is the same as RFC6145. btw, = RFC6145's logic, when applied with MAP, is: > A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) { > calculate IPv6 address for dst, taking the port (or equivalent = field when ICMP) from Payload_Proto.header;=20 > recalculate the checksum in Payload_Proto.header; > } else { > discard; > } >=20 >=20 > both A and A' has no risk as B has. See above why B has no operational risk. Thanks, RD =20 > =20 >=20 >=20 >=20 >> >>>> For an ISP to extend this advantage to its stateful NAT64, it = need to be 4rd >> >>>> aware (become a NAT64+). >> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address = (with a V >> >>>> octet instead of a "u" octet), use the 4rd header mapping = instead of RFC6145 >> >>>> translation. >>=20 >> questions: 1. NAT64+ here refers to stateful case only, right? >=20 >> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make = decision between 4rd-U pseudo-encapsulation (let me use this term = because i argue it does not conform to the behavior of encapsulation) = and NAT64 translation? (as we have neither V nor U in the IPv4 = addresses). >=20 > a) Note that there is no claim that 4rd-u would be an encapsulation = solution (it isn't!). What is claimed is that it is a transparent-tunnel = solution (same IPv4 packet received by destinations as sent by sources, = except for TTL which progress, and for ECNs that may be changed if = congestion is met between source and destination).=20 >=20 > yes. TTL is progressing as if it were in translation. ECN is another = topic: it changes even in the encapsulation.=20 > =20 >=20 > b) In draft -04, R-7 (8) says: > "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST = derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): = take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 = address; append the CNP. > <----------- Rule IPv6 prefix --------->: > +-------------------------------+---+---+-------------+------+ > | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | > +-------------------------------+---+---+-------------+------+ > : 64 : 8 : 8 : 32 : 16 : >=20 > Figure 6 " > what do you mean with the unspecified IPv4 address*es*? isn't it only = the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? =20= >=20 > reading your example in 5.1, i understand your point: the above = picture describes the mapping for the source address if the packet is = sent to the IPv6 world through BR but without the = inverse-header-mapping. in this case the U-octet is applied and the = CE-delegated prefix plays also the role of NAT64+ IPv6 prefix. and the = NAT64+ translation happens at CE. right? if i'm right, it is clear.=20 >=20 > but i haven't seen the necessity of defining the V-octet here. with = the V, BR seeing the V does the header mapping while seeing the U does = nothing but only the regular routing. without the V, BR seeing the = CE-delegated /64 does the header mapping while seeing another prefix (no = matter how long the length is) does nothing but only the regular = routing.=20 >=20 > the V-attached stuff in fact makes another, more-specific prefix under = the delegated prefix of a CE.=20 >> >>> >> >>> I perfer to leave NAT64 out of scope. >> >> >> >> NAT64 as is remains out of scope. >> >> What is in scope is only the possibility to improve IPv4 = transparency of NAT64 nodes by using transparent tunneling, instead of = double translation, when reached by 4rd CEs (making them NAT64+ nodes). >> > >> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What = justify a >> > new term NAT64+ invented? >>=20 >>=20 >> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 = needs to be upgraded to replace RFC5145 translation by header mapping = when IPv6 addresses it deals with are 4rd addresses (have the V octet). >=20 > confused. how does NAT64+ happens at BR? without the V octet, NAT64 = needs not to be upgraded at all.=20 >>=20 >>=20 >> > >> >> This new capability, introduced in -04, is derived from the = 464XLAT proposal. >> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only = networks can communicate via NAT64s, but IPv4 transparency has = limitations which can be eliminated by upgrading NAT64s to NAT64+ status = (a backward compatible evolution). >> >> >> > >> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >>=20 >> To take advantage, for customers that are 4rd capable, of better IPv4 = transparency than with double translation, the NAT64 MUST be upgraded. >=20 >=20 > Remi didn't answer this question of Washam. 4rd-U keeps only stateful = NAT64 as it is at CE, to my understanding.=20 > =20 >>=20 >> may i add that it (4rd-U) provides better IPv4 transparency than = double translation but less simplicity in the term of layering = architecture than encapsulation? (here i avoid sticking things on my = understanding to "transparency"). personally i don't think transparency = is the most important reason that generally operators prefer = encapsulation rather than translation. simplicity and clear concept in = architecture is the reason. no matter how much we keep IPv4 information = unchanged across the IPv6 domain, as long as the IPv4 header is = destroyed, it is a solution of "translation" rather than of = "encapsulation".=20 >=20 > Different view here. > a) Ole had a nice slide in the interim meeting about how double = translation tends to break transparency. I use "reversible header = mapping" which I find intuitive, or just "header mapping", but = "reversible header translation" could be OK.=20 > A key difference, is that payloads are transparently tunneled in 4rd = while they are processed, with dependence of upper layer protocols in = double translation. This is AFAIK an important difference. (To take an = example, RFC6145 requires to discard UDP-lite packets (RFC3828) while = they are tunneled with 4rd) >=20 > where is it stated in RFC6145 that it requires to DISCARD UDP-lite = packets?=20 > =20 >=20 > b) As said in Sec 1 of draft -04: > " While IPv6 headers are too long to be mapped into IPv4 headers, so = that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, = IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd = tunnel packets can be designed to be valid IPv6 packets, thus ensuring = compatibility with IPv6-only middle boxes that perform = deep-packet-inspection." > I see no real complexity in noting that IPv4 headers are small enough = to be reversibly mapped in IPv6 headers. >=20 > our terminologies are biased. i emphasize the simplicity is in the = term of architecture. encapsulation is a widely used concept in the = networking, making one protocol as an underlay of another. we may have a = packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP = framework plus but re-ordered and re-organized, into, e.g., a super = L2-U. it is surely a reversible header mapping but we can't say that of = either encapsulation or the (narrow-sense) tunneling. this is my point. = from the operator's view, once it is not the simple layered = encapsulation, i cannot see it as a substitute for the encapsulation, = but see it as a substitute of other translations, if i see this is a = more gentle translation than others and this gentleness costs little.=20 > =20 > Of course this still requires careful technical verification, but = once done, it's done once and for all.=20 >=20 >> i don't incline to use the term "tunneling" since tunnel could have a = variety of forms, among which encapsulation is one but not the only one.=20= >=20 > Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation = tunnels. >=20 > well, in general sense "tunnel" means a source route essentially = (RFC1241 made a very good summary about variety of tunnels). to such = extent, RFC6145 makes *translation tunnels* (in general sense of the = term "source route"). but we never call it like that, because, when most = people are talking about "tunnel" today, we refers to the narrow sense = "tunnel", which means the encapsulation. it is fine that 4rd-U call = itself as a tunnel solution but it should be pointed out that this is a = tunnel in the general sense.=20 >=20 > therefore i emphasize that, maybe too academic, the counterpart of = translation is encapsulation but not the "tunneling". in the = architecture, we have either the building block of making an underlay = protocol as a virtual link or the building block of making another = protocol as a participant in the path of end-to-end delivery. although = you argued this is *ONLY* the understanding of some diffserv guys, i = don't think this understanding is not generic.=20 >=20 > for the simplicity in operation, we often think in such a way: if we = would like to hide the underlay and make a protocol as an underlay or we = would like to expose the things out. both have their use cases. if 4rd-U = is said it fills some important gaps between the two, it would be great. = if 4rd-U is said it replaces the both, i doubt it can. once we want to = make a stuff having advantage of this and that, we often make out a = stuff also having disadvantage of both. for me, i prefer if 4rd-U is = moderately defined with specific use-case and fully description on its = pros/cons, features/limitations, approaches/tradeoffs.=20 >=20 > cheers, > maoke > =20 >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >>=20 >> cheers, >> maoke >> =20 >> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only = hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue = to use the NAT64+ as an ordinary NAT64. >>=20 >> Regards, >> RD >>=20 >> > >> > Thanks, >> > washam >> >>> Such transparency could be achieved by whther to add = fragmentation header. >> >>> Anyway, let's hear some comments from the group >> >> >> >> OK >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-87-804345445 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/9= R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Thanks Maoke for the opportunity to = clarify some of the points below.


2012-03-09  03:14, Maoke:

hi = Remi,

sorry but i follow this late. = something not clear to me, according to our earlier = discussions.

2012/3/8 R=E9mi Despr=E9s= <despres.remi@laposte.net>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional = requirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in = the NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double = translation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and = future protocols that may
>>>> use the TCP checksum = algorithms)

to clarify my = understanding:
1. DF transparency is kept totally in 4rd-U but = RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 = message directly as IPv6 payload is a wise idea. lack of address = consistency ensurance mechanism (i.e. no header checksum in IPv6 header = no pseudo-header checksum in ICMPv4 message)

The 4rd ICMPv4 error = message has as only purpose to be delivered to a 4rd-aware node. There, = it will be treated as an ICMPv4 error.
It is assumed that no = DPI in some middle box will need to interpret ICMPv4 error = messages. 

3. for the "future protocols", i remember our earlier discussion = concluded that CNP can free the code change with ALREADY KNOWN = tcp-checksumed protocols. am i wrong = here? 

I think you are. As the 4rd-u-04 says (sec = 4.4):
"NOTE: This guarantees that, for all protocols that = use the same checksum algorithm as TCP, Tunnel packets are = valid IPv6 packets, and this independently from where = the checksum field is placed for each protocol.  Today, = such protocols are UDP [RFC0768], TCP [RFC0793], = UDP-Lite [RFC3828], and DCCP [RFC5595].  Should new ones = be specified, BRs will support them without needing = an update."
        =                     =                     =                     =                     =                     =                     =                 =  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
exactly here it is the point of disagreement. here the "update" = refers to implementation, right? then what is the BR's = logic? 

A. if = (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {
      calculate IPv6 address for dst, taking the = port from L4_proto.header; 
      /* do = nothing with checksum, CNP applied for the LIST */
  =  } else {
      discard;
  =  }

No. R-7 = (3) isn't ambiguous about this.


B. if (1) {
      calculate MAP IPv6 = address for dst, supposing dst port is always there;
  =     /* do nothing with checksum suppose CNP applied to all = protocols */
  =  }

Yes, as specified in R-7 = (3).

As a matter of fact, it doesn't "suppose dst = port is always there". 
It just takes bits that are the = right ones if dst port (or ICMPv4 ID) is present, unless a source has, = by mistake, sent a port-less packet to a shared IPv4 = address.
What happens in this mistake case is detailed below. =  


if you refer to logic B, the "BR will support them without needing = an update" is true. =

Right.

however, the risk is = should new ones specified but not having the tcp-like layout or the = tcp-checksum may fail to become a valid IPv6 packet and (because of the = layout difference) it is possible that the destination IPv6 address is = wrong. 

If a = source sends to a shared IPv4 address with a port-less protocol, it will = receive a  "destination unreachable" ICMPv4 = packet.
Its code will be either "network unreachable", because = no CE had the derived IPv6 address (sec. 4.7), or "protocol = unreachable", because the reached CE NAT44 cannot process this port-less = protocol.
The usual error-signalling mechanism works as it has = to.

if you refer to logic A, the BR must be updated whenever any new = protocol is added to the LIST. this is the same as RFC6145. btw, = RFC6145's logic, when applied with MAP, is:
A'. if = (Payload_Proto in LIST{UDP, TCP, ICMP}) {
      calculate IPv6 address for dst, taking the = port (or equivalent field when ICMP) from = Payload_Proto.header; 
      recalculate = the checksum in Payload_Proto.header;
   } else = {
      discard;
   }


both A and = A' has no risk as B = has.

See above why B has no = operational = risk.

Thanks,
RD


 
 



>>>> For an ISP to extend this advantage to its stateful = NAT64, it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd = IPv6 address (with a V
>>>> octet instead of a "u" octet), use the 4rd header = mapping instead of RFC6145
>>>> = translation.

questions: 1. = NAT64+ here refers to stateful case only, = right?

2. for the IPv4-to-IPv6 directly, how does = the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let = me use this term because  i argue it does not conform to the = behavior of encapsulation) and NAT64 translation? (as we have neither V = nor U in the IPv4 addresses).

a) Note that there is no = claim that 4rd-u would be an encapsulation solution (it isn't!). What is = claimed is that it is a transparent-tunnel solution (same IPv4 packet = received by destinations as sent by sources, except for TTL which = progress, and for ECNs that may be changed if congestion is met between = source and destination). 

yes. TTL is = progressing as if it were in translation. ECN is another topic: it = changes even in the = encapsulation. 
 

b) In = draft -04, R-7 (8) says:
"CEs that are assigned unspecified = IPv4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from = 4rd IPv4 addresses as follows (Figure 6): take the Rule = IPv6 prefix of the NAT64+ mapping rue; append the IPv4 = address; append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              =
"
what do you mean with = the unspecified IPv4 address*es*? isn't it only the 0.0.0.0, or you mean = 0.0.0.0/0 excluding the mapped-in-rule = block?  

reading your example in 5.1, i understand your = point: the above picture describes the mapping for the source address if = the packet is sent to the IPv6 world through BR but without the = inverse-header-mapping. in this case the U-octet is applied and the = CE-delegated prefix plays also the role of NAT64+ IPv6 prefix. and the = NAT64+ translation happens at CE. right? if i'm right, it is = clear. 

but i haven't seen the necessity of defining the = V-octet here. with the V, BR seeing the V does the header mapping while = seeing the U does nothing but only the regular routing. without the V, = BR seeing the CE-delegated /64 does the header mapping while seeing = another prefix (no matter how long the length is) does nothing but only = the regular routing. 

the V-attached stuff in fact makes another, = more-specific prefix under the delegated prefix of a = CE. 
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 = transparency of NAT64 nodes by using transparent tunneling, instead of = double translation, when reached by 4rd CEs (making them NAT64+ = nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What = justify a
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the = NAT64 needs to be upgraded to replace RFC5145 translation by header = mapping when IPv6 addresses it deals with are 4rd addresses (have the V = octet).
confused. = how does NAT64+ happens at BR? without the V octet, NAT64 needs not to = be upgraded at all. 


>
>> This new capability, introduced in -04, is derived from the = 464XLAT proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only = networks can communicate via NAT64s, but IPv4 transparency has = limitations which can be eliminated by upgrading NAT64s to NAT64+ status = (a backward compatible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it = is?

To take advantage, for customers that are 4rd capable, of better = IPv4 transparency than with double translation, the NAT64 MUST be = upgraded.

Remi didn't answer this question of Washam. 4rd-U keeps = only stateful NAT64 as it is at CE, to my = understanding. 
 

may i add that it (4rd-U) = provides better IPv4 transparency than double translation but less = simplicity in the term of layering architecture than encapsulation? = (here i avoid sticking things on my understanding to "transparency"). = personally i don't think transparency is the most important reason that = generally operators prefer encapsulation rather than translation. = simplicity and clear concept in architecture is the reason. no matter = how much we keep IPv4 information unchanged across the IPv6 domain, as = long as the IPv4 header is destroyed, it is a solution of "translation" = rather than of "encapsulation". 

Different view = here.
a) Ole had a nice slide in the interim meeting about how = double translation tends to break transparency. I use "reversible header = mapping" which I find intuitive, or just "header mapping", but = "reversible header translation" could be OK. 
 A key difference, is that payloads are transparently tunneled = in 4rd while they are processed, with dependence of upper layer = protocols in double translation. This is AFAIK an important difference. = (To take an example, RFC6145 requires to discard UDP-lite packets = (RFC3828) while they are tunneled with 4rd)

where is it stated in = RFC6145 that it requires to DISCARD UDP-lite = packets? 
 

b) As = said in Sec 1 of draft -04:
 " While IPv6 = headers are too long to be mapped into IPv4 headers, so that 6rd = requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 = headers can be reversibly mapped into IPv6 headers so that 4rd = tunnel packets can be designed to be valid IPv6 packets, thus = ensuring compatibility with IPv6-only middle boxes that perform = deep-packet-inspection."
 I see no real complexity in noting that IPv4 headers are = small enough to be reversibly mapped in IPv6 = headers.

our = terminologies are biased. i emphasize the simplicity is in the term of = architecture. encapsulation is a widely used concept in the networking, = making one protocol as an underlay of another. we may have a packet with = all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but = re-ordered and re-organized, into, e.g., a super L2-U. it is surely a = reversible header mapping but we can't say that of either encapsulation = or the (narrow-sense) tunneling. this is my point. from the operator's = view, once it is not the simple layered encapsulation, i cannot see it = as a substitute for the encapsulation, but see it as a substitute of = other translations, if i see this is a more gentle translation than = others and this gentleness costs little. 
 
 Of course this still = requires careful technical verification, but once done, it's done once = and for all. 

i don't incline to use the term "tunneling" = since tunnel could have a variety of forms, among which encapsulation is = one but not the only one. 

Exactly: 4rd uses = header-mapping tunnels, and MAP-E uses encapsulation = tunnels.

well, = in general sense "tunnel" means a source route essentially (RFC1241 made = a very good summary about variety of tunnels). to such extent, RFC6145 = makes *translation tunnels* (in general sense of the term "source = route"). but we never call it like that, because, when most people are = talking about "tunnel" today, we refers to the narrow sense "tunnel", = which means the encapsulation. it is fine that 4rd-U call itself as a = tunnel solution but it should be pointed out that this is a tunnel in = the general sense. 

therefore i emphasize that, maybe too academic, the = counterpart of translation is encapsulation but not the "tunneling". in = the architecture, we have either the building block of making an = underlay protocol as a virtual link or the building block of making = another protocol as a participant in the path of end-to-end delivery. = although you argued this is *ONLY* the understanding of some diffserv = guys, i don't think this understanding is not generic. 

for the simplicity in operation, we often think in = such a way: if we would like to hide the underlay and make a protocol as = an underlay or we would like to expose the things out. both have their = use cases. if 4rd-U is said it fills some important gaps between the = two, it would be great. if 4rd-U is said it replaces the both, i doubt = it can. once we want to make a stuff having advantage of this and that, = we often make out a stuff also having disadvantage of both. for me, i = prefer if 4rd-U is moderately defined with specific use-case and fully = description on its pros/cons, features/limitations, = approaches/tradeoffs. 
=

cheers,
maoke
 


Cheers,
RD





cheers,
maoke
 
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only = hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue = to use the NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add = fragmentation header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-87-804345445-- From despres.remi@laposte.net Fri Mar 9 05:40:07 2012 Return-Path: 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 2DC2121F861D for ; Fri, 9 Mar 2012 05:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 kIaIh874FaWk for ; Fri, 9 Mar 2012 05:40:06 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id E407E21F84A1 for ; Fri, 9 Mar 2012 05:40:05 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id jRg01i00237Y3f403Rg0Xm; Fri, 09 Mar 2012 14:40:03 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-88-805881867 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F59AE74.4090204@cernet.edu.cn> Date: Fri, 9 Mar 2012 14:39:59 +0100 Message-Id: <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:40:07 -0000 --Apple-Mail-88-805881867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Xing, Le 2012-03-09 =C3=A0 08:17, Xing Li a =C3=A9crit : > Hi, Remi, >=20 > =E4=BA=8E 2012/2/10 18:23, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93: >>=20 >> Hi Xing, >> Good to have you coming in the (unfinished) technical analysis. >>=20 >> I answered to Ole on his remarks, which you support, but not on the = following: >>=20 >> You propose to have a line on "IPv4 to IPv6 communication (single = translation) supported", wit=20 >> Let me therefore reiterate the wish to see an ISP use case, with its = Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem = you see. >=20 > The CERNET2 is an IPv6-only core network. We provide stateless = IPv4/IPv6 translation between CERNET2 and the IPv4 core network = (CERNET). The users can either use single translation directly, or add = their own IPv4/IPv6 translor if double translation is required.=20 >=20 > Is this answer your question? Not quite, since neither example MAP-T Mapping rules nor assigned IPv6 = prefixes are provided, but that may be sufficient so far. A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE = node, when it receives no 4rd mapping rule, to exercise single = translation.=20 Actually, I believe that using for this the BIH of RFC6535 is both = sufficient and recommendable. Translated IPv4 packets, because they are sent from CE nodes to DNS64 = synthesized addresses, are appropriately routed to their destinations. = (It can be via the NAT64-CGN if needed, or via more direct paths if = possible.) Anything missed? Regards, RD > Regards, >=20 > xing >=20 >=20 >>=20 >> Regards, >> RD >> =20 >>=20 >>=20 >>=20 >>=20 >> Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit : >> ... | | | | | >>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | = N | >>>>> | | packets | | | | = | >>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>=20 >>>=20 >>> (2) More clarification should be added here. I am not sure 4rd-H can = support single translation. >>>=20 >>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>=20 >>> (b) In the softwire mailing list, it seems that 4rd-H cannot support = single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html = and other posts. >>>=20 >>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>=20 >> ... >>=20 >>> (5) I would like to see the details of how 4rd-H handles ICMP and = ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>=20 >>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >> ... >>=20 >=20 --Apple-Mail-88-805881867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Xing,

Le 2012-03-09 =C3=A0 08:17, Xing Li a =C3=A9crit = :

=20 =20
Hi, Remi,

=E4=BA=8E 2012/2/10 18:23, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93:
Hi Xing,
Good to have you coming in the (unfinished) technical analysis.

I answered to Ole on his remarks, which you support, but not on the following:

You propose to have a line on "IPv4 to IPv6 communication (single translation) supported", = wit 

Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see.

The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 translation between CERNET2 and the IPv4 core network (CERNET). The users can either use single translation directly, or add their own IPv4/IPv6 translor if double translation is required.

Is this answer your = question?

Not quite, since neither = example MAP-T Mapping rules nor assigned IPv6 prefixes are provided, but = that may be sufficient so far.

 A key = point is that 4rd doesn't prevent a 4rd-capable dual-stack CE = node, when it receives no 4rd mapping rule, to exercise single = translation. 
 Actually, I believe that using for = this the BIH of RFC6535 is both sufficient and = recommendable.
 Translated IPv4 packets, because they are = sent from CE nodes to DNS64 synthesized addresses, are appropriately = routed to their destinations. (It can be via the NAT64-CGN if needed, or = via more direct paths if possible.)
Anything = missed?

Regards,
RD





=20 Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :
... | | | | = |
  |  5 | IPv6 web caches work for IPv4  =
      |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 =
communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...



= --Apple-Mail-88-805881867-- From wdec@cisco.com Fri Mar 9 08:03:07 2012 Return-Path: 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 D1F0921F871D for ; Fri, 9 Mar 2012 08:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.316 X-Spam-Level: X-Spam-Status: No, score=-110.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 gAn6-BAEU3T5 for ; Fri, 9 Mar 2012 08:03:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3A621F8707 for ; Fri, 9 Mar 2012 08:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=690; q=dns/txt; s=iport; t=1331308986; x=1332518586; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=qwg1a8rriINRMvmQ3fVjuueMQmeCfOh8GZ+J9a4ui2M=; b=kzoDZRjN+2ncEsvqHEIPtfPCkFvk1hGofTOtvgPoYECoUmiDfTh7VXnj 4gEahF5jhpFWNzcGJAiBSM4SNLTVz80NN2EcTBM/3o53n/t8zHMYgzMmp Kt+d3G8WRkydPOGAqY1UF+5Tb25VLRrAlkRayxXoWp5jjHejw1k9wogcS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJsoWk+Q/khR/2dsb2JhbABCtT+BB4IMAQQSAScCAToUAYElAQEELgeHaAueWYEnAZcejTiDIgSVSZAcgmQ X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="131851378" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 16:03:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29G350P018731 for ; Fri, 9 Mar 2012 16:03:05 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 17:03:05 +0100 Received: from 10.55.82.114 ([10.55.82.114]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 16:03:04 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 17:03:02 +0100 From: Wojciech Dec To: Message-ID: Thread-Topic: New Version Notification for draft-mdt-softwire-map-translation-01.txt Thread-Index: Acz+DhrT2Lkv7Hw08EGDryjUHCAUcw== In-Reply-To: <20120309160005.22225.51929.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Mar 2012 16:03:05.0220 (UTC) FILETIME=[1CBF5440:01CCFE0E] Subject: [Softwires] New Version Notification for draft-mdt-softwire-map-translation-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:03:08 -0000 Hi All A new version of I-D, draft-mdt-softwire-map-translation-01.txt has been posted under: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 Filename: draft-mdt-softwire-map-translation Revision: 01 Title: MAP Translation (MAP-T) - specification Creation date: 2012-03-09 WG ID: Individual Submission Number of pages: 22 Abstract: This document specifies the "Mapping of Address and Port" (MAP) double stateless translation based solution (MAP-T) for providing IPv4 hosts connectivity to and across an IPv6 domain. We welcome further WG feedback. From despres.remi@laposte.net Fri Mar 9 08:42:54 2012 Return-Path: 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 2C59C21F86DA for ; Fri, 9 Mar 2012 08:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 c5R5IoB2YKYq for ; Fri, 9 Mar 2012 08:42:53 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 713F321F8665 for ; Fri, 9 Mar 2012 08:42:51 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 73BDF940186; Fri, 9 Mar 2012 17:42:44 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 17:42:42 +0100 Message-Id: To: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] Why a BR IPv4 address in MAP Default mapping rule? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:42:54 -0000 Hi Ole, Sec. 4.4 of draft-mdt-softwire-mapping-address-and-port-03 says: "Default Mapping Rule: {2001:db8:0001:0000::/128 (Rule IPv6 prefix), 0.0.0.0/0 (Rule IPv4 prefix), 192.0.2.1 (BR IPv4 address)} Example 3: Default Mapping Rule In most implementations of a routing table, the next-hop address must be = of the same address family as the prefix. To satisfy this requirement a = BR IPv4 address is included in the rule. Giving a default route in the = IPv4 routing table:=20 0.0.0.0 -> 192.0.2.1, MAP-Interface0" I must admit I found this very confusing: - It seems to be a purely internal matter, having therefore no place in = a proposed standard. - In an internal IPv4 routing table, any never-assigned address seems = sufficient (no need for dependence on the BR IPv4 address). - How a MAP-T CE could get the BR IPv4 address isn't specified (no = DHCPv6 parameter specified for its transmission). Thanks for explaining, RD= From ot@cisco.com Fri Mar 9 08:48:36 2012 Return-Path: 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 37EAE21F873C for ; Fri, 9 Mar 2012 08:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 xUcxsG2u+Ntw for ; Fri, 9 Mar 2012 08:48:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7368921F8736 for ; Fri, 9 Mar 2012 08:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1246; q=dns/txt; s=iport; t=1331311715; x=1332521315; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4i3TonQEZixNXT0R7GUJHYvvIvlueyJRDHiTC5LhTZU=; b=LqzD5ZrMs4sJPResmRtjMBvdS/npeV2TjCARXpovr+9+9Q9CY5/wsksn 9lOL7yXLn+G43FEKZIZh45V8EOkxllljiMPpwKIRG4tSi89Uc0KqnCtKq cZ+4xvkXuhE8AyifEetzQr7IREhCdV2fGJYw6WgtSUk6YjpTf87LHToeY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACwzWk+Q/khN/2dsb2JhbABDtTKBB4IKAQEBAwESARQTPwULC0ZXBjWHYwWcGwGfBY93YwSVSZAcgmQ X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="131857060" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 16:48:33 +0000 Received: from dhcp-10-61-96-216.cisco.com (dhcp-10-61-96-216.cisco.com [10.61.96.216]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q29GmXQJ003561; Fri, 9 Mar 2012 16:48:33 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 9 Mar 2012 17:48:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] Why a BR IPv4 address in MAP Default mapping rule? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:48:36 -0000 Remi, > Sec. 4.4 of draft-mdt-softwire-mapping-address-and-port-03 says: > "Default Mapping Rule: > {2001:db8:0001:0000::/128 (Rule IPv6 prefix), > 0.0.0.0/0 (Rule IPv4 prefix), > 192.0.2.1 (BR IPv4 address)} >=20 > Example 3: Default Mapping Rule >=20 > In most implementations of a routing table, the next-hop address must = be of the same address family as the prefix. To satisfy this = requirement a BR IPv4 address is included in the rule. Giving a default = route in the IPv4 routing table:=20 > 0.0.0.0 -> 192.0.2.1, MAP-Interface0" >=20 > I must admit I found this very confusing: > - It seems to be a purely internal matter, having therefore no place = in a proposed standard. > - In an internal IPv4 routing table, any never-assigned address seems = sufficient (no need for dependence on the BR IPv4 address). the idea of the BR also being part of the domain has some benefits. e.g. it is possible to IPv4 ping the default gateway. it isn't strictly = necessary as you say, but I think it has value in troubleshooting. > - How a MAP-T CE could get the BR IPv4 address isn't specified (no = DHCPv6 parameter specified for its transmission). manual configuration. cheers, Ole= From despres.remi@laposte.net Fri Mar 9 08:52:10 2012 Return-Path: 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 06D1821E800E for ; Fri, 9 Mar 2012 08:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 4tvboHjijBnr for ; Fri, 9 Mar 2012 08:52:09 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC221F8600 for ; Fri, 9 Mar 2012 08:52:03 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id jUs11i00Q37Y3f403Us1Ng; Fri, 09 Mar 2012 17:52:02 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 9 Mar 2012 17:52:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3028AA06-F236-4589-9CF6-8788128A7702@laposte.net> References: To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Why a BR IPv4 address in MAP Default mapping rule? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:52:10 -0000 Le 2012-03-09 =E0 17:48, Ole Tr=F8an a =E9crit : > Remi, >=20 >> Sec. 4.4 of draft-mdt-softwire-mapping-address-and-port-03 says: >> "Default Mapping Rule: >> {2001:db8:0001:0000::/128 (Rule IPv6 prefix), >> 0.0.0.0/0 (Rule IPv4 prefix), >> 192.0.2.1 (BR IPv4 address)} >>=20 >> Example 3: Default Mapping Rule >>=20 >> In most implementations of a routing table, the next-hop address must = be of the same address family as the prefix. To satisfy this = requirement a BR IPv4 address is included in the rule. Giving a default = route in the IPv4 routing table:=20 >> 0.0.0.0 -> 192.0.2.1, MAP-Interface0" >>=20 >> I must admit I found this very confusing: >> - It seems to be a purely internal matter, having therefore no place = in a proposed standard. Not answered. >> - In an internal IPv4 routing table, any never-assigned address seems = sufficient (no need for dependence on the BR IPv4 address). >=20 > the idea of the BR also being part of the domain has some benefits. > e.g. it is possible to IPv4 ping the default gateway. it isn't = strictly necessary as you say, but I think it has value in = troubleshooting. >=20 >> - How a MAP-T CE could get the BR IPv4 address isn't specified (no = DHCPv6 parameter specified for its transmission). >=20 > manual configuration. Are you really suggesting that MAP-T CEs would be manually configured? RD >=20 > cheers, > Ole From ot@cisco.com Fri Mar 9 08:56:29 2012 Return-Path: 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 89C3F21F8713 for ; Fri, 9 Mar 2012 08:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 iqSLz6lu6hGU for ; Fri, 9 Mar 2012 08:56:28 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE4A21F866B for ; Fri, 9 Mar 2012 08:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1537; q=dns/txt; s=iport; t=1331312188; x=1332521788; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Cb24ugKjkYq3rK14lAn71fyt3mC9PtonoKiV1zlGsSE=; b=VllO7nC+QTCJHjZSiwIq3GmRdXlxGiecA5KdBt6rL7E5LKN+mv9WTpNI w4FYA6PBMn41sS+iLEZ3zwt6XYH/IEcGeFFTjerZweLqJdbPEOqgaTKQQ CuyyDis1S+i5kAU0RygFXBc4PQpiAeKy/X7d+uL6Pysp3DtAWM2KqS/vy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIQ1Wk+Q/khL/2dsb2JhbABDtTKBB4IKAQEBAwESARRSEAtGVwY1h2MFnBMBnwSPd2MElUmQHIJk X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="131857824" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 16:56:27 +0000 Received: from dhcp-10-61-96-216.cisco.com (dhcp-10-61-96-216.cisco.com [10.61.96.216]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29GuRpl014256; Fri, 9 Mar 2012 16:56:27 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <3028AA06-F236-4589-9CF6-8788128A7702@laposte.net> Date: Fri, 9 Mar 2012 17:56:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62C66F07-CC39-42F7-9DAF-B9E3F816ADAA@cisco.com> References: <3028AA06-F236-4589-9CF6-8788128A7702@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] Why a BR IPv4 address in MAP Default mapping rule? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:56:29 -0000 >>> Sec. 4.4 of draft-mdt-softwire-mapping-address-and-port-03 says: >>> "Default Mapping Rule: >>> {2001:db8:0001:0000::/128 (Rule IPv6 prefix), >>> 0.0.0.0/0 (Rule IPv4 prefix), >>> 192.0.2.1 (BR IPv4 address)} >>>=20 >>> Example 3: Default Mapping Rule >>>=20 >>> In most implementations of a routing table, the next-hop address = must be of the same address family as the prefix. To satisfy this = requirement a BR IPv4 address is included in the rule. Giving a default = route in the IPv4 routing table:=20 >>> 0.0.0.0 -> 192.0.2.1, MAP-Interface0" >>>=20 >>> I must admit I found this very confusing: >>> - It seems to be a purely internal matter, having therefore no place = in a proposed standard. >=20 > Not answered. see two lines below. >>> - In an internal IPv4 routing table, any never-assigned address = seems sufficient (no need for dependence on the BR IPv4 address). >>=20 >> the idea of the BR also being part of the domain has some benefits. >> e.g. it is possible to IPv4 ping the default gateway. it isn't = strictly necessary as you say, but I think it has value in = troubleshooting. >>=20 >>> - How a MAP-T CE could get the BR IPv4 address isn't specified (no = DHCPv6 parameter specified for its transmission). >>=20 >> manual configuration. >=20 > Are you really suggesting that MAP-T CEs would be manually configured? no, sorry, I thought you asked how the BR was configured. the CE can extract the BR IPv4 address from the BR IPv6 address. Ole= From despres.remi@laposte.net Fri Mar 9 09:13:43 2012 Return-Path: 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 69AE921F8459 for ; Fri, 9 Mar 2012 09:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 6oJZn+dvJRw3 for ; Fri, 9 Mar 2012 09:13:42 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id F261221F869F for ; Fri, 9 Mar 2012 09:13:35 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id jVDa1i00337Y3f403VDaU7; Fri, 09 Mar 2012 18:13:34 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <62C66F07-CC39-42F7-9DAF-B9E3F816ADAA@cisco.com> Date: Fri, 9 Mar 2012 18:13:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55928F8D-FBD4-4B44-8FAF-562019D02910@laposte.net> References: <3028AA06-F236-4589-9CF6-8788128A7702@laposte.net> <62C66F07-CC39-42F7-9DAF-B9E3F816ADAA@cisco.com> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Why a BR IPv4 address in MAP Default mapping rule? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:13:43 -0000 Le 2012-03-09 =E0 17:56, Ole Tr=F8an a =E9crit : >>>> Sec. 4.4 of draft-mdt-softwire-mapping-address-and-port-03 says: >>>> "Default Mapping Rule: >>>> {2001:db8:0001:0000::/128 (Rule IPv6 prefix), >>>> 0.0.0.0/0 (Rule IPv4 prefix), >>>> 192.0.2.1 (BR IPv4 address)} >>>>=20 >>>> Example 3: Default Mapping Rule >>>>=20 >>>> In most implementations of a routing table, the next-hop address = must be of the same address family as the prefix. To satisfy this = requirement a BR IPv4 address is included in the rule. Giving a default = route in the IPv4 routing table:=20 >>>> 0.0.0.0 -> 192.0.2.1, MAP-Interface0" >>>>=20 >>>> I must admit I found this very confusing: >>>> - It seems to be a purely internal matter, having therefore no = place in a proposed standard. >>=20 >> Not answered. >=20 > see two lines below. They don't explain why one would need "0.0.0.0 -> 192.0.2.1, = MAP-Interface0" in a proposed standard. >>>> - In an internal IPv4 routing table, any never-assigned address = seems sufficient (no need for dependence on the BR IPv4 address). >>>=20 >>> the idea of the BR also being part of the domain has some benefits. >>> e.g. it is possible to IPv4 ping the default gateway. it isn't = strictly necessary as you say, but I think it has value in = troubleshooting. >>>=20 >>>> - How a MAP-T CE could get the BR IPv4 address isn't specified (no = DHCPv6 parameter specified for its transmission). >>>=20 >>> manual configuration. >>=20 >> Are you really suggesting that MAP-T CEs would be manually = configured? >=20 > no, sorry, I thought you asked how the BR was configured. No hurry is needed, but please answer THE question. Not only does it = concern a CE (not a BR), but also a -T (not a -E). > the CE can extract the BR IPv4 address from the BR IPv6 address. The draft says: "The Rule IPv6 prefix is the IPv6 address or prefix of the BR. Which is = used, is dependent on the mode used. For example translation requires = that the IPv4 destination address is encoded in the BR IPv6 address, so = only a prefix is used in the DMR to allow for a generated interface = identifier."=20 Thanks, RD=20 >=20 > Ole From sarikaya2012@gmail.com Fri Mar 9 09:30:52 2012 Return-Path: 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 31D0221F86B7 for ; Fri, 9 Mar 2012 09:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rq+3loqfI-Qe for ; Fri, 9 Mar 2012 09:30:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5621F86B1 for ; Fri, 9 Mar 2012 09:30:51 -0800 (PST) Received: by iazz13 with SMTP id z13so2784164iaz.31 for ; Fri, 09 Mar 2012 09:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=SZj2VklnxRKtKZK+t6pqENlRqKjcGLy8gkPcnV7NPvk=; b=oZdbrx+W0GgBg1jzSuo7ilNiccp8dt8LqwNUPB/pFwGRYsKF8QmZpl1L+eRoH+REYs coTiPYYJM7pMZLPBEK2TN2R15ExYr+agyrV6R/lygsad6krLm9I5s9FqzvXdmw5/T3Zs HsmBczLtATniBa/Gp0JM6R5Vpm0sN+OkdthPtBmin1ciRB4yY7LV89PBAxrpx2m2qjsV UDVYCYfa2L5jqbMI1Gbbnf5/noc78UcK9/OIWClprf537+YOt62B4rQTC0AAe7DiQCoQ h6TUPjNA6tTqzgvH/zN6ktZm5arvxbkpKgEn2dmZzqObwsfYF0r9gohhNpYbrpkKch9d 2D5w== MIME-Version: 1.0 Received: by 10.43.52.74 with SMTP id vl10mr3885192icb.55.1331314251135; Fri, 09 Mar 2012 09:30:51 -0800 (PST) Received: by 10.231.179.71 with HTTP; Fri, 9 Mar 2012 09:30:51 -0800 (PST) In-Reply-To: References: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> Date: Fri, 9 Mar 2012 11:30:51 -0600 Message-ID: From: Behcet Sarikaya To: Softwires-wg , Softwire Chairs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:30:52 -0000 +1 Behcet On Mon, Feb 6, 2012 at 10:30 PM, Qiong wrote: > +1 support > > > On Mon, Feb 6, 2012 at 5:33 PM, wrote: >> >> Hi, >> >> I support the adoption of this draft as a softwire WG document. >> >> Cheers, >> >> Christian. >> >> >> -----Message d'origine----- >> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De l= a >> part de Yong Cui >> Envoy=E9 : lundi 6 f=E9vrier 2012 01:57 >> =C0 : Softwires WG >> Cc : Yong Cui >> Objet : [Softwires] ask for adoption of >> draft-qin-softwire-multicast-prefix-option >> >> Dear Softwires wg, >> >> >> As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix = in >> Taipei meeting, the chairs would like to ask for WG adoption on the mail= ing >> list. Please review this document and send your comments (especially you= r >> opinion on the adoption with your reasons) to the mailing list by two we= eks, >> i.e. Feb. 20. >> >> FYI: >> >> http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-opti= on/ >> >> >> Yong & Alain >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorization. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange shall not be liable if >> this message was modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From washam.fan@gmail.com Sun Mar 11 01:49:00 2012 Return-Path: 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 64D2621F84FC for ; Sun, 11 Mar 2012 01:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZnHaPa8kPI-1 for ; Sun, 11 Mar 2012 01:48:59 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89C9221F84F6 for ; Sun, 11 Mar 2012 01:48:59 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1835610wib.13 for ; Sun, 11 Mar 2012 01:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fxZhU8oVNPjGMXj3ZjJgIrMCTYD+SrLpdPDkPZk/0Hk=; b=cwCXMllxBmB0mbS7/BKMrUZP2aXg64YqbU3BOVYK0ypV8d1396uMi5IftbH9cud5BU Jy/1r46Rt648keV9eEm0UUZ5js9GB5B4c3e/EK7I0VQP8pHoNzT2JhHoJLRw8nin9iBy iolcK3PK+BUKm5+DhgMllnzm5FVVPvLZz9dHH72oSH0nGCcnwXDe1tMrd0ujv+ifxD5I /itzf1tcU41lAULP014Nuv8t5UZBVkCJ1cvRNGeG0GJE6AKR+l1untPN9kC8m7H00Yld +UqLED1H1NRk6F4enB1V7qVc8MEBZrcpSWc5fhJGCtAf82HWy/S4lDHs3+7kKQbxiNLi PHVA== MIME-Version: 1.0 Received: by 10.180.19.196 with SMTP id h4mr14594675wie.12.1331459338488; Sun, 11 Mar 2012 01:48:58 -0800 (PST) Received: by 10.216.205.169 with HTTP; Sun, 11 Mar 2012 01:48:58 -0800 (PST) Date: Sun, 11 Mar 2012 17:48:58 +0800 Message-ID: From: Washam Fan To: Softwires Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 09:49:00 -0000 Hi, Eventually I get a chance to review this version and have some major comments and questions as below. 1. Relationship with MAP, MAP-T, MAP-E. I thought, MAP was expected to be a generic algorithm for stateless mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, MAP would apply to MAP-T, MAP-E as well as 4rd-u. But draft 4rd-u-04 doesn't mention MAP draft. And I see the mapping rules stuff in the draft overlapped with MAP. Confused. I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. Would you mind expaund on what benefits 4rd-u can gain exclusively? Ideally, there would be a seperate section or even a seperate draft for such comparison. 2. NAT64+ stuff. My understanding, NAT64+ would translate 4rd tunnel packet as well as native IPv6 packet to IPv4 packet and vice verse. Right? I don't know what the CE delegated prefix in NAT64+ looks like. Can the native IPv6 and 4rd shared the same delegated prefix? if Yes, how to distinguish them? the figure 6 seems to me it was talking about destination IPv6 address derivation. IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support harpinning between 4rd tunnel packet and native IPv6 packet? Personally, I'd like NAT64+ removed from the draft. It might deserve a seperate draft. This way, it would make the draft more understanding for readers who are new to 4rd-u. 3. Fragments. The algorithm proposed in R-9, would have applied to generic NAT generally. Why it is specific to 4rd BR? Anyway BR would keep fragment state somehow and anycase BR facing IPv4 Internet would be impossible. Thanks, washam From fibrib@gmail.com Sun Mar 11 19:08:17 2012 Return-Path: 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 3DE4A21F85D7 for ; Sun, 11 Mar 2012 19:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] 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 a-MHShQsmlLP for ; Sun, 11 Mar 2012 19:08:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE01021F8513 for ; Sun, 11 Mar 2012 19:08:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2360403ghb.31 for ; Sun, 11 Mar 2012 19:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0JlJhSFfeaHbi8Gh9aO1x0BFUTMzqQdAniy5wxntDM=; b=eCMindQJvOdlZ03htnuSrzAsF03g5QCQdHwzqpXq0LeDns9S1bzkx8IdwPxZe5AJ5M nx1nP49qJzcDNPGmM5Q2ufuuRjWbf4RJN0wxqwcuCgBLjaPeBZc8CrfzjgUfOguClFo0 hVFhy9wtgfm4AgcZ0EdTodS3hF4v6xCFdUi9JjXjgOgT8FC27xmVoerHk+IwtN67lG6I xEsdfJ7SIkSolCAuDN+HcVr32rqxO5TkxMwheBeEM/+vpS4VCrY+jLklzYyDk4CiEyzd aimUUiTOz23WBZR7b5G95vS/7lDQ49XmiZf93FhwMldI+3Dg4HgTQxb3lgIAsULt82Vf NZdg== MIME-Version: 1.0 Received: by 10.229.134.196 with SMTP id k4mr1977251qct.29.1331518094122; Sun, 11 Mar 2012 19:08:14 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sun, 11 Mar 2012 19:08:14 -0700 (PDT) In-Reply-To: <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> Date: Mon, 12 Mar 2012 11:08:14 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c6a86e203213504bb0237dd Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 02:08:17 -0000 --00248c6a86e203213504bb0237dd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/9 R=E9mi Despr=E9s > Maoke, > Thanks for the detailed question. > Clarification below. > > > 2012-03-09 12:04, Maoke : > > 2012/3/9 R=E9mi Despr=E9s > >> Thanks Maoke for the opportunity to clarify some of the points below. >> >> >> 2012-03-09 03:14, Maoke: >> >> hi Remi, >> >> sorry but i follow this late. something not clear to me, according to ou= r >> earlier discussions. >> >> 2012/3/8 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : >>> >>> > Hi Remi, >>> > >>> >>>>> Secondly, -04 added NAT64+ parts. >>> >>>>> If I understood correctly, there are no additional requirements >>> for NAT64 >>> >>>>> boxes. >>> >>>> >>> >>>> Well, NAT64 boxes remain what they are. >>> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 >>> although it >>> >>>> has a dual stack. >>> >>>> >>> >>>> But the advantage of 4rd tunneling over RFC6145 double translation >>> is better >>> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocol= s >>> that may >>> >>>> use the TCP checksum algorithms) >>> >> >> to clarify my understanding: >> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the >> DF=3D1/MF=3D1 cases >> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message >> directly as IPv6 payload is a wise idea. lack of address consistency >> ensurance mechanism (i.e. no header checksum in IPv6 header no >> pseudo-header checksum in ICMPv4 message) >> >> >> The 4rd ICMPv4 error message has as only purpose to be delivered to a >> 4rd-aware node. There, it will be treated as an ICMPv4 error. >> It is assumed that no DPI in some middle box will need to interpret >> ICMPv4 error messages. >> >> 3. for the "future protocols", i remember our earlier discussion >> concluded that CNP can free the code change with ALREADY KNOWN >> tcp-checksumed protocols. am i wrong here? >> >> >> I think you are. As the 4rd-u-04 says (sec 4.4): >> "NOTE: This guarantees that, for all protocols that use the same checksu= m >> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this >> independently from where the checksum field is placed for each protocol. >> Today, such protocols are UDP [RFC0768], TCP [RFC0793], >> UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, B= Rs >> will support them without needing an update." >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > exactly here it is the point of disagreement. here the "update" refers to > implementation, right? then what is the BR's logic? > > > A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) { > calculate IPv6 address for dst, taking the port from > L4_proto.header; > /* do nothing with checksum, CNP applied for the LIST */ > } else { > discard; > } > > > No. R-7 (3) isn't ambiguous about this. > > > B. if (1) { > calculate MAP IPv6 address for dst, supposing dst port is always > there; > /* do nothing with checksum suppose CNP applied to all protocols */ > } > > > Yes, as specified in R-7 (3). > > As a matter of fact, it doesn't "suppose dst port is always there". > It just takes bits that are the right ones if dst port (or ICMPv4 ID) is > present, unless a source has, by mistake, sent a port-less packet to a > shared IPv4 address. > What happens in this mistake case is detailed below. > > > if you refer to logic B, the "BR will support them without needing an > update" is true. > > > Right. > > however, the risk is should new ones specified but not having the tcp-lik= e > layout or the tcp-checksum may fail to become a valid IPv6 packet and > (because of the layout difference) it is possible that the destination IP= v6 > address is wrong. > > > If a source sends to a shared IPv4 address with a port-less protocol, it > will receive a "destination unreachable" ICMPv4 packet. > Its code will be either "network unreachable", because no CE had the > derived IPv6 address (sec. 4.7), or "protocol unreachable", because the > reached CE NAT44 cannot process this port-less protocol. > The usual error-signalling mechanism works as it has to. > > ok. now i got the whole picture. sorry for the late understanding. but does this means 4rd-U is an extension of NAT44 or at least depends upon NAT44? RFC6145 has no such dependence at all. - maoke > > > if you refer to logic A, the BR must be updated whenever any new protocol > is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, > when applied with MAP, is: > A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) { > calculate IPv6 address for dst, taking the port (or equivalent fiel= d > when ICMP) from Payload_Proto.header; > recalculate the checksum in Payload_Proto.header; > } else { > discard; > } > > > both A and A' has no risk as B has. > > > See above why B has no operational risk. > > Thanks, > RD > > > > > > > >> >> >>>> For an ISP to extend this advantage to its stateful NAT64, it need >>> to be 4rd >>> >>>> aware (become a NAT64+). >>> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address >>> (with a V >>> >>>> octet instead of a "u" octet), use the 4rd header mapping instead >>> of RFC6145 >>> >>>> translation. >>> >> >> questions: 1. NAT64+ here refers to stateful case only, right? >> >> >> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make >> decision between 4rd-U pseudo-encapsulation (let me use this term becaus= e >> i argue it does not conform to the behavior of encapsulation) and NAT64 >> translation? (as we have neither V nor U in the IPv4 addresses). >> >> >> a) Note that there is no claim that 4rd-u would be an encapsulation >> solution (it isn't!). What is claimed is that it is a transparent-tunnel >> solution (same IPv4 packet received by destinations as sent by sources, >> except for TTL which progress, and for ECNs that may be changed if >> congestion is met between source and destination). >> > > yes. TTL is progressing as if it were in translation. ECN is another > topic: it changes even in the encapsulation. > > >> >> b) In draft -04, R-7 (8) says: >> "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST >> derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): >> take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 >> address; append the CNP. >> >> <----------- Rule IPv6 prefix --------->: >> +-------------------------------+---+---+-------------+------+ >> | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | >> +-------------------------------+---+---+-------------+------+ >> : 64 : 8 : 8 : 32 : 16 : >> >> Figure 6 " >> >> what do you mean with the unspecified IPv4 address*es*? isn't it only th= e > 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? > > reading your example in 5.1, i understand your point: the above picture > describes the mapping for the source address if the packet is sent to the > IPv6 world through BR but without the inverse-header-mapping. in this cas= e > the U-octet is applied and the CE-delegated prefix plays also the role of > NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i= 'm > right, it is clear. > > but i haven't seen the necessity of defining the V-octet here. with the V= , > BR seeing the V does the header mapping while seeing the U does nothing b= ut > only the regular routing. without the V, BR seeing the CE-delegated /64 > does the header mapping while seeing another prefix (no matter how long t= he > length is) does nothing but only the regular routing. > > the V-attached stuff in fact makes another, more-specific prefix under th= e > delegated prefix of a CE. > >> >>> >>> >>> I perfer to leave NAT64 out of scope. >>> >> >>> >> NAT64 as is remains out of scope. >>> >> What is in scope is only the possibility to improve IPv4 transparenc= y >>> of NAT64 nodes by using transparent tunneling, instead of double >>> translation, when reached by 4rd CEs (making them NAT64+ nodes). >>> > >>> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify = a >>> > new term NAT64+ invented? >>> >>> >>> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 >>> needs to be upgraded to replace RFC5145 translation by header mapping w= hen >>> IPv6 addresses it deals with are 4rd addresses (have the V octet). >>> >> confused. how does NAT64+ happens at BR? without the V octet, NAT64 need= s > not to be upgraded at all. > >> >>> >>> > >>> >> This new capability, introduced in -04, is derived from the 464XLAT >>> proposal. >>> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only >>> networks can communicate via NAT64s, but IPv4 transparency has limitati= ons >>> which can be eliminated by upgrading NAT64s to NAT64+ status (a backwar= d >>> compatible evolution). >>> >> >>> > >>> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >>> >>> To take advantage, for customers that are 4rd capable, of better IPv4 >>> transparency than with double translation, the NAT64 MUST be upgraded. >>> >> > Remi didn't answer this question of Washam. 4rd-U keeps only stateful > NAT64 as it is at CE, to my understanding. > > >> >> may i add that it (4rd-U) provides better IPv4 transparency than double >> translation but less simplicity in the term of layering architecture tha= n >> encapsulation? (here i avoid sticking things on my understanding to >> "transparency"). personally i don't think transparency is the most >> important reason that generally operators prefer encapsulation rather th= an >> translation. simplicity and clear concept in architecture is the reason.= no >> matter how much we keep IPv4 information unchanged across the IPv6 domai= n, >> as long as the IPv4 header is destroyed, it is a solution of "translatio= n" >> rather than of "encapsulation". >> >> >> Different view here. >> a) Ole had a nice slide in the interim meeting about how double >> translation tends to break transparency. I use "reversible header mappin= g" >> which I find intuitive, or just "header mapping", but "reversible header >> translation" could be OK. >> A key difference, is that payloads are transparently tunneled in 4rd >> while they are processed, with dependence of upper layer protocols in >> double translation. This is AFAIK an important difference. (To take an >> example, RFC6145 requires to discard UDP-lite packets (RFC3828) while th= ey >> are tunneled with 4rd) >> > > where is it stated in RFC6145 that it requires to DISCARD UDP-lite > packets? > > >> >> b) As said in Sec 1 of draft -04: >> " While IPv6 headers are too long to be mapped into IPv4 headers, so >> that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IP= v4 >> headers can be reversibly mapped into IPv6 headers so that 4rd tunnel >> packets can be designed to be valid IPv6 packets, thus ensuring >> compatibility with IPv6-only middle boxes that perform >> deep-packet-inspection." >> I see no real complexity in noting that IPv4 headers are small enough t= o >> be reversibly mapped in IPv6 headers. >> > > our terminologies are biased. i emphasize the simplicity is in the term o= f > architecture. encapsulation is a widely used concept in the networking, > making one protocol as an underlay of another. we may have a packet with > all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but > re-ordered and re-organized, into, e.g., a super L2-U. it is surely a > reversible header mapping but we can't say that of either encapsulation o= r > the (narrow-sense) tunneling. this is my point. from the operator's view, > once it is not the simple layered encapsulation, i cannot see it as a > substitute for the encapsulation, but see it as a substitute of other > translations, if i see this is a more gentle translation than others and > this gentleness costs little. > > >> Of course this still requires careful technical verification, but once >> done, it's done once and for all. >> >> i don't incline to use the term "tunneling" since tunnel could have a >> variety of forms, among which encapsulation is one but not the only one. >> >> >> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation >> tunnels. >> > > well, in general sense "tunnel" means a source route essentially (RFC1241 > made a very good summary about variety of tunnels). to such extent, RFC61= 45 > makes *translation tunnels* (in general sense of the term "source route")= . > but we never call it like that, because, when most people are talking abo= ut > "tunnel" today, we refers to the narrow sense "tunnel", which means the > encapsulation. it is fine that 4rd-U call itself as a tunnel solution but > it should be pointed out that this is a tunnel in the general sense. > > therefore i emphasize that, maybe too academic, the counterpart of > translation is encapsulation but not the "tunneling". in the architecture= , > we have either the building block of making an underlay protocol as a > virtual link or the building block of making another protocol as a > participant in the path of end-to-end delivery. although you argued this = is > *ONLY* the understanding of some diffserv guys, i don't think this > understanding is not generic. > > for the simplicity in operation, we often think in such a way: if we woul= d > like to hide the underlay and make a protocol as an underlay or we would > like to expose the things out. both have their use cases. if 4rd-U is sai= d > it fills some important gaps between the two, it would be great. if 4rd-U > is said it replaces the both, i doubt it can. once we want to make a stuf= f > having advantage of this and that, we often make out a stuff also having > disadvantage of both. for me, i prefer if 4rd-U is moderately defined wit= h > specific use-case and fully description on its pros/cons, > features/limitations, approaches/tradeoffs. > > cheers, > maoke > > >> >> >> Cheers, >> RD >> >> >> >> >> >> cheers, >> maoke >> >> >>> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only >>> hosts, or dual-stack hosts supporting BIH of RFC6535): they can continu= e to >>> use the NAT64+ as an ordinary NAT64. >>> >>> Regards, >>> RD >>> >>> > >>> > Thanks, >>> > washam >>> >>> Such transparency could be achieved by whther to add fragmentation >>> header. >>> >>> Anyway, let's hear some comments from the group >>> >> >>> >> OK >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> > > --00248c6a86e203213504bb0237dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/3/9 R=E9mi Despr=E9s = <despres.remi@laposte.net>
Maoke,
Thanks for the detailed ques= tion.
Clarification below.


2012-03-09 12:04, Maoke =A0:
2012/3/9 R=E9mi Despr=E9s <= despres.remi@= laposte.net>
Thanks Maoke for the opportunity to cla= rify some of the points below.



hi Remi,

sorry but i follow this late. something not clear to me, according to ou= r earlier discussions.

2012/3/8 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional req= uirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in the= NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double tra= nslation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may
>>>> use the TCP checksum algorithms)

to clarify my understanding:
1. DF transparency = is kept totally in 4rd-U but RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 messag= e directly as IPv6 payload is a wise idea. lack of address consistency ensu= rance mechanism (i.e. no header checksum in IPv6 header no pseudo-header ch= ecksum in ICMPv4 message)

The 4rd ICMPv4 error message h= as as only purpose to be delivered to a 4rd-aware node. There, it will be t= reated as an ICMPv4 error.
It is assumed that no DPI in some midd= le box will need to interpret ICMPv4 error messages.=A0

3. for the "future protocols", i remember our earlier discus= sion concluded that CNP can free the code change with ALREADY KNOWN tcp-che= cksumed protocols. am i wrong here?=A0

I think you are. As the 4rd-u-04 says (sec 4.4):
"NOTE: This guarantees that, for all protocols that use the=A0sa= me checksum algorithm as TCP, Tunnel packets are valid=A0IPv6 packets, and = this independently from where the=A0checksum field is placed for each proto= col. =A0Today, such=A0protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite= =A0[RFC3828], and DCCP [RFC5595]. =A0Should new ones be=A0specified, BRs wi= ll support them without needing an=A0update."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^
exactly here it is the point of disagreement. here the "update&qu= ot; refers to implementation, right? then what is the BR's logic?=A0

A.= if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port from L4_pr= oto.header;=A0
=A0 =A0 =A0 /* do nothing with checksum, CNP appli= ed for the LIST */
=A0 =A0} else {
=A0 =A0 =A0 discard;=
=A0 =A0}

No.=A0R-7 (3)=A0isn'= t ambiguous about this.


B. if (1) {
=A0 =A0 =A0 calculate MAP IPv6 address for dst, = supposing dst port is always there;
=A0 =A0 =A0 /* do nothing wit= h checksum suppose CNP applied to all protocols */
=A0 =A0}
=

Yes, as specified in R-7 (3).

A= s a matter of fact, it doesn't "suppose dst port is always there&q= uot;.=A0
It just takes bits that are the right ones if dst port (= or ICMPv4 ID) is present, unless a source has, by mistake, sent a port-less= packet to a shared IPv4 address.
What happens in this mistake case is detailed below. =A0


if you refer to logic B, the "BR will support them without needin= g an update" is true.

Right.

however, the risk is should new ones specified but not having the tcp-= like layout or the tcp-checksum may fail to become a valid IPv6 packet and = (because of the layout difference) it is possible that the destination IPv6= address is wrong.=A0

If a source sends to a sh= ared IPv4 address with a port-less protocol, it will receive a =A0"des= tination unreachable"=A0ICMPv4 packet.
Its code will be eith= er "network unreachable", because no CE had the derived IPv6 addr= ess (sec. 4.7), or "protocol unreachable", because the reached CE= NAT44 cannot process this port-less protocol.
The usual error-signalling mechanism works as it has to.
=A0=
=A0
ok. now i got= the whole picture. sorry for the late understanding.
but does t= his means 4rd-U is an extension of NAT44 or at least depends upon NAT44?
=A0
RFC6145 has no such dependence at all.
=A0
- maoke
=A0
=A0

<= /div>
if you refer to logic A, the BR must be updated whenever any new proto= col is added to the LIST. this is the same as RFC6145. btw, RFC6145's l= ogic, when applied with MAP, is:
A'. if (Payload_Proto i= n LIST{UDP, TCP, ICMP}) {
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port (or equiva= lent field when ICMP) from Payload_Proto.header;=A0
=A0 =A0 =A0 r= ecalculate the checksum in Payload_Proto.header;
=A0 =A0} else {<= /div>
=A0 =A0 =A0 discard;
=A0 =A0}


both A and A' has= no risk as B has.

See a= bove why B has no operational risk.

Thanks,
RD


=A0
=A0



>>>> For an ISP to extend this advantage to its stateful NAT64,= it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 a= ddress (with a V
>>>> octet instead of a "u" octet), use the 4rd heade= r mapping instead of RFC6145
>>>> translation.

que= stions: 1. NAT64+ here refers to stateful case only, right?

2. = for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision bet= ween 4rd-U pseudo-encapsulation (let me use this term because =A0i argue it= does not conform to the behavior of encapsulation) and NAT64 translation? = (as we have neither V nor U in the IPv4 addresses).

a) Note that there is no claim= that 4rd-u would be an encapsulation solution (it isn't!). What is cla= imed is that it is a transparent-tunnel solution (same IPv4 packet received= by destinations as sent by sources, except for TTL which progress, and for= ECNs that may be changed if congestion is met between source and destinati= on).=A0

yes. TTL is progressing = as if it were in translation. ECN is another topic: it changes even in the = encapsulation.=A0
=A0

b) In dra= ft -04, R-7 (8) says:
"CEs that are assigned unspecified IPv= 4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd=A0IPv4 a= ddresses as follows (Figure 6): take the Rule IPv6=A0prefix of the NAT64+ m= apping rue; append the IPv4 address;=A0append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              "
what do you mean with the unspecifi= ed IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-r= ule block? =A0

reading your example in 5.1, i understand your point: t= he above picture describes the mapping for the source address if the packet= is sent to the IPv6 world through BR but without the inverse-header-mappin= g. in this case the U-octet is applied and the CE-delegated prefix plays al= so the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE= . right? if i'm right, it is clear.=A0

but i haven't seen the necessity of defining the V-= octet here. with the V, BR seeing the V does the header mapping while seein= g the U does nothing but only the regular routing. without the V, BR seeing= the CE-delegated /64 does the header mapping while seeing another prefix (= no matter how long the length is) does nothing but only the regular routing= .=A0

the V-attached stuff in fact makes another, more-specif= ic prefix under the delegated prefix of a CE.=A0
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 transpare= ncy of NAT64 nodes by using transparent tunneling, instead of double transl= ation, when reached by 4rd CEs (making them NAT64+ nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a=
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 n= eeds to be upgraded to replace RFC5145 translation by header mapping when I= Pv6 addresses it deals with are 4rd addresses (have the V octet).
confused. how = does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgra= ded at all.=A0


>
>> This new capability, introduced in -04, is derived from the 464XLA= T proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only net= works can communicate via NAT64s, but IPv4 transparency has limitations whi= ch can be eliminated by upgrading NAT64s to NAT64+ status (a backward compa= tible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?
To take advantage, for customers that are 4rd capable, of better IPv4= transparency than with double translation, the NAT64 MUST be upgraded.
=

Remi didn't answer this question of Washam. 4rd-U keeps = only stateful NAT64 as it is at CE, to my understanding.=A0
=A0

may i add that it (4rd-U) = provides better IPv4 transparency than double translation but less simplici= ty in the term of layering architecture than encapsulation? (here i avoid s= ticking things on my understanding to "transparency"). personally= i don't think transparency is the most important reason that generally= operators prefer encapsulation rather than translation. simplicity and cle= ar concept in architecture is the reason. no matter how much we keep IPv4 i= nformation unchanged across the IPv6 domain, as long as the IPv4 header is = destroyed, it is a solution of "translation" rather than of "= ;encapsulation".=A0

Different view here.
a) Ole had a nice slide in the interim meeting about how double translatio= n tends to break transparency. I use "reversible header mapping" = which I find intuitive, or just "header mapping", but "rever= sible header translation" could be OK.=A0
=A0A key difference, is that payloads are transparently tunneled in 4r= d while they are processed, with dependence of upper layer protocols in dou= ble translation. This is AFAIK an important difference. (To take an example= , RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tun= neled with 4rd)

where is it stated in RF= C6145 that it requires to DISCARD UDP-lite packets?=A0
=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">

b) As sai= d in Sec 1 of=A0draft -04:
=A0"=A0While IPv6 headers are too= long to be mapped=A0into IPv4 headers, so that 6rd requires encapsulation = of full IPv6=A0packets in IPv4 packets, IPv4 headers can be reversibly mapp= ed into=A0IPv6 headers so that 4rd tunnel packets can be designed to be val= id=A0IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes= =A0that perform deep-packet-inspection."
=A0I see no real complexity in noting that IPv4 headers are small enou= gh to be reversibly mapped in IPv6 headers.

our terminologies are biased. i emphasize the simp= licity is in the term of architecture. encapsulation is a widely used conce= pt in the networking, making one protocol as an underlay of another. we may= have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP fra= mework plus but re-ordered and re-organized, into, e.g., a super L2-U. it i= s surely a reversible header mapping but we can't say that of either en= capsulation or the (narrow-sense) tunneling. this is my point. from the ope= rator's view, once it is not the simple layered encapsulation, i cannot= see it as a substitute for the encapsulation, but see it as a substitute o= f other translations, if i see this is a more gentle translation than other= s and this gentleness costs little.=A0
=A0
=A0Of course this still requires careful technical verification, but once d= one, it's done once and for all.=A0

i don't incline to use the term "tunneling" since tunnel c= ould have a variety of forms, among which encapsulation is one but not the = only one.=A0

Exactly: 4rd uses header-mappi= ng tunnels, and MAP-E uses encapsulation tunnels.

well, in general sense "tunnel" me= ans a source route essentially (RFC1241 made a very good summary about vari= ety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in ge= neral sense of the term "source route"). but we never call it lik= e that, because, when most people are talking about "tunnel" toda= y, we refers to the narrow sense "tunnel", which means the encaps= ulation. it is fine that 4rd-U call itself as a tunnel solution but it shou= ld be pointed out that this is a tunnel in the general sense.=A0

therefore i emphasize that, maybe too academic, the cou= nterpart of translation is encapsulation but not the "tunneling".= in the architecture, we have either the building block of making an underl= ay protocol as a virtual link or the building block of making another proto= col as a participant in the path of end-to-end delivery. although you argue= d this is *ONLY* the understanding of some diffserv guys, i don't think= this understanding is not generic.=A0

for the simplicity in operation, we often think in such= a way: if we would like to hide the underlay and make a protocol as an und= erlay or we would like to expose the things out. both have their use cases.= if 4rd-U is said it fills some important gaps between the two, it would be= great. if 4rd-U is said it replaces the both, i doubt it can. once we want= to make a stuff having advantage of this and that, we often make out a stu= ff also having disadvantage of both. for me, i prefer if 4rd-U is moderatel= y defined with specific use-case and fully description on its pros/cons, fe= atures/limitations, approaches/tradeoffs.=A0

cheers,
maoke
=A0


Cheers,
RD





cheers,
maoke
=A0
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, o= r dual-stack hosts supporting BIH of RFC6535): they can continue to use the= NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add fragmenta= tion header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires





--00248c6a86e203213504bb0237dd-- From fibrib@gmail.com Sun Mar 11 20:09:23 2012 Return-Path: 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 69CEA21F851D for ; Sun, 11 Mar 2012 20:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] 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 RxdPhk9FqWCp for ; Sun, 11 Mar 2012 20:09:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99C21F84DF for ; Sun, 11 Mar 2012 20:09:20 -0700 (PDT) Received: by yenm5 with SMTP id m5so2386624yen.31 for ; Sun, 11 Mar 2012 20:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wg+oau3xB9u0NM+l0ibGkZWbXPcCDmZmAUBJ8+58Kp8=; b=SmxhS/mnXWfRBhBba6jofDlfgC71DY9J6dJGtK4Vy1EOA+SCEMEQM9thXohKZ/DaXL s9PyOSlQpZ2A7xm4ZgyO3xBa6QDYdobPgsE7KDWanj7AlsVICtQsYU3wxFaZn6Dcc2/c ZLLNhPdwJWh847cqMh0JHU6Ua8KbHGNOtUjxAV38FqbXhviY8lQLkAvdr1gXxNsftzjm VGO64wCcwMWgxZF4ZX9AXeGYXFcgRYhomRBe5PAO4yi/522AwisijnfrxVv9oOc22UeO bLqJvQH+JXVnrMvPtwIuh28cuT4+nN1PZ3xzGFx/0ejqcGaVyJeBWHGkLG3FUsQIDy/7 qKaQ== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr6959209qab.13.1331521760027; Sun, 11 Mar 2012 20:09:20 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sun, 11 Mar 2012 20:09:19 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> Date: Mon, 12 Mar 2012 03:09:19 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef784650804bb0311ed Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 03:09:23 -0000 --20cf30363ef784650804bb0311ed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/12 Maoke > > 2012/3/9 R=E9mi Despr=E9s > >> Maoke, >> Thanks for the detailed question. >> Clarification below. >> >> >> 2012-03-09 12:04, Maoke : >> >> 2012/3/9 R=E9mi Despr=E9s >> >>> Thanks Maoke for the opportunity to clarify some of the points below. >>> >>> >>> 2012-03-09 03:14, Maoke: >>> >>> hi Remi, >>> >>> sorry but i follow this late. something not clear to me, according to >>> our earlier discussions. >>> >>> 2012/3/8 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit : >>>> >>>> > Hi Remi, >>>> > >>>> >>>>> Secondly, -04 added NAT64+ parts. >>>> >>>>> If I understood correctly, there are no additional requirements >>>> for NAT64 >>>> >>>>> boxes. >>>> >>>> >>>> >>>> Well, NAT64 boxes remain what they are. >>>> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 >>>> although it >>>> >>>> has a dual stack. >>>> >>>> >>>> >>>> But the advantage of 4rd tunneling over RFC6145 double translatio= n >>>> is better >>>> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future >>>> protocols that may >>>> >>>> use the TCP checksum algorithms) >>>> >>> >>> to clarify my understanding: >>> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the >>> DF=3D1/MF=3D1 cases >>> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message >>> directly as IPv6 payload is a wise idea. lack of address consistency >>> ensurance mechanism (i.e. no header checksum in IPv6 header no >>> pseudo-header checksum in ICMPv4 message) >>> >>> >>> The 4rd ICMPv4 error message has as only purpose to be delivered to a >>> 4rd-aware node. There, it will be treated as an ICMPv4 error. >>> It is assumed that no DPI in some middle box will need to interpret >>> ICMPv4 error messages. >>> >>> 3. for the "future protocols", i remember our earlier discussion >>> concluded that CNP can free the code change with ALREADY KNOWN >>> tcp-checksumed protocols. am i wrong here? >>> >>> >>> I think you are. As the 4rd-u-04 says (sec 4.4): >>> "NOTE: This guarantees that, for all protocols that use the same >>> checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and t= his >>> independently from where the checksum field is placed for each protocol= . >>> Today, such protocols are UDP [RFC0768], TCP [RFC0793], >>> UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, = BRs >>> will support them without needing an update." >>> >> >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> exactly here it is the point of disagreement. here the "update" refers t= o >> implementation, right? then what is the BR's logic? >> >> >> A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) { >> calculate IPv6 address for dst, taking the port from >> L4_proto.header; >> /* do nothing with checksum, CNP applied for the LIST */ >> } else { >> discard; >> } >> >> >> No. R-7 (3) isn't ambiguous about this. >> >> >> B. if (1) { >> calculate MAP IPv6 address for dst, supposing dst port is always >> there; >> /* do nothing with checksum suppose CNP applied to all protocols *= / >> } >> >> >> Yes, as specified in R-7 (3). >> >> As a matter of fact, it doesn't "suppose dst port is always there". >> It just takes bits that are the right ones if dst port (or ICMPv4 ID) is >> present, unless a source has, by mistake, sent a port-less packet to a >> shared IPv4 address. >> What happens in this mistake case is detailed below. >> >> >> if you refer to logic B, the "BR will support them without needing an >> update" is true. >> >> >> Right. >> >> however, the risk is should new ones specified but not having the >> tcp-like layout or the tcp-checksum may fail to become a valid IPv6 pack= et >> and (because of the layout difference) it is possible that the destinati= on >> IPv6 address is wrong. >> >> >> If a source sends to a shared IPv4 address with a port-less protocol, it >> will receive a "destination unreachable" ICMPv4 packet. >> Its code will be either "network unreachable", because no CE had the >> derived IPv6 address (sec. 4.7), or "protocol unreachable", because the >> reached CE NAT44 cannot process this port-less protocol. >> The usual error-signalling mechanism works as it has to. >> >> > > ok. now i got the whole picture. sorry for the late understanding. > but does this means 4rd-U is an extension of NAT44 or at least depends > upon NAT44? > btw, BR also depends upon NAT44 to deal with the unknown protocol, right? if so, may i say your statement "BR will support them without needing an update" is a proposition actually not existing? because NAT44 won't support them without any update. right? - maoke > > RFC6145 has no such dependence at all. > > - maoke > > >> >> >> if you refer to logic A, the BR must be updated whenever any new protoco= l >> is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, >> when applied with MAP, is: >> A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) { >> calculate IPv6 address for dst, taking the port (or equivalent >> field when ICMP) from Payload_Proto.header; >> recalculate the checksum in Payload_Proto.header; >> } else { >> discard; >> } >> >> >> both A and A' has no risk as B has. >> >> >> See above why B has no operational risk. >> >> Thanks, >> RD >> >> >> >> >> >> >> >>> >>> >>>> For an ISP to extend this advantage to its stateful NAT64, it nee= d >>>> to be 4rd >>>> >>>> aware (become a NAT64+). >>>> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address >>>> (with a V >>>> >>>> octet instead of a "u" octet), use the 4rd header mapping instead >>>> of RFC6145 >>>> >>>> translation. >>>> >>> >>> questions: 1. NAT64+ here refers to stateful case only, right? >>> >>> >>> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make >>> decision between 4rd-U pseudo-encapsulation (let me use this term becau= se >>> i argue it does not conform to the behavior of encapsulation) and NAT6= 4 >>> translation? (as we have neither V nor U in the IPv4 addresses). >>> >>> >>> a) Note that there is no claim that 4rd-u would be an encapsulation >>> solution (it isn't!). What is claimed is that it is a transparent-tunne= l >>> solution (same IPv4 packet received by destinations as sent by sources, >>> except for TTL which progress, and for ECNs that may be changed if >>> congestion is met between source and destination). >>> >> >> yes. TTL is progressing as if it were in translation. ECN is another >> topic: it changes even in the encapsulation. >> >> >>> >>> b) In draft -04, R-7 (8) says: >>> "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST >>> derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6)= : >>> take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 >>> address; append the CNP. >>> >>> <----------- Rule IPv6 prefix --------->: >>> +-------------------------------+---+---+-------------+------+ >>> | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | >>> +-------------------------------+---+---+-------------+------+ >>> : 64 : 8 : 8 : 32 : 16 : >>> >>> Figure 6 " >>> >>> what do you mean with the unspecified IPv4 address*es*? isn't it only >> the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? >> >> reading your example in 5.1, i understand your point: the above picture >> describes the mapping for the source address if the packet is sent to th= e >> IPv6 world through BR but without the inverse-header-mapping. in this ca= se >> the U-octet is applied and the CE-delegated prefix plays also the role o= f >> NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if = i'm >> right, it is clear. >> >> but i haven't seen the necessity of defining the V-octet here. with the >> V, BR seeing the V does the header mapping while seeing the U does nothi= ng >> but only the regular routing. without the V, BR seeing the CE-delegated = /64 >> does the header mapping while seeing another prefix (no matter how long = the >> length is) does nothing but only the regular routing. >> >> the V-attached stuff in fact makes another, more-specific prefix under >> the delegated prefix of a CE. >> >>> >>> >>>> >>> I perfer to leave NAT64 out of scope. >>>> >> >>>> >> NAT64 as is remains out of scope. >>>> >> What is in scope is only the possibility to improve IPv4 >>>> transparency of NAT64 nodes by using transparent tunneling, instead of >>>> double translation, when reached by 4rd CEs (making them NAT64+ nodes)= . >>>> > >>>> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify= a >>>> > new term NAT64+ invented? >>>> >>>> >>>> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 >>>> needs to be upgraded to replace RFC5145 translation by header mapping = when >>>> IPv6 addresses it deals with are 4rd addresses (have the V octet). >>>> >>> confused. how does NAT64+ happens at BR? without the V octet, NAT64 >> needs not to be upgraded at all. >> >>> >>>> >>>> > >>>> >> This new capability, introduced in -04, is derived from the 464XLAT >>>> proposal. >>>> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only >>>> networks can communicate via NAT64s, but IPv4 transparency has limitat= ions >>>> which can be eliminated by upgrading NAT64s to NAT64+ status (a backwa= rd >>>> compatible evolution). >>>> >> >>>> > >>>> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >>>> >>>> To take advantage, for customers that are 4rd capable, of better IPv4 >>>> transparency than with double translation, the NAT64 MUST be upgraded. >>>> >>> >> Remi didn't answer this question of Washam. 4rd-U keeps only stateful >> NAT64 as it is at CE, to my understanding. >> >> >>> >>> may i add that it (4rd-U) provides better IPv4 transparency than double >>> translation but less simplicity in the term of layering architecture th= an >>> encapsulation? (here i avoid sticking things on my understanding to >>> "transparency"). personally i don't think transparency is the most >>> important reason that generally operators prefer encapsulation rather t= han >>> translation. simplicity and clear concept in architecture is the reason= . no >>> matter how much we keep IPv4 information unchanged across the IPv6 doma= in, >>> as long as the IPv4 header is destroyed, it is a solution of "translati= on" >>> rather than of "encapsulation". >>> >>> >>> Different view here. >>> a) Ole had a nice slide in the interim meeting about how double >>> translation tends to break transparency. I use "reversible header mappi= ng" >>> which I find intuitive, or just "header mapping", but "reversible heade= r >>> translation" could be OK. >>> A key difference, is that payloads are transparently tunneled in 4rd >>> while they are processed, with dependence of upper layer protocols in >>> double translation. This is AFAIK an important difference. (To take an >>> example, RFC6145 requires to discard UDP-lite packets (RFC3828) while t= hey >>> are tunneled with 4rd) >>> >> >> where is it stated in RFC6145 that it requires to DISCARD UDP-lite >> packets? >> >> >>> >>> b) As said in Sec 1 of draft -04: >>> " While IPv6 headers are too long to be mapped into IPv4 headers, so >>> that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, I= Pv4 >>> headers can be reversibly mapped into IPv6 headers so that 4rd tunnel >>> packets can be designed to be valid IPv6 packets, thus ensuring >>> compatibility with IPv6-only middle boxes that perform >>> deep-packet-inspection." >>> I see no real complexity in noting that IPv4 headers are small enough >>> to be reversibly mapped in IPv6 headers. >>> >> >> our terminologies are biased. i emphasize the simplicity is in the term >> of architecture. encapsulation is a widely used concept in the networkin= g, >> making one protocol as an underlay of another. we may have a packet with >> all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but >> re-ordered and re-organized, into, e.g., a super L2-U. it is surely a >> reversible header mapping but we can't say that of either encapsulation = or >> the (narrow-sense) tunneling. this is my point. from the operator's view= , >> once it is not the simple layered encapsulation, i cannot see it as a >> substitute for the encapsulation, but see it as a substitute of other >> translations, if i see this is a more gentle translation than others and >> this gentleness costs little. >> >> >>> Of course this still requires careful technical verification, but once >>> done, it's done once and for all. >>> >>> i don't incline to use the term "tunneling" since tunnel could have a >>> variety of forms, among which encapsulation is one but not the only one= . >>> >>> >>> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation >>> tunnels. >>> >> >> well, in general sense "tunnel" means a source route essentially (RFC124= 1 >> made a very good summary about variety of tunnels). to such extent, RFC6= 145 >> makes *translation tunnels* (in general sense of the term "source route"= ). >> but we never call it like that, because, when most people are talking ab= out >> "tunnel" today, we refers to the narrow sense "tunnel", which means the >> encapsulation. it is fine that 4rd-U call itself as a tunnel solution bu= t >> it should be pointed out that this is a tunnel in the general sense. >> >> therefore i emphasize that, maybe too academic, the counterpart of >> translation is encapsulation but not the "tunneling". in the architectur= e, >> we have either the building block of making an underlay protocol as a >> virtual link or the building block of making another protocol as a >> participant in the path of end-to-end delivery. although you argued this= is >> *ONLY* the understanding of some diffserv guys, i don't think this >> understanding is not generic. >> >> for the simplicity in operation, we often think in such a way: if we >> would like to hide the underlay and make a protocol as an underlay or we >> would like to expose the things out. both have their use cases. if 4rd-U= is >> said it fills some important gaps between the two, it would be great. if >> 4rd-U is said it replaces the both, i doubt it can. once we want to make= a >> stuff having advantage of this and that, we often make out a stuff also >> having disadvantage of both. for me, i prefer if 4rd-U is moderately >> defined with specific use-case and fully description on its pros/cons, >> features/limitations, approaches/tradeoffs. >> >> cheers, >> maoke >> >> >>> >>> >>> Cheers, >>> RD >>> >>> >>> >>> >>> >>> cheers, >>> maoke >>> >>> >>>> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only >>>> hosts, or dual-stack hosts supporting BIH of RFC6535): they can contin= ue to >>>> use the NAT64+ as an ordinary NAT64. >>>> >>>> Regards, >>>> RD >>>> >>>> > >>>> > Thanks, >>>> > washam >>>> >>> Such transparency could be achieved by whther to add fragmentation >>>> header. >>>> >>> Anyway, let's hear some comments from the group >>>> >> >>>> >> OK >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> >>> >> >> > --20cf30363ef784650804bb0311ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/12 Maoke <fibrib@gmail.com>

2012/3/9 R=E9mi Despr= =E9s <despres.remi@laposte.net>
Maoke,
Thanks for the detailed ques= tion.
Clarification below.


2012-03-09 12:04, Maoke =A0:
2012/3/9 R=E9mi Despr=E9s <= despres.remi@= laposte.net>
Thanks Maoke for the opportunity to cla= rify some of the points below.



hi Remi,

sorry but i follow this late. something not clear to me, according to ou= r earlier discussions.

2012/3/8 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-08 =E0 03:47, Washam Fan a =E9crit :

> Hi Remi,
>
>>>>> Secondly, -04 added NAT64+ parts.
>>>>> If I understood correctly, there are no additional req= uirements for NAT64
>>>>> boxes.
>>>>
>>>> Well, NAT64 boxes remain what they are.
>>>> Any host can use BIH to look like an IPv6-only host in the= NAT64 although it
>>>> has a dual stack.
>>>>
>>>> But the advantage of 4rd tunneling over RFC6145 double tra= nslation is better
>>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future = protocols that may
>>>> use the TCP checksum algorithms)

to clarify my understanding:
1. DF transparency = is kept totally in 4rd-U but RFC6145 sacrificies the DF=3D1/MF=3D1 cases
2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 messag= e directly as IPv6 payload is a wise idea. lack of address consistency ensu= rance mechanism (i.e. no header checksum in IPv6 header no pseudo-header ch= ecksum in ICMPv4 message)

The 4rd ICMPv4 error message h= as as only purpose to be delivered to a 4rd-aware node. There, it will be t= reated as an ICMPv4 error.
It is assumed that no DPI in some midd= le box will need to interpret ICMPv4 error messages.=A0

3. for the "future protocols", i remember our earlier discus= sion concluded that CNP can free the code change with ALREADY KNOWN tcp-che= cksumed protocols. am i wrong here?=A0

I think you are. As the 4rd-u-04 says (sec 4.4):
"NOTE: This guarantees that, for all protocols that use the=A0sa= me checksum algorithm as TCP, Tunnel packets are valid=A0IPv6 packets, and = this independently from where the=A0checksum field is placed for each proto= col. =A0Today, such=A0protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite= =A0[RFC3828], and DCCP [RFC5595]. =A0Should new ones be=A0specified, BRs wi= ll support them without needing an=A0update."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^
exactly here it is the point of disagreement. here the "update&qu= ot; refers to implementation, right? then what is the BR's logic?=A0

A.= if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port from L4_pr= oto.header;=A0
=A0 =A0 =A0 /* do nothing with checksum, CNP appli= ed for the LIST */
=A0 =A0} else {
=A0 =A0 =A0 discard;=
=A0 =A0}

No.=A0R-7 (3)=A0isn'= t ambiguous about this.


B. if (1) {
=A0 =A0 =A0 calculate MAP IPv6 address for dst, = supposing dst port is always there;
=A0 =A0 =A0 /* do nothing wit= h checksum suppose CNP applied to all protocols */
=A0 =A0}
=

Yes, as specified in R-7 (3).

A= s a matter of fact, it doesn't "suppose dst port is always there&q= uot;.=A0
It just takes bits that are the right ones if dst port (= or ICMPv4 ID) is present, unless a source has, by mistake, sent a port-less= packet to a shared IPv4 address.
What happens in this mistake case is detailed below. =A0


if you refer to logic B, the "BR will support them without needin= g an update" is true.

Right.

however, the risk is should new ones specified but not having the tcp-= like layout or the tcp-checksum may fail to become a valid IPv6 packet and = (because of the layout difference) it is possible that the destination IPv6= address is wrong.=A0

If a source sends to a sh= ared IPv4 address with a port-less protocol, it will receive a =A0"des= tination unreachable"=A0ICMPv4 packet.
Its code will be eith= er "network unreachable", because no CE had the derived IPv6 addr= ess (sec. 4.7), or "protocol unreachable", because the reached CE= NAT44 cannot process this port-less protocol.
The usual error-signalling mechanism works as it has to.
=A0=
=A0
o= k. now i got the whole picture. sorry for the late understanding.
but does this means 4rd-U is an extension of NAT44 or at least depends upon= NAT44?

btw, BR also depends up= on NAT44 to deal with the unknown protocol, right? if so, may i say your st= atement "BR will support them without needing an update" is a pro= position actually not existing? because NAT44 won't support them withou= t any update. right?

- maoke=A0
=A0
=A0
RFC6145 has no such dependence at all.
=A0
- maoke
=
=A0
=A0

<= /div>
if you refer to logic A, the BR must be updated whenever any new proto= col is added to the LIST. this is the same as RFC6145. btw, RFC6145's l= ogic, when applied with MAP, is:
A'. if (Payload_Proto i= n LIST{UDP, TCP, ICMP}) {
=A0 =A0 =A0 calculate IPv6 address for dst, taking the port (or equiva= lent field when ICMP) from Payload_Proto.header;=A0
=A0 =A0 =A0 r= ecalculate the checksum in Payload_Proto.header;
=A0 =A0} else {<= /div>
=A0 =A0 =A0 discard;
=A0 =A0}


both A and A' has= no risk as B has.

See a= bove why B has no operational risk.

Thanks,
RD


=A0
=A0


>>>> For an ISP to extend this advantage to its stateful NAT64,= it need to be 4rd
>>>> aware (become a NAT64+).
>>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 a= ddress (with a V
>>>> octet instead of a "u" octet), use the 4rd heade= r mapping instead of RFC6145
>>>> translation.

que= stions: 1. NAT64+ here refers to stateful case only, right?

2. = for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision bet= ween 4rd-U pseudo-encapsulation (let me use this term because =A0i argue it= does not conform to the behavior of encapsulation) and NAT64 translation? = (as we have neither V nor U in the IPv4 addresses).

a) Note that there is no claim= that 4rd-u would be an encapsulation solution (it isn't!). What is cla= imed is that it is a transparent-tunnel solution (same IPv4 packet received= by destinations as sent by sources, except for TTL which progress, and for= ECNs that may be changed if congestion is met between source and destinati= on).=A0

yes. TTL is progressing = as if it were in translation. ECN is another topic: it changes even in the = encapsulation.=A0
=A0

b) In dra= ft -04, R-7 (8) says:
"CEs that are assigned unspecified IPv= 4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd=A0IPv4 a= ddresses as follows (Figure 6): take the Rule IPv6=A0prefix of the NAT64+ m= apping rue; append the IPv4 address;=A0append the CNP.
<----------- Rule IPv6 prefix --------->:
+-------------------------------+---+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
+-------------------------------+---+---+-------------+------+
:               64              : 8 : 8 :      32     :  16  :

                                       Figure 6              "
what do you mean with the unspecifi= ed IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-r= ule block? =A0

reading your example in 5.1, i understand your point: t= he above picture describes the mapping for the source address if the packet= is sent to the IPv6 world through BR but without the inverse-header-mappin= g. in this case the U-octet is applied and the CE-delegated prefix plays al= so the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE= . right? if i'm right, it is clear.=A0

but i haven't seen the necessity of defining the V-= octet here. with the V, BR seeing the V does the header mapping while seein= g the U does nothing but only the regular routing. without the V, BR seeing= the CE-delegated /64 does the header mapping while seeing another prefix (= no matter how long the length is) does nothing but only the regular routing= .=A0

the V-attached stuff in fact makes another, more-specif= ic prefix under the delegated prefix of a CE.=A0
>>>
>>> I perfer to leave NAT64 out of scope.
>>
>> NAT64 as is remains out of scope.
>> What is in scope is only the possibility to improve IPv4 transpare= ncy of NAT64 nodes by using transparent tunneling, instead of double transl= ation, when reached by 4rd CEs (making them NAT64+ nodes).
>
> Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a=
> new term NAT64+ invented?


NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 n= eeds to be upgraded to replace RFC5145 translation by header mapping when I= Pv6 addresses it deals with are 4rd addresses (have the V octet).
confused. how = does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgra= ded at all.=A0


>
>> This new capability, introduced in -04, is derived from the 464XLA= T proposal.
>> With 464XLAT, IPv4 applications in hosts attached to IPv6-only net= works can communicate via NAT64s, but IPv4 transparency has limitations whi= ch can be eliminated by upgrading NAT64s to NAT64+ status (a backward compa= tible evolution).
>>
>
> In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?
To take advantage, for customers that are 4rd capable, of better IPv4= transparency than with double translation, the NAT64 MUST be upgraded.
=

Remi didn't answer this question of Washam. 4rd-U keeps = only stateful NAT64 as it is at CE, to my understanding.=A0
=A0

may i add that it (4rd-U) = provides better IPv4 transparency than double translation but less simplici= ty in the term of layering architecture than encapsulation? (here i avoid s= ticking things on my understanding to "transparency"). personally= i don't think transparency is the most important reason that generally= operators prefer encapsulation rather than translation. simplicity and cle= ar concept in architecture is the reason. no matter how much we keep IPv4 i= nformation unchanged across the IPv6 domain, as long as the IPv4 header is = destroyed, it is a solution of "translation" rather than of "= ;encapsulation".=A0

Different view here.
a) Ole had a nice slide in the interim meeting about how double translatio= n tends to break transparency. I use "reversible header mapping" = which I find intuitive, or just "header mapping", but "rever= sible header translation" could be OK.=A0
=A0A key difference, is that payloads are transparently tunneled in 4r= d while they are processed, with dependence of upper layer protocols in dou= ble translation. This is AFAIK an important difference. (To take an example= , RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tun= neled with 4rd)

where is it stated in RF= C6145 that it requires to DISCARD UDP-lite packets?=A0
=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">

b) As sai= d in Sec 1 of=A0draft -04:
=A0"=A0While IPv6 headers are too= long to be mapped=A0into IPv4 headers, so that 6rd requires encapsulation = of full IPv6=A0packets in IPv4 packets, IPv4 headers can be reversibly mapp= ed into=A0IPv6 headers so that 4rd tunnel packets can be designed to be val= id=A0IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes= =A0that perform deep-packet-inspection."
=A0I see no real complexity in noting that IPv4 headers are small enou= gh to be reversibly mapped in IPv6 headers.

our terminologies are biased. i emphasize the simp= licity is in the term of architecture. encapsulation is a widely used conce= pt in the networking, making one protocol as an underlay of another. we may= have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP fra= mework plus but re-ordered and re-organized, into, e.g., a super L2-U. it i= s surely a reversible header mapping but we can't say that of either en= capsulation or the (narrow-sense) tunneling. this is my point. from the ope= rator's view, once it is not the simple layered encapsulation, i cannot= see it as a substitute for the encapsulation, but see it as a substitute o= f other translations, if i see this is a more gentle translation than other= s and this gentleness costs little.=A0
=A0
=A0Of course this still requires careful technical verification, but once d= one, it's done once and for all.=A0

i don't incline to use the term "tunneling" since tunnel c= ould have a variety of forms, among which encapsulation is one but not the = only one.=A0

Exactly: 4rd uses header-mappi= ng tunnels, and MAP-E uses encapsulation tunnels.

well, in general sense "tunnel" me= ans a source route essentially (RFC1241 made a very good summary about vari= ety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in ge= neral sense of the term "source route"). but we never call it lik= e that, because, when most people are talking about "tunnel" toda= y, we refers to the narrow sense "tunnel", which means the encaps= ulation. it is fine that 4rd-U call itself as a tunnel solution but it shou= ld be pointed out that this is a tunnel in the general sense.=A0

therefore i emphasize that, maybe too academic, the cou= nterpart of translation is encapsulation but not the "tunneling".= in the architecture, we have either the building block of making an underl= ay protocol as a virtual link or the building block of making another proto= col as a participant in the path of end-to-end delivery. although you argue= d this is *ONLY* the understanding of some diffserv guys, i don't think= this understanding is not generic.=A0

for the simplicity in operation, we often think in such= a way: if we would like to hide the underlay and make a protocol as an und= erlay or we would like to expose the things out. both have their use cases.= if 4rd-U is said it fills some important gaps between the two, it would be= great. if 4rd-U is said it replaces the both, i doubt it can. once we want= to make a stuff having advantage of this and that, we often make out a stu= ff also having disadvantage of both. for me, i prefer if 4rd-U is moderatel= y defined with specific use-case and fully description on its pros/cons, fe= atures/limitations, approaches/tradeoffs.=A0

cheers,
maoke
=A0


Cheers,
RD





cheers,
maoke
=A0
Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, o= r dual-stack hosts supporting BIH of RFC6535): they can continue to use the= NAT64+ as an ordinary NAT64.

Regards,
RD

>
> Thanks,
> washam
>>> Such transparency could be achieved by whther to add fragmenta= tion header.
>>> Anyway, let's hear some comments from the group
>>
>> OK

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires






--20cf30363ef784650804bb0311ed-- From despres.remi@laposte.net Mon Mar 12 01:19:24 2012 Return-Path: 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 0A71421F864D for ; Mon, 12 Mar 2012 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 7z4hKQzu1yCe for ; Mon, 12 Mar 2012 01:19:22 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id E239121F8648 for ; Mon, 12 Mar 2012 01:19:19 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id kYKH1i00837Y3f403YKHpU; Mon, 12 Mar 2012 09:19:18 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 12 Mar 2012 09:19:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> References: To: Washam Fan X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:19:24 -0000 Hi, Washam, Thanks for your detailed questions and comments. Answers and further comments in line.=20 Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit : > Hi, >=20 > Eventually I get a chance to review this version and have some major > comments and questions as below. >=20 > 1. Relationship with MAP, MAP-T, MAP-E. > I thought, MAP was expected to be a generic algorithm for stateless > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > MAP would apply to MAP-T, MAP-E as well as 4rd-u. The point is that 4rd-u unifies not only the address format for -T and = -E, but also the header format so that a single standard becomes = sufficient. The 4rd-U technique for this was presented in Taipei, but it didn't = arise interest in the MAP team. Design of 4rd-u had then to become = autonomous.=20 > But draft 4rd-u-04 > doesn't mention MAP draft. 4rd-u is proposed as an alternative to the 2-standards approach of MAP. It therefore needs only needs a historical reference to MAP, which is = done in sec. 8.=20 > And I see the mapping rules stuff in the > draft overlapped with MAP. Confused. >=20 > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. > Would you mind expaund on what benefits 4rd-u can gain exclusively? > Ideally, there would be a seperate section or even a seperate draft > for such comparison. As announced, an update of = draft-despres-softwire-stateless-analysis-tool will contain a comparison = (now to be posted very soon). An earlier comparison table was available in http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to = use IPv6-only middle boxes for deep packet inspection and web caches; = also, like MAP-E, it ensures full IPv4 transparency. > 2. NAT64+ stuff. > My understanding, NAT64+ would translate 4rd tunnel packet as well as > native IPv6 packet to IPv4 packet and vice verse. Right? If the NAT64 is stateful per session, yes, it does translation at layer = 4. NAT64s that are stateless at this layer are however also possible. THis = is independent from 4rd. > I don't know > what the CE delegated prefix in NAT64+ looks like. - The delegated prefix is any prefix up to /64 that doesn't match any CE = prefix (R-6 of draft-04)) - The source of a CE to NAT64+ packet must have the V octet for NAT64+s = to be able to distinguish 4rd packets from other IPv6 packets (def of = NAT64+). - The format is then: +-----------------------+-------+---+-----------------+------+ | CE IPv6 prefix | 0 | V | 0 | CNP | +-----------------------+-------+---+-----------------+------+ : =3D< 64 : >=3D 0 : 8 : 40 : 16 : Yet, it should be clearer in the draft.=20 Thanks for this (good) question. > Can the native IPv6 > and 4rd shared the same delegated prefix? Yes. (This is the purpose of the V octet) > if Yes, how to distinguish > them? See above.=20 > the figure 6 seems to me it was talking about destination IPv6 > address derivation. Right. > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support > harpinning between 4rd tunnel packet and native IPv6 packet? The only evolution of NAT64 to make it a NAT64+ is its use of tunneling = instead of RFC6145 translation, for all IPv6 addresses that have the V = octet. (No other behavior needs to be modified.) > Personally, I'd like NAT64+ removed from the draft. It might deserve a > seperate draft. > This way, it would make the draft more understanding > for readers who are new to 4rd-u. The specification has to explain conditions in which a CE can tunnel = IPv4 packets although it has no assigned public IPv4 address, even = shared.=20 Explaining more what is NAT64+ is IMHO better than explaining less. > 3. Fragments. > The algorithm proposed in R-9, would have applied to generic NAT > generally. Why it is specific to 4rd BR? NATs may have to remember not only destination ports but also source = ports. A similar algorithm could however apply to NAT64s, but this is off 4rd = scope. > Anyway BR would keep fragment=20 They MAY, but AFAIK don't need to if they use R-9 algorithm. > state somehow and anycase BR facing IPv4 Internet would be impossible. In the CE to BR direction, destinations are full IPv4 addresses so that = each fragment can be individually forwarded.=20 Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that = no port-based check is needed to ensure that no CE can spoof fragments = from another CE. Regards, RD=20 >=20 > Thanks, > washam > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Mar 12 01:33:12 2012 Return-Path: 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 076D221F86DC for ; Mon, 12 Mar 2012 01:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.078, 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 fFP9B2pEoy-r for ; Mon, 12 Mar 2012 01:33:11 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id BFF6F21F8685 for ; Mon, 12 Mar 2012 01:33:10 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id kYZ61i00N37Y3f403YZ6Bc; Mon, 12 Mar 2012 09:33:09 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-93-1046668547 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 12 Mar 2012 09:33:06 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:33:12 -0000 --Apple-Mail-93-1046668547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-03-12 03:08, Maoke: > 2012/3/9 R=E9mi Despr=E9s ... > If a source sends to a shared IPv4 address with a port-less protocol, = it will receive a "destination unreachable" ICMPv4 packet. > Its code will be either "network unreachable", because no CE had the = derived IPv6 address (sec. 4.7), or "protocol unreachable", because the = reached CE NAT44 cannot process this port-less protocol. > The usual error-signalling mechanism works as it has to. > =20 > =20 > ok. now i got the whole picture. sorry for the late understanding. > but does this means 4rd-U is an extension of NAT44 or at least depends = upon NAT44? > =20 > RFC6145 has no such dependence at all. R-1 says: "A node whose CE is assigned a shared IPv4 address MUST include a NAT44 = [RFC1631]. This NAT44 MUST only use external ports that are in the CE = assigned port set." For other cases, the choice remains open. In CEs that are assigned IPv4 = prefixes, NAT44s are clearly possible but not required.=20 In a CE-node that is only a host, the NAT44 might be optional. Would it = be good or not to permit it isn't clear to me but, in R-1, a SHOULD = seems more appropriate than a MUST. Thanks for the point. RD --Apple-Mail-93-1046668547 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/9 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
...
If a source sends to = a shared IPv4 address with a port-less protocol, it will receive a =  "destination unreachable" ICMPv4 packet.
Its code = will be either "network unreachable", because no CE had the derived IPv6 = address (sec. 4.7), or "protocol unreachable", because the reached CE = NAT44 cannot process this port-less protocol.
The usual error-signalling mechanism works as it has = to.
 
 =
ok. now i got the whole picture. sorry for the late = understanding.
but does this means 4rd-U is an extension of = NAT44 or at least depends upon NAT44?
 
RFC6145 has no such dependence at all. =


R-1 = says:
"A node whose CE is assigned a shared IPv4 address MUST = include a NAT44 [RFC1631].  This NAT44 MUST only use external = ports that are in the CE assigned port set."
For other = cases, the choice remains open. In CEs that are assigned IPv4 prefixes, = NAT44s are clearly possible but not = required. 

In a CE-node that is only a host, the = NAT44 might be optional. Would it be good or not to permit it isn't = clear to me but, in R-1, a SHOULD seems more appropriate than a = MUST.
Thanks for the = point.

RD


= --Apple-Mail-93-1046668547-- From despres.remi@laposte.net Mon Mar 12 01:43:40 2012 Return-Path: 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 6404021F86B8 for ; Mon, 12 Mar 2012 01:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 wBkjikt5jF7G for ; Mon, 12 Mar 2012 01:43:40 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id A4CFE21F86A1 for ; Mon, 12 Mar 2012 01:43:39 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id kYjb1i00d37Y3f403YjbwU; Mon, 12 Mar 2012 09:43:37 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 12 Mar 2012 09:43:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:43:40 -0000 2012-03-12 04:09, Maoke: ... > btw, BR also depends upon NAT44 to deal with the unknown protocol, = right? if so, may i say your statement "BR will support them without = needing an update" is a proposition actually not existing? because NAT44 = won't support them without any update. right? Not right. Only CEs that need to support a new protocol are concerned: - If a shared address server supports a new protocol, it can be reached = via an unchanged BR. - If a client using a new protocol tries to reach a shared-address CE = that doesn't support this protocol, the client will be returned an error = message by the destination NAT44. RD =20 From washam.fan@gmail.com Mon Mar 12 02:10:38 2012 Return-Path: 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 5429B21F8720 for ; Mon, 12 Mar 2012 02:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 tKvsy2lYtn6P for ; Mon, 12 Mar 2012 02:10:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7097121F871C for ; Mon, 12 Mar 2012 02:10:37 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2653839wib.13 for ; Mon, 12 Mar 2012 02:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPZoLasvJ3c8o62vyHG42BHYgU9f2/0n0SeMh/nAPtU=; b=dQxNFHcWd154UgYER9HSm53FfuC+tVLPFlN9rAgLDoNvX9twBmV/dbD/VXuMZ9tx0x bt8E9tkr9fad5RNp8QC6enAmMf487QK1sRI9WFYDN4l9qwyykt+9o9JdVsyjrwJWFhuD 9AeT2Hy6e5laM7pSkUGQpiKuUrAMND8DEkrTZHUmQrP9feJDAgInMOL/6WxZYhQtAfXA b7web5dWGQuNbyj9JccKxa+56+jrFZRrQ76e7mTnHZ0GSaklJJwOBWUsZlMjxw0azg4q P702ZxQO9TXcC5lpjyEGbpFUckTP+dg9Mc/bYaZ+vEvCDXwttfQ2jaJ5VqfcFlh1gLV4 wtLg== MIME-Version: 1.0 Received: by 10.180.87.8 with SMTP id t8mr25004094wiz.15.1331543436486; Mon, 12 Mar 2012 02:10:36 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Mon, 12 Mar 2012 02:10:36 -0700 (PDT) In-Reply-To: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> References: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> Date: Mon, 12 Mar 2012 17:10:36 +0800 Message-ID: From: Washam Fan To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:10:38 -0000 Hi Remi, Thanks for the clarification. Only one response, >> 3. Fragments. >> The algorithm proposed in R-9, would have applied to generic NAT >> generally. Why it is specific to 4rd BR? > > NATs may have to remember not only destination ports but also source ports. Yes. I agree. > A similar algorithm could however apply to NAT64s, but this is off 4rd scope. So curious why a similar algorithm is NOT there for NATs. Thanks, washam From fibrib@gmail.com Mon Mar 12 02:21:35 2012 Return-Path: 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 604EA21F8738 for ; Mon, 12 Mar 2012 02:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 unh72hXRYD75 for ; Mon, 12 Mar 2012 02:21:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7344921F86DD for ; Mon, 12 Mar 2012 02:21:34 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2638737ggm.31 for ; Mon, 12 Mar 2012 02:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IXQB6d9D4XqdWyh6uLmuRx5qibg2kyaW0AsJaLfVP3U=; b=Fee5RpBn7eK1sTAEJ+IyMuSKZss8urJPidmgsgXQ0vG0q7EuuUzBWd5QjQ+G11Dtlf HdAxiPJmozRFH4qW8rpE9MgMiHdcDy3yYJKEQsdnOMpZw+Iibm+FdQkWTAODd5F8LZ8o FwlGDduCEzQdFrFs/0a9IqdVXzywvTI1Tw9rZ6fFQzwD2A8d1pF+fx/k9ugbkJ9aMH1W 8/EPoJQmZCRA/RFNMRDp6zFosXVTXPWgJekP1qugIHO8xRbOChiJUlxqZsg7ggeaTYKo xKowhh9uJXTLTldZ9l9tgt4L53qhIyfh5ME03EP9jvVQX+XRg1oy4rIQ3NIlnmioE5dV gOag== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr7756916qab.39.1331544093889; Mon, 12 Mar 2012 02:21:33 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 12 Mar 2012 02:21:33 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> Date: Mon, 12 Mar 2012 09:21:33 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47eb8155f04bb08446b Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:21:35 -0000 --20cf3074b47eb8155f04bb08446b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, 2012/3/12 R=E9mi Despr=E9s > > 2012-03-12 04:09, Maoke: > ... > > btw, BR also depends upon NAT44 to deal with the unknown protocol, > right? if so, may i say your statement "BR will support them without > needing an update" is a proposition actually not existing? because NAT44 > won't support them without any update. right? > > Not right. Only CEs that need to support a new protocol are concerned: > - If a shared address server supports a new protocol, it can be reached > via an unchanged BR. > - If a client using a new protocol tries to reach a shared-address CE tha= t > doesn't support this protocol, the client will be returned an error messa= ge > by the destination NAT44. > thanks a lot for the clarification! take an example: A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 Internet)--- B now A and B are supposed to use a new protocol other than known TCP/UDP/etc. my understanding: B --> A 1. BR just passes the new protocol without any concern. 2. CE's NAT44 module would say "this is not supported and a 'destination unreachable with port unknown' ICMP message is returned to B. A --> B 1. CE's NAT44 module directly say "destination unreachable with port unknown" ICMP message to A. is the above what you mean? when NAT44 module DOESN'T support the new protocol, things are working while we have no the problem about the "change" at all for the time being. then let's consider the case where the NAT44 module has been updated to support the new protocol. i understand BR passing all protocols can be survived if and only if the new protocol follows the TCP-layout for the destination port and the TCP-checksum, right? then you made a limitation (#1) to the NAT44 module of the CE: even if the NAT44 has supported a new protocol not following TCP layout/checksum, this support MUST be disabled in the 4rd-U environment; otherwise, BR may behave wrong when making the mapped IPv6 addresses while the NAT44 would still try to translate with the new protocol rather than dropping an error message because it has known it. right? further (#2), what if the packets don't pass through the NAT44 module at all (in the case of non-shared IPv4 addresses)? please clarify if the limitation of (#1) and (#2) are true or false. i believe with requiring L4 modification, either MAP or RFC6145 has no such two limitations: enforcing the checksum update at L4, their framework is safe for either TCP-layout/checksum or alien-layout/checksum, either shared or exclusive IPv4 addresses. i worry the CNP is making a situation of "cutting feet to fit the shoes". - maoke > > RD > > > --20cf3074b47eb8155f04bb08446b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi,

2012/3/12 R=E9mi Despr=E9s <despres.remi@l= aposte.net>

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the unk= nown protocol, right? if so, may i say your statement "BR will support= them without needing an update" is a proposition actually not existin= g? because NAT44 won't support them without any update. right?

Not right. Only CEs that need to support a new protocol are concerned= :
- If a shared address server supports a new protocol, it can be reached via= an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE that = doesn't support this protocol, the client will be returned an error mes= sage by the destination NAT44.

thanks a= lot for the clarification! take an example:=A0

=A0A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- B= R ---(IPv4 Internet)--- B

now A and B are supposed= to use a new protocol other than known TCP/UDP/etc. my understanding:
B --> A
1. BR just passes the new protocol without any co= ncern.
2. CE's NAT44 module would say "this is not suppo= rted and a 'destination unreachable with port unknown' ICMP message= is returned to B.
A --> B
1. CE's NAT44 module directly say "desti= nation unreachable with port unknown" ICMP message to A.=A0
=
is the above what you mean? when NAT44 module DOESN'T su= pport the new protocol, things are working while we have no the problem abo= ut the "change" at all for the time being.=A0

then let's consider the case where the NAT44 module= has been updated to support the new protocol. i understand BR passing all = protocols can be survived if and only if the new protocol follows the TCP-l= ayout for the destination port and the TCP-checksum, right?=A0

then you made a limitation (#1) to the NAT44 module of = the CE: even if the NAT44 has supported a new protocol not following TCP la= yout/checksum, this support MUST be disabled in the 4rd-U environment; othe= rwise, BR may behave wrong when making the mapped IPv6 addresses while the = NAT44 would still try to translate with the new protocol rather than droppi= ng an error message because it has known it. right?=A0

further (#2), what if the packets don't pass throug= h the NAT44 module at all (in the case of non-shared IPv4 addresses)?=A0

please clarify if the limitation of (#1) and (#2) ar= e true or false. i believe with requiring L4 modification, either MAP or RF= C6145 has no such two limitations: enforcing the checksum update at L4, the= ir framework is safe for either TCP-layout/checksum or alien-layout/checksu= m, either shared or exclusive IPv4 addresses. i worry the CNP is making a s= ituation of "cutting feet to fit the shoes".=A0

- maoke
=A0

RD



--20cf3074b47eb8155f04bb08446b-- From fibrib@gmail.com Mon Mar 12 03:51:31 2012 Return-Path: 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 2D40D21F86F3 for ; Mon, 12 Mar 2012 03:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 IpsRGans3sAS for ; Mon, 12 Mar 2012 03:51:29 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 244C521F86D8 for ; Mon, 12 Mar 2012 03:51:27 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2730390ggm.31 for ; Mon, 12 Mar 2012 03:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OoDSXntSk2hpkTkUi7I22xGe6ud+sGBrwgen/Dgv7lw=; b=R4iIfTmRuJVAY3WF0+T8lz/8HOtefuTxzX5u6Zq0yBtLrbFFDguUU/6eOB+TootfG6 jTvbFj6XnmU7uBE3a1R1b+cES+w9ZHpfQ003aTK/YS4BttpQ+B2R+obQqgZ8e3pnDs4e G021W8lhRRswm0sDdhvDgJZMPI5TXb8WEFIkwKCrtLwFHArGb7R//QULyZ6+LQp4RUJd BxZlliDhSExuJXtE4cNMFf4EObDapQNrjxNumCA4zGmc+//P2zV6KcGYRnSIr6Sr1XHP BJ4T9GWthND43yyFUXshLo1nWnM2y2aRNHps2neGB58pti+7ZBgJdpdlc2wAwTomzXN6 kJEA== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr8014104qab.39.1331549486736; Mon, 12 Mar 2012 03:51:26 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 12 Mar 2012 03:51:26 -0700 (PDT) In-Reply-To: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> References: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> Date: Mon, 12 Mar 2012 10:51:26 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47e2865e004bb0986f7 Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 10:51:31 -0000 --20cf3074b47e2865e004bb0986f7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/12 R=E9mi Despr=E9s > Hi, Washam, > > Thanks for your detailed questions and comments. > Answers and further comments in line. > > Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit : > > > Hi, > > > > Eventually I get a chance to review this version and have some major > > comments and questions as below. > > > > 1. Relationship with MAP, MAP-T, MAP-E. > > I thought, MAP was expected to be a generic algorithm for stateless > > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > > MAP would apply to MAP-T, MAP-E as well as 4rd-u. > > The point is that 4rd-u unifies not only the address format for -T and > -E, but also the header format so that a single standard becomes sufficie= nt. > The 4rd-U technique for this was presented in Taipei, but it didn't aris= e > interest in the MAP team. Design of 4rd-u had then to become autonomous. > > > But draft 4rd-u-04 > > doesn't mention MAP draft. > > 4rd-u is proposed as an alternative to the 2-standards approach of MAP. > It therefore needs only needs a historical reference to MAP, which is don= e > in sec. 8. > > > And I see the mapping rules stuff in the > > draft overlapped with MAP. Confused. > > > > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. > > Would you mind expaund on what benefits 4rd-u can gain exclusively? > > Ideally, there would be a seperate section or even a seperate draft > > for such comparison. > > As announced, an update of draft-despres-softwire-stateless-analysis-tool > will contain a comparison (now to be posted very soon). > > An earlier comparison table was available in > http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html > > In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to us= e > IPv6-only middle boxes for deep packet inspection and web caches; also, > like MAP-E, it ensures full IPv4 transparency. > > > > 2. NAT64+ stuff. > > My understanding, NAT64+ would translate 4rd tunnel packet as well as > > native IPv6 packet to IPv4 packet and vice verse. Right? > > If the NAT64 is stateful per session, yes, it does translation at layer 4= . > NAT64s that are stateless at this layer are however also possible. THis i= s > independent from 4rd. > > > I don't know > > what the CE delegated prefix in NAT64+ looks like. > > - The delegated prefix is any prefix up to /64 that doesn't match any CE > prefix (R-6 of draft-04)) > - The source of a CE to NAT64+ packet must have the V octet for NAT64+s t= o > be able to distinguish 4rd packets from other IPv6 packets (def of NAT64+= ). > - The format is then: > +-----------------------+-------+---+-----------------+------+ > | CE IPv6 prefix | 0 | V | 0 | CNP | > +-----------------------+-------+---+-----------------+------+ > : =3D< 64 : >=3D 0 : 8 : 40 : 16 : > > > Yet, it should be clearer in the draft. > Thanks for this (good) question. > > > > Can the native IPv6 > > and 4rd shared the same delegated prefix? > > Yes. (This is the purpose of the V octet) > > may i compare the V-octet with the MAP strategy? #1. shared ipv4 address take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=3D8. 4rd-U (with V-octet): native IPv6: 2001:db8:1234:5678:0200::/72 mapped IPv6: 2001:db8:1234:5678:0300::/72 cost: IANA authority on the use of V-bit. MAP (without V-octet): native IPv6: 2001:db8:1234:5678::/64 mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a more-specific) cost: almost none. #2. exclusive ipv4 address 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 4rd-U (with V-octet), now aggragation doesn't make sense: native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match! MAP (without V-octet): native IPv6: 2001:db8:1234:5670::/60 mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a more-specific) cost: almost none. #3. exclusive ipv4 subnet 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f 4rd-U (with V-octet), now aggragation doesn't make sense: native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match! MAP (without V-octet): native IPv6: 2001:db8:1234:5600::/56 mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a more-specific= ) 2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a more-specific= ) ... 2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a more-specific) cost: a number of more-specific to identify the mapped things; but it won't leaked out beyond the CE. if the well-developed longest-match can work, why should we need another mechanism? cheers, maoke > > if Yes, how to distinguish > > them? > > See above. > > > the figure 6 seems to me it was talking about destination IPv6 > > address derivation. > > Right. > > > > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support > > harpinning between 4rd tunnel packet and native IPv6 packet? > > The only evolution of NAT64 to make it a NAT64+ is its use of tunneling > instead of RFC6145 translation, for all IPv6 addresses that have the V > octet. (No other behavior needs to be modified.) > > > > Personally, I'd like NAT64+ removed from the draft. It might deserve a > > seperate draft. > > This way, it would make the draft more understanding > > for readers who are new to 4rd-u. > > The specification has to explain conditions in which a CE can tunnel IPv4 > packets although it has no assigned public IPv4 address, even shared. > Explaining more what is NAT64+ is IMHO better than explaining less. > > > > 3. Fragments. > > The algorithm proposed in R-9, would have applied to generic NAT > > generally. Why it is specific to 4rd BR? > > NATs may have to remember not only destination ports but also source port= s. > A similar algorithm could however apply to NAT64s, but this is off 4rd > scope. > > > > Anyway BR would keep fragment > > They MAY, but AFAIK don't need to if they use R-9 algorithm. > > > state somehow and anycase BR facing IPv4 Internet would be impossible. > > In the CE to BR direction, destinations are full IPv4 addresses so that > each fragment can be individually forwarded. > Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that > no port-based check is needed to ensure that no CE can spoof fragments > from another CE. > > > Regards, > RD > > > > > > > Thanks, > > washam > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b47e2865e004bb0986f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Hi, Washam,

Thanks for your detailed questions and comments.
Answers and further comments in line.

Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit :

> Hi,
>
> Eventually I get a chance to review this version and have some major > comments and questions as below.
>
> 1. Relationship with MAP, MAP-T, MAP-E.
> I thought, MAP was expected to be a generic algorithm for stateless > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > MAP would apply to MAP-T, MAP-E as well as 4rd-u.

=A0The point is that 4rd-u unifies not only the address format for -T= and -E, but also the header format so that a single standard becomes suffi= cient.
=A0The 4rd-U technique for this was presented in Taipei, but it didn't = arise interest in the MAP team. Design of 4rd-u had then to become autonomo= us.

> But draft 4rd-u-04
> doesn't mention MAP draft.

4rd-u is proposed as an alternative to the 2-standards approach of MA= P.
It therefore needs only needs a historical reference to MAP, which is done = in sec. 8.

> And I see the mapping rules stuff in the
> draft overlapped with MAP. Confused.
>
> I thought, 4rd-u is competing with MAP-T and MAP-E to some extend.
> Would you mind expaund on what benefits 4rd-u can gain exclusively? > Ideally, there would be a seperate section or even a seperate draft > for such comparison.

As announced, an update of draft-despres-softwire-stateless-analysis-= tool will contain a comparison (now to be posted very soon).

An earlier comparison table was available in
http://www.ietf.org/mail-archive/web/softwires/curr= ent/msg03442.html

In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to use = IPv6-only middle boxes for deep packet inspection and web caches; also, lik= e MAP-E, it ensures full IPv4 transparency.


> 2. NAT64+ stuff.
> My understanding, NAT64+ would translate 4rd tunnel packet as well as<= br> > native IPv6 packet to IPv4 packet and vice verse. Right?

If the NAT64 is stateful per session, yes, it does translation at lay= er 4.
NAT64s that are stateless at this layer are however also possible. THis is = independent from 4rd.

> I don't know
> what the CE delegated prefix in NAT64+ looks like.

- The delegated prefix is any prefix up to /64 that doesn't match= any CE prefix (R-6 of draft-04))
- The source of a CE to NAT64+ packet must have the V octet for NAT64+s to = be able to distinguish 4rd packets from other IPv6 packets (def of NAT64+).=
- The format is then:
+-----------------------+-------+---+-----------------+------+
| =A0 =A0CE IPv6 prefix =A0 =A0 | =A0 0 =A0 | V | =A0 =A0 =A0 =A0 =A00 =A0 = =A0 =A0| =A0CNP |
+-----------------------+-------+---+-----------------+------+
: =A0 =A0 =A0=3D< 64 =A0 =A0 =A0 =A0 =A0 =A0: =A0>=3D 0 : 8 : =A0 =A0= =A040 =A0 =A0 =A0 =A0 : =A016 =A0:


Yet, it should be clearer in the draft.
Thanks for this (good) question.


> Can the native IPv6
> and 4rd shared the same delegated prefix?

Yes. (This is the purpose of the V octet)


may i compare = the V-octet with the MAP strategy?

#1. shared ipv= 4 address
take an example of delegated prefix 2001:db8:1234:5678:= :/64 and the IPv4 address for the CE is 0xabcde567, PSID=3D8.=A0

4rd-U (with V-octet):
native IPv6: 2001:db8:1= 234:5678:0200::/72
mapped IPv6: 2001:db8:1234:5678:0300::/72
cost: IANA authority on the use of V-bit.

MAP (without V-octet):
native IPv6: 2001:db8:1234:5678::/64
=
mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a more-spe= cific)=A0
cost: almost none.

#2. exclusi= ve ipv4 address
2001:db8:1234:5670::/60, IPv4 address 0xabcde567

4rd-U (with V-octet), now aggragation doesn't make sense:
native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
cost: IA= NA authority on the use of V-bit; implementation cannot take the logic of l= ongest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: 2001:db8:1234:5= 670:02ab:cde5:6700:0000/128 (as a more-specific)=A0
cost: almost = none.=A0

#3. exclusive ipv4 subnet
2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f
=
4rd-U (with V-octet), now aggragation doesn't make sense= :
native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit
cost: IANA authority on the use of V-bit; implementation cannot take the = logic of longest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: 2001:db8:1= 234:5600:02ab:cde5:6000:0000/128 (as a more-specific)
=A0 =A0 =A0= =A0 =A0 =A0 =A02001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a more-speci= fic)
=A0 =A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0 =A0 =A020= 01:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a more-specific)=A0
= cost: a number of more-specific to identify the mapped things; but it won&#= 39;t leaked out beyond the CE.=A0

if the well-developed longest-match can work, why shoul= d we need another mechanism?=A0

cheers,
= maoke

=A0
> if Yes, how to distinguish
> them?

See above.

> the figure 6 seems to me it was talking about destination IPv6
> address derivation.

Right.


> IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ suppor= t
> harpinning between 4rd tunnel packet and native IPv6 packet?

The only evolution of NAT64 to make it a NAT64+ is its use of tunneli= ng instead of RFC6145 translation, for all IPv6 addresses that have the V o= ctet. (No other behavior needs to be modified.)


> Personally, I'd like NAT64+ removed from the draft. It might deser= ve a
> seperate draft.
> This way, it would make the draft more understanding
> for readers who are new to 4rd-u.

The specification has to explain conditions in which a CE can tunnel = IPv4 packets although it has no assigned public IPv4 address, even shared.<= br> Explaining more what is NAT64+ is IMHO better than explaining less.


> 3. Fragments.
> The algorithm proposed in R-9, would have applied to generic NAT
> generally. Why it is specific to 4rd BR?

NATs may have to remember not only destination ports but also source = ports.
A similar algorithm could however apply to NAT64s, but this is off 4rd scop= e.


> Anyway BR would keep fragment

They MAY, but AFAIK don't need to if they use R-9 algorithm.

> state somehow and anycase BR facing IPv4 Internet would be impossible.=

In the CE to BR direction, destinations are full IPv4 addresses so th= at each fragment can be individually forwarded.
Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that no= port-based check is needed to =A0ensure that no CE can spoof fragments fro= m another CE.


Regards,
RD



>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b47e2865e004bb0986f7-- From internet-drafts@ietf.org Mon Mar 12 05:44:56 2012 Return-Path: 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 7B1B021F8712; Mon, 12 Mar 2012 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DeJUNxbYPdTi; Mon, 12 Mar 2012 05:44:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF31E21F86DF; Mon, 12 Mar 2012 05:44:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312124455.5382.26454.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 05:44:55 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:44:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Chris Metz Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-01.txt Pages : 12 Date : 2012-03-12 When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks. This mechanism is an IPv4 access method for network users in IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt From internet-drafts@ietf.org Mon Mar 12 07:01:12 2012 Return-Path: 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 4F1F221E8029; Mon, 12 Mar 2012 07:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ls9cXCLRUxVq; Mon, 12 Mar 2012 07:01:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD60921E8021; Mon, 12 Mar 2012 07:01:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312140111.3016.80389.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 07:01:11 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:01:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Deployment Considerations for Dual-Stack Lite Author(s) : Yiu L. Lee Roberta Maglione Carl Williams Christian Jacquenet Mohamed Boucadair Filename : draft-ietf-softwire-dslite-deployment-03.txt Pages : 14 Date : 2012-03-12 This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment-0= 3.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dslite-deployment-03= .txt From despres.remi@laposte.net Mon Mar 12 07:56:48 2012 Return-Path: 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 8600C21F87FC for ; Mon, 12 Mar 2012 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 T6+F60FlNWPv for ; Mon, 12 Mar 2012 07:56:48 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C848421F87A7 for ; Mon, 12 Mar 2012 07:56:45 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1988C940119; Mon, 12 Mar 2012 15:56:32 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 15:56:31 +0100 To: Softwires WG Message-Id: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:56:48 -0000 Hello, all, An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 Differences with -04 include: - DHCPv6 options are now specified - various errors and typos are corrected - some clarifications are added, following received questions and = comments - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs) - An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs. - Document layout has been adjusted as a result of other modifications. - the authors list has been completed. Questions and comments are most welcome. Regards, RD From despres.remi@laposte.net Mon Mar 12 10:00:50 2012 Return-Path: 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 CEB6621F886C for ; Mon, 12 Mar 2012 10:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 Ho0gvQ+gTH0l for ; Mon, 12 Mar 2012 10:00:49 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id D49AF21F8860 for ; Mon, 12 Mar 2012 10:00:46 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 98BDC940248; Mon, 12 Mar 2012 18:00:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-102--1070365877 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 12 Mar 2012 18:00:35 +0100 Message-Id: <62F71361-3110-4069-B186-915003CD986B@laposte.net> References: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:00:50 -0000 --Apple-Mail-102--1070365877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, 1. What you call the cost of "IANA authority on the use of V-bit" is = neither a development nor an operational cost. Once standardization is = done, the cost becomes 0. 2. Isn't it true that MAP addresses must have the "u" octet, i.e. 0x00, in = address bits 64-71? If yes, MAP example addresses you give with 0x02 or 0x03 instead of "u", = aren't AFAIK valid MAP addresses. If no, please explain what I missed.=20 3. You say that aggregation doesn't make sense in 4rd-u, e.g. with the = following example: - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit But the right choice for the second line is: - mapped IPv6: 2001:db8:1234:5670:3000::/72=20 Thus, longest match does the job. (What you describe is what might have applied if we had kept the maxPsid = feature. But, as you may recall, we abandoned it unanimously in Taipei.) Cheers, RD=20 Le 2012-03-12 =E0 11:51, Maoke a =E9crit : >=20 >=20 > 2012/3/12 R=E9mi Despr=E9s > Hi, Washam, >=20 > Thanks for your detailed questions and comments. > Answers and further comments in line. >=20 > Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit : >=20 > > Hi, > > > > Eventually I get a chance to review this version and have some major > > comments and questions as below. > > > > 1. Relationship with MAP, MAP-T, MAP-E. > > I thought, MAP was expected to be a generic algorithm for stateless > > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > > MAP would apply to MAP-T, MAP-E as well as 4rd-u. >=20 > The point is that 4rd-u unifies not only the address format for -T = and -E, but also the header format so that a single standard becomes = sufficient. > The 4rd-U technique for this was presented in Taipei, but it didn't = arise interest in the MAP team. Design of 4rd-u had then to become = autonomous. >=20 > > But draft 4rd-u-04 > > doesn't mention MAP draft. >=20 > 4rd-u is proposed as an alternative to the 2-standards approach of = MAP. > It therefore needs only needs a historical reference to MAP, which is = done in sec. 8. >=20 > > And I see the mapping rules stuff in the > > draft overlapped with MAP. Confused. > > > > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. > > Would you mind expaund on what benefits 4rd-u can gain exclusively? > > Ideally, there would be a seperate section or even a seperate draft > > for such comparison. >=20 > As announced, an update of = draft-despres-softwire-stateless-analysis-tool will contain a comparison = (now to be posted very soon). >=20 > An earlier comparison table was available in > http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html >=20 > In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to = use IPv6-only middle boxes for deep packet inspection and web caches; = also, like MAP-E, it ensures full IPv4 transparency. >=20 >=20 > > 2. NAT64+ stuff. > > My understanding, NAT64+ would translate 4rd tunnel packet as well = as > > native IPv6 packet to IPv4 packet and vice verse. Right? >=20 > If the NAT64 is stateful per session, yes, it does translation at = layer 4. > NAT64s that are stateless at this layer are however also possible. = THis is independent from 4rd. >=20 > > I don't know > > what the CE delegated prefix in NAT64+ looks like. >=20 > - The delegated prefix is any prefix up to /64 that doesn't match any = CE prefix (R-6 of draft-04)) > - The source of a CE to NAT64+ packet must have the V octet for = NAT64+s to be able to distinguish 4rd packets from other IPv6 packets = (def of NAT64+). > - The format is then: > +-----------------------+-------+---+-----------------+------+ > | CE IPv6 prefix | 0 | V | 0 | CNP | > +-----------------------+-------+---+-----------------+------+ > : =3D< 64 : >=3D 0 : 8 : 40 : 16 : >=20 >=20 > Yet, it should be clearer in the draft. > Thanks for this (good) question. >=20 >=20 > > Can the native IPv6 > > and 4rd shared the same delegated prefix? >=20 > Yes. (This is the purpose of the V octet) >=20 >=20 > may i compare the V-octet with the MAP strategy? >=20 > #1. shared ipv4 address > take an example of delegated prefix 2001:db8:1234:5678::/64 and the = IPv4 address for the CE is 0xabcde567, PSID=3D8.=20 >=20 > 4rd-U (with V-octet): > native IPv6: 2001:db8:1234:5678:0200::/72 > mapped IPv6: 2001:db8:1234:5678:0300::/72 > cost: IANA authority on the use of V-bit. >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5678::/64 > mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a = more-specific)=20 > cost: almost none. >=20 > #2. exclusive ipv4 address > 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 >=20 > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take = the logic of longest-match! >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5670::/60 > mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a = more-specific)=20 > cost: almost none.=20 >=20 > #3. exclusive ipv4 subnet > 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f >=20 > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take = the logic of longest-match! >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5600::/56 > mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a = more-specific) > 2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a = more-specific) > ... > 2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a = more-specific)=20 > cost: a number of more-specific to identify the mapped things; but it = won't leaked out beyond the CE.=20 >=20 > if the well-developed longest-match can work, why should we need = another mechanism?=20 >=20 > cheers, > maoke >=20 > =20 > > if Yes, how to distinguish > > them? >=20 > See above. >=20 > > the figure 6 seems to me it was talking about destination IPv6 > > address derivation. >=20 > Right. >=20 >=20 > > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support > > harpinning between 4rd tunnel packet and native IPv6 packet? >=20 > The only evolution of NAT64 to make it a NAT64+ is its use of = tunneling instead of RFC6145 translation, for all IPv6 addresses that = have the V octet. (No other behavior needs to be modified.) >=20 >=20 > > Personally, I'd like NAT64+ removed from the draft. It might deserve = a > > seperate draft. > > This way, it would make the draft more understanding > > for readers who are new to 4rd-u. >=20 > The specification has to explain conditions in which a CE can tunnel = IPv4 packets although it has no assigned public IPv4 address, even = shared. > Explaining more what is NAT64+ is IMHO better than explaining less. >=20 >=20 > > 3. Fragments. > > The algorithm proposed in R-9, would have applied to generic NAT > > generally. Why it is specific to 4rd BR? >=20 > NATs may have to remember not only destination ports but also source = ports. > A similar algorithm could however apply to NAT64s, but this is off 4rd = scope. >=20 >=20 > > Anyway BR would keep fragment >=20 > They MAY, but AFAIK don't need to if they use R-9 algorithm. >=20 > > state somehow and anycase BR facing IPv4 Internet would be = impossible. >=20 > In the CE to BR direction, destinations are full IPv4 addresses so = that each fragment can be individually forwarded. > Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so = that no port-based check is needed to ensure that no CE can spoof = fragments from another CE. >=20 >=20 > Regards, > RD >=20 >=20 >=20 > > > > Thanks, > > washam > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-102--1070365877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

2.
Isn't it true that MAP = addresses must have the "u" octet, i.e. 0x00, in address bits = 64-71?
If yes, MAP example addresses you give with 0x02 or = 0x03 instead of "u", aren't AFAIK valid MAP addresses.
If no, = please explain what I = missed. 

3.
You say = that aggregation doesn't make sense in 4rd-u, e.g. with the = following example:
- native IPv6: = 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
- mapped IPv6: = 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
But the = right choice for the second line is:
- mapped = IPv6: 2001:db8:1234:5670:3000::/72 
Thus, longest= match does the job.

(What you describe is what = might have applied if we had kept the maxPsid feature. But, as you may = recall, we abandoned it unanimously in = Taipei.)

Cheers,
RD 

Le 2012-03-12 =E0 11:51, Maoke a =E9crit = :



2012/3/12 R=E9mi = Despr=E9s <despres.remi@laposte.net><= /span>
Hi, Washam,

Thanks for your detailed questions and comments.
Answers and further comments in line.

Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit :

> Hi,
>
> Eventually I get a chance to review this version and have some = major
> comments and questions as below.
>
> 1. Relationship with MAP, MAP-T, MAP-E.
> I thought, MAP was expected to be a generic algorithm for = stateless
> mapping IPv4 addresses to IPv6 addresses and vice versa. I = thought,
> MAP would apply to MAP-T, MAP-E as well as 4rd-u.

 The point is that 4rd-u unifies not only the address format = for -T and -E, but also the header format so that a single standard = becomes sufficient.
 The 4rd-U technique for this was presented in Taipei, but it = didn't arise interest in the MAP team. Design of 4rd-u had then to = become autonomous.

> But draft 4rd-u-04
> doesn't mention MAP draft.

4rd-u is proposed as an alternative to the 2-standards approach of = MAP.
It therefore needs only needs a historical reference to MAP, which is = done in sec. 8.

> And I see the mapping rules stuff in the
> draft overlapped with MAP. Confused.
>
> I thought, 4rd-u is competing with MAP-T and MAP-E to some = extend.
> Would you mind expaund on what benefits 4rd-u can gain = exclusively?
> Ideally, there would be a seperate section or even a seperate = draft
> for such comparison.

As announced, an update of = draft-despres-softwire-stateless-analysis-tool will contain a comparison = (now to be posted very soon).

An earlier comparison table was available in
http://www.ietf.org/mail-archive/web/softwires/current/m= sg03442.html

In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to = use IPv6-only middle boxes for deep packet inspection and web caches; = also, like MAP-E, it ensures full IPv4 transparency.


> 2. NAT64+ stuff.
> My understanding, NAT64+ would translate 4rd tunnel packet as well = as
> native IPv6 packet to IPv4 packet and vice verse. Right?

If the NAT64 is stateful per session, yes, it does translation at = layer 4.
NAT64s that are stateless at this layer are however also possible. THis = is independent from 4rd.

> I don't know
> what the CE delegated prefix in NAT64+ looks like.

- The delegated prefix is any prefix up to /64 that doesn't match = any CE prefix (R-6 of draft-04))
- The source of a CE to NAT64+ packet must have the V octet for NAT64+s = to be able to distinguish 4rd packets from other IPv6 packets (def of = NAT64+).
- The format is then:
+-----------------------+-------+---+-----------------+------+
|    CE IPv6 prefix     |   0   | V | =          0      |  CNP = |
+-----------------------+-------+---+-----------------+------+
:      =3D< 64           =  :  >=3D 0 : 8 :      40     =     :  16  :


Yet, it should be clearer in the draft.
Thanks for this (good) question.


> Can the native IPv6
> and 4rd shared the same delegated prefix?

Yes. (This is the purpose of the V octet)


may i = compare the V-octet with the MAP strategy?

#1. = shared ipv4 address
take an example of delegated prefix = 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, = PSID=3D8. 

4rd-U (with V-octet):
native IPv6: = 2001:db8:1234:5678:0200::/72
mapped IPv6: = 2001:db8:1234:5678:0300::/72
cost: IANA authority on the use = of V-bit.

MAP (without V-octet):
native IPv6: = 2001:db8:1234:5678::/64
mapped IPv6: = 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a = more-specific) 
cost: almost = none.

#2. exclusive ipv4 address
2001:db8:1234:5670::/60, IPv4 address = 0xabcde567

4rd-U (with V-octet), now = aggragation doesn't make sense:
native IPv6: = 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
cost: = IANA authority on the use of V-bit; implementation cannot take the logic = of longest-match!

MAP (without = V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: = 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a = more-specific) 
cost: almost = none. 

#3. exclusive ipv4 = subnet
2001:db8:1234:5600::/56, IPv4 address = 0xabcde560~0xabcde56f

4rd-U (with = V-octet), now aggragation doesn't make sense:
native IPv6: = 2001:db8:1234:5600::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 = bit
cost: IANA authority on the use of V-bit; = implementation cannot take the logic of = longest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: = 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a = more-specific)
            =  2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a = more-specific)
            =  ...
            =  2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a = more-specific) 
cost: a number of more-specific to = identify the mapped things; but it won't leaked out beyond the = CE. 

if the well-developed longest-match can work, why = should we need another = mechanism? 

cheers,
maoke

 
> if Yes, how to distinguish
> them?

See above.

> the figure 6 seems to me it was talking about destination IPv6
> address derivation.

Right.


> IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ = support
> harpinning between 4rd tunnel packet and native IPv6 packet?

The only evolution of NAT64 to make it a NAT64+ is its use of = tunneling instead of RFC6145 translation, for all IPv6 addresses that = have the V octet. (No other behavior needs to be modified.)


> Personally, I'd like NAT64+ removed from the draft. It might = deserve a
> seperate draft.
> This way, it would make the draft more understanding
> for readers who are new to 4rd-u.

The specification has to explain conditions in which a CE can = tunnel IPv4 packets although it has no assigned public IPv4 address, = even shared.
Explaining more what is NAT64+ is IMHO better than explaining less.


> 3. Fragments.
> The algorithm proposed in R-9, would have applied to generic = NAT
> generally. Why it is specific to 4rd BR?

NATs may have to remember not only destination ports but also = source ports.
A similar algorithm could however apply to NAT64s, but this is off 4rd = scope.


> Anyway BR would keep fragment

They MAY, but AFAIK don't need to if they use R-9 algorithm.

> state somehow and anycase BR facing IPv4 Internet would be = impossible.

In the CE to BR direction, destinations are full IPv4 addresses so = that each fragment can be individually forwarded.
Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that = no port-based check is needed to  ensure that no CE can spoof = fragments from another CE.


Regards,
RD



>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-102--1070365877-- From despres.remi@laposte.net Mon Mar 12 10:25:50 2012 Return-Path: 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 5321421F88E4 for ; Mon, 12 Mar 2012 10:25:50 -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 QVR0TIWCKLBl for ; Mon, 12 Mar 2012 10:25:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0F221F88D9 for ; Mon, 12 Mar 2012 10:25:45 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id khRh1i00D37Y3f403hRhcc; Mon, 12 Mar 2012 18:25:43 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-103--1068860692 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 12 Mar 2012 18:25:41 +0100 Message-Id: <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:25:50 -0000 --Apple-Mail-103--1068860692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-12 =E0 10:21, Maoke a =E9crit : > hi Remi, >=20 > 2012/3/12 R=E9mi Despr=E9s >=20 > 2012-03-12 04:09, Maoke: > ... > > btw, BR also depends upon NAT44 to deal with the unknown protocol, = right? if so, may i say your statement "BR will support them without = needing an update" is a proposition actually not existing? because NAT44 = won't support them without any update. right? >=20 > Not right. Only CEs that need to support a new protocol are concerned: > - If a shared address server supports a new protocol, it can be = reached via an unchanged BR. > - If a client using a new protocol tries to reach a shared-address CE = that doesn't support this protocol, the client will be returned an error = message by the destination NAT44. >=20 > thanks a lot for the clarification! take an example:=20 >=20 > A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 = Internet)--- B >=20 > now A and B are supposed to use a new protocol other than known = TCP/UDP/etc. my understanding: > B --> A > 1. BR just passes the new protocol without any concern. > 2. CE's NAT44 module would say "this is not supported and a = 'destination unreachable with port unknown' ICMP message is returned to = B. As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message = should be, more precisely, "protocol unreachable". Everything OK. > A --> B > 1. CE's NAT44 module directly say "destination unreachable with port = unknown" ICMP message to A. Presumably also "protocol unreachable", but this remains a NAT44 matter. = 4rd isn't involved. > is the above what you mean? when NAT44 module DOESN'T support the new = protocol, things are working while we have no the problem about the = "change" at all for the time being.=20 >=20 > then let's consider the case where the NAT44 module has been updated = to support the new protocol. i understand BR passing all protocols can = be survived if and only if the new protocol follows the TCP-layout for = the destination port and the TCP-checksum, right?=20 The 4rd mechanism is for protocols that have ports at their usual place = (all existing protocols that have ports have them at the same place, = even if using another checksum algorithm like SCTP). =20 > then you made a limitation (#1) to the NAT44 module of the CE: even if = the NAT44 has supported a new protocol not following TCP = layout/checksum, this support MUST be disabled in the 4rd-U environment; = otherwise, BR may behave wrong when making the mapped IPv6 addresses = while the NAT44 would still try to translate with the new protocol = rather than dropping an error message because it has known it. right?=20 To me this looks like a far fetched theoretical problem, with no = consequence in practice. OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate = DCCP or not is a real problem, and so is the fact that it doesn't = support UDP Lite, another already existing protocol. =20 > further (#2), what if the packets don't pass through the NAT44 module = at all (in the case of non-shared IPv4 addresses)?=20 In case of non shared addresses, neither BRs nor CEs look at any port = field (there in no PSID to be found). > please clarify if the limitation of (#1) and (#2) are true or false. Answered above. > i believe with requiring L4 modification, either MAP or RFC6145 has no = such two limitations: enforcing the checksum update at L4, their = framework is safe for either TCP-layout/checksum or = alien-layout/checksum, either shared or exclusive IPv4 addresses. This remains AFAIK a belief that ignores DCCP and UDP Lite limitations = of RFC6145. > i worry the CNP is making a situation of "cutting feet to fit the = shoes".=20 Hopefully, you will see that no such worry is justified. Cheers, RD >=20 > - maoke > =20 >=20 > RD >=20 >=20 >=20 --Apple-Mail-103--1068860692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi = Remi,

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the = unknown protocol, right? if so, may i say your statement "BR will = support them without needing an update" is a proposition actually not = existing? because NAT44 won't support them without any update. = right?

Not right. Only CEs that need to support a new protocol are = concerned:
- If a shared address server supports a new protocol, it can be reached = via an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE = that doesn't support this protocol, the client will be returned an error = message by the destination = NAT44.

thanks a lot for the = clarification! take an example: 

 A --- NAT44/CE ---(IPv6 backbone of 4rd = domain)--- BR ---(IPv4 Internet)--- B

now A and = B are supposed to use a new protocol other than known TCP/UDP/etc. my = understanding:
B --> A
1. BR just passes the new protocol without any = concern.
2. CE's NAT44 module would say "this is not supported = and a 'destination unreachable with port unknown' ICMP message is = returned to B.

As now documented = in 4rd-u-05 in the NOTE of 4.4 (3), the error message should be, more = precisely, "protocol unreachable".
Everything = OK.


A --> B
1. CE's NAT44 module directly say "destination = unreachable with port unknown" ICMP message to = A.

Presumably also "protocol = unreachable", but this remains a NAT44 matter. 4rd isn't = involved.

is the above what you mean? when NAT44 module = DOESN'T support the new protocol, things are working while we have no = the problem about the "change" at all for the time being. 

then let's consider the case where the NAT44 module = has been updated to support the new protocol. i understand BR passing = all protocols can be survived if and only if the new protocol follows = the TCP-layout for the destination port and the TCP-checksum, = right? 

The 4rd = mechanism is for protocols that have ports at their usual place (all = existing protocols that have ports have them at the same place, even if = using another checksum algorithm like = SCTP).
 

then you made a limitation (#1) to the NAT44 module of the CE: even = if the NAT44 has supported a new protocol not following TCP = layout/checksum, this support MUST be disabled in the 4rd-U environment; = otherwise, BR may behave wrong when making the mapped IPv6 addresses = while the NAT44 would still try to translate with the new protocol = rather than dropping an error message because it has known it. = right? 

To me this looks = like a far fetched theoretical problem, with no consequence in = practice.
OTOH, the fact that RFC6145 doesn't tell you whether = you MUST translate DCCP or not is a real problem, and so is the fact = that it doesn't support UDP Lite, another already existing protocol. =  

=
further (#2), what if the packets don't pass through the NAT44 = module at all (in the case of non-shared IPv4 = addresses)? 

In case of = non shared addresses, neither BRs nor CEs look at any port field (there = in no PSID to be found).

please clarify if the limitation of (#1) and = (#2) are true or false.

Answered = above.


i believe with requiring L4 modification, = either MAP or RFC6145 has no such two limitations: enforcing the = checksum update at L4, their framework is safe for either = TCP-layout/checksum or alien-layout/checksum, either shared or exclusive = IPv4 addresses.

This remains = AFAIK a belief that ignores DCCP and UDP Lite limitations of = RFC6145.


i worry the CNP is making a situation of = "cutting feet to fit the = shoes". 

Hopefully, you = will see that no such worry is = justified.


Cheers,
RD





- maoke
 

RD




= --Apple-Mail-103--1068860692-- From shtsuchi@cisco.com Mon Mar 12 10:31:50 2012 Return-Path: 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 35A5421F8924; Mon, 12 Mar 2012 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] 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 4O-NTgwcUfTe; Mon, 12 Mar 2012 10:31:45 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C821F891D; Mon, 12 Mar 2012 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=4803; q=dns/txt; s=iport; t=1331573505; x=1332783105; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XtnXJw8fKYgm1f8SQYVNshK1tAbAo8x/3LVmwOJkZSY=; b=HJfxkMyQCSUviGXLb7ZNUuoo00fCQFkXmmu0jfMmxFeNvH9FCc186Q6W NsqWtiJAVkkw1hanazMQHe2v3ID1wsdyyuFC5Ewg7CvqdAN0dt9xJ361j +9RC6/+weOcFCJh3Q3Kd12NVhHLUDbAVXNZQPtDKpj2tKSgKhHSD6F9Ah s=; X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="7702899" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 12 Mar 2012 17:31:43 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHVVnU032266; Mon, 12 Mar 2012 17:31:32 GMT Message-ID: <4F5E32F2.50302@cisco.com> Date: Tue, 13 Mar 2012 02:31:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com><4F320549.20100@cisco.com> <4F34A0AD.4040300@cisco.com> In-Reply-To: <4F34A0AD.4040300@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [Softwires] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:31:50 -0000 v6ops I published 04,add some comments. 4.2. Configuration 4.4. Traffic Pattern http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04 I believe native IPv6 data center is ideal,but the operators sometimes can not reach the ideal. Server based 6rd would be useful to provide IPv6 to customer as solution. Could you share presentation time slot in IETF83? Regards, -Shishio (2012/02/10 13:44), Shishio Tsuchiya wrote: > Linda > Thanks for comments. > > (2012/02/10 8:26), Linda Dunbar wrote: >> Shishio, >> >> Thank you very much for sharing the v6 deployment in data center. >> >> I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? > > Yes. > 6rd is IPv6 over IPv4 tunnel technology. > So backbone operator does not need to care to IPv6 on the core. > Additionally 6rd has stateless feature. > Once the operator has placed/configured 6rd BR on the exit point to the IPv6 internet,does not need additional operation to add 6rd CE(server based 6rd). > And if the server would like to go to the IPv6 internet,then IPv4 packets will through 6rd BR and de-capsulate. > If the server would like to communicate other 6rd server within the data center,then IPv4 packets will reach 6rd server directly and de-capsulate. > >> >> >> Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? > > In Sakura internet 6rd cases,each of 6rd server has one 6rd delegate prefix(/64). > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-4.1 > > The 6rd delegate prefix calculates from Sakura's IPv6 prefix(/32) and IPv4 address. > Sakura has the scalability problem which is same as ARMD draft. > http://tools.ietf.org/html/draft-ietf-armd-problem-statement-00 > > They also had to update switches to resolve security issue(Rogue RA). > http://tools.ietf.org/html/rfc6104 > > They selected "server-based 6rd" as the solution to avoid scalability and security problem. > > Regards, > -Shishio > > >> >> Thanks, Linda Dunbar >> >> >> >> >> >> On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya> wrote: >> >> v6ops and ARMD >> Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. >> We thought this is interesting idea,so published the draft. >> >> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 >> >> I think both of mailing list participants are also interesting in this technique. >> If you have any comment and question of the draft,please let me know. >> >> Regards, >> -Shishio >> -------- Original Message -------- >> Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt >> Date: Mon, 14 Nov 2011 17:21:26 +0800 >> From:> >> Reply-To:> >> To:> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : IPv6 Rapid Deployment (6rd) in a Large Data Center >> Author(s) : Shishio Tsuchiya >> Mark Townsley >> Shuichi Ohkubo >> Filename : draft-sakura-6rd-datacenter-03.txt >> Pages : 15 >> Date : 2011-11-14 >> >> IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid >> deployment of IPv6 by an access service provider which has difficulty >> deploying native IPv6. This document describes how 6rd can be used >> to deliver IPv6 within a Large Data Center. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >> >> > > From despres.remi@laposte.net Mon Mar 12 12:07:11 2012 Return-Path: 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 8301C21F8A37 for ; Mon, 12 Mar 2012 12:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 SgeC7xpVe20C for ; Mon, 12 Mar 2012 12:07:11 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE421F8A36 for ; Mon, 12 Mar 2012 12:07:06 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id kj741i00D37Y3f403j7446; Mon, 12 Mar 2012 20:07:04 +0100 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Mar 2012 20:07:04 +0100 Message-Id: <21B66A22-348A-4060-B476-6A2DA3E04853@laposte.net> To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] Stateless-analysis-tool-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:07:11 -0000 Hello, all, The new comparison tool of StatelessV4viaV6 solutions is now available at http://tools.ietf.org/html/draft-despres-softwire-stateless-analysis-tool-01 Questions and comments are most welcome. Regards, RD From sarikaya2012@gmail.com Mon Mar 12 15:09:08 2012 Return-Path: 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 6C77F21E811B for ; Mon, 12 Mar 2012 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 DI6JoY3DhCPP for ; Mon, 12 Mar 2012 15:09:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3824921F8A8D for ; Mon, 12 Mar 2012 15:09:06 -0700 (PDT) Received: by iazz13 with SMTP id z13so8235162iaz.31 for ; Mon, 12 Mar 2012 15:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=79bjUDXhGyiHWC50YbPokbucODNyia7nCiMkiAK5A48=; b=p6ur/1bcHL4q/5gB6+hS91AsvP2+EV1s7+8Zciac1yqbj6WJ2/qFuARVIDZS94zKNe yfN00HnZsnIl4r4VKxOCLcGBDUsCh1kLuyb5VQsI/DhEni1LyxcT7fIsCwwYEZvSnqVY 25/bK6osdPS5bRfvCdSYJxkxT92bnYLLAUG2W2yfTJN+EG7qaoHS2aNrTWGPFyNnXOXG QA9cPGHmNhvHvhDpcGmCVFS7AH8PYskKnk54PyMDPg9N+M+OsSrnpT2LVYjrNnU0ihVz IZ9tIajcLj1DiwVlL78qA2Z6Ig8EjXjWW3RmnseQWqFwUjwK8cUroWiCGAAE6ZBMCz2l Jsvg== MIME-Version: 1.0 Received: by 10.43.52.74 with SMTP id vl10mr17440145icb.55.1331590145764; Mon, 12 Mar 2012 15:09:05 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Mon, 12 Mar 2012 15:09:05 -0700 (PDT) In-Reply-To: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> Date: Mon, 12 Mar 2012 17:09:05 -0500 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:09:08 -0000 Hi Remi, My quick comments: editorial on abstract: - The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). remove: for this. Better still have a sentence like: 4rd specifies a protocol mechanism to support Pv4 via a service provider's (SP's) IPv6 network without maintaining per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). - To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. It is not customers but it is CPE or CEs, right? - 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145) replace "of" with "with" Technical: I don't understand NAT64+ discussion in this draft (it has been added in -04). Why do you need it? In NAT64, IPv6 packet is not created by CE but by the host with the help of DNS64.Where is DNS64 in your draft, except for a reference to RFC 6147 which is a bogus reference. NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over an IPv6 network. So it has almost nothing to do with 4rd. One thing you can do is to say that NAT64 could be colocated with 4rd BR if Pref64 of NAT is chosen to match 4rd prefix. In that case you need to add support for RFC6145 stateful packet translation as well as the NAT state in 4rd BRs. Is this what you would like to do? Maybe I missed something. Regards, Behcet On Mon, Mar 12, 2012 at 9:56 AM, R=E9mi Despr=E9s wrote: > Hello, all, > > An updated version of draft-despres-softwire-4rd-u is now available at ht= tp://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 > > Differences with -04 include: > - DHCPv6 options are now specified > - various errors and typos are corrected > - some clarifications are added, following received questions and comment= s > - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and= within CPEs) > - An editor's note has been added, following a WG-ML discussion, about an= additional Mapping-rule parameter that might be needed to assign privilege= d ports to to some shared-address CEs. > - Document layout has been adjusted as a result of other modifications. > - the authors list has been completed. > > Questions and comments are most welcome. > > Regards, > RD > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Mon Mar 12 15:52:45 2012 Return-Path: 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 6888E21E817B for ; Mon, 12 Mar 2012 15:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qh2jeF3a4juH for ; Mon, 12 Mar 2012 15:52:43 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF521E8170 for ; Mon, 12 Mar 2012 15:52:43 -0700 (PDT) Received: by dakl33 with SMTP id l33so6196026dak.31 for ; Mon, 12 Mar 2012 15:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=LjQFaJNJLSuveMcdvrymL74fHQxUKVQ1Rg7aL7MVqzU=; b=B2GA1a/vtr8LYN2+WBiRgwe8Ux8nan9HuohkO07yXQWRBXM00LPLn4dcDoACviFpoA tTrjGkX2N+YvGgej43sKx0Vgx/i0O+CMfBbIptJjgGoC9uiEQYTuKYV19yWp964etPgV 66puF82WGsk8zLxZJdzi9xYlhf/I4OZ9QDYve3tnmuUTNhrOAwj0x8EbwjyhF9mD8/kr TaYFAGSXbM+mAn5SXuGBcPQ/M57VA73KrLUzi65n90yk3C+F7HvgHn8e3+JnuM5TvZme BBVsBk7F5jwYgZXm3WNaa86+D7g9l1tszQs1uws70+WJ4KT2KmXtu5dtG7SRvcqL2ydL bV0Q== Received: by 10.68.226.227 with SMTP id rv3mr122810pbc.65.1331592763334; Mon, 12 Mar 2012 15:52:43 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-65-140.tor.primus.ca. [173.206.65.140]) by mx.google.com with ESMTPS id f5sm10666368pbq.43.2012.03.12.15.52.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 15:52:42 -0700 (PDT) Message-ID: <4F5E7E37.1030705@gmail.com> Date: Mon, 12 Mar 2012 18:52:39 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Softwires References: <20120312222107.13683.34483.idtracker@ietfa.amsl.com> In-Reply-To: <20120312222107.13683.34483.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120312222107.13683.34483.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120312-1, 12/03/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-6rd-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:52:46 -0000 This draft has been brought up to date. Unlike the peculiar series of Sarikaya drafts, it really is about multicast in the intervening (IPv4) network. -------- Original Message -------- Subject: New Version Notification for draft-tsou-softwire-6rd-multicast-01.txt Date: Mon, 12 Mar 2012 15:21:07 -0700 From: internet-drafts@ietf.org To: tom.taylor.stds@gmail.com CC: cathy.zhou@huawei.com, jihui@chinatelecom.com.cn, tina.tsou.zouting@huawei.com A new version of I-D, draft-tsou-softwire-6rd-multicast-01.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-softwire-6rd-multicast Revision: 01 Title: IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment Creation date: 2012-03-11 WG ID: Individual Submission Number of pages: 8 Abstract: This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network. The IETF Secretariat From fibrib@gmail.com Mon Mar 12 17:59:46 2012 Return-Path: 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 D19E511E8072 for ; Mon, 12 Mar 2012 17:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kWsRXlBzFA4u for ; Mon, 12 Mar 2012 17:59:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9FE11E8079 for ; Mon, 12 Mar 2012 17:59:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3680028ghb.31 for ; Mon, 12 Mar 2012 17:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zOHPPF2lRDC59vQBcML5njG5yhmCAIQ4DMvJT2W5YDE=; b=FIh3j8Ye7lslXYd0G6radH8PX1Ubr+S5t/AFV+Od8pA5vG0shhfT6aDI7xcYbiYXxz XBkStu7ThQBUBAbyD1MV4RFUenBG0RJ7xBgwtmw9ifd4owwVQ5B2WaYCgkAfr3yUx/8O dxbzqD7HiOiS6Pn4R5OAioPojraTMKHRxBg5sxleBY2lNY3k8m9rV3cwLWvk29U0hAiF VisKgErBRWXsxy4VxPbDXYtrz03ZudMnJVR2c8v9ZVrCtHli+4Ri5FRJmBPlKD3/lVef kCEKZHUnmD3lXq6P86MVJDDUuP3utzkz9Sl+0Dh300ZnS1sD92V1lK1KxTtCERYq0KUA 05ew== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr3272046qct.9.1331600384595; Mon, 12 Mar 2012 17:59:44 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 12 Mar 2012 17:59:44 -0700 (PDT) In-Reply-To: <62F71361-3110-4069-B186-915003CD986B@laposte.net> References: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> <62F71361-3110-4069-B186-915003CD986B@laposte.net> Date: Tue, 13 Mar 2012 00:59:44 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=002354530350e8191f04bb155f66 Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:59:46 -0000 --002354530350e8191f04bb155f66 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, 2012/3/12 R=E9mi Despr=E9s > Maoke, > > 1. > What you call the cost of "IANA authority on the use of V-bit" is neither > a development nor an operational cost. Once standardization is done, the > cost becomes 0. > exactly. > > 2. > Isn't it true that MAP addresses must have the "u" octet, i.e. 0x00, in > address bits 64-71? > If yes, MAP example addresses you give with 0x02 or 0x03 instead of "u", > aren't AFAIK valid MAP addresses. > oh, yes! i made the typo, falling into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter states: "Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero." thanks a lot for pointing out the mistake! the corresponding example should be corrected as: #1. shared ipv4 address take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=3D8. MAP (without V-octet): native IPv6: 2001:db8:1234:5678::/64 mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a more-specific) cost: almost none. #2. exclusive ipv4 address 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 MAP (without V-octet): native IPv6: 2001:db8:1234:5670::/60 mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a more-specific) cost: almost none. #3. exclusive ipv4 subnet 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f MAP (without V-octet): native IPv6: 2001:db8:1234:5600::/56 mapped IPv6: 2001:db8:1234:5600:00ab:cde5:6000:0000/128 (as a more-specific= ) 2001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a more-specific= ) ... 2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a more-specific) > If no, please explain what I missed. > thanks a lot! > > 3. > You say that aggregation doesn't make sense in 4rd-u, e.g. with the > following example: > - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > But the right choice for the second line is: > - mapped IPv6: 2001:db8:1234:5670:3000::/72 > 2001:db8:1234:5670:0300::/72, right? ;-) > Thus, longest match does the job. > > exactly. however, my point is: as the longest-match can do the job with V octet or without it, why don't we directly use the version without it? - maoke > (What you describe is what might have applied if we had kept the maxPsid > feature. But, as you may recall, we abandoned it unanimously in Taipei.) > > Cheers, > RD > > > Le 2012-03-12 =E0 11:51, Maoke a =E9crit : > > > > 2012/3/12 R=E9mi Despr=E9s > >> Hi, Washam, >> >> Thanks for your detailed questions and comments. >> Answers and further comments in line. >> >> Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit : >> >> > Hi, >> > >> > Eventually I get a chance to review this version and have some major >> > comments and questions as below. >> > >> > 1. Relationship with MAP, MAP-T, MAP-E. >> > I thought, MAP was expected to be a generic algorithm for stateless >> > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, >> > MAP would apply to MAP-T, MAP-E as well as 4rd-u. >> >> The point is that 4rd-u unifies not only the address format for -T and >> -E, but also the header format so that a single standard becomes suffici= ent. >> The 4rd-U technique for this was presented in Taipei, but it didn't >> arise interest in the MAP team. Design of 4rd-u had then to become >> autonomous. >> >> > But draft 4rd-u-04 >> > doesn't mention MAP draft. >> >> 4rd-u is proposed as an alternative to the 2-standards approach of MAP. >> It therefore needs only needs a historical reference to MAP, which is >> done in sec. 8. >> >> > And I see the mapping rules stuff in the >> > draft overlapped with MAP. Confused. >> > >> > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. >> > Would you mind expaund on what benefits 4rd-u can gain exclusively? >> > Ideally, there would be a seperate section or even a seperate draft >> > for such comparison. >> >> As announced, an update of draft-despres-softwire-stateless-analysis-too= l >> will contain a comparison (now to be posted very soon). >> >> An earlier comparison table was available in >> http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html >> >> In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to >> use IPv6-only middle boxes for deep packet inspection and web caches; al= so, >> like MAP-E, it ensures full IPv4 transparency. >> >> >> > 2. NAT64+ stuff. >> > My understanding, NAT64+ would translate 4rd tunnel packet as well as >> > native IPv6 packet to IPv4 packet and vice verse. Right? >> >> If the NAT64 is stateful per session, yes, it does translation at layer = 4. >> NAT64s that are stateless at this layer are however also possible. THis >> is independent from 4rd. >> >> > I don't know >> > what the CE delegated prefix in NAT64+ looks like. >> >> - The delegated prefix is any prefix up to /64 that doesn't match any CE >> prefix (R-6 of draft-04)) >> - The source of a CE to NAT64+ packet must have the V octet for NAT64+s >> to be able to distinguish 4rd packets from other IPv6 packets (def of >> NAT64+). >> - The format is then: >> +-----------------------+-------+---+-----------------+------+ >> | CE IPv6 prefix | 0 | V | 0 | CNP | >> +-----------------------+-------+---+-----------------+------+ >> : =3D< 64 : >=3D 0 : 8 : 40 : 16 : >> >> >> Yet, it should be clearer in the draft. >> Thanks for this (good) question. >> >> >> > Can the native IPv6 >> > and 4rd shared the same delegated prefix? >> >> Yes. (This is the purpose of the V octet) >> >> > may i compare the V-octet with the MAP strategy? > > #1. shared ipv4 address > take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 > address for the CE is 0xabcde567, PSID=3D8. > > 4rd-U (with V-octet): > native IPv6: 2001:db8:1234:5678:0200::/72 > mapped IPv6: 2001:db8:1234:5678:0300::/72 > cost: IANA authority on the use of V-bit. > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5678::/64 > mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a > more-specific) > cost: almost none. > > #2. exclusive ipv4 address > 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 > > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take the > logic of longest-match! > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5670::/60 > mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a > more-specific) > cost: almost none. > > #3. exclusive ipv4 subnet > 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f > > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take the > logic of longest-match! > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5600::/56 > mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a > more-specific) > 2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a > more-specific) > ... > 2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a > more-specific) > cost: a number of more-specific to identify the mapped things; but it > won't leaked out beyond the CE. > > if the well-developed longest-match can work, why should we need another > mechanism? > > cheers, > maoke > > > >> > if Yes, how to distinguish >> > them? >> >> See above. >> >> > the figure 6 seems to me it was talking about destination IPv6 >> > address derivation. >> >> Right. >> >> >> > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support >> > harpinning between 4rd tunnel packet and native IPv6 packet? >> >> The only evolution of NAT64 to make it a NAT64+ is its use of tunneling >> instead of RFC6145 translation, for all IPv6 addresses that have the V >> octet. (No other behavior needs to be modified.) >> >> >> > Personally, I'd like NAT64+ removed from the draft. It might deserve a >> > seperate draft. >> > This way, it would make the draft more understanding >> > for readers who are new to 4rd-u. >> >> The specification has to explain conditions in which a CE can tunnel IPv= 4 >> packets although it has no assigned public IPv4 address, even shared. >> Explaining more what is NAT64+ is IMHO better than explaining less. >> >> >> > 3. Fragments. >> > The algorithm proposed in R-9, would have applied to generic NAT >> > generally. Why it is specific to 4rd BR? >> >> NATs may have to remember not only destination ports but also source >> ports. >> A similar algorithm could however apply to NAT64s, but this is off 4rd >> scope. >> >> >> > Anyway BR would keep fragment >> >> They MAY, but AFAIK don't need to if they use R-9 algorithm. >> >> > state somehow and anycase BR facing IPv4 Internet would be impossible. >> >> In the CE to BR direction, destinations are full IPv4 addresses so that >> each fragment can be individually forwarded. >> Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that >> no port-based check is needed to ensure that no CE can spoof fragments >> from another CE. >> >> >> Regards, >> RD >> >> >> >> > >> > Thanks, >> > washam >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --002354530350e8191f04bb155f66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,

2012/3/12 R=E9mi Despr=E9= s <despres= .remi@laposte.net>
Maoke,

1.
= What you call the cost of "IANA authority on the use of V-bit" is= neither a development nor an operational cost. Once standardization is don= e, the cost becomes 0.

exactly.=A0
=A0

2.
Isn't it true that MAP addresses must have the "u&quo= t; octet, i.e. 0x00, in address bits 64-71?
If yes, MAP example a= ddresses you give with 0x02 or 0x03 instead of "u", aren't AF= AIK valid MAP addresses.

oh, yes! i made the typo, falling in= to the EUI-64 case. MAP cites RFC6052 format for IID, while the latter stat= es:
"Bits 64 to 71 of the address are reserved for compatibi= lity with the
host identifier format defined in the IPv6 addressing architecture
= =A0 [RFC4291]. These bits MUST be set to zero."=A0

thanks a lot for pointing out the mistake! the corresponding exampl= e should be corrected as:

#1. shared ipv4 address
take an example = of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE= is 0xabcde567, PSID=3D8.=A0

MAP (without V-octet):
native IPv6: 2001:db8:= 1234:5678::/64
mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:000= 0/128 (as a more-specific)=A0
cost: almost none.

#2. exclusive ipv4 address
2001:db8:1234:5670::/60, IPv4 address 0xabcde567

MAP (without V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: 2001:db8:1234:5= 670:00ab:cde5:6700:0000/128 (as a more-specific)=A0
cost: almost = none.=A0

#3. exclusive ipv4 subnet
2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f
=
MAP (without V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: 2001:db8:1= 234:5600:00ab:cde5:6000:0000/128 (as a more-specific)
=A0 =A0 =A0= =A0 =A0 =A0 =A02001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a more-speci= fic)
=A0 =A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0 =A0 =A020= 01:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a more-specific)=A0
=A0
If no, please explain what I misse= d.=A0

thanks a lot!
= =A0

3.
You sa= y that=A0aggregation doesn't make sense in 4rd-u, e.g. with the followi= ng example:
- native IPv6: 2001:db8:1234:5670::/60, 0x02 for= 64-71 bit
- mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
=
But the right choice for the second line is:
- mapped IPv6:= =A02001:db8:1234:5670:3000::/72=A0

<= div> 2001:db8:1234:5670:0300::/72, right? ;-)
=A0
Thus,=A0longest ma= tch does the job.


exactly. however, my = point is: as the longest-match can do the job with V octet or without it, w= hy don't we directly use the version without it?=A0

- maoke
=A0
(What you describe is what might have applie= d if we had kept the maxPsid feature. But, as you may recall, we abandoned = it unanimously in Taipei.)

Cheers,
RD=A0


Le 2012-03-12 =E0 11:51, Maoke a =E9crit :



2012/3= /12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi, Washam,

Thanks for your detailed questions and comments.
Answers and further comments in line.

Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit :

> Hi,
>
> Eventually I get a chance to review this version and have some major > comments and questions as below.
>
> 1. Relationship with MAP, MAP-T, MAP-E.
> I thought, MAP was expected to be a generic algorithm for stateless > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > MAP would apply to MAP-T, MAP-E as well as 4rd-u.

=A0The point is that 4rd-u unifies not only the address format for -T= and -E, but also the header format so that a single standard becomes suffi= cient.
=A0The 4rd-U technique for this was presented in Taipei, but it didn't = arise interest in the MAP team. Design of 4rd-u had then to become autonomo= us.

> But draft 4rd-u-04
> doesn't mention MAP draft.

4rd-u is proposed as an alternative to the 2-standards approach of MA= P.
It therefore needs only needs a historical reference to MAP, which is done = in sec. 8.

> And I see the mapping rules stuff in the
> draft overlapped with MAP. Confused.
>
> I thought, 4rd-u is competing with MAP-T and MAP-E to some extend.
> Would you mind expaund on what benefits 4rd-u can gain exclusively? > Ideally, there would be a seperate section or even a seperate draft > for such comparison.

As announced, an update of draft-despres-softwire-stateless-analysis-= tool will contain a comparison (now to be posted very soon).

An earlier comparison table was available in
http://www.ietf.org/mail-archive/web/softwires/curr= ent/msg03442.html

In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to use = IPv6-only middle boxes for deep packet inspection and web caches; also, lik= e MAP-E, it ensures full IPv4 transparency.


> 2. NAT64+ stuff.
> My understanding, NAT64+ would translate 4rd tunnel packet as well as<= br> > native IPv6 packet to IPv4 packet and vice verse. Right?

If the NAT64 is stateful per session, yes, it does translation at lay= er 4.
NAT64s that are stateless at this layer are however also possible. THis is = independent from 4rd.

> I don't know
> what the CE delegated prefix in NAT64+ looks like.

- The delegated prefix is any prefix up to /64 that doesn't match= any CE prefix (R-6 of draft-04))
- The source of a CE to NAT64+ packet must have the V octet for NAT64+s to = be able to distinguish 4rd packets from other IPv6 packets (def of NAT64+).=
- The format is then:
+-----------------------+-------+---+-----------------+------+
| =A0 =A0CE IPv6 prefix =A0 =A0 | =A0 0 =A0 | V | =A0 =A0 =A0 =A0 =A00 =A0 = =A0 =A0| =A0CNP |
+-----------------------+-------+---+-----------------+------+
: =A0 =A0 =A0=3D< 64 =A0 =A0 =A0 =A0 =A0 =A0: =A0>=3D 0 : 8 : =A0 =A0= =A040 =A0 =A0 =A0 =A0 : =A016 =A0:


Yet, it should be clearer in the draft.
Thanks for this (good) question.


> Can the native IPv6
> and 4rd shared the same delegated prefix?

Yes. (This is the purpose of the V octet)


may i compare the V-octet w= ith the MAP strategy?

#1. shared ipv4 address
take an example of delegated prefix 2001:db8:1234:5678::/64 and the = IPv4 address for the CE is 0xabcde567, PSID=3D8.=A0

4rd-U (with V-octet):
native IPv6: 2001:db8:1= 234:5678:0200::/72
mapped IPv6: 2001:db8:1234:5678:0300::/72
cost: IANA authority on the use of V-bit.

MAP (without V-octet):
native IPv6: 2001:db8:1234:5678::/64
=
mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a more-spe= cific)=A0
cost: almost none.

#2. exclusi= ve ipv4 address
2001:db8:1234:5670::/60, IPv4 address 0xabcde567

4rd-U (with V-octet), now aggragation doesn't make sense:
native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
cost: IA= NA authority on the use of V-bit; implementation cannot take the logic of l= ongest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: 2001:db8:1234:5= 670:02ab:cde5:6700:0000/128 (as a more-specific)=A0
cost: almost = none.=A0

#3. exclusive ipv4 subnet
2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f
=
4rd-U (with V-octet), now aggragation doesn't make sense= :
native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit
cost: IANA authority on the use of V-bit; implementation cannot take the = logic of longest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: 2001:db8:1= 234:5600:02ab:cde5:6000:0000/128 (as a more-specific)
=A0 =A0 =A0= =A0 =A0 =A0 =A02001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a more-speci= fic)
=A0 =A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0 =A0 =A020= 01:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a more-specific)=A0
= cost: a number of more-specific to identify the mapped things; but it won&#= 39;t leaked out beyond the CE.=A0

if the well-developed longest-match can work, why shoul= d we need another mechanism?=A0

cheers,
= maoke

=A0
> if Yes, how to distinguish
> them?

See above.

> the figure 6 seems to me it was talking about destination IPv6
> address derivation.

Right.


> IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ suppor= t
> harpinning between 4rd tunnel packet and native IPv6 packet?

The only evolution of NAT64 to make it a NAT64+ is its use of tunneli= ng instead of RFC6145 translation, for all IPv6 addresses that have the V o= ctet. (No other behavior needs to be modified.)


> Personally, I'd like NAT64+ removed from the draft. It might deser= ve a
> seperate draft.
> This way, it would make the draft more understanding
> for readers who are new to 4rd-u.

The specification has to explain conditions in which a CE can tunnel = IPv4 packets although it has no assigned public IPv4 address, even shared.<= br> Explaining more what is NAT64+ is IMHO better than explaining less.


> 3. Fragments.
> The algorithm proposed in R-9, would have applied to generic NAT
> generally. Why it is specific to 4rd BR?

NATs may have to remember not only destination ports but also source = ports.
A similar algorithm could however apply to NAT64s, but this is off 4rd scop= e.


> Anyway BR would keep fragment

They MAY, but AFAIK don't need to if they use R-9 algorithm.

> state somehow and anycase BR facing IPv4 Internet would be impossible.=

In the CE to BR direction, destinations are full IPv4 addresses so th= at each fragment can be individually forwarded.
Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that no= port-based check is needed to =A0ensure that no CE can spoof fragments fro= m another CE.


Regards,
RD



>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--002354530350e8191f04bb155f66-- From fibrib@gmail.com Mon Mar 12 19:18:10 2012 Return-Path: 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 DB24B21F888D for ; Mon, 12 Mar 2012 19:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 atCB7UUIDv5Y for ; Mon, 12 Mar 2012 19:18:09 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6274821F8887 for ; Mon, 12 Mar 2012 19:18:09 -0700 (PDT) Received: by yhpp34 with SMTP id p34so51148yhp.31 for ; Mon, 12 Mar 2012 19:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=acCS7DX2l8g0kx6yd5zkBbEzvChKp0mu3qtTCExKC/0=; b=hCtrKFsER3MyajJkX41wZtTIV57zjo3nv2KCagiiWah0mLsGpclca7NK/ksLCopQZ/ 9bGg0Ro4xjEj9EQ1UXE4DoTS1gl1u6HcrHHKhRuKFhu5pJOV9GRC6LNSbYF7ys7Wr801 ghsb0g8+RY87I4yl0nMeMwLFMRxmMtw6MhtI1N1as1MdCQBu7/LxCCcQbOb10uT3N6aY IlkGtWahIh4eMeu0wCxTvtTMXwupm2GaDEWuvO3Fuv2bSSocSJxpe/UXI4sDJB8H0O9Z LImt3GVDpiiCFcSy6nwjAjNdfXZ9kkA15qzc5hfxNo+YIBDxg77Wa45ULyD8pDx5v1t0 /Yjg== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr3330768qct.9.1331605088815; Mon, 12 Mar 2012 19:18:08 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 12 Mar 2012 19:18:08 -0700 (PDT) In-Reply-To: <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> Date: Tue, 13 Mar 2012 02:18:08 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023545303504ccb7e04bb16781b Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:18:11 -0000 --0023545303504ccb7e04bb16781b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/12 R=E9mi Despr=E9s > Le 2012-03-12 =E0 10:21, Maoke a =E9crit : > > hi Remi, > > 2012/3/12 R=E9mi Despr=E9s > >> >> 2012-03-12 04:09, Maoke: >> ... >> > btw, BR also depends upon NAT44 to deal with the unknown protocol, >> right? if so, may i say your statement "BR will support them without >> needing an update" is a proposition actually not existing? because NAT44 >> won't support them without any update. right? >> >> Not right. Only CEs that need to support a new protocol are concerned: >> - If a shared address server supports a new protocol, it can be reached >> via an unchanged BR. >> - If a client using a new protocol tries to reach a shared-address CE >> that doesn't support this protocol, the client will be returned an error >> message by the destination NAT44. >> > > thanks a lot for the clarification! take an example: > > A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 > Internet)--- B > > now A and B are supposed to use a new protocol other than known > TCP/UDP/etc. my understanding: > B --> A > 1. BR just passes the new protocol without any concern. > 2. CE's NAT44 module would say "this is not supported and a 'destination > unreachable with port unknown' ICMP message is returned to B. > > > As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message > should be, more precisely, "protocol unreachable". > thanks for the precise description. > Everything OK. > > > > A --> B > 1. CE's NAT44 module directly say "destination unreachable with port > unknown" ICMP message to A. > > > Presumably also "protocol unreachable", but this remains a NAT44 matter. > 4rd isn't involved. > > is the above what you mean? when NAT44 module DOESN'T support the new > protocol, things are working while we have no the problem about the > "change" at all for the time being. > > then let's consider the case where the NAT44 module has been updated to > support the new protocol. i understand BR passing all protocols can be > survived if and only if the new protocol follows the TCP-layout for the > destination port and the TCP-checksum, right? > > > The 4rd mechanism is for protocols that have ports at their usual place > (all existing protocols that have ports have them at the same place, even > if using another checksum algorithm like SCTP). > > > then you made a limitation (#1) to the NAT44 module of the CE: even if th= e > NAT44 has supported a new protocol not following TCP layout/checksum, thi= s > support MUST be disabled in the 4rd-U environment; otherwise, BR may beha= ve > wrong when making the mapped IPv6 addresses while the NAT44 would still t= ry > to translate with the new protocol rather than dropping an error message > because it has known it. right? > > > To me this looks like a far fetched theoretical problem, with no > consequence in practice. > to me, new protocols following TCP-layout and checksum are a far fetched theoretical problem too, with no consequen in today's practice. i mean, it is unfair when you state the 4rd-U pros you emphasize that BR needs no change with some new protocols, but when we say some other new protocols you say that's far fetched theoretical problem! > OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate > DCCP or not is a real problem, and so is the fact that it doesn't support > UDP Lite, another already existing protocol. > i understand RFC6145 said OPTIONAL supporting DCCP just because it was considered less critical at that point of writing (may the authors give an explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with the same reason. implementation and operation can follow the RFC6145 logic to deal with any L4 protocols. on the other hand, it is easy to update RFC6145 or just making a suggestion anywhere, like a FYI on double-translation behavior of RFC6145, with clarifying DCCP *optional* support should be consistent throughout the domain and clarifying other unmentioned L4 protocol processing should follow the protocol's checksum logic that is specified. i don't see it is necessary to enforcing the address-level checksum neutrality rather than such a simple update or implementation/deployment guidance. it is surely fine technically that we enforce that. no problem. but if it is so necessary? here i have a point regarding the implementation/deployment: if the address mapping and header processing are decoupled, the things would be happier than a solution making them tightly coupled. MAP is made in such a fashion, where header processing could follow either encapsulation standard or translation standard. RFC6145 is made in such a way, where addresses could follow stateless mapping in RFC6052 or processed with state as in RFC6146, and now it is also fine with MAP. such a decoupling property makes implementation modularized and the operators may have better flexibility of choice. in the term of decoupling, surely we have two choices: 1) making address format checksum-neutral, suitable for either with L4 recalculation or without. 2) making L4 recalculation, suitable for either addresses are checksum-neutral or aren't. RFC6052 explains why the authors gave up the CNP in the address and choose 2). i also have an understanding that 2) is a solution in implementation, once distributed, not easy to modify; while 1) is a solution in deployment, easy to change at any time. for example, if our equipment is made with RFC6145, the same equipment can be used in either RFC6052, or MAP, or 4rd-U address-mapping environment, but if our equipment is made with 4rd-U, we must only use it in 4rd-U environment. once we find we need to try something others, we have to buy new equipment, which means cost. > > further (#2), what if the packets don't pass through the NAT44 module at > all (in the case of non-shared IPv4 addresses)? > > > In case of non shared addresses, neither BRs nor CEs look at any port > field (there in no PSID to be found). > thanks. then (#2) is not a limitation. my mis. then the behavior of a new protocol (of the far fetched theoretical case, where non-tcp-layout/checksum is applied) would be very tricky: #2.1 address shared while NAT doesn't support the new protocol =3D> dropped at NAT44, possibly not the correct NAT44 though; #2.2 address shared while NAT does support the new protocol =3D> not droppe= d but it is possible to be incorrectly delivered because BR may take wrong value for the port; #2.3 address not shared =3D> passes to the end systems. correct understanding? > > please clarify if the limitation of (#1) and (#2) are true or false. > > > Answered above. > > > i believe with requiring L4 modification, either MAP or RFC6145 has no > such two limitations: enforcing the checksum update at L4, their framewor= k > is safe for either TCP-layout/checksum or alien-layout/checksum, either > shared or exclusive IPv4 addresses. > > > This remains AFAIK a belief that ignores DCCP and UDP Lite limitations of > RFC6145. > > see above. cheers, maoke > > i worry the CNP is making a situation of "cutting feet to fit the shoes". > > > Hopefully, you will see that no such worry is justified. > > > Cheers, > RD > > > > > > - maoke > > >> >> RD >> >> >> > > --0023545303504ccb7e04bb16781b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Le 2012-03-12 =E0 10:21, Maok= e a =E9crit :

hi Remi,=

2012/3/12 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the unknown protocol= , right? if so, may i say your statement "BR will support them without= needing an update" is a proposition actually not existing? because NA= T44 won't support them without any update. right?

Not right. Only CEs that need to support a new protocol are concerned= :
- If a shared address server supports a new protocol, it can be reached via= an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE that = doesn't support this protocol, the client will be returned an error mes= sage by the destination NAT44.

thanks a= lot for the clarification! take an example:=A0

=A0A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- B= R ---(IPv4 Internet)--- B

now A and B are supposed= to use a new protocol other than known TCP/UDP/etc. my understanding:
B --> A
1. BR just passes the new protocol without any co= ncern.
2. CE's NAT44 module would say "this is not suppo= rted and a 'destination unreachable with port unknown' ICMP message= is returned to B.

As now documented in 4rd-u-05 in th= e NOTE of 4.4 (3), the error message should be, more precisely, "proto= col unreachable".

thanks f= or the precise description.=A0
=A0
Everything OK.



A --> B
1. CE's NAT44 module directly say "desti= nation unreachable with port unknown" ICMP message to A.

Presumably also=A0"protocol unreachabl= e", but this remains a NAT44 matter. 4rd isn't involved.

is the above what you mean? when NAT44 module DOESN'T support= the new protocol, things are working while we have no the problem about th= e "change" at all for the time being.=A0

then let's consider the case where the NAT44 module= has been updated to support the new protocol. i understand BR passing all = protocols can be survived if and only if the new protocol follows the TCP-l= ayout for the destination port and the TCP-checksum, right?=A0

The 4rd mechanism is for proto= cols that have ports at their usual place (all existing protocols that have= ports have them at the same place, even if using another checksum algorith= m like SCTP).
=A0

then you made a limitation (#1) to the NAT44 module of the CE: even if= the NAT44 has supported a new protocol not following TCP layout/checksum, = this support MUST be disabled in the 4rd-U environment; otherwise, BR may b= ehave wrong when making the mapped IPv6 addresses while the NAT44 would sti= ll try to translate with the new protocol rather than dropping an error mes= sage because it has known it. right?=A0

To me this looks like a far fetched= theoretical problem, with no consequence in practice.

to me, new protocols following TCP-layout and check= sum are a far fetched theoretical problem too, with no consequen in today&#= 39;s practice. i mean, it is unfair when you state the 4rd-U pros you empha= size that BR needs no change with some new protocols, but when we say some = other new protocols you say that's far fetched theoretical problem!=A0<= /div>
=A0
OTOH, the fact that RFC6145 doesn't tell you whether you MUS= T translate DCCP or not is a real problem, and so is the fact that it doesn= 't support UDP Lite, another already existing protocol. =A0

i understand RFC6145 said OPTIONAL s= upporting DCCP just because it was considered less critical at that point o= f writing (may the authors give an explanation?). UDP-Lite was not mentione= d in RFC6145 then, i think, with the same reason. implementation and operat= ion can follow the RFC6145 logic to deal with any L4 protocols. on the othe= r hand, it is easy to update RFC6145 or just making a suggestion anywhere, = like a FYI on double-translation behavior of RFC6145, with clarifying DCCP = *optional* support should be consistent throughout the domain and clarifyin= g other unmentioned L4 protocol processing should follow the protocol's= checksum logic that is specified.

i don't see it is necessary to enforcing the addres= s-level checksum neutrality rather than such a simple update or implementat= ion/deployment guidance.=A0

it is surely fine tech= nically that we enforce that. no problem. but if it is so necessary? here i= have a point regarding the implementation/deployment: if the address mappi= ng and header processing are decoupled, the things would be happier than a = solution making them tightly coupled. MAP is made in such a fashion, where = header processing could follow either encapsulation standard or translation= standard. RFC6145 is made in such a way, where addresses could follow stat= eless mapping in RFC6052 or processed with state as in RFC6146, and now it = is also fine with MAP. such a decoupling property makes implementation modu= larized and the operators may have better flexibility of choice.=A0

in the term of decoupling, surely we have two choices:<= /div>
1) making address format checksum-neutral, suitable for either wi= th L4 recalculation or without.=A0
2) making L4 recalculation, su= itable for either addresses are checksum-neutral or aren't.=A0

RFC6052 explains why the authors gave up the CNP in the= address and choose 2). i also have an understanding that 2) is a solution = in implementation, once distributed, not easy to modify; while 1) is a solu= tion in deployment, easy to change at any time. for example, if our equipme= nt is made with RFC6145, the same equipment can be used in either RFC6052, = or MAP, or 4rd-U address-mapping environment, but if our equipment is made = with 4rd-U, we must only use it in 4rd-U environment. once we find we need = to try something others, we have to buy new equipment, which means cost.=A0=
=A0

further (#2), what if the packets don't pass through the NAT44 mod= ule at all (in the case of non-shared IPv4 addresses)?=A0

In case of non shared addresses, neither B= Rs nor CEs look at any port field (there in no PSID to be found).

thanks. then (#2) is not a lim= itation. my mis.=A0

then the behavior of a new pro= tocol (of the far fetched theoretical case, where non-tcp-layout/checksum i= s applied) would be very tricky:
#2.1 address shared while NAT doesn't support the new protocol =3D= > dropped at NAT44, possibly not the correct NAT44 though;=A0
= #2.2 address shared while NAT does support the new protocol =3D> not dro= pped but it is possible to be incorrectly delivered because BR may take wro= ng value for the port;=A0
#2.3 address not shared =3D> passes to the end systems.=A0

correct understanding?
=A0

please clarify if the limitat= ion of (#1) and (#2) are true or false.

<= /div>
Answered above.


i believe with requirin= g L4 modification, either MAP or RFC6145 has no such two limitations: enfor= cing the checksum update at L4, their framework is safe for either TCP-layo= ut/checksum or alien-layout/checksum, either shared or exclusive IPv4 addre= sses.

This remains AFAIK a belief that ig= nores DCCP and UDP Lite limitations of RFC6145.

<= /blockquote>

see above.=A0

chee= rs,
maoke
=A0

=
i worry the CNP is making a situation of "cutting feet to fit the= shoes".=A0

Hopefull= y, you will see that no such worry is justified.


Cheers,
RD





- maoke
=A0

RD





--0023545303504ccb7e04bb16781b-- From despres.remi@laposte.net Tue Mar 13 01:34:00 2012 Return-Path: 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 7E1B921F8609 for ; Tue, 13 Mar 2012 01:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.065, 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 YCkipVUHKo09 for ; Tue, 13 Mar 2012 01:33:56 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC5721F8602 for ; Tue, 13 Mar 2012 01:33:54 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id kwZs1i00B37Y3f403wZshS; Tue, 13 Mar 2012 09:33:53 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-110--1014369430 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 13 Mar 2012 09:33:52 +0100 Message-Id: <3E3DC09D-37FF-4748-99FD-007B268DD26A@laposte.net> References: <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> <62F71361-3110-4069-B186-915003CD986B@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Comments on 4rd-u-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 08:34:01 -0000 --Apple-Mail-110--1014369430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-13 =E0 01:59, Maoke a =E9crit : > hi Remi, >=20 > 2012/3/12 R=E9mi Despr=E9s > Maoke, >=20 > 1. > What you call the cost of "IANA authority on the use of V-bit" is = neither a development nor an operational cost. Once standardization is = done, the cost becomes 0. >=20 > exactly.=20 > =20 >=20 > 2. > Isn't it true that MAP addresses must have the "u" octet, i.e. 0x00, = in address bits 64-71? > If yes, MAP example addresses you give with 0x02 or 0x03 instead of = "u", aren't AFAIK valid MAP addresses. >=20 > oh, yes! i made the typo, falling into the EUI-64 case. MAP cites = RFC6052 format for IID, while the latter states: > "Bits 64 to 71 of the address are reserved for compatibility with the > host identifier format defined in the IPv6 addressing architecture > [RFC4291]. These bits MUST be set to zero."=20 >=20 > thanks a lot for pointing out the mistake! the corresponding example = should be corrected as: >=20 > #1. shared ipv4 address > take an example of delegated prefix 2001:db8:1234:5678::/64 and the = IPv4 address for the CE is 0xabcde567, PSID=3D8.=20 >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5678::/64 > mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a = more-specific)=20 > cost: almost none. >=20 > #2. exclusive ipv4 address > 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5670::/60 > mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a = more-specific)=20 > cost: almost none.=20 >=20 > #3. exclusive ipv4 subnet > 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f >=20 > MAP (without V-octet): > native IPv6: 2001:db8:1234:5600::/56 > mapped IPv6: 2001:db8:1234:5600:00ab:cde5:6000:0000/128 (as a = more-specific) > 2001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a = more-specific) > ... > 2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a = more-specific)=20 > =20 > If no, please explain what I missed.=20 >=20 > thanks a lot! > =20 >=20 > 3. > You say that aggregation doesn't make sense in 4rd-u, e.g. with the = following example: > - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > But the right choice for the second line is: > - mapped IPv6: 2001:db8:1234:5670:3000::/72=20 >=20 > 2001:db8:1234:5670:0300::/72, right? ;-) Right ;-). > =20 > Thus, longest match does the job. >=20 >=20 > exactly. however, my point is: as the longest-match can do the job = with V octet or without it, why don't we directly use the version = without it?=20 That's a very different question, answered in sec 4.4 (6) of the draft: "NOTE: The V octet is a 4rd-specific mark. Its function is to ensure = that 4rd does not interfere with the choice of subnet prefixes in CE = sites. For this, the V octet has its "u" and "g" bits of both set to 1. This differs from "u" =3D 0, = reserved for local-scope Interface IDs, and also differs from "u" =3D 1 = and "g"=3D 0, reserved for unicast Interface IDs using the EUI-64 = format. Bits other than "u" and "g", are proposed to be 0, giving V =3D = 0x03.=20 With the V octet, IPv6 packets can be routed to the 4rd function within = a CE node based on a /80 prefix that no native-IPv6 address can contain.=20= The V octet can also facilitate maintenance by the parameterless = distinction it introduces between Tunnel packets and native-IPv6 = packets. A tunnel packet has at least one of its IPv6 addresses having = the V octet."=20 Cheers, RD >=20 > - maoke > =20 > (What you describe is what might have applied if we had kept the = maxPsid feature. But, as you may recall, we abandoned it unanimously in = Taipei.) >=20 > Cheers, > RD=20 >=20 >=20 > Le 2012-03-12 =E0 11:51, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/12 R=E9mi Despr=E9s >> Hi, Washam, >>=20 >> Thanks for your detailed questions and comments. >> Answers and further comments in line. >>=20 >> Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit : >>=20 >> > Hi, >> > >> > Eventually I get a chance to review this version and have some = major >> > comments and questions as below. >> > >> > 1. Relationship with MAP, MAP-T, MAP-E. >> > I thought, MAP was expected to be a generic algorithm for stateless >> > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, >> > MAP would apply to MAP-T, MAP-E as well as 4rd-u. >>=20 >> The point is that 4rd-u unifies not only the address format for -T = and -E, but also the header format so that a single standard becomes = sufficient. >> The 4rd-U technique for this was presented in Taipei, but it didn't = arise interest in the MAP team. Design of 4rd-u had then to become = autonomous. >>=20 >> > But draft 4rd-u-04 >> > doesn't mention MAP draft. >>=20 >> 4rd-u is proposed as an alternative to the 2-standards approach of = MAP. >> It therefore needs only needs a historical reference to MAP, which is = done in sec. 8. >>=20 >> > And I see the mapping rules stuff in the >> > draft overlapped with MAP. Confused. >> > >> > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. >> > Would you mind expaund on what benefits 4rd-u can gain exclusively? >> > Ideally, there would be a seperate section or even a seperate draft >> > for such comparison. >>=20 >> As announced, an update of = draft-despres-softwire-stateless-analysis-tool will contain a comparison = (now to be posted very soon). >>=20 >> An earlier comparison table was available in >> http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html >>=20 >> In any case, the main benefit is simple: 4rd-U permits, like MAP-T, = to use IPv6-only middle boxes for deep packet inspection and web caches; = also, like MAP-E, it ensures full IPv4 transparency. >>=20 >>=20 >> > 2. NAT64+ stuff. >> > My understanding, NAT64+ would translate 4rd tunnel packet as well = as >> > native IPv6 packet to IPv4 packet and vice verse. Right? >>=20 >> If the NAT64 is stateful per session, yes, it does translation at = layer 4. >> NAT64s that are stateless at this layer are however also possible. = THis is independent from 4rd. >>=20 >> > I don't know >> > what the CE delegated prefix in NAT64+ looks like. >>=20 >> - The delegated prefix is any prefix up to /64 that doesn't match any = CE prefix (R-6 of draft-04)) >> - The source of a CE to NAT64+ packet must have the V octet for = NAT64+s to be able to distinguish 4rd packets from other IPv6 packets = (def of NAT64+). >> - The format is then: >> +-----------------------+-------+---+-----------------+------+ >> | CE IPv6 prefix | 0 | V | 0 | CNP | >> +-----------------------+-------+---+-----------------+------+ >> : =3D< 64 : >=3D 0 : 8 : 40 : 16 : >>=20 >>=20 >> Yet, it should be clearer in the draft. >> Thanks for this (good) question. >>=20 >>=20 >> > Can the native IPv6 >> > and 4rd shared the same delegated prefix? >>=20 >> Yes. (This is the purpose of the V octet) >>=20 >>=20 >> may i compare the V-octet with the MAP strategy? >>=20 >> #1. shared ipv4 address >> take an example of delegated prefix 2001:db8:1234:5678::/64 and the = IPv4 address for the CE is 0xabcde567, PSID=3D8.=20 >>=20 >> 4rd-U (with V-octet): >> native IPv6: 2001:db8:1234:5678:0200::/72 >> mapped IPv6: 2001:db8:1234:5678:0300::/72 >> cost: IANA authority on the use of V-bit. >>=20 >> MAP (without V-octet): >> native IPv6: 2001:db8:1234:5678::/64 >> mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a = more-specific)=20 >> cost: almost none. >>=20 >> #2. exclusive ipv4 address >> 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 >>=20 >> 4rd-U (with V-octet), now aggragation doesn't make sense: >> native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit >> mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit >> cost: IANA authority on the use of V-bit; implementation cannot take = the logic of longest-match! >>=20 >> MAP (without V-octet): >> native IPv6: 2001:db8:1234:5670::/60 >> mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a = more-specific)=20 >> cost: almost none.=20 >>=20 >> #3. exclusive ipv4 subnet >> 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f >>=20 >> 4rd-U (with V-octet), now aggragation doesn't make sense: >> native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit >> mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit >> cost: IANA authority on the use of V-bit; implementation cannot take = the logic of longest-match! >>=20 >> MAP (without V-octet): >> native IPv6: 2001:db8:1234:5600::/56 >> mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a = more-specific) >> 2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a = more-specific) >> ... >> 2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a = more-specific)=20 >> cost: a number of more-specific to identify the mapped things; but it = won't leaked out beyond the CE.=20 >>=20 >> if the well-developed longest-match can work, why should we need = another mechanism?=20 >>=20 >> cheers, >> maoke >>=20 >> =20 >> > if Yes, how to distinguish >> > them? >>=20 >> See above. >>=20 >> > the figure 6 seems to me it was talking about destination IPv6 >> > address derivation. >>=20 >> Right. >>=20 >>=20 >> > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support >> > harpinning between 4rd tunnel packet and native IPv6 packet? >>=20 >> The only evolution of NAT64 to make it a NAT64+ is its use of = tunneling instead of RFC6145 translation, for all IPv6 addresses that = have the V octet. (No other behavior needs to be modified.) >>=20 >>=20 >> > Personally, I'd like NAT64+ removed from the draft. It might = deserve a >> > seperate draft. >> > This way, it would make the draft more understanding >> > for readers who are new to 4rd-u. >>=20 >> The specification has to explain conditions in which a CE can tunnel = IPv4 packets although it has no assigned public IPv4 address, even = shared. >> Explaining more what is NAT64+ is IMHO better than explaining less. >>=20 >>=20 >> > 3. Fragments. >> > The algorithm proposed in R-9, would have applied to generic NAT >> > generally. Why it is specific to 4rd BR? >>=20 >> NATs may have to remember not only destination ports but also source = ports. >> A similar algorithm could however apply to NAT64s, but this is off = 4rd scope. >>=20 >>=20 >> > Anyway BR would keep fragment >>=20 >> They MAY, but AFAIK don't need to if they use R-9 algorithm. >>=20 >> > state somehow and anycase BR facing IPv4 Internet would be = impossible. >>=20 >> In the CE to BR direction, destinations are full IPv4 addresses so = that each fragment can be individually forwarded. >> Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so = that no port-based check is needed to ensure that no CE can spoof = fragments from another CE. >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> > >> > Thanks, >> > washam >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-110--1014369430 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi = Remi,

2012/3/12 R=E9mi Despr=E9s = <despres.remi@laposte.net><= /span>
Maoke,

1.
What= you call the cost of "IANA authority on the use of V-bit" is neither a = development nor an operational cost. Once standardization is done, the = cost becomes 0.
=

exactly. 
 

2.
Isn't it true that MAP addresses must have the "u" octet, = i.e. 0x00, in address bits 64-71?
If yes, MAP example = addresses you give with 0x02 or 0x03 instead of "u", aren't AFAIK valid = MAP addresses.

oh, yes! i made the typo, falling = into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter = states:
"Bits 64 to 71 of the address are reserved for = compatibility with the
host identifier format defined in the IPv6 addressing = architecture
  [RFC4291]. These bits MUST be set to = zero." 

thanks a lot for pointing out the = mistake! the corresponding example should be corrected as:

#1. shared ipv4 address
take an = example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address = for the CE is 0xabcde567, PSID=3D8. 

MAP (without V-octet):
native IPv6: = 2001:db8:1234:5678::/64
mapped IPv6: = 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a = more-specific) 
cost: almost none.

#2. exclusive ipv4 address
2001:db8:1234:5670::/60, IPv4 address = 0xabcde567

MAP (without = V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: = 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a = more-specific) 
cost: almost = none. 

#3. exclusive ipv4 = subnet
2001:db8:1234:5600::/56, IPv4 address = 0xabcde560~0xabcde56f

MAP (without = V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: = 2001:db8:1234:5600:00ab:cde5:6000:0000/128 (as a = more-specific)
            =  2001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a = more-specific)
            =  ...
            =  2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a = more-specific) 
 
If no, please explain what I = missed. 

thanks a = lot!
 

3.
You = say that aggregation doesn't make sense in 4rd-u, e.g. with the = following example:
- native IPv6: = 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
- mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 = bit
But the right choice for the second line = is:
- mapped = IPv6: 2001:db8:1234:5670:3000::/72 

2001:db8:1234:5670:0300::/72, right? = ;-)

Right = ;-).


 
Thus, longest match does the = job.


exactly. however, = my point is: as the longest-match can do the job with V octet or without = it, why don't we directly use the version without = it? 

That's a very = different question, answered in sec 4.4 (6) of the = draft:

"NOTE: The V octet is a 4rd-specific = mark. Its function is to ensure that 4rd does not interfere with the = choice of subnet prefixes in CE sites. For this, the V octet has its "u" = and "g" bits of <xref target=3D"RFC4291"/> both set to 1. This = differs from "u" =3D 0, reserved for local-scope Interface IDs, and also = differs from "u" =3D 1 and "g"=3D 0, reserved for unicast Interface IDs = using the EUI-64 format. Bits other than "u" and "g", are proposed to be = 0, giving V =3D 0x03. 
 With the V octet, IPv6 = packets can be routed to the 4rd function within a CE node based on a = /80 prefix that no native-IPv6 address can = contain. 
 The V octet can also facilitate = maintenance by the parameterless distinction it introduces between = Tunnel packets and native-IPv6 packets. A tunnel packet has at least one = of its IPv6 addresses having the V = octet." 

Cheers,
RD

=



- maoke
 
(What = you describe is what might have applied if we had kept the maxPsid = feature. But, as you may recall, we abandoned it unanimously in = Taipei.)
=

Cheers,
RD 

Le 2012-03-12 =E0 11:51, Maoke a =E9crit :



2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi, Washam,

Thanks for your detailed questions and comments.
Answers and further comments in line.

Le 2012-03-11 =E0 10:48, Washam Fan a =E9crit :

> Hi,
>
> Eventually I get a chance to review this version and have some = major
> comments and questions as below.
>
> 1. Relationship with MAP, MAP-T, MAP-E.
> I thought, MAP was expected to be a generic algorithm for = stateless
> mapping IPv4 addresses to IPv6 addresses and vice versa. I = thought,
> MAP would apply to MAP-T, MAP-E as well as 4rd-u.

 The point is that 4rd-u unifies not only the address format = for -T and -E, but also the header format so that a single standard = becomes sufficient.
 The 4rd-U technique for this was presented in Taipei, but it = didn't arise interest in the MAP team. Design of 4rd-u had then to = become autonomous.

> But draft 4rd-u-04
> doesn't mention MAP draft.

4rd-u is proposed as an alternative to the 2-standards approach of = MAP.
It therefore needs only needs a historical reference to MAP, which is = done in sec. 8.

> And I see the mapping rules stuff in the
> draft overlapped with MAP. Confused.
>
> I thought, 4rd-u is competing with MAP-T and MAP-E to some = extend.
> Would you mind expaund on what benefits 4rd-u can gain = exclusively?
> Ideally, there would be a seperate section or even a seperate = draft
> for such comparison.

As announced, an update of = draft-despres-softwire-stateless-analysis-tool will contain a comparison = (now to be posted very soon).

An earlier comparison table was available in
http://www.ietf.org/mail-archive/web/softwires/current/m= sg03442.html

In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to = use IPv6-only middle boxes for deep packet inspection and web caches; = also, like MAP-E, it ensures full IPv4 transparency.


> 2. NAT64+ stuff.
> My understanding, NAT64+ would translate 4rd tunnel packet as well = as
> native IPv6 packet to IPv4 packet and vice verse. Right?

If the NAT64 is stateful per session, yes, it does translation at = layer 4.
NAT64s that are stateless at this layer are however also possible. THis = is independent from 4rd.

> I don't know
> what the CE delegated prefix in NAT64+ looks like.

- The delegated prefix is any prefix up to /64 that doesn't match = any CE prefix (R-6 of draft-04))
- The source of a CE to NAT64+ packet must have the V octet for NAT64+s = to be able to distinguish 4rd packets from other IPv6 packets (def of = NAT64+).
- The format is then:
+-----------------------+-------+---+-----------------+------+
|    CE IPv6 prefix     |   0   | V | =          0      |  CNP = |
+-----------------------+-------+---+-----------------+------+
:      =3D< 64           =  :  >=3D 0 : 8 :      40     =     :  16  :


Yet, it should be clearer in the draft.
Thanks for this (good) question.


> Can the native IPv6
> and 4rd shared the same delegated prefix?

Yes. (This is the purpose of the V octet)


may i compare the = V-octet with the MAP strategy?

#1. shared ipv4 = address
take an example of delegated prefix = 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, = PSID=3D8. 

4rd-U (with V-octet):
native IPv6: = 2001:db8:1234:5678:0200::/72
mapped IPv6: = 2001:db8:1234:5678:0300::/72
cost: IANA authority on the use = of V-bit.

MAP (without V-octet):
native IPv6: = 2001:db8:1234:5678::/64
mapped IPv6: = 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a = more-specific) 
cost: almost = none.

#2. exclusive ipv4 address
2001:db8:1234:5670::/60, IPv4 address = 0xabcde567

4rd-U (with V-octet), now = aggragation doesn't make sense:
native IPv6: = 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
cost: = IANA authority on the use of V-bit; implementation cannot take the logic = of longest-match!

MAP (without = V-octet):
native IPv6: 2001:db8:1234:5670::/60
mapped IPv6: = 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a = more-specific) 
cost: almost = none. 

#3. exclusive ipv4 = subnet
2001:db8:1234:5600::/56, IPv4 address = 0xabcde560~0xabcde56f

4rd-U (with = V-octet), now aggragation doesn't make sense:
native IPv6: = 2001:db8:1234:5600::/60, 0x02 for 64-71 bit
mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 = bit
cost: IANA authority on the use of V-bit; = implementation cannot take the logic of = longest-match!

MAP (without V-octet):
native IPv6: 2001:db8:1234:5600::/56
mapped IPv6: = 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a = more-specific)
            =  2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a = more-specific)
            =  ...
            =  2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a = more-specific) 
cost: a number of more-specific to = identify the mapped things; but it won't leaked out beyond the = CE. 

if the well-developed longest-match can work, why = should we need another = mechanism? 

cheers,
maoke

 
> if Yes, how to distinguish
> them?

See above.

> the figure 6 seems to me it was talking about destination IPv6
> address derivation.

Right.


> IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ = support
> harpinning between 4rd tunnel packet and native IPv6 packet?

The only evolution of NAT64 to make it a NAT64+ is its use of = tunneling instead of RFC6145 translation, for all IPv6 addresses that = have the V octet. (No other behavior needs to be modified.)


> Personally, I'd like NAT64+ removed from the draft. It might = deserve a
> seperate draft.
> This way, it would make the draft more understanding
> for readers who are new to 4rd-u.

The specification has to explain conditions in which a CE can = tunnel IPv4 packets although it has no assigned public IPv4 address, = even shared.
Explaining more what is NAT64+ is IMHO better than explaining less.


> 3. Fragments.
> The algorithm proposed in R-9, would have applied to generic = NAT
> generally. Why it is specific to 4rd BR?

NATs may have to remember not only destination ports but also = source ports.
A similar algorithm could however apply to NAT64s, but this is off 4rd = scope.


> Anyway BR would keep fragment

They MAY, but AFAIK don't need to if they use R-9 algorithm.

> state somehow and anycase BR facing IPv4 Internet would be = impossible.

In the CE to BR direction, destinations are full IPv4 addresses so = that each fragment can be individually forwarded.
Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that = no port-based check is needed to  ensure that no CE can spoof = fragments from another CE.


Regards,
RD



>
> Thanks,
> washam
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-110--1014369430-- From fibrib@gmail.com Tue Mar 13 02:53:28 2012 Return-Path: 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 5AFE821F87AA for ; Tue, 13 Mar 2012 02:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 cLm0jqQlvOXW for ; Tue, 13 Mar 2012 02:53:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC121F86D7 for ; Tue, 13 Mar 2012 02:53:26 -0700 (PDT) Received: by ghbg16 with SMTP id g16so377754ghb.31 for ; Tue, 13 Mar 2012 02:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qV6QbI31R+zWQr+e3j9rp3DIMKVNbDh+ugKdyfwz08k=; b=L+kX3OrguXYzpLmv8hqht7iHiA/Wc7VmZXxGs7YMkY2CGgBz7q6Mw8Z+y3wndWp0Pu S39oohVREQ98udxyqGyTq1gv5InPP8jl1UunfKD/J4VGMuMHQ76IGnx9PypEt/3Eh13b SPZYC9Blcr8lbjLzNjp0/9L1X+EcWoomsRZftSEWxLaX7fkNEl33rreTdXnb/iCH4WTT s/CV/kYPbCW7XM3l2V4u5GnXPak1QM4sW9T+k5a/o/+RzlptUIk67wKMBXBJef8l1IxE EvvtMMywWQAs5buFn6Kbt/kghFNx5kzdadXp4DHF2mY2ChZmXh7B8OP/8FlRn8lTGriR wYfA== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr12332688qab.39.1331632406108; Tue, 13 Mar 2012 02:53:26 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Tue, 13 Mar 2012 02:53:26 -0700 (PDT) In-Reply-To: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> Date: Tue, 13 Mar 2012 09:53:26 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47e8999e104bb1cd4fe Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 09:53:28 -0000 --20cf3074b47e8999e104bb1cd4fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, discussion on R-16 of Sec 4.7: > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet > MUST contain the first 8 octets of the discarded-packet IP > payload. now the ICMPv6 error message contains the payload as the "header-mapped" IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translates this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP doesn't help) if it does, you'd better cite RFC6145 here. if it doesn't, please specify. > If the CE or BR has a global IPv4 address, this > address MUST be used as source of this packet. Otherwise, the > unspecified address 0.0.0.0 SHOULD be used as this source. let me draw an example for that: A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B 1. consider ICMPv6 error happens at R1 original IPv4 packet at A, sent to B: +---------+----------------------------------------------+ | IPv4 | payload | | hdr, H1 | P1 | +---------+----------------------------------------------+ CE translates (precisely speaking, "header-maps") it to: +------------+----------------------------------------------+ | IPv6 | payload | | header, H2 | P1 | +------------+----------------------------------------------+ R1 found a error for this IPv6 packet, it generates an ICMPv6 report: +------------+--------+-----------+-------------------------+ | IPv6 | ICMPv6 | IPv6 | payload (truncated to | | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | +------------+--------+-----------+-------------------------+ \_______________ ___________________/ V as the ICMPv6 error message body this message feedbacked to CE, who will translate it to: +---------+--------+--------+--------------+ | IPv4 | ICMPv4 | IPv4 | truncated | | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | +---------+--------+--------+--------------+ |<- 8 octet ->| \__________ __________/ V as the ICMPv4 error message body it is clear that 4rd-U address mapping is applied for H1 -> H2 -> H4 H3 has the source address of R1 while the destination address as the CE. then, CE's (or BR's for the case of B --> A) global IPv4 address or 0.0.0.0 will be used in H5, right? first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address represents either a host not yet having gained an IPv4 address on the LOCAL network or an application listening on any addresses of a host. packet with 0.0.0.0 might be dropped by any intermediate routers of current implementations. > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unreachable, No > route to destination") MUST be translated into ICMPv4 Type =3D 3 > and Code =3D 0 (Destination unreachable, Net unreachable). > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit > exceeded in transit) MUST be translated into ICMPv4 Type =3D 11 > and Code =3D 0 (Time exceeded, Time to live exceeded in > transit). for C1 -> C2 translation, i have the following comments: 1) here 4rd-U uses the CE's global IPv4 address (i think "global" refers to a non-shared one, right?) to represent all the error generator inside in the IPv6 domain. this surely fits a "tunnel" behavior that attempts to treat the delivery from CE to BR as a "link", and therefore the error is responded by the link's end point. 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit exceeded and ICMPv6 unreachable node should be translated as ICMPv4 destination unreachable (Type =3D 3) host unreachable (Code =3D 1), because= it should indicates the link problem of the tunnel. 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a typical behavior of path participant rather than a "tunnel". the difference of the tunnel and the path participant is: the latter consumes the TTL per physical hop. for example, if we set TTL =3D 32 in H1, tunneling means from= A to B communication may succeed as long as (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well connected; while current 4rd-U means from A to B communication may succeed only when total numbers of intermediate routers doesn't exceed 31. this is why typical tunneling solutions initialize the out-header's IPv6 Hop Limit to 255. when routing loop happens in the IPv6 domain and Hop Limit is consumed out, the link is considered broken. 2. consider ICMPv4 error happens at R2: R2 sees original IPv4 packet at A, sent to B: +---------+----------------------------------------------+ | IPv4 | payload | | hdr, H1 | P1 | +---------+----------------------------------------------+ R2 has found some error with that packet, issuing an ICMPv4 message and sending to A: +---------+--------+--------+--------------+ | IPv4 | ICMPv4 | IPv4 | truncated | | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | +---------+--------+--------+--------------+ |<- 8 octet ->| \__________ __________/ V as the ICMPv4 error message body 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): +------------+--------+--------+--------------+ | IPv6 | ICMPv4 | IPv4 | truncated | | header, H7 | hdr, C3| hdr, H1| payload, P3 | +------------+--------+--------+--------------+ woops, unfortunately, R1 also found something wrong. R1 generates an ICMPv6 report, responding back to B: +------------+--------+------------+--------+--------+--------------+ | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | +------------+--------+------------+--------+--------+--------------+ BR sees this and makes translation to: +---------+--------+---------+--------+--------+------------+ | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| +---------+--------+---------+--------+--------+------------+ |<------- 8 octet ----------->| \___________________ __________________/ V as the ICMPv4 error message body here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. here 4rd-U can have two options: 1) let it be but depends on the IPv4 Internet routers, or host B itself to drop the ICMP of ICMP; 2) actively check the header in the ICMPv4 message body (H9 above) and identify if the protocol of the discard-packet is ICMPv4 too; if so, BR drops the packet. i doubt either is good. anyway, no matter which is used, 4rd-U must deal with this issue. (sorry if i missed some text where it has been done.) cheers, maoke 2012/3/12 R=E9mi Despr=E9s > Hello, all, > > An updated version of draft-despres-softwire-4rd-u is now available at > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 > > Differences with -04 include: > - DHCPv6 options are now specified > - various errors and typos are corrected > - some clarifications are added, following received questions and comment= s > - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and > within CPEs) > - An editor's note has been added, following a WG-ML discussion, about an > additional Mapping-rule parameter that might be needed to assign privileg= ed > ports to to some shared-address CEs. > - Document layout has been adjusted as a result of other modifications. > - the authors list has been completed. > > Questions and comments are most welcome. > > Regards, > RD > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b47e8999e104bb1cd4fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,=A0

discussion on R-16 of Sec 4.7:

=A0 > R-16: If a CE or BR receives an ICMPv6 er= ror message [RFC4443], it
=A0 > MUST synthesize an ICMPv4 erro= r packet [RFC0792]. This packet
=A0 > MUST contain the first 8 octets of the discarded-packet IP=
=A0 > payload.

now the ICMPv6 err= or message contains the payload as the "header-mapped" IPv6 PDU o= f the discarded packet. right? so does 4rd-U CE or BR translates this ICMPv= 6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies the checksu= m adjustment algorithm between ICMPv6 and ICMPv4 here, as the RFC6145 does?= (for ICMP, the CNP doesn't help)

if it does, you'd better cite RFC6145 here. if it d= oesn't, please specify.=A0

=A0 > If the CE = or BR has a global IPv4 address, this
=A0 > address MUST be u= sed as source of this packet. Otherwise, the
=A0 > unspecified address 0.0.0.0 SHOULD be used as this source.=

let me draw an example for that:

A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Intern= et; router R2 here)--- B

1. consider ICMPv6 error happens at R1

original IPv4 packet at A, sent to B:
+---------+-------= ---------------------------------------+
| IPv4 =A0 =A0| payload = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

CE translates (precisel= y speaking, "header-maps") it to:=A0
+------------+----------------------------------------------+
| IPv6 =A0=A0 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| header, H2 | P1 =A0=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0|
+------------+----------------------------------------------+

R1 found a error for this IPv6 packet, it generates an ICM= Pv6 report:
+------------+--------+-----------+-------------= ------------+
| IPv6 =A0=A0 =A0 =A0| ICMPv6 | IPv6 =A0 =A0 =A0| payload (truncated t= o =A0 |
| header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),= P2 |
+------------+--------+-----------+-------------------------= +
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_______________ ___________= ________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv6 error message body

this message feedbacked to CE, who will translate it to:
+---------+--------+--------+--------------+
| IPv4 =A0= =A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H5 | hdr, C= 2| hdr, H4| payload, P3=A0 |
+---------+--------+--------+-------= -------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

it is clear that 4rd-U address mapping is applied for= =A0

=A0 H1 -> H2 -> H4

<= div>H3 has the source address of R1 while the destination address as the CE= .

then, CE's (or BR's for the case of B --> A)= global IPv4 address or 0.0.0.0 will be used in H5, right?=A0
first of all, the 0.0.0.0 might be a wrong choice. Unspecified = Address represents either a host not yet having gained an IPv4 address on t= he LOCAL network or an application listening on any addresses of a host. pa= cket with 0.0.0.0 might be dropped by any intermediate routers of current i= mplementations.=A0

=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Destinati= on unreachable, No
=A0 > route to destination") MUST be = translated into ICMPv4 Type =3D 3
=A0 > and Code =3D 0 (Desti= nation unreachable, Net unreachable).
=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit=
=A0 > exceeded in transit) MUST be translated into ICMPv4 Ty= pe =3D 11
=A0 > and Code =3D 0 (Time exceeded, Time to live e= xceeded in
=A0 > transit).

for C1 -> C2 transla= tion, i have the following comments:

1) here = 4rd-U uses the CE's global IPv4 address (i think "global" ref= ers to a non-shared one, right?) to represent all the error generator insid= e in the IPv6 domain. this surely fits a "tunnel" behavior that a= ttempts to treat the delivery from CE to BR as a "link", and ther= efore the error is responded by the link's end point.=A0
2) however, if this is treated as a "tunnel", both ICMPv6 ho= p-limit exceeded and ICMPv6 unreachable node should be translated as ICMPv4= destination unreachable (Type =3D 3) host unreachable (Code =3D 1), becaus= e it should indicates the link problem of the tunnel.
3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a = typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter consumes t= he TTL per physical hop. for example, if we set TTL =3D 32 in H1, tunneling= means from A to B communication may succeed as long as (A---CE) + (BR---B)= doesn't exceed 30 hops and CE---BR is well connected; while current 4r= d-U means from A to B communication may succeed only when total numbers of = intermediate routers doesn't exceed 31.=A0

this is why typical tunneling solutions initializ= e the out-header's IPv6 Hop Limit to 255. when routing loop happens in = the IPv6 domain and Hop Limit is consumed out, the link is considered broke= n.

2. consider ICMPv4 error happens at R2:=A0
R2 sees original IPv4 packet at A, sent to B:
+= ---------+----------------------------------------------+
| IPv4 = =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b47e8999e104bb1cd4fe-- From mohamed.boucadair@orange.com Tue Mar 13 02:58:48 2012 Return-Path: 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 CA1BA21F8718 for ; Tue, 13 Mar 2012 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 yHeSSla6v1fQ for ; Tue, 13 Mar 2012 02:58:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 83FDB21F86A1 for ; Tue, 13 Mar 2012 02:58:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C92262643B4; Tue, 13 Mar 2012 10:58:46 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A8594238104; Tue, 13 Mar 2012 10:58:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 13 Mar 2012 10:58:46 +0100 From: To: "draft-penno-softwire-sdnat@tools.ietf.org" Date: Tue, 13 Mar 2012 10:58:45 +0100 Thread-Topic: draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0A/+EWdXWJOgkkQtWGDvsvOFeIRw== Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E281DB353PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.83315 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite Subject: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 09:58:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E281DB353PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Reinaldo, all, I read the updated version of draft-penno-softwire-sdnat. I like this new v= ersion. Below some questions for clarification: (1) draft-penno is converging to what is documented in draft-cui-softwire-b4-translated-ds-lite: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassign]. Bes= ides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoord] f= or one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.". Question 5-1: Why "MUST"? IMHO, this is deployment-specific. Question 5-2: By "external IPv4 address", do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E281DB353PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Reinaldo, all,
 
I= read the=20 updated version of draft-penno-softwire-sdnat. I like this new version. Below som= e=20 questions for clarification:
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB> 
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB>   (1) draft-penno is converging to what is document= ed=20 in
  =20 draft-cui-softwire-b4-translated-ds-lite:
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB> 
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB>      (*) Question 1: It is not clear= in=20 text if there is a second NAT
      in the AFTR= or=20 not.  Could you please confirm/infirm a second=20 NAT
      is=20 present?

      (*) Question 2: If yes, is there an= y=20 reason why you want to
      maintain that seco= nd=20 NAT?

      (*) Question 3: If the public IP ad= dress=20 assigned by the AFTR is
      not known to the= =20 port-restricted CPE, some applications may=20 fail
      (referral).  How the CPE will m= ake a=20 distinction between the
      external IP addre= ss to=20 be assigned in the WAN and the one used in
     = ; the=20 AFTR?  If UPnP is used, the WAN IP address should not=20 be
     =20 returned.
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB> 
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB>   (2) Unlike draft-penno-*, draft-cui-* does not ma= ndate=20 any proffered
   provisioning means for port ranges; a list of= =20 alternatives is
   provided in draft-cui-* without any prefere= nce=20 (this is deployment-
   specific):
<= SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt; mso-fareast-font-fami= ly: 'MS Mincho'; mso-ansi-language: EN-GB; mso-fareast-language: JA; mso-bi= di-language: AR-SA"=20 lang=3DEN-GB>
   o  DHCPv4: the DHCPv4 protocol should =
be extended to support port-set
      allocation [I-D.bajko-pripaddras=
sign].  Besides, the DHCP message
      should send to the concentrator over IPv6.  The concentrator can
      be the DHCP server or DHCP relay
      agent[I-D.ietf-dhc-dhcpv4-over-ipv6].

   o  PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP
      requests simultaneously to acquire a number ports within the same
      IPv4 address, or use [I-D.tsou-pcp-=
natcoord] for one-time port-set
      allocation.

   o  DHCPv6: the DHCPv6 protocol should be extended to support port-set
      allocation [I-=
D.boucadair-dhcpv6-shared-address-option].

   o  IPCP: IPCP should be extended to carry the port-set.  [RFC6431]
      gives an example.
<= SPAN=20 class=3D321275308-13032012>      (*) Question 4: Given this list= , is=20 there really a need for the
      proposed=20 ICMP-based solution?

      (*) Question 5:= =20 draft-penno-* says: "A stateless DS-Lite CPE=20 MUST
      implement the DHCPv4 client relay op= tion=20 defined in [I-D.ietf-dhc-
      dhcpv4-over-ipv= 6] to=20 learn is external IPv4=20 address.".

         Question 5-1: Why= =20 "MUST"?  IMHO, this is deployment-specific.

         Question 5-2: By= =20 "external IPv4 address", do you mean=20 the
         address to be assig= ned=20 in the AFTR (if any)? or the one to=20 be
         used in the WAN inte= rface=20 of the CPE?
 
&= nbsp; =20 (3) draft-penno-* advocates it is deterministic but this feature=20 can
   be enforced in any IPv4 address sharing=20 technique:
 
<= SPAN=20 class=3D321275308-13032012>      (*) Question 6: Is there any=20 particular reason draft-penno-* does
      not= =20 mention=20 draft-donley-behave-deterministic-cgn?
 =
 =
<= SPAN=20 class=3D321275308-13032012>Cheers,
<= SPAN=20 class=3D321275308-13032012>Med
 
 
 
 
 
 
 
--_000_94C682931C08B048B7A8645303FDC9F36E281DB353PUEXCB1Bnante_-- From despres.remi@laposte.net Tue Mar 13 03:12:54 2012 Return-Path: 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 CD7A221F87D6 for ; Tue, 13 Mar 2012 03:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.063, 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 uQ4wEYGyPM+o for ; Tue, 13 Mar 2012 03:12:53 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id B588E21F87D2 for ; Tue, 13 Mar 2012 03:12:51 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id kyCo1i00S37Y3f403yCos9; Tue, 13 Mar 2012 11:12:50 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-111--1008433489 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 13 Mar 2012 11:12:48 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 10:12:54 -0000 --Apple-Mail-111--1008433489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-13 =E0 03:18, Maoke a =E9crit : > 2012/3/12 R=E9mi Despr=E9s > Le 2012-03-12 =E0 10:21, Maoke a =E9crit : >=20 >> hi Remi, >>=20 >> 2012/3/12 R=E9mi Despr=E9s >>=20 >> 2012-03-12 04:09, Maoke: >> ... >> > btw, BR also depends upon NAT44 to deal with the unknown protocol, = right? if so, may i say your statement "BR will support them without = needing an update" is a proposition actually not existing? because NAT44 = won't support them without any update. right? >>=20 >> Not right. Only CEs that need to support a new protocol are = concerned: >> - If a shared address server supports a new protocol, it can be = reached via an unchanged BR. >> - If a client using a new protocol tries to reach a shared-address CE = that doesn't support this protocol, the client will be returned an error = message by the destination NAT44. >>=20 >> thanks a lot for the clarification! take an example:=20 >>=20 >> A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 = Internet)--- B >>=20 >> now A and B are supposed to use a new protocol other than known = TCP/UDP/etc. my understanding: >> B --> A >> 1. BR just passes the new protocol without any concern. >> 2. CE's NAT44 module would say "this is not supported and a = 'destination unreachable with port unknown' ICMP message is returned to = B. >=20 > As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error = message should be, more precisely, "protocol unreachable". >=20 > thanks for the precise description.=20 > =20 > Everything OK. >=20 >=20 >=20 >> A --> B >> 1. CE's NAT44 module directly say "destination unreachable with port = unknown" ICMP message to A. >=20 > Presumably also "protocol unreachable", but this remains a NAT44 = matter. 4rd isn't involved. >=20 >> is the above what you mean? when NAT44 module DOESN'T support the new = protocol, things are working while we have no the problem about the = "change" at all for the time being.=20 >>=20 >> then let's consider the case where the NAT44 module has been updated = to support the new protocol. i understand BR passing all protocols can = be survived if and only if the new protocol follows the TCP-layout for = the destination port and the TCP-checksum, right?=20 >=20 > The 4rd mechanism is for protocols that have ports at their usual = place (all existing protocols that have ports have them at the same = place, even if using another checksum algorithm like SCTP). > =20 >=20 >> then you made a limitation (#1) to the NAT44 module of the CE: even = if the NAT44 has supported a new protocol not following TCP = layout/checksum, this support MUST be disabled in the 4rd-U environment; = otherwise, BR may behave wrong when making the mapped IPv6 addresses = while the NAT44 would still try to translate with the new protocol = rather than dropping an error message because it has known it. right?=20 >=20 > To me this looks like a far fetched theoretical problem, with no = consequence in practice. I said far fetched because: - For shared-address CEs, only protocols that use ports at their usual = place and the TCP checksum algorithm are in scope (H6 of comparison = tables). With them, there is never anything to "disable". - For non-shared address CEs, MAP-T needs updates for all newly = supported protocols (including an existing one such as UDP Lite). Like = MAP-E, 4rd works for all layer-4 protocols, never needing any update. =20= > to me, new protocols following TCP-layout and checksum are a far = fetched theoretical problem too, with no consequen in today's practice. = i mean, it is unfair when you state the 4rd-U pros you emphasize that BR = needs no change with some new protocols, but when we say some other new = protocols you say that's far fetched theoretical problem!=20 > =20 > OTOH, the fact that RFC6145 doesn't tell you whether you MUST = translate DCCP or not is a real problem, and so is the fact that it = doesn't support UDP Lite, another already existing protocol. =20 >=20 > i understand RFC6145 said OPTIONAL supporting DCCP just because it was = considered less critical at that point of writing (may the authors give = an explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, = with the same reason. implementation and operation can follow the = RFC6145 logic to deal with any L4 protocols. Non-documented reasons were what they were, but consequences should not = depend on them. > on the other hand, it is easy to update RFC6145 or just making a = suggestion anywhere, like a FYI on double-translation behavior of = RFC6145, with clarifying DCCP *optional* support should be consistent = throughout the domain and clarifying other unmentioned L4 protocol = processing should follow the protocol's checksum logic that is = specified. >=20 > i don't see it is necessary to enforcing the address-level checksum = neutrality rather than such a simple update or implementation/deployment = guidance.=20 Different view on practical consequences of the TBD "update or = implementation/deployment guidance" you propose. Accepting an NIH feature that solves the problem without this TBD would = IMHO be a step forward. > it is surely fine technically that we enforce that. no problem. but if = it is so necessary? here i have a point regarding the = implementation/deployment: if the address mapping and header processing = are decoupled, the things would be happier than a solution making them = tightly coupled. MAP is made in such a fashion, where header processing = could follow either encapsulation standard or translation standard. = RFC6145 is made in such a way, where addresses could follow stateless = mapping in RFC6052 or processed with state as in RFC6146, and now it is = also fine with MAP. such a decoupling property makes implementation = modularized and the operators may have better flexibility of choice. > =20 >=20 > in the term of decoupling, surely we have two choices: > 1) making address format checksum-neutral, suitable for either with L4 = recalculation or without.=20 > 2) making L4 recalculation, suitable for either addresses are = checksum-neutral or aren't.=20 >=20 > RFC6052 explains why the authors gave up the CNP in the address and = choose 2). i also have an understanding that 2) is a solution in = implementation, once distributed, not easy to modify; while 1) is a = solution in deployment, easy to change at any time. for example, if our = equipment is made with RFC6145, the same equipment can be used in either = RFC6052, or MAP, or 4rd-U address-mapping environment, but if our = equipment is made with 4rd-U, we must only use it in 4rd-U environment. = once we find we need to try something others, we have to buy new = equipment, which means cost.=20 In RFC6052, checksum neutrality was abandoned "because it would not help = with stateful translation and because checksum neutrality can also be = achieved by an appropriate choice of the Network-Specific Prefix, i.e., = selecting a prefix whose one's complement checksum equals either 0 or = 0xffff." - Stateful translation is off scope - MAP-T cannot select for each CE "a prefix whose one's complement = checksum equals either 0 or 0xffff". >> further (#2), what if the packets don't pass through the NAT44 module = at all (in the case of non-shared IPv4 addresses)?=20 >=20 > In case of non shared addresses, neither BRs nor CEs look at any port = field (there in no PSID to be found). >=20 > thanks. then (#2) is not a limitation. my mis.=20 >=20 > then the behavior of a new protocol (of the far fetched theoretical = case, where non-tcp-layout/checksum is applied) would be very tricky: > #2.1 address shared while NAT doesn't support the new protocol =3D> = dropped at NAT44, > possibly not the correct NAT44 though;=20 ??? > #2.2 address shared while NAT does support the new protocol =3D> not = dropped but it is possible to be incorrectly delivered because BR may = take wrong value for the port;=20 As stated many times, 4rd only deals, for shared-address CEs, with = protocols, existing or future, that have ports their usual place and the = TCP checksum algorithm. With these, no problem. Since this seems to be misunderstood, H6 of the comparison tables ca = clarify, in a next version, that future protocols that are considered = are supposed to have ports at their usual place (that of all existing = port-based protocols, be they or not with the TCP checksum algorithm). =20= > #2.3 address not shared =3D> passes to the end systems.=20 >=20 > correct understanding? See just above. Cheers, RD > =20 >=20 >> please clarify if the limitation of (#1) and (#2) are true or false. >=20 > Answered above. >=20 >=20 >> i believe with requiring L4 modification, either MAP or RFC6145 has = no such two limitations: enforcing the checksum update at L4, their = framework is safe for either TCP-layout/checksum or = alien-layout/checksum, either shared or exclusive IPv4 addresses. >=20 > This remains AFAIK a belief that ignores DCCP and UDP Lite limitations = of RFC6145. >=20 >=20 > see above.=20 >=20 > cheers, > maoke > =20 >=20 >> i worry the CNP is making a situation of "cutting feet to fit the = shoes".=20 >=20 > Hopefully, you will see that no such worry is justified. >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >>=20 >> - maoke >> =20 >>=20 >> RD >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-111--1008433489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/12 = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Le 2012-03-12 =E0 10:21, = Maoke a =E9crit :

hi = Remi,

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the unknown = protocol, right? if so, may i say your statement "BR will support them = without needing an update" is a proposition actually not existing? = because NAT44 won't support them without any update. right?

Not right. Only CEs that need to support a new protocol are = concerned:
- If a shared address server supports a new protocol, it can be reached = via an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE = that doesn't support this protocol, the client will be returned an error = message by the destination = NAT44.

thanks a lot for the = clarification! take an example: 

 A --- NAT44/CE ---(IPv6 backbone of 4rd = domain)--- BR ---(IPv4 Internet)--- B

now A and = B are supposed to use a new protocol other than known TCP/UDP/etc. my = understanding:
B --> A
1. BR just passes the new protocol without any = concern.
2. CE's NAT44 module would say "this is not supported = and a 'destination unreachable with port unknown' ICMP message is = returned to B.

As now documented in 4rd-u-05 in = the NOTE of 4.4 (3), the error message should be, more precisely, = "protocol = unreachable".

thanks for the = precise description. 
 
Everything OK.



A --> B
1. CE's NAT44 module directly say "destination = unreachable with port unknown" ICMP message to = A.

Presumably = also "protocol unreachable", but this remains a NAT44 matter. 4rd = isn't involved.

is the above what you mean? when NAT44 module = DOESN'T support the new protocol, things are working while we have no = the problem about the "change" at all for the time being. 

then let's consider the case where the NAT44 module = has been updated to support the new protocol. i understand BR passing = all protocols can be survived if and only if the new protocol follows = the TCP-layout for the destination port and the TCP-checksum, = right? 

The 4rd mechanism is for = protocols that have ports at their usual place (all existing protocols = that have ports have them at the same place, even if using another = checksum algorithm like SCTP).
 

then you made a limitation (#1) to the NAT44 module of the CE: even = if the NAT44 has supported a new protocol not following TCP = layout/checksum, this support MUST be disabled in the 4rd-U environment; = otherwise, BR may behave wrong when making the mapped IPv6 addresses = while the NAT44 would still try to translate with the new protocol = rather than dropping an error message because it has known it. = right? 

To me this looks like a far = fetched theoretical problem, with no consequence in = practice.

I = said far fetched because:
- For shared-address CEs, only = protocols that use ports at their usual place and the TCP checksum = algorithm are in scope (H6 of comparison tables). With them, there is = never anything to "disable".
- For non-shared address CEs, = MAP-T needs updates for all newly supported protocols (including an = existing one such as UDP Lite). Like MAP-E, 4rd works for all = layer-4 protocols, never needing any update. =  

to me, new protocols following TCP-layout and = checksum are a far fetched theoretical problem too, with no consequen in = today's practice. i mean, it is unfair when you state the 4rd-U pros you = emphasize that BR needs no change with some new protocols, but when we = say some other new protocols you say that's far fetched theoretical = problem! 
 
OTOH, the fact that RFC6145 doesn't = tell you whether you MUST translate DCCP or not is a real problem, and = so is the fact that it doesn't support UDP Lite, another already = existing protocol.  

i understand RFC6145 said = OPTIONAL supporting DCCP just because it was considered less critical at = that point of writing (may the authors give an explanation?). UDP-Lite = was not mentioned in RFC6145 then, i think, with the same reason. = implementation and operation can follow the RFC6145 logic to deal with = any L4 protocols. =

Non-documented reasons were = what they were, but consequences should not depend on = them.


on the other hand, it is easy to update = RFC6145 or just making a suggestion anywhere, like a FYI on = double-translation behavior of RFC6145, with clarifying DCCP *optional* = support should be consistent throughout the domain and clarifying other = unmentioned L4 protocol processing should follow the protocol's checksum = logic that is specified.

i don't see it is necessary to enforcing the = address-level checksum neutrality rather than such a simple update or = implementation/deployment = guidance. 

Different view on = practical consequences of the TBD "update = or implementation/deployment guidance" you = propose.
Accepting an NIH feature that solves the problem = without this TBD would IMHO be a step = forward.


it is surely fine = technically that we enforce that. no problem. but if it is so necessary? = here i have a point regarding the implementation/deployment: if the = address mapping and header processing are decoupled, the things would be = happier than a solution making them tightly coupled. MAP is made in such = a fashion, where header processing could follow either encapsulation = standard or translation standard. RFC6145 is made in such a way, where = addresses could follow stateless mapping in RFC6052 or processed with = state as in RFC6146, and now it is also fine with MAP. such a decoupling = property makes implementation modularized and the operators may have = better flexibility of choice.
 

in the term of decoupling, surely we have two = choices:
1) making address format checksum-neutral, suitable = for either with L4 recalculation or without. 
2) making = L4 recalculation, suitable for either addresses are checksum-neutral or = aren't. 

RFC6052 explains why the authors gave up the CNP in = the address and choose 2). i also have an understanding that 2) is a = solution in implementation, once distributed, not easy to modify; while = 1) is a solution in deployment, easy to change at any time. for example, = if our equipment is made with RFC6145, the same equipment can be used in = either RFC6052, or MAP, or 4rd-U address-mapping environment, but if our = equipment is made with 4rd-U, we must only use it in 4rd-U environment. = once we find we need to try something others, we have to buy new = equipment, which means = cost. 

In RFC6052, checksum neutrality was abandoned "because =
it would not help with stateful translation and because checksum =
neutrality can also be achieved by an appropriate choice of the =
Network-Specific Prefix, i.e., selecting a prefix whose one's complement =
checksum equals either 0 or 0xffff."
- Stateful translation is off scope
- MAP-T cannot select for each CE "a prefix whose one's complement =
checksum equals either 0 or 0xffff".

further (#2), what if the packets don't pass = through the NAT44 module at all (in the case of non-shared IPv4 = addresses)? 

In = case of non shared addresses, neither BRs nor CEs look at any port field = (there in no PSID to be found).

thanks. then (#2) is not a = limitation. my mis. 

then the behavior of = a new protocol (of the far fetched theoretical case, where = non-tcp-layout/checksum is applied) would be very tricky:
#2.1 address shared while NAT doesn't support the new protocol = =3D> dropped at NAT44,

possibly not the correct = NAT44 = though; 

???

#2.2 address = shared while NAT does support the new protocol =3D> not dropped but = it is possible to be incorrectly delivered because BR may take wrong = value for the port; 

As = stated many times, 4rd only deals, for shared-address CEs, with = protocols, existing or future, that have ports their usual place and the = TCP checksum algorithm.
With these, no = problem.

Since this seems to be misunderstood, = H6 of the comparison tables ca clarify, in a next version, that future = protocols that are considered are supposed to have ports at their usual = place (that of all existing port-based protocols, be they or not with = the TCP checksum algorithm).  

#2.3 address not shared =3D> passes to the end = systems. 

correct = understanding?

See just = above.

Cheers,
RD

<= div>


 

please clarify if the = limitation of (#1) and (#2) are true or false. =

Answered above.


i believe with requiring L4 modification, = either MAP or RFC6145 has no such two limitations: enforcing the = checksum update at L4, their framework is safe for either = TCP-layout/checksum or alien-layout/checksum, either shared or exclusive = IPv4 addresses.

This remains AFAIK a belief that = ignores DCCP and UDP Lite limitations of = RFC6145.


see = above. 

cheers,
maoke
 

i worry the CNP is making a situation of "cutting feet to fit the = shoes". 

Hopefully,= you will see that no such worry is justified.

=
Cheers,
RD





- maoke
 

RD






= --Apple-Mail-111--1008433489-- From fibrib@gmail.com Tue Mar 13 04:02:38 2012 Return-Path: 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 C23E021F87FB for ; Tue, 13 Mar 2012 04:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 giOk+rwAWvft for ; Tue, 13 Mar 2012 04:02:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06BDE21F87EE for ; Tue, 13 Mar 2012 04:02:36 -0700 (PDT) Received: by ghbg16 with SMTP id g16so453062ghb.31 for ; Tue, 13 Mar 2012 04:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qjy6/gP+mHMnZ3tR9uoH2Jocpv5EZpQ7ooK+lRNbm5s=; b=XxatMq7TxR4JIlotSaGgDKOLlZ75mVkMqOjhN6EJTVlFTDGsKuHr/18HnOMAV2EVSf JEOwnxLMpfrpvlN4uVjNzTNsbmgdp67YTQwLDH/qGmTXAmImy/gbXP6Vy8Vswx9bvpYM 582UfcyVN8Y+7h1ix+mwnUnTDGkRQihGJdS6s0pjHULMR7HEO6J8+th6gUTsfTh3/gw/ LTR6pJ3Zp072jnQvLFHYZAxUqRAK+Ncgdn9Lg2KBw0f5CjBeQY2+C5uMxbBR5VFMwxZC VwLd94eByR0GEC/b3XXPJoao6sIFzibEK4qeWM8KNRfn22me+W7qa80trBrMUioX89XY iFPQ== MIME-Version: 1.0 Received: by 10.224.101.130 with SMTP id c2mr9932289qao.47.1331636556584; Tue, 13 Mar 2012 04:02:36 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Tue, 13 Mar 2012 04:02:36 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> Date: Tue, 13 Mar 2012 11:02:36 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b794ecd61e04bb1dcb98 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:02:38 -0000 --20cf3074b794ecd61e04bb1dcb98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/13 R=E9mi Despr=E9s > > Le 2012-03-13 =E0 03:18, Maoke a =E9crit : > > 2012/3/12 R=E9mi Despr=E9s > >> Le 2012-03-12 =E0 10:21, Maoke a =E9crit : >> >> hi Remi, >> >> 2012/3/12 R=E9mi Despr=E9s >> >>> >>> 2012-03-12 04:09, Maoke: >>> ... >>> > btw, BR also depends upon NAT44 to deal with the unknown protocol, >>> right? if so, may i say your statement "BR will support them without >>> needing an update" is a proposition actually not existing? because NAT4= 4 >>> won't support them without any update. right? >>> >>> Not right. Only CEs that need to support a new protocol are concerned: >>> - If a shared address server supports a new protocol, it can be reached >>> via an unchanged BR. >>> - If a client using a new protocol tries to reach a shared-address CE >>> that doesn't support this protocol, the client will be returned an erro= r >>> message by the destination NAT44. >>> >> >> thanks a lot for the clarification! take an example: >> >> A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 >> Internet)--- B >> >> now A and B are supposed to use a new protocol other than known >> TCP/UDP/etc. my understanding: >> B --> A >> 1. BR just passes the new protocol without any concern. >> 2. CE's NAT44 module would say "this is not supported and a 'destination >> unreachable with port unknown' ICMP message is returned to B. >> >> >> As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message >> should be, more precisely, "protocol unreachable". >> > > thanks for the precise description. > > >> Everything OK. >> >> >> >> A --> B >> 1. CE's NAT44 module directly say "destination unreachable with port >> unknown" ICMP message to A. >> >> >> Presumably also "protocol unreachable", but this remains a NAT44 matter. >> 4rd isn't involved. >> >> is the above what you mean? when NAT44 module DOESN'T support the new >> protocol, things are working while we have no the problem about the >> "change" at all for the time being. >> >> then let's consider the case where the NAT44 module has been updated to >> support the new protocol. i understand BR passing all protocols can be >> survived if and only if the new protocol follows the TCP-layout for the >> destination port and the TCP-checksum, right? >> >> >> The 4rd mechanism is for protocols that have ports at their usual place >> (all existing protocols that have ports have them at the same place, eve= n >> if using another checksum algorithm like SCTP). >> > may you have a check on the statement of "all existing protocols" again? = i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. - maoke > >> >> then you made a limitation (#1) to the NAT44 module of the CE: even if >> the NAT44 has supported a new protocol not following TCP layout/checksum= , >> this support MUST be disabled in the 4rd-U environment; otherwise, BR ma= y >> behave wrong when making the mapped IPv6 addresses while the NAT44 would >> still try to translate with the new protocol rather than dropping an err= or >> message because it has known it. right? >> >> >> To me this looks like a far fetched theoretical problem, with no >> consequence in practice. >> > > I said far fetched because: > - For shared-address CEs, only protocols that use ports at their usual > place and the TCP checksum algorithm are in scope (H6 of comparison > tables). With them, there is never anything to "disable". > - For non-shared address CEs, MAP-T needs updates for all newly supported > protocols (including an existing one such as UDP Lite). Like MAP-E, 4rd > works for all layer-4 protocols, never needing any update. > > to me, new protocols following TCP-layout and checksum are a far fetched > theoretical problem too, with no consequen in today's practice. i mean, i= t > is unfair when you state the 4rd-U pros you emphasize that BR needs no > change with some new protocols, but when we say some other new protocols > you say that's far fetched theoretical problem! > > >> OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate >> DCCP or not is a real problem, and so is the fact that it doesn't suppor= t >> UDP Lite, another already existing protocol. >> > > i understand RFC6145 said OPTIONAL supporting DCCP just because it was > considered less critical at that point of writing (may the authors give a= n > explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with > the same reason. implementation and operation can follow the RFC6145 logi= c > to deal with any L4 protocols. > > > Non-documented reasons were what they were, but consequences should not > depend on them. > > > on the other hand, it is easy to update RFC6145 or just making a > suggestion anywhere, like a FYI on double-translation behavior of RFC6145= , > with clarifying DCCP *optional* support should be consistent throughout t= he > domain and clarifying other unmentioned L4 protocol processing should > follow the protocol's checksum logic that is specified. > > i don't see it is necessary to enforcing the address-level checksum > neutrality rather than such a simple update or implementation/deployment > guidance. > > > Different view on practical consequences of the TBD "update > or implementation/deployment guidance" you propose. > Accepting an NIH feature that solves the problem without this TBD would > IMHO be a step forward. > > > it is surely fine technically that we enforce that. no problem. but if it > is so necessary? here i have a point regarding the > implementation/deployment: if the address mapping and header processing a= re > decoupled, the things would be happier than a solution making them tightl= y > coupled. MAP is made in such a fashion, where header processing could > follow either encapsulation standard or translation standard. RFC6145 is > made in such a way, where addresses could follow stateless mapping in > RFC6052 or processed with state as in RFC6146, and now it is also fine wi= th > MAP. such a decoupling property makes implementation modularized and the > operators may have better flexibility of choice. > > > > in the term of decoupling, surely we have two choices: > 1) making address format checksum-neutral, suitable for either with L4 > recalculation or without. > 2) making L4 recalculation, suitable for either addresses are > checksum-neutral or aren't. > > RFC6052 explains why the authors gave up the CNP in the address and choos= e > 2). i also have an understanding that 2) is a solution in implementation, > once distributed, not easy to modify; while 1) is a solution in deploymen= t, > easy to change at any time. for example, if our equipment is made with > RFC6145, the same equipment can be used in either RFC6052, or MAP, or 4rd= -U > address-mapping environment, but if our equipment is made with 4rd-U, we > must only use it in 4rd-U environment. once we find we need to try > something others, we have to buy new equipment, which means cost. > > > In RFC6052, checksum neutrality was abandoned "because it would not help = with stateful translation and because checksum neutrality can also be achie= ved by an appropriate choice of the Network-Specific Prefix, i.e., selectin= g a prefix whose one's complement checksum equals either 0 or 0xffff." > - Stateful translation is off scope > - MAP-T cannot select for each CE "a prefix whose one's complement checks= um equals either 0 or 0xffff". > > > further (#2), what if the packets don't pass through the NAT44 module at >> all (in the case of non-shared IPv4 addresses)? >> >> >> In case of non shared addresses, neither BRs nor CEs look at any port >> field (there in no PSID to be found). >> > > thanks. then (#2) is not a limitation. my mis. > > then the behavior of a new protocol (of the far fetched theoretical case, > where non-tcp-layout/checksum is applied) would be very tricky: > #2.1 address shared while NAT doesn't support the new protocol =3D> dropp= ed > at NAT44, > > > possibly not the correct NAT44 though; > > > ??? > > #2.2 address shared while NAT does support the new protocol =3D> not drop= ped > but it is possible to be incorrectly delivered because BR may take wrong > value for the port; > > > As stated many times, 4rd only deals, for shared-address CEs, with > protocols, existing or future, that have ports their usual place and the > TCP checksum algorithm. > With these, no problem. > > Since this seems to be misunderstood, H6 of the comparison tables ca > clarify, in a next version, that future protocols that are considered are > supposed to have ports at their usual place (that of all existing > port-based protocols, be they or not with the TCP checksum algorithm). > > #2.3 address not shared =3D> passes to the end systems. > > correct understanding? > > > See just above. > > Cheers, > RD > > > > > > >> >> please clarify if the limitation of (#1) and (#2) are true or false. >> >> >> Answered above. >> >> >> i believe with requiring L4 modification, either MAP or RFC6145 has no >> such two limitations: enforcing the checksum update at L4, their framewo= rk >> is safe for either TCP-layout/checksum or alien-layout/checksum, either >> shared or exclusive IPv4 addresses. >> >> >> This remains AFAIK a belief that ignores DCCP and UDP Lite limitations o= f >> RFC6145. >> >> > see above. > > cheers, > maoke > > >> >> i worry the CNP is making a situation of "cutting feet to fit the shoes"= . >> >> >> Hopefully, you will see that no such worry is justified. >> >> >> Cheers, >> RD >> >> >> >> >> >> - maoke >> >> >>> >>> RD >>> >>> >>> >> >> > > --20cf3074b794ecd61e04bb1dcb98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-13 =E0 03:18, = Maoke a =E9crit :

2012/3/12 R=E9mi Despr=E9s &l= t;despres.rem= i@laposte.net>
Le 2012-03-12 =E0 10:21, Maok= e a =E9crit :

hi Remi,

2012/3/12 R=E9mi Despr=E9s <despres.remi@lapo= ste.net>

2012-03-12 04:09, Maoke:
...
> btw, BR also depends upon NAT44 to deal with the unknown protocol= , right? if so, may i say your statement "BR will support them without= needing an update" is a proposition actually not existing? because NA= T44 won't support them without any update. right?

Not right. Only CEs that need to support a new protocol are concerned= :
- If a shared address server supports a new protocol, it can be reached via= an unchanged BR.
- If a client using a new protocol tries to reach a shared-address CE that = doesn't support this protocol, the client will be returned an error mes= sage by the destination NAT44.

thanks a= lot for the clarification! take an example:=A0

=A0A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- B= R ---(IPv4 Internet)--- B

now A and B are supposed= to use a new protocol other than known TCP/UDP/etc. my understanding:
B --> A
1. BR just passes the new protocol without any co= ncern.
2. CE's NAT44 module would say "this is not suppo= rted and a 'destination unreachable with port unknown' ICMP message= is returned to B.

As now documented in 4rd-u-05 in th= e NOTE of 4.4 (3), the error message should be, more precisely, "proto= col unreachable".

thanks f= or the precise description.=A0
=A0
<= div style=3D"word-wrap:break-word">
Everything OK.



A --> B
1. CE's NAT44 module directly say "desti= nation unreachable with port unknown" ICMP message to A.

Presumably also=A0"protocol unreachabl= e", but this remains a NAT44 matter. 4rd isn't involved.

is = the above what you mean? when NAT44 module DOESN'T support the new prot= ocol, things are working while we have no the problem about the "chang= e" at all for the time being.=A0

then let's consider the case where the NAT44 module= has been updated to support the new protocol. i understand BR passing all = protocols can be survived if and only if the new protocol follows the TCP-l= ayout for the destination port and the TCP-checksum, right?=A0

The 4rd mechanism is for proto= cols that have ports at their usual place (all existing protocols that have= ports have them at the same place, even if using another checksum algorith= m like SCTP).
may you have a check on the statement of "all existing prot= ocols" again? i noticed RFC908/RFC1151. sorry if that are not a transp= ort protocol over IP.=A0

- maoke=A0
=A0

then you made a limitation (#1) to the NAT44 module of the CE: even if= the NAT44 has supported a new protocol not following TCP layout/checksum, = this support MUST be disabled in the 4rd-U environment; otherwise, BR may b= ehave wrong when making the mapped IPv6 addresses while the NAT44 would sti= ll try to translate with the new protocol rather than dropping an error mes= sage because it has known it. right?=A0

To me this looks like a far fetched= theoretical problem, with no consequence in practice.

I said far fetched becaus= e:
- For shared-address CEs, only protocols that use ports at their usual= place and the TCP checksum algorithm are in scope (H6 of comparison tables= ). With them, there is never anything to "disable".
- For non-shared address CEs, MAP-T needs updates for all newly supported p= rotocols (including an existing one such as UDP Lite). Like MAP-E,=A04rd wo= rks for all layer-4 protocols, never needing any update. =A0

to me, new pr= otocols following TCP-layout and checksum are a far fetched theoretical pro= blem too, with no consequen in today's practice. i mean, it is unfair w= hen you state the 4rd-U pros you emphasize that BR needs no change with som= e new protocols, but when we say some other new protocols you say that'= s far fetched theoretical problem!=A0
=A0
OTOH, the fact that RFC6145 doesn't tell you whether you MUS= T translate DCCP or not is a real problem, and so is the fact that it doesn= 't support UDP Lite, another already existing protocol. =A0

i understand RFC6145 said OPTIONAL s= upporting DCCP just because it was considered less critical at that point o= f writing (may the authors give an explanation?). UDP-Lite was not mentione= d in RFC6145 then, i think, with the same reason. implementation and operat= ion can follow the RFC6145 logic to deal with any L4 protocols.

Non-documented reasons were wh= at they were, but consequences should not depend on them.


on the other hand, it is easy to update RFC6145 or just making a sugge= stion anywhere, like a FYI on double-translation behavior of RFC6145, with = clarifying DCCP *optional* support should be consistent throughout the doma= in and clarifying other unmentioned L4 protocol processing should follow th= e protocol's checksum logic that is specified.

i don't see it is necessary to enforcing the addres= s-level checksum neutrality rather than such a simple update or implementat= ion/deployment guidance.=A0

Different view on practical consequences of the TBD "update or=A0imple= mentation/deployment guidance" you propose.
Accepting an NIH= feature that solves the problem without this TBD would IMHO be a step forw= ard.


it is surely fine technically that we e= nforce that. no problem. but if it is so necessary? here i have a point reg= arding the implementation/deployment: if the address mapping and header pro= cessing are decoupled, the things would be happier than a solution making t= hem tightly coupled. MAP is made in such a fashion, where header processing= could follow either encapsulation standard or translation standard. RFC614= 5 is made in such a way, where addresses could follow stateless mapping in = RFC6052 or processed with state as in RFC6146, and now it is also fine with= MAP. such a decoupling property makes implementation modularized and the o= perators may have better flexibility of choice.
=A0

in the term of decoupling, surely we have two choices:<= /div>
1) making address format checksum-neutral, suitable for either wi= th L4 recalculation or without.=A0
2) making L4 recalculation, su= itable for either addresses are checksum-neutral or aren't.=A0

RFC6052 explains why the authors gave up the CNP in the= address and choose 2). i also have an understanding that 2) is a solution = in implementation, once distributed, not easy to modify; while 1) is a solu= tion in deployment, easy to change at any time. for example, if our equipme= nt is made with RFC6145, the same equipment can be used in either RFC6052, = or MAP, or 4rd-U address-mapping environment, but if our equipment is made = with 4rd-U, we must only use it in 4rd-U environment. once we find we need = to try something others, we have to buy new equipment, which means cost.=A0= 

In RFC6052, checksum neut=
rality was abandoned "because it would not help with stateful translat=
ion and because checksum neutrality can also be achieved by an appropriate =
choice of the Network-Specific Prefix, i.e., selecting a prefix whose one&#=
39;s complement checksum equals either 0 or 0xffff."
- Stateful translation is off scope
- MAP-T cannot select for each CE "a prefix whose one's complement=
 checksum equals either 0 or 0xffff".

further (#2), what if the packets don't pa= ss through the NAT44 module at all (in the case of non-shared IPv4 addresse= s)?=A0

In case of non shared addresse= s, neither BRs nor CEs look at any port field (there in no PSID to be found= ).

thanks. then (#2) is not a lim= itation. my mis.=A0

then the behavior of a new pro= tocol (of the far fetched theoretical case, where non-tcp-layout/checksum i= s applied) would be very tricky:
#2.1 address shared while NAT doesn't support the new protocol =3D= > dropped at NAT44,

possibly not the correct NAT44 though;= =A0

???
#2.2 address sha= red while NAT does support the new protocol =3D> not dropped but it is p= ossible to be incorrectly delivered because BR may take wrong value for the= port;=A0

As stated many times, 4rd only deal= s, for shared-address CEs, with protocols, existing or future, that have po= rts their usual place and the TCP checksum algorithm.
With these,= no problem.

Since this seems to be misunderstood, H6 of the compari= son tables ca clarify, in a next version, that future protocols that are co= nsidered are supposed to have ports at their usual place (that of all exist= ing port-based protocols, be they or not with the TCP checksum algorithm). = =A0

#2.3 address not shared =3D> passes to the end systems.=A0

correct understanding?

See just above.

Cheers,
RD




=
=A0

please clarify if the limitation of (#1) a= nd (#2) are true or false.

Answered above.


i believe with requiring L4 modifica= tion, either MAP or RFC6145 has no such two limitations: enforcing the chec= ksum update at L4, their framework is safe for either TCP-layout/checksum o= r alien-layout/checksum, either shared or exclusive IPv4 addresses.

This remains AFAIK a belief that ig= nores DCCP and UDP Lite limitations of RFC6145.

<= /blockquote>

see above.=A0

chee= rs,
maoke
=A0

i worry the CNP is making a situation of "cutting feet to fit the= shoes".=A0

Hopefull= y, you will see that no such worry is justified.


Cheers,
RD





- maoke
=A0

RD







--20cf3074b794ecd61e04bb1dcb98-- From despres.remi@laposte.net Tue Mar 13 06:50:10 2012 Return-Path: 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 320E221F86DD for ; Tue, 13 Mar 2012 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 ye2QTJ+HrEM0 for ; Tue, 13 Mar 2012 06:50:09 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 1470D21F86D5 for ; Tue, 13 Mar 2012 06:50:02 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DFED69400BC; Tue, 13 Mar 2012 14:49:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 13 Mar 2012 14:49:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Cameron Byrne Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:50:10 -0000 Hi Behcet, Please see in line. Le 2012-03-12 =E0 23:09, Behcet Sarikaya a =E9crit : > Hi Remi, >=20 > My quick comments: > editorial on abstract: > - The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment > possible via IPv6 networks without maintaining for this per-customer > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > 6rd). > remove: for this. > Better still have a sentence like: > 4rd specifies a protocol mechanism to support Pv4 via a > service provider's (SP's) IPv6 network without maintaining = per-customer > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > 6rd). > - To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. >=20 > It is not customers but it is CPE or CEs, right? >=20 > - 4rd-capable customer nodes can exchange packets of their > IPv4-only applications via stateful NAT64s that are upgraded to > support 4rd tunnels (in addition to their IP/ICMP translation of > RFC6145) > replace "of" with "with" Editorial improvements can be done later, but thanks for your = suggestions. As regards "customer", this word seems to me good enough in an abstract = (BTW, the word on which are based CPE and CE acronyms). > Technical: >=20 > I don't understand NAT64+ discussion in this draft (it has been added > in -04). Why do you need it? It came as a result of the discussion on 464XLAT in v6ops (=3D> copy = sent to Cameron Byrne). What is achieved by 464XLAT is AFAIK that, in dual-stack-capable nodes = (DS nodes), IPv4-only applications can reach IPv4-only servers via = NAT64s. If a DS node is 4rd-capable, and is in a Domain where it has no public = IPv4 address (even shared) but where there is a 4rd-capable NAT64 = (called a NAT64+), it does all what it does with 464XLAT, but with an = improved IPv4 transparency (DF, ICMPv4, DCCP, UDP Lite ...). > In NAT64, IPv6 packet is not created by CE but by the host with the > help of DNS64. So far, the NAT64 doesn't know how packets are created. A NAT64+ recognizes IPv6 packets that were created to tunnel IPv4 = packets, and takes, for them, advantage of better IPv4 transparency.=20 > Where is DNS64 in your draft, except for a reference to > RFC 6147 which is a bogus reference. Right, this reference isn't needed. Thanks. (NAT64s always go with DNS4s in the IPv4/IPv6 framework of RFC6144, but = this isn't a 4rd matter.) > NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over > an IPv6 network. Indeed, but it also helps DS hosts attached to IPv6-only networks to = reach IPv4-only servers, e.g. with BIH. > So it has almost nothing to do with 4rd. Nothing to do with 4rd... until 4rd includes a way to improve IPv4 = transparency of NAT64s for hosts that are DS (upgrading them to NAT64+). >=20 > One thing you can do is to say that NAT64 could be colocated with 4rd > BR if Pref64 of NAT is chosen to match 4rd prefix. > In that case you > need to add support for RFC6145 stateful packet translation as well as > the NAT state in 4rd BRs. Not in 4rd BRs as defined, only in nodes that colocate BRs and NAT64s. > Is this what you would like to do? >=20 > Maybe I missed something. Hope the above is clarifying. Kind regards, RD >=20 > Regards, >=20 > Behcet >=20 > On Mon, Mar 12, 2012 at 9:56 AM, R=E9mi Despr=E9s = wrote: >> Hello, all, >>=20 >> An updated version of draft-despres-softwire-4rd-u is now available = at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>=20 >> Differences with -04 include: >> - DHCPv6 options are now specified >> - various errors and typos are corrected >> - some clarifications are added, following received questions and = comments >> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs) >> - An editor's note has been added, following a WG-ML discussion, = about an additional Mapping-rule parameter that might be needed to = assign privileged ports to to some shared-address CEs. >> - Document layout has been adjusted as a result of other = modifications. >> - the authors list has been completed. >>=20 >> Questions and comments are most welcome. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Tue Mar 13 06:58:17 2012 Return-Path: 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 B877F21F8892 for ; Tue, 13 Mar 2012 06:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.061, 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 gFPm5drxphL7 for ; Tue, 13 Mar 2012 06:58:16 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id BB78A21F888B for ; Tue, 13 Mar 2012 06:58:15 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id l1yA1i00E37Y3f4031yBd6; Tue, 13 Mar 2012 14:58:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-112--994909994 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 13 Mar 2012 14:58:11 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:58:17 -0000 --Apple-Mail-112--994909994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-03-13 12:02, Maoke : > 2012/3/13 R=E9mi Despr=E9s ... >> The 4rd mechanism is for protocols that have ports at their usual = place (all existing protocols that have ports have them at the same = place, even if using another checksum algorithm like SCTP). >=20 > may you have a check on the statement of "all existing protocols" = again? i noticed RFC908/RFC1151. sorry if that are not a transport = protocol over IP.=20 I missed this one. None of the proposed stateless solutions supports it, but it remains = that you are right: it has ports at a different place. Thanks for this info. RD --Apple-Mail-112--994909994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
...
The= 4rd mechanism is for protocols that have ports at their usual place = (all existing protocols that have ports have them at the same place, = even if using another checksum algorithm like = SCTP).
=

=
may you have a check on the statement of "all existing = protocols" again? i noticed RFC908/RFC1151. sorry if that are not a = transport protocol over = IP. 

I missed this = one.
None of the proposed stateless solutions supports = it, but it remains that you are right: it has ports at a different = place.
Thanks for this = info.

RD


= --Apple-Mail-112--994909994-- From Francis.Dupont@fdupont.fr Tue Mar 13 09:55:44 2012 Return-Path: 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 EE74221F871E for ; Tue, 13 Mar 2012 09:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] 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 MvTDIDfDfRvL for ; Tue, 13 Mar 2012 09:55:44 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id EADE721F86A3 for ; Tue, 13 Mar 2012 09:55:43 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2DGtZil087855; Tue, 13 Mar 2012 17:55:35 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203131655.q2DGtZil087855@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Tue, 13 Mar 2012 10:58:45 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Mar 2012 17:55:35 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:55:45 -0000 In your previous mail you wrote: > (*) Question 1: It is not clear in text if there is a second NAT > in the AFTR or not. Could you please confirm/infirm a second NAT > is present? => there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) > (*) Question 2: If yes, is there any reason why you want to > maintain that second NAT? => I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) > (*) Question 3: If the public IP address assigned by the AFTR is > not known to the port-restricted CPE, some applications may fail > (referral). How the CPE will make a distinction between the > external IP address to be assigned in the WAN and the one used in > the AFTR? If UPnP is used, the WAN IP address should not be > returned. => my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > provisioning means for port ranges; a list of alternatives is > provided in draft-cui-* without any preference (this is deployment- > specific): => but the ICMP-based solution is deeply broken so is it a real advantage? > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? => see previous item > (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST > implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > Question 5-1: Why "MUST"? IMHO, this is deployment-specific. => no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states "DS-Lite" so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) > Question 5-2: By "external IPv4 address", do you mean the > address to be assigned in the AFTR (if any)? or the one to be > used in the WAN interface of the CPE? => if they are the same the answer is easy > (3) draft-penno-* advocates it is deterministic but this feature can > be enforced in any IPv4 address sharing technique: => BTW we need a better definition of "deterministic". My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). > (*) Question 6: Is there any particular reason draft-penno-* does > not mention draft-donley-behave-deterministic-cgn? => too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] <-> [N... 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 C8FD521F8514 for ; Tue, 13 Mar 2012 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.992 X-Spam-Level: X-Spam-Status: No, score=-9.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ypRL0J5syK4c for ; Tue, 13 Mar 2012 13:19:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A80CE21F84D1 for ; Tue, 13 Mar 2012 13:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4900; q=dns/txt; s=iport; t=1331669967; x=1332879567; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=++bCjProVmg6C4P/s+T7aw33p/s0Og9nPytAi4wZ0eA=; b=V4Rm3mLho4IToIvm+TTEOZeqwWfJbD/qzSAb/KZqiadEcIQHc6xUODOL aOeIe7gFgORGqKy9j4KOyV+dyUueYNmRiu8pziF2A+/DIAnQcd33wjhyY bt8JTI5t4Uj5jjJadJxYBn67jqQNgAGNf35hLbpbJnkZgAsewbEPCWxx6 s=; X-IronPort-AV: E=Sophos;i="4.73,579,1325462400"; d="scan'208";a="63132144" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 13 Mar 2012 20:19:27 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2DKJRg0031163; Tue, 13 Mar 2012 20:19:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 15:19:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 15:19:26 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA90C@XMB-RCD-111.cisco.com> In-Reply-To: <201203131655.q2DGtZil087855@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0BOiyUUcpqp8L9Te+mLvidk1wL8AAHAINQ References: Your message of Tue, 13 Mar 2012 10:58:45 +0100.<94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> From: "Rajiv Asati (rajiva)" To: "Francis Dupont" , , X-OriginalArrivalTime: 13 Mar 2012 20:19:27.0817 (UTC) FILETIME=[97245B90:01CD0156] Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , draft-penno-softwire-sdnat@tools.ietf.org Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:19:28 -0000 > I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA > (still trivial to implement and to use but harder to trace). I agree. GMA is defined here, btw - http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0 2#section-4.1 Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Francis Dupont > Sent: Tuesday, March 13, 2012 12:56 PM > To: mohamed.boucadair@orange.com > Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno- > softwire-sdnat@tools.ietf.org > Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4- > translated-ds-lite >=20 >=20 > In your previous mail you wrote: >=20 > > (*) Question 1: It is not clear in text if there is a second NAT > > in the AFTR or not. Could you please confirm/infirm a second NAT > > is present? >=20 > =3D> there is one but: > - it translates only port numbers following an algorithm >=20 > - the NAT is not strictly required: one can imagine to assign > directly to a CPE its port range as it is visible from the Internet > (note: 1- it should be not what we want as it makes CPEs trivial > to track, 2- it doesn't remove the mandatory check on source ports > in the from CPE to the Internet way) >=20 > > (*) Question 2: If yes, is there any reason why you want to > > maintain that second NAT? >=20 > =3D> I can see at least 2 reasons: > - make CPE simplers (only applications which need to know what is a port > number seen from the Internet side have to enter into the second NAT > details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) >=20 > > (*) Question 3: If the public IP address assigned by the AFTR is > > not known to the port-restricted CPE, some applications may fail > > (referral). How the CPE will make a distinction between the > > external IP address to be assigned in the WAN and the one used in > > the AFTR? If UPnP is used, the WAN IP address should not be > > returned. >=20 > =3D> my read of the SD-NAT mechanism is the public IP address is the same > at each side of the SD-CGN. >=20 > > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > > provisioning means for port ranges; a list of alternatives is > > provided in draft-cui-* without any preference (this is deployment- > > specific): >=20 > =3D> but the ICMP-based solution is deeply broken so is it a real > advantage? >=20 > > (*) Question 4: Given this list, is there really a need for the > > proposed ICMP-based solution? >=20 > =3D> see previous item >=20 > > (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST > > implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- > > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > > > Question 5-1: Why "MUST"? IMHO, this is deployment-specific. >=20 > =3D> no such specific: > - it makes the reasonable assumption than IPv4 addresses are assigned > using DHCPv4 > - it states "DS-Lite" so there is no direct IPv4 available > - so IMHO the question is more about the DHCPv4-over-IPv6 application > and is more for the DHC WG (BTW please don't bounce this issue between > the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 > itself) >=20 > > Question 5-2: By "external IPv4 address", do you mean the > > address to be assigned in the AFTR (if any)? or the one to be > > used in the WAN interface of the CPE? >=20 > =3D> if they are the same the answer is easy >=20 > > (3) draft-penno-* advocates it is deterministic but this feature can > > be enforced in any IPv4 address sharing technique: >=20 > =3D> BTW we need a better definition of "deterministic". My proposal > is it means the mapping follows an algorithm (and it is the case on > the SD-CGN, BTW not on the SD-CPE). >=20 > > (*) Question 6: Is there any particular reason draft-penno-* does > > not mention draft-donley-behave-deterministic-cgn? >=20 > =3D> too many drafts...? More seriously I have more concerns about > too simple algorithms deployed in the SD-CGN, for instance the: > [1024...xxx] <-> [N... is good for tests or demos but makes CPEs too easy to trace, > I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA > (still trivial to implement and to use but harder to trace). >=20 > Regards >=20 > Francis.Dupont@fdupont.fr > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Tue Mar 13 16:51:08 2012 Return-Path: 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 DDF8321E8013 for ; Tue, 13 Mar 2012 16:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wMnpo-ZbhFrM for ; Tue, 13 Mar 2012 16:51:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCD4921E8046 for ; Tue, 13 Mar 2012 16:51:07 -0700 (PDT) Received: by iazz13 with SMTP id z13so1696334iaz.31 for ; Tue, 13 Mar 2012 16:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kMH/LbSJse9AIs55MjVvMJVUknEYtef6XWTOUVVbDv0=; b=LqF8PsnF/W074ICcYmgPVzxdzI97ochYkEhZQiFelPot3qj3gJyf7q7N6K8hqGuzGh xyRcpQdk2VhLGKwfJLNfmYpeeI+jWFReL9N0CrSMqI2O0a8WiMDvXkTtCk/nypFGtsA4 R+pG2e4ChLTomXX+DkrYtxMPRFDJNqc1B4OnqJS6NbVZA/DhtMyUKb9ckd1HG5Xz04h8 4M8Nd6vlw3tdiByYN4BY6jYrljp40FUvfvH4gPjFFaIjfUo3LmOugAwM03/R+7GNTtvy XnSl12+G2IvCtEl5G14ZD4l23EiJIlAzyEndw0oLcuTQVZG6aSz4CDDQ7eByZv9zI8H6 NZOA== Received: by 10.50.182.168 with SMTP id ef8mr841453igc.15.1331682667386; Tue, 13 Mar 2012 16:51:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.137.135 with HTTP; Tue, 13 Mar 2012 16:50:27 -0700 (PDT) In-Reply-To: <201203131655.q2DGtZil087855@givry.fdupont.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> From: Qiong Date: Wed, 14 Mar 2012 07:50:27 +0800 Message-ID: To: Francis Dupont Content-Type: multipart/alternative; boundary=14dae9340a9157d89d04bb2888ed Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 23:51:09 -0000 --14dae9340a9157d89d04bb2888ed Content-Type: text/plain; charset=UTF-8 Hi Francis, Thanks for your reply. Please see inline. On Wed, Mar 14, 2012 at 12:55 AM, Francis Dupont wrote: > In your previous mail you wrote: > > > (*) Question 1: It is not clear in text if there is a second NAT > > in the AFTR or not. Could you please confirm/infirm a second NAT > > is present? > > => there is one but: > - it translates only port numbers following an algorithm > > - the NAT is not strictly required: one can imagine to assign > directly to a CPE its port range as it is visible from the Internet > (note: 1- it should be not what we want as it makes CPEs trivial > to track, 2- it doesn't remove the mandatory check on source ports > in the from CPE to the Internet way) > [Qiong] Thanks for clarification. It seems this is not mentioned when to adopt and how to process the second NAT in current version of sd-nat. But still, I would prefer a solution without double-NAT. > > > (*) Question 2: If yes, is there any reason why you want to > > maintain that second NAT? > > => I can see at least 2 reasons: > - make CPE simplers (only applications which need to know what is a port > number seen from the Internet side have to enter into the second NAT > details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the > CPE) > > > (*) Question 3: If the public IP address assigned by the AFTR is > > not known to the port-restricted CPE, some applications may fail > > (referral). How the CPE will make a distinction between the > > external IP address to be assigned in the WAN and the one used in > > the AFTR? If UPnP is used, the WAN IP address should not be > > returned. > > => my read of the SD-NAT mechanism is the public IP address is the same > at each side of the SD-CGN. > > > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > > provisioning means for port ranges; a list of alternatives is > > provided in draft-cui-* without any preference (this is deployment- > > specific): > > => but the ICMP-based solution is deeply broken so is it a real > advantage? > [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the "ICMP processing" in section 10. And we have verified that it works fine in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. > > > (*) Question 4: Given this list, is there really a need for the > > proposed ICMP-based solution? > > => see previous item > > > (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST > > implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- > > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > > > Question 5-1: Why "MUST"? IMHO, this is deployment-specific. > > => no such specific: > - it makes the reasonable assumption than IPv4 addresses are assigned > using DHCPv4 > - it states "DS-Lite" so there is no direct IPv4 available > - so IMHO the question is more about the DHCPv4-over-IPv6 application > and is more for the DHC WG (BTW please don't bounce this issue between > the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 > itself) > [Qiong] I still think it is deployment-specific. For operators who perfer to deploy PCP solution, it is nature for them to adopt PCP-base or PCP-extension (pcp-natcoord). For operators who would like to deploy DHCPv4-over-IPv6, port-range can be assigned in this way. > > > Question 5-2: By "external IPv4 address", do you mean the > > address to be assigned in the AFTR (if any)? or the one to be > > used in the WAN interface of the CPE? > > => if they are the same the answer is easy > > > (3) draft-penno-* advocates it is deterministic but this feature can > > be enforced in any IPv4 address sharing technique: > > => BTW we need a better definition of "deterministic". My proposal > is it means the mapping follows an algorithm (and it is the case on > the SD-CGN, BTW not on the SD-CPE). > > > (*) Question 6: Is there any particular reason draft-penno-* does > > not mention draft-donley-behave-deterministic-cgn? > > => too many drafts...? More seriously I have more concerns about > too simple algorithms deployed in the SD-CGN, for instance the: > [1024...xxx] <-> [N... is good for tests or demos but makes CPEs too easy to trace, > I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA > (still trivial to implement and to use but harder to trace). > [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm which has been discusses widely in the WG. Best wishes Qiong > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae9340a9157d89d04bb2888ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francis,

Thanks for your reply. Please see inline.

On Wed, Mar 14, 2012 at 12:55 AM, Francis Dupont <Francis.Dupon= t@fdupont.fr> wrote:
=C2=A0In your previous mai= l you wrote:

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 1: It is not clear in text if = there is a second NAT
> =C2=A0 =C2=A0 =C2=A0 =C2=A0in the AFTR or not. =C2=A0Could you please = confirm/infirm a second NAT
> =C2=A0 =C2=A0 =C2=A0 =C2=A0is present?

=3D> there is one but:
=C2=A0- it translates only port numbers following an algorithm

=C2=A0- the NAT is not strictly required: one can imagine to assign
=C2=A0 directly to a CPE its port range as it is visible from the Internet=
=C2=A0 (note: 1- it should be not what we want as it makes CPEs trivial =C2=A0 =C2=A0to track, 2- it doesn't remove the mandatory check on sou= rce ports
=C2=A0 =C2=A0in the from CPE to the Internet way)
[Qi= ong] Thanks for clarification. It seems this is not mentioned when to adopt= and how to process the second NAT in current version of sd-nat. But still,= I would prefer a solution without double-NAT.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 2: If yes, is there any reason= why you want to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0maintain that second NAT?

=3D> I can see at least 2 reasons:
=C2=A0- make CPE simplers (only applications which need to know what is a p= ort
=C2=A0number seen from the Internet side have to enter into the second NAT=
=C2=A0details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on t= he CPE)

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 3: If the public IP address as= signed by the AFTR is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0not known to the port-restricted CPE, some = applications may fail
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(referral). =C2=A0How the CPE will make a d= istinction between the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0external IP address to be assigned in the W= AN and the one used in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the AFTR? =C2=A0If UPnP is used, the WAN IP= address should not be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0returned.

=3D> my read of the SD-NAT mechanism is the public IP address is t= he same
at each side of the SD-CGN.

> =C2=A0 =C2=A0 (2) Unlike draft-penno-*, draft-cui-* does not mandate a= ny proffered
> =C2=A0 =C2=A0 provisioning means for port ranges; a list of alternativ= es is
> =C2=A0 =C2=A0 provided in draft-cui-* without any preference (this is = deployment-
> =C2=A0 =C2=A0 specific):

=3D> but the ICMP-based solution is deeply broken so is it a real<= br> advantage?
[Qiong] In draft-cui-softwire-b4-translated= -ds-lite, we have described the "ICMP processing" in section 10. = And we have verified that it works fine in all ICMP-based protocols, e.g. p= ing, tracert, etc. There is no problem here.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 4: Given this list, is there r= eally a need for the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0proposed ICMP-based solution?

=3D> see previous item

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 5: draft-penno-* says: "A= stateless DS-Lite CPE MUST
> =C2=A0 =C2=A0 =C2=A0 =C2=A0implement the DHCPv4 client relay option de= fined in [I-D.ietf-dhc-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0dhcpv4-over-ipv6] to learn is external IPv4= address.".
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Question 5-1: Why "MUST"?= =C2=A0IMHO, this is deployment-specific.

=3D> no such specific:
=C2=A0- it makes the reasonable assumption than IPv4 addresses are assigned=
=C2=A0using DHCPv4
=C2=A0- it states "DS-Lite" so there is no direct IPv4 available<= br> =C2=A0- so IMHO the question is more about the DHCPv4-over-IPv6 application=
=C2=A0and is more for the DHC WG (BTW please don't bounce this issue b= etween
=C2=A0the two WGs, my idea is more to make a point about DHCPv4-over-IPv6<= br> =C2=A0itself)
[Qiong] I still think it is deployment-= specific. For operators who perfer to deploy PCP solution, it is nature for= them to adopt PCP-base or PCP-extension (pcp-natcoord). For operators who = would like to deploy DHCPv4-over-IPv6, port-range can be assigned in this w= ay.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Question 5-2: By "external IPv= 4 address", do you mean the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address to be assigned in the AFTR = (if any)? or the one to be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used in the WAN interface of the CP= E?

=3D> if they are the same the answer is easy

> =C2=A0 =C2=A0 (3) draft-penno-* advocates it is deterministic but this= feature can
> =C2=A0 =C2=A0 be enforced in any IPv4 address sharing technique:

=3D> BTW we need a better definition of "deterministic".= My proposal
is it means the mapping follows an algorithm (and it is the case on
the SD-CGN, BTW not on the SD-CPE).

> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*) Question 6: Is there any particular rea= son draft-penno-* does
> =C2=A0 =C2=A0 =C2=A0 =C2=A0not mention draft-donley-behave-determinist= ic-cgn?

=3D> too many drafts...? More seriously I have more concerns about=
too simple algorithms deployed in the SD-CGN, for instance the:
=C2=A0[1024...xxx] <-> [N...<N-1024+xxx] where p' =3D p + N - = 1024
is good for tests or demos but makes CPEs too easy to trace,
I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace).
[Qiong] Since it is a stateless solution, I also prefer the GMA algo= rithm which has been discusses widely in the WG.

Best wishes

Qiong


Regards

Francis.Dupont@fdupont.fr<= br> _______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--14dae9340a9157d89d04bb2888ed-- From phdgang@gmail.com Tue Mar 13 22:39:50 2012 Return-Path: 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 2B4B121F85EC for ; Tue, 13 Mar 2012 22:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 asOwDg-gFV-D for ; Tue, 13 Mar 2012 22:39:49 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1093821F85F0 for ; Tue, 13 Mar 2012 22:39:43 -0700 (PDT) Received: by werb10 with SMTP id b10so1566554wer.31 for ; Tue, 13 Mar 2012 22:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SlNvjl/Pr8wUDDYVRrTScS7uzQ5FFiMd8xlIXipDQg=; b=XFgUgHXFPmG42YegY8HeOtwFEbMyQU+knUKIPPpGcg4udW4dzLQENw+b7147HNzBe1 Wl4zOV6s8lbWgkqQOKu1Uh1q6gQeQRL4YocsXKDf+I7jRbK8VFKtIv56KJBTCBSjZXD6 M6xr3rcoTwlJOwBq+UuilddZlsiTDXRV5cXKQuJaZHpPsJ+PJV9OUY53LP29JVKEqpyt 7m9vrij4RDYPEJfpcXUUE7FSSz8gay8xxWBunCTBrdkQdoisykiQJXnrilcE8gX5jByX zFhs+TCTyhMQwSQifIXyK8ojicSx8DRCvpyn7cmQ3sTxNzU2I0J7iiXg0TkGiTZDOjGj B/NQ== MIME-Version: 1.0 Received: by 10.180.80.70 with SMTP id p6mr13511752wix.21.1331703582469; Tue, 13 Mar 2012 22:39:42 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Tue, 13 Mar 2012 22:39:42 -0700 (PDT) In-Reply-To: <201203131655.q2DGtZil087855@givry.fdupont.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> Date: Wed, 14 Mar 2012 13:39:42 +0800 Message-ID: From: GangChen To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 05:39:50 -0000 2012/3/14, Francis Dupont : > In your previous mail you wrote: > >> (*) Question 1: It is not clear in text if there is a second NAT >> in the AFTR or not. Could you please confirm/infirm a second NAT >> is present? > > => there is one but: > - it translates only port numbers following an algorithm > > - the NAT is not strictly required: one can imagine to assign > directly to a CPE its port range as it is visible from the Internet > (note: 1- it should be not what we want as it makes CPEs trivial > to track, 2- it doesn't remove the mandatory check on source ports > in the from CPE to the Internet way) > >> (*) Question 2: If yes, is there any reason why you want to >> maintain that second NAT? > > => I can see at least 2 reasons: > - make CPE simplers (only applications which need to know what is a port > number seen from the Internet side have to enter into the second NAT > details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the > CPE) However, the draft seems give people impression there is only one NAT at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is responsible for decapsulation and IPv4 package validation. Did I miss something? BRs Gang From fibrib@gmail.com Tue Mar 13 22:51:26 2012 Return-Path: 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 743C821F8568 for ; Tue, 13 Mar 2012 22:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 wn2dINOjU8KG for ; Tue, 13 Mar 2012 22:51:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9477721F8565 for ; Tue, 13 Mar 2012 22:51:25 -0700 (PDT) Received: by yhpp34 with SMTP id p34so1613358yhp.31 for ; Tue, 13 Mar 2012 22:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G3zPXAuI+BU+CmPAl1CBbkJDAN5+TAYTCquDxI+0Sec=; b=wzlL9o96SF2w7VThZPUcpIW3J79YhCy8KMVUg9KxkTEHQsM+F+DoWb4CvQGf5V9Ye2 3t1xkm1imuJc9ZuhumJ431Gi81h0iy7xoKbvhG0Ch5KZDeW+3c0EemXaalYHa/Q1AF5g 1IeWF6egawMYNM8gqYp9qGeG3yw7TmcV5rk3y8vZYmobPe7iKLKpGX4Rf1gArhQdXlLR zcwq6tefevQBj+CAhx/qIz3HdV1Q6NvvCtFGJJCjwa07vynhZC1lTgwgNfwEeO+AA7WP DWHXmeAeM1u7JzxD+GHNr90rU0/xtE3RgGzpQvy00oVCDdDF88DaKCpyLzc8m0jRKOHh eNYA== MIME-Version: 1.0 Received: by 10.224.101.130 with SMTP id c2mr1645589qao.47.1331704285017; Tue, 13 Mar 2012 22:51:25 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Tue, 13 Mar 2012 22:51:24 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> Date: Wed, 14 Mar 2012 05:51:24 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b794dab44404bb2d90e8 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 05:51:26 -0000 --20cf3074b794dab44404bb2d90e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/13 R=E9mi Despr=E9s > 2012-03-13 12:02, Maoke : > > 2012/3/13 R=E9mi Despr=E9s > > ... > > The 4rd mechanism is for protocols that have ports at their usual place >>> (all existing protocols that have ports have them at the same place, ev= en >>> if using another checksum algorithm like SCTP). >>> >> > may you have a check on the statement of "all existing protocols" again? = i > noticed RFC908/RFC1151. sorry if that are not a transport protocol over I= P. > > > I missed this one. > None of the proposed stateless solutions supports it, but it remains that > you are right: it has ports at a different place. > alright. so 4rd-U doesn't not support "all existing transport protocol" either. but i suppose you may make an update in the 4rd-u-06 so that a new "if...else..." is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. but this is not my point. my point is: there must be something we don't know ("non omnia possumus omnes"). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state "currently blahblabla L4 protocols are supported". the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like "far fetched theoretical problem". the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. only my 2 cents. maoke > Thanks for this info. > > RD > > > --20cf3074b794dab44404bb2d90e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
2012-03-13 12:02, Maoke :
2012/3/13 R=E9mi Des= pr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for prot= ocols that have ports at their usual place (all existing protocols that hav= e ports have them at the same place, even if using another checksum algorit= hm like SCTP).

may you have a check on the statement of "all existing prot= ocols" again? i noticed RFC908/RFC1151. sorry if that are not a transp= ort protocol over IP.=A0

I missed this one.
None o= f the=A0proposed stateless solutions supports it, but it remains that you a= re right: it has ports at a different place.

alright. so 4rd-U doesn't not support "all existing= transport protocol" either. but i suppose you may make an update in t= he 4rd-u-06 so that a new "if...else..." is added the port pick-u= p logic, and surely the CNP is not a problem for RDP because the old versio= n (RFC908) has 32bit checksum but not involving pseudo-header while the new= er version (RFC1151) changed to use TCP-checksum. no big deal but only need= s a new patch to the draft.=A0

but this is not my point. my point is: there must be so= mething we don't know ("non omnia possumus omnes"). even we h= ave gone through the RFCs, there might be some other proprietary L4 protoco= ls, or experimental protocols. even they are minority, i don't think ig= noring their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but a= n L4 protocol owner may makes his own NAT44, either attached to the CE or s= eparated. if 4rd-U respects such an effort, it should state "currently= blahblabla L4 protocols are supported". the similar statement applies= to the RFC6145 or MAP as well. i somehow am hard to accept words like &quo= t;far fetched theoretical problem".=A0

the L4-recalculate is a generic, architectural solution= , surely needing codes for every L4 protocol. but this generality in archit= ecture makes RFC6145 or MAP-T equipment be easily enhanced to support anyth= ing new with the same logic. but for the 4rd-U BR, it looks to me we cannot= have the unified logic for all (even limited to existing and well-known) L= 4 protocols.=A0

only my 2 cents.=A0

maoke
=A0
Thanks for this info.

RD



--20cf3074b794dab44404bb2d90e8-- From mohamed.boucadair@orange.com Tue Mar 13 23:42:11 2012 Return-Path: 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 2A53621F85A0 for ; Tue, 13 Mar 2012 23:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 s5Fr3kqsUB0x for ; Tue, 13 Mar 2012 23:42:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 54FC521F855D for ; Tue, 13 Mar 2012 23:42:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0D0B218C560; Wed, 14 Mar 2012 07:42:08 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DCE4A238135; Wed, 14 Mar 2012 07:42:07 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 14 Mar 2012 07:42:07 +0100 From: To: "Francis.Dupont@fdupont.fr" Date: Wed, 14 Mar 2012 07:42:06 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0BOiI+2jcF80dFTRyPuyloQo9FDAAcgpVA Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB696@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Tue, 13 Mar 2012 10:58:45 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> In-Reply-To: <201203131655.q2DGtZil087855@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.14.44516 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:42:11 -0000 Hi Francis, Please see inline. Cheers, Med > -----Message d'origine----- > De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 > Envoy=E9 : mardi 13 mars 2012 17:56 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : draft-penno-softwire-sdnat@tools.ietf.org; Softwires WG;=20 > draft-cui-softwire-b4-translated-ds-lite > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite=20 >=20 > In your previous mail you wrote: >=20 > > (*) Question 1: It is not clear in text if there is=20 > a second NAT > > in the AFTR or not. Could you please confirm/infirm=20 > a second NAT > > is present? >=20 > =3D> there is one but: > - it translates only port numbers following an algorithm Med: Ok, thanks. But this is not clear in the -02 of draft-penno-*. >=20 > - the NAT is not strictly required: one can imagine to assign > directly to a CPE its port range as it is visible from the Internet Med: Agree. > (note: 1- it should be not what we want as it makes CPEs trivial > to track, 2- it doesn't remove the mandatory check on source ports > in the from CPE to the Internet way) Med: I failed to get your first point. Could you please clarify? Thanks. > =20 > > (*) Question 2: If yes, is there any reason why you want to > > maintain that second NAT? >=20 > =3D> I can see at least 2 reasons: > - make CPE simplers (only applications which need to know=20 > what is a port > number seen from the Internet side have to enter into the second NAT > details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...)=20 > server on the CPE) Med: applications using referral need to know the external IP address. I fa= iled to see why this is simpler compared to draft-cui-*. >=20 > > (*) Question 3: If the public IP address assigned by=20 > the AFTR is > > not known to the port-restricted CPE, some=20 > applications may fail > > (referral). How the CPE will make a distinction between the > > external IP address to be assigned in the WAN and=20 > the one used in > > the AFTR? If UPnP is used, the WAN IP address should not be > > returned. >=20 > =3D> my read of the SD-NAT mechanism is the public IP address=20 > is the same > at each side of the SD-CGN. Med: This is not clear in -02 of the draft-penno-*. >=20 > > (2) Unlike draft-penno-*, draft-cui-* does not mandate=20 > any proffered > > provisioning means for port ranges; a list of alternatives is > > provided in draft-cui-* without any preference (this is=20 > deployment- > > specific): >=20 > =3D> but the ICMP-based solution is deeply broken so is it a real > advantage? >=20 > > (*) Question 4: Given this list, is there really a=20 > need for the > > proposed ICMP-based solution? >=20 > =3D> see previous item >=20 > > (*) Question 5: draft-penno-* says: "A stateless=20 > DS-Lite CPE MUST > > implement the DHCPv4 client relay option defined in=20 > [I-D.ietf-dhc- > > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > =20 > > Question 5-1: Why "MUST"? IMHO, this is=20 > deployment-specific. >=20 > =3D> no such specific: > - it makes the reasonable assumption than IPv4 addresses are assigned > using DHCPv4 Med: It is not "reasonable" when you don't have a DHCPv4 server but use PCP= for instance.=20 >=20 > > (*) Question 6: Is there any particular reason=20 > draft-penno-* does > > not mention draft-donley-behave-deterministic-cgn? >=20 > =3D> too many drafts...? Med: I think it is fair to cite draft-donley-*. More seriously I have more concerns about > too simple algorithms deployed in the SD-CGN, for instance the: > [1024...xxx] <-> [N... is good for tests or demos but makes CPEs too easy to trace, > I prefer what=20 > draft-tsou-softwire-port-set-algorithms-analysis calls GMA > (still trivial to implement and to use but harder to trace). Med: We don't have the constraint of MAP so I would not exclude pseudo-rand= om port set algos (see http://tools.ietf.org/html/draft-tsou-softwire-port-= set-algorithms-analysis-01#section-3.3) From mohamed.boucadair@orange.com Tue Mar 13 23:45:50 2012 Return-Path: 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 D6A7421F85D3 for ; Tue, 13 Mar 2012 23:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 Bl3yiVzleHP4 for ; Tue, 13 Mar 2012 23:45:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C85CB21F85C3 for ; Tue, 13 Mar 2012 23:45:49 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 17432324295; Wed, 14 Mar 2012 07:45:49 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DCB6E27C113; Wed, 14 Mar 2012 07:45:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 14 Mar 2012 07:45:48 +0100 From: To: "Rajiv Asati (rajiva)" , Francis Dupont , "ot@cisco.com" Date: Wed, 14 Mar 2012 07:45:47 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0BOiyUUcpqp8L9Te+mLvidk1wL8AAHAINQABXbXFA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB69B@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Tue, 13 Mar 2012 10:58:45 +0100.<94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> <067E6CE33034954AAC05C9EC85E2577C079FA90C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA90C@XMB-RCD-111.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.14.44516 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:45:50 -0000 Re-, Thanks Rajiv for the pointer.=20 BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must= be adjacent), draft-cui-* and the like can use pseudo-random algorithms to= generate port ranges.=20 Cheers, Med > -----Message d'origine----- > De : Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 > Envoy=E9 : mardi 13 mars 2012 21:19 > =C0 : Francis Dupont; BOUCADAIR Mohamed OLNC/NAD/TIP; ot@cisco.com > Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite;=20 > draft-penno-softwire-sdnat@tools.ietf.org > Objet : RE: [Softwires] draft-penno-softwire-sdnat=20 > vs.draft-cui-softwire-b4-translated-ds-lite >=20 > > I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls > GMA > > (still trivial to implement and to use but harder to trace). >=20 > I agree. GMA is defined here, btw - > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address- > and-port-0 > 2#section-4.1 >=20 > Cheers, > Rajiv >=20 >=20 >=20 > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > On > > Behalf Of Francis Dupont > > Sent: Tuesday, March 13, 2012 12:56 PM > > To: mohamed.boucadair@orange.com > > Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite; > draft-penno- > > softwire-sdnat@tools.ietf.org > > Subject: Re: [Softwires] draft-penno-softwire-sdnat > vs.draft-cui-softwire-b4- > > translated-ds-lite > >=20 > >=20 > > In your previous mail you wrote: > >=20 > > > (*) Question 1: It is not clear in text if there=20 > is a second > NAT > > > in the AFTR or not. Could you please=20 > confirm/infirm a second > NAT > > > is present? > >=20 > > =3D> there is one but: > > - it translates only port numbers following an algorithm > >=20 > > - the NAT is not strictly required: one can imagine to assign > > directly to a CPE its port range as it is visible from=20 > the Internet > > (note: 1- it should be not what we want as it makes CPEs trivial > > to track, 2- it doesn't remove the mandatory check on=20 > source ports > > in the from CPE to the Internet way) > >=20 > > > (*) Question 2: If yes, is there any reason why you want to > > > maintain that second NAT? > >=20 > > =3D> I can see at least 2 reasons: > > - make CPE simplers (only applications which need to know what is a > port > > number seen from the Internet side have to enter into the=20 > second NAT > > details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on > the CPE) > >=20 > > > (*) Question 3: If the public IP address assigned=20 > by the AFTR > is > > > not known to the port-restricted CPE, some applications may > fail > > > (referral). How the CPE will make a distinction=20 > between the > > > external IP address to be assigned in the WAN and the one > used in > > > the AFTR? If UPnP is used, the WAN IP address=20 > should not be > > > returned. > >=20 > > =3D> my read of the SD-NAT mechanism is the public IP address is the > same > > at each side of the SD-CGN. > >=20 > > > (2) Unlike draft-penno-*, draft-cui-* does not mandate any > proffered > > > provisioning means for port ranges; a list of alternatives is > > > provided in draft-cui-* without any preference (this is > deployment- > > > specific): > >=20 > > =3D> but the ICMP-based solution is deeply broken so is it a real > > advantage? > >=20 > > > (*) Question 4: Given this list, is there really a need for > the > > > proposed ICMP-based solution? > >=20 > > =3D> see previous item > >=20 > > > (*) Question 5: draft-penno-* says: "A stateless=20 > DS-Lite CPE > MUST > > > implement the DHCPv4 client relay option defined in > [I-D.ietf-dhc- > > > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > > > > > Question 5-1: Why "MUST"? IMHO, this is > deployment-specific. > >=20 > > =3D> no such specific: > > - it makes the reasonable assumption than IPv4 addresses=20 > are assigned > > using DHCPv4 > > - it states "DS-Lite" so there is no direct IPv4 available > > - so IMHO the question is more about the DHCPv4-over-IPv6=20 > application > > and is more for the DHC WG (BTW please don't bounce this issue > between > > the two WGs, my idea is more to make a point about=20 > DHCPv4-over-IPv6 > > itself) > >=20 > > > Question 5-2: By "external IPv4 address", do=20 > you mean the > > > address to be assigned in the AFTR (if any)? or=20 > the one to > be > > > used in the WAN interface of the CPE? > >=20 > > =3D> if they are the same the answer is easy > >=20 > > > (3) draft-penno-* advocates it is deterministic but=20 > this feature > can > > > be enforced in any IPv4 address sharing technique: > >=20 > > =3D> BTW we need a better definition of "deterministic". My proposal > > is it means the mapping follows an algorithm (and it is the case on > > the SD-CGN, BTW not on the SD-CPE). > >=20 > > > (*) Question 6: Is there any particular reason=20 > draft-penno-* > does > > > not mention draft-donley-behave-deterministic-cgn? > >=20 > > =3D> too many drafts...? More seriously I have more concerns about > > too simple algorithms deployed in the SD-CGN, for instance the: > > [1024...xxx] <-> [N... > is good for tests or demos but makes CPEs too easy to trace, > > I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls > GMA > > (still trivial to implement and to use but harder to trace). > >=20 > > Regards > >=20 > > Francis.Dupont@fdupont.fr > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > = From mohamed.boucadair@orange.com Tue Mar 13 23:49:39 2012 Return-Path: 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 5DF0021F84DA for ; Tue, 13 Mar 2012 23:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 bjGj4QipzW+z for ; Tue, 13 Mar 2012 23:49:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 97A2721F851B for ; Tue, 13 Mar 2012 23:49:38 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 008D8324623; Wed, 14 Mar 2012 07:49:38 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D6912238133; Wed, 14 Mar 2012 07:49:37 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 14 Mar 2012 07:49:37 +0100 From: To: Qiong , Francis Dupont Date: Wed, 14 Mar 2012 07:49:36 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0BdCp4hU1rqWZTSsO3FBw4hfDlpwAOgDyw Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB69C@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <201203131655.q2DGtZil087855@givry.fdupont.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E281DB69CPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.14.44516 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:49:39 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E281DB69CPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Qiong, Please see inline. Cheers, Med ________________________________ De : Qiong [mailto:bingxuere@gmail.com] Envoy=E9 : mercredi 14 mars 2012 00:50 =C0 : Francis Dupont Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; draft-cui-softwire-b4-tr= anslated-ds-lite; draft-penno-softwire-sdnat@tools.ietf.org Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b= 4-translated-ds-lite > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > provisioning means for port ranges; a list of alternatives is > provided in draft-cui-* without any preference (this is deployment- > specific): =3D> but the ICMP-based solution is deeply broken so is it a real advantage? [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the = "ICMP processing" in section 10. And we have verified that it works fine in= all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem her= e. [Med] I know it is confusing but these are two distinct issues. draft-penno= -* defines a new method using ICMP to learn ports. Please refer to http://t= ools.ietf.org/html/draft-penno-softwire-sdnat-02#section-5 --_000_94C682931C08B048B7A8645303FDC9F36E281DB69CPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Qiong,
 
Please see inline.
 
Cheers,
Med

De : Qiong [mailto:bingxuere@gma= il.com]=20
Envoy=E9 : mercredi 14 mars 2012 00:50
=C0 :=20 Francis Dupont
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwi= res=20 WG; draft-cui-softwire-b4-translated-ds-lite;=20 draft-penno-softwire-sdnat@tools.ietf.org
Objet : Re:=20 [Softwires] draft-penno-softwire-sdnat vs.=20 draft-cui-softwire-b4-translated-ds-lite


>=20     (2) Unlike draft-penno-*, draft-cui-* does not mandate an= y=20 proffered
>     provisioning means for port ranges; a l= ist=20 of alternatives is
>     provided in draft-cui-* withou= t any=20 preference (this is deployment-
>    =20 specific):

=3D> but the ICMP-based solution is deeply b= roken=20 so is it a real
advantage?
[Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have describ= ed=20 the "ICMP processing" in section 10. And we have verified that it works f= ine=20 in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem= =20 here.
 
[Med] I know it is confusing but these are two= =20 distinct issues. draft-penno-* defines a new method using ICMP to learn p= orts.=20 Please refer to http://tools.ietf.org/html/draft-penno-softwire-sdnat-02#section-5&n= bsp;
 

--_000_94C682931C08B048B7A8645303FDC9F36E281DB69CPUEXCB1Bnante_-- From despres.remi@laposte.net Wed Mar 14 01:47:50 2012 Return-Path: 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 1DBD821F86E5 for ; Wed, 14 Mar 2012 01:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.067, 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 OBesmUZNaue5 for ; Wed, 14 Mar 2012 01:47:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id B969021F86E1 for ; Wed, 14 Mar 2012 01:47:47 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id lLng1i00s37Y3f403Lng4U; Wed, 14 Mar 2012 09:47:42 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-116--927141668 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 14 Mar 2012 09:47:40 +0100 Message-Id: <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 08:47:50 -0000 --Apple-Mail-116--927141668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-14 =E0 06:51, Maoke a =E9crit : >=20 >=20 > 2012/3/13 R=E9mi Despr=E9s > 2012-03-13 12:02, Maoke : >> 2012/3/13 R=E9mi Despr=E9s > ... >=20 >>> The 4rd mechanism is for protocols that have ports at their usual = place (all existing protocols that have ports have them at the same = place, even if using another checksum algorithm like SCTP). >=20 >>=20 >> may you have a check on the statement of "all existing protocols" = again? i noticed RFC908/RFC1151. sorry if that are not a transport = protocol over IP.=20 >=20 > I missed this one. > None of the proposed stateless solutions supports it, but it remains = that you are right: it has ports at a different place. > alright. so 4rd-U doesn't not support "all existing transport = protocol" either. Never said that without qualifying which protocols. > but i suppose you may make an update in the 4rd-u-06 so that a new = "if...else..." is added the port pick-up logic, and surely the CNP is = not a problem for RDP because the old version (RFC908) has 32bit = checksum but not involving pseudo-header while the newer version = (RFC1151) changed to use TCP-checksum. no big deal but only needs a new = patch to the draft. In the Note in 4.4 (7), the first sentence is: "This guarantees that, for all protocols that use the same checksum = algorithm as TCP, Tunnel packets are valid IPv6 packets, and this = independently from where the checksum field is placed for each = protocol." It can become:=20 "This guarantees that, for all protocols that use the same checksum = algorithm as TCP and have ports at the same place, Tunnel packets are = valid IPv6 packets, and this independently from where the checksum field = is placed for each protocol." Similarly, in the comparison table, H6 is: "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as = future protocols using the TCP checksum algorithm" It can become: "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any = future protocol that might use the TCP checksum algorithm and ports at = the same place" =20 > but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. > i somehow am hard to accept words like "far fetched theoretical = problem".=20 If I had thought it might be so, I would have avoided the word. > the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >=20 > only my 2 cents.=20 With amendments above, the point is AFAIK completely covered: everything = is rigorously true, and worth noting. Thanks for the useful reference to the RDP of RFC1151. RD=20 --Apple-Mail-116--927141668 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
2012-03-13 12:02, Maoke = :
2012/3/13 = R=E9mi Despr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for = protocols that have ports at their usual place (all existing protocols = that have ports have them at the same place, even if using another = checksum algorithm like SCTP).
=

=
may you have a check on the statement of "all existing = protocols" again? i noticed RFC908/RFC1151. sorry if that are not a = transport protocol over IP. 

I missed this = one.
None of the proposed stateless solutions supports = it, but it remains that you are right: it has ports at a different = place.

alright. so 4rd-U doesn't = not support "all existing transport protocol" either. =

Never said that without = qualifying which protocols.

but i suppose you may make an update in the = 4rd-u-06 so that a new "if...else..." is added the port pick-up logic, = and surely the CNP is not a problem for RDP because the old version = (RFC908) has 32bit checksum but not involving pseudo-header while the = newer version (RFC1151) changed to use TCP-checksum. no big deal but = only needs a new patch to the = draft.

In the Note in 4.4 (7), = the first sentence is:
"This guarantees that, for all = protocols that use the same checksum algorithm as TCP, Tunnel = packets are valid IPv6 packets, and this independently from where = the checksum field is placed for each protocol."
It can = become: 
"This guarantees that, for all protocols that = use the same checksum algorithm as TCP and have ports at the same = place, Tunnel packets are valid IPv6 packets, and this = independently from where the checksum field is placed for each = protocol."

Similarly, in the comparison table, = H6 is:
"For shared IPv4 addresses, DCCP and UDP-Lite = supported, as well as future  protocols using the TCP = checksum algorithm"
It can become:
"For shared = IPv4 addresses, DCCP and UDP-Lite supported, as well any future = protocol that might use the TCP checksum algorithm and ports at the = same place"    

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to = accept words like "far fetched theoretical = problem". 

If I had = thought it might be so, I would have avoided the = word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of = RFC1151.

RD 

=


= --Apple-Mail-116--927141668-- From fibrib@gmail.com Wed Mar 14 02:00:34 2012 Return-Path: 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 12CFE21F866A for ; Wed, 14 Mar 2012 02:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 fzSjoQ0VX55C for ; Wed, 14 Mar 2012 02:00:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1A21F8663 for ; Wed, 14 Mar 2012 02:00:28 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1753543ghb.31 for ; Wed, 14 Mar 2012 02:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zJvT8arjJDr5jkKArKaAP6GREKpwbj/qwApdGgBnPBc=; b=N8uBvSRdg4PoFKAFWh5jpMRhjAMgvyCqa+bwnZjCp7OOePncdY1CGAdM44G4I6RFPZ 1Xo3mkiyOl3UvlWiR3niT8H7sr0qnAMYI7BhaVcEZzFzD6P2DSgBn+GmUQju+wxXw4sJ TZPKgjqGOhnOp9sOY2TQbOYuJ/Q5bB8IYg157WFIs97RxFXjeHueChOzRAMo424qcUqv mLt2MGMWS5yaTOhpCL6l2wLEAvlsa7AJKYkj71JVa6pobqxs6zGJQpCpU2TjItqgGOJl 9pAx5Ah+r/Qaf7y/VkBTZXX2Y3oU3RENt/JH1+HQc7QO7O7WNrUrhAjlh3wYTy6NEsqk kf3g== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr587860qct.9.1331715627655; Wed, 14 Mar 2012 02:00:27 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Wed, 14 Mar 2012 02:00:27 -0700 (PDT) In-Reply-To: <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> Date: Wed, 14 Mar 2012 09:00:27 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=002354530350eda12d04bb3034c8 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:00:34 -0000 --002354530350eda12d04bb3034c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/14 R=E9mi Despr=E9s > > Le 2012-03-14 =E0 06:51, Maoke a =E9crit : > > > > 2012/3/13 R=E9mi Despr=E9s > >> 2012-03-13 12:02, Maoke : >> >> 2012/3/13 R=E9mi Despr=E9s >> >> ... >> >> The 4rd mechanism is for protocols that have ports at their usual place >>>> (all existing protocols that have ports have them at the same place, e= ven >>>> if using another checksum algorithm like SCTP). >>>> >>> >> may you have a check on the statement of "all existing protocols" >> again? i noticed RFC908/RFC1151. sorry if that are not a transport proto= col >> over IP. >> >> >> I missed this one. >> None of the proposed stateless solutions supports it, but it remains tha= t >> you are right: it has ports at a different place. >> > > alright. so 4rd-U doesn't not support "all existing transport protocol" > either. > > > Never said that without qualifying which protocols. > > but i suppose you may make an update in the 4rd-u-06 so that a new > "if...else..." is added the port pick-up logic, and surely the CNP is not= a > problem for RDP because the old version (RFC908) has 32bit checksum but n= ot > involving pseudo-header while the newer version (RFC1151) changed to use > TCP-checksum. no big deal but only needs a new patch to the draft. > > > In the Note in 4.4 (7), the first sentence is: > "This guarantees that, for all protocols that use the same checksum > algorithm as TCP, Tunnel packets are valid IPv6 packets, and this > independently from where the checksum field is placed for each protocol." > It can become: > "This guarantees that, for all protocols that use the same checksum > algorithm as TCP and have ports at the same place, Tunnel packets are > valid IPv6 packets, and this independently from where the checksum field = is > placed for each protocol." > > Similarly, in the comparison table, H6 is: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as > future protocols using the TCP checksum algorithm" > It can become: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any > future protocol that might use the TCP checksum algorithm and ports at th= e > same place" > then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's "optional") - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation ;-) maoke > > but this is not my point. my point is: there must be something we don't > know ("non omnia possumus omnes"). even we have gone through the RFCs, > there might be some other proprietary L4 protocols, or experimental > protocols. even they are minority, i don't think ignoring their existance > in our solution fits the spirit of the Internet. it might be argued that > NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may > makes his own NAT44, either attached to the CE or separated. if 4rd-U > respects such an effort, it should state "currently blahblabla L4 protoco= ls > are supported". the similar statement applies to the RFC6145 or MAP as we= ll. > > > i somehow am hard to accept words like "far fetched theoretical problem". > > > If I had thought it might be so, I would have avoided the word. > > > the L4-recalculate is a generic, architectural solution, surely needing > codes for every L4 protocol. but this generality in architecture makes > RFC6145 or MAP-T equipment be easily enhanced to support anything new wit= h > the same logic. but for the 4rd-U BR, it looks to me we cannot have the > unified logic for all (even limited to existing and well-known) L4 > protocols. > > only my 2 cents. > > > With amendments above, the point is AFAIK completely covered: everything > is rigorously true, and worth noting. > Thanks for the useful reference to the RDP of RFC1151. > > RD > > > > > --002354530350eda12d04bb3034c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-14 =E0 06:51, = Maoke a =E9crit :


=
2012/3/13 R=E9mi Despr=E9s <despres.= remi@laposte.net>
2012-03-13 12:02, Maoke :
2012/3/13 R=E9mi Des= pr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for prot= ocols that have ports at their usual place (all existing protocols that hav= e ports have them at the same place, even if using another checksum algorit= hm like SCTP).

may you have a check on the statement of "all existing prot= ocols" again? i noticed RFC908/RFC1151. sorry if that are not a transp= ort protocol over IP.=A0

I missed this one.
None o= f the=A0proposed stateless solutions supports it, but it remains that you a= re right: it has ports at a different place.

= alright. so 4rd-U doesn't not support "all existing transport prot= ocol" either.

Never= said that without qualifying which protocols.

=
but i suppose you may make an update in the 4rd-u-06 so that a new &qu= ot;if...else..." is added the port pick-up logic, and surely the CNP i= s not a problem for RDP because the old version (RFC908) has 32bit checksum= but not involving pseudo-header while the newer version (RFC1151) changed = to use TCP-checksum. no big deal but only needs a new patch to the draft.

In the Note in 4.4 (7), the first s= entence is:
"This guarantees that, for all= protocols that use the=A0same checksum algorithm as TCP, Tunnel packets ar= e valid=A0IPv6 packets, and this independently from where the=A0checksum fi= eld is placed for each protocol."
It can become:=A0
"This guarantees that, for all = protocols that use the=A0same checksum algorithm as TCP and have ports at t= he same place, Tunnel packets are valid=A0IPv6 packets, and this independen= tly from where the=A0checksum field is placed for each protocol."

Similarly, in the comparison table, H6 is:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as well = as future=A0=A0protocols using the TCP checksum=A0algorithm"
It can become:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as wel= l any future protocol that might use the TCP checksum=A0algorithm and ports= at the same place"=A0=A0 =A0

<= /div>
then it is fine. with these statement, 4rd-U can support=A0
- TCP= =A0
- UDP
- DCCP
- any future or less well-kn= own protocol as long as it uses TCP checksum and port at the same place

as a counterpart, we may suggest MAP-T to state it supp= orts=A0
- TCP
- UDP
- DCCP (with enforcing it= rather than RFC6145's "optional")=A0
- any future = or less well-known protocol, no matter what layout it is nor how the checks= um is defined, with the similar logic of L4 checksum recalculation=A0

;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


<= div class=3D"gmail_quote">
the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0




--002354530350eda12d04bb3034c8-- From despres.remi@laposte.net Wed Mar 14 02:29:19 2012 Return-Path: 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 EE82321F85A0 for ; Wed, 14 Mar 2012 02:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.064, 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 wmy6fXy+5mea for ; Wed, 14 Mar 2012 02:29:19 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 817F921F86E8 for ; Wed, 14 Mar 2012 02:29:17 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id lMVC1i00C37Y3f403MVDqX; Wed, 14 Mar 2012 10:29:15 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-117--924649142 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 14 Mar 2012 10:29:12 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:29:20 -0000 --Apple-Mail-117--924649142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-14 =E0 10:00, Maoke a =E9crit : >=20 >=20 > 2012/3/14 R=E9mi Despr=E9s >=20 > Le 2012-03-14 =E0 06:51, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/13 R=E9mi Despr=E9s >> 2012-03-13 12:02, Maoke : >>> 2012/3/13 R=E9mi Despr=E9s >> ... >>=20 >>>> The 4rd mechanism is for protocols that have ports at their usual = place (all existing protocols that have ports have them at the same = place, even if using another checksum algorithm like SCTP). >>=20 >>>=20 >>> may you have a check on the statement of "all existing protocols" = again? i noticed RFC908/RFC1151. sorry if that are not a transport = protocol over IP.=20 >>=20 >> I missed this one. >> None of the proposed stateless solutions supports it, but it remains = that you are right: it has ports at a different place. >=20 >> alright. so 4rd-U doesn't not support "all existing transport = protocol" either. >=20 > Never said that without qualifying which protocols. >=20 >> but i suppose you may make an update in the 4rd-u-06 so that a new = "if...else..." is added the port pick-up logic, and surely the CNP is = not a problem for RDP because the old version (RFC908) has 32bit = checksum but not involving pseudo-header while the newer version = (RFC1151) changed to use TCP-checksum. no big deal but only needs a new = patch to the draft. >=20 > In the Note in 4.4 (7), the first sentence is: > "This guarantees that, for all protocols that use the same checksum = algorithm as TCP, Tunnel packets are valid IPv6 packets, and this = independently from where the checksum field is placed for each = protocol." > It can become:=20 > "This guarantees that, for all protocols that use the same checksum = algorithm as TCP and have ports at the same place, Tunnel packets are = valid IPv6 packets, and this independently from where the checksum field = is placed for each protocol." >=20 > Similarly, in the comparison table, H6 is: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as = future protocols using the TCP checksum algorithm" > It can become: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any = future protocol that might use the TCP checksum algorithm and ports at = the same place" =20 >=20 > then it is fine. with these statement, 4rd-U can support=20 > - TCP=20 > - UDP > - DCCP > - any future or less well-known protocol as long as it uses TCP = checksum and port at the same place >=20 > as a counterpart, we may suggest MAP-T to state it supports=20 > - TCP > - UDP > - DCCP (with enforcing it rather than RFC6145's "optional")=20 > - any future or less well-known protocol, no matter what layout it is = nor how the checksum is defined, with the similar logic of L4 checksum = recalculation=20 Maybe I get the point you are making: you implicitly consider that BR = and CE modifications can be synchronized. This is feasible if ISPs = provide all CE nodes, but not in the general case. =20 Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). =20 To be even more precise, H6 of the comparison table can be: "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" Does this cover the point? RD >=20 > ;-) > maoke=20 > =20 >=20 >> but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >=20 >> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >=20 > If I had thought it might be so, I would have avoided the word. >=20 >=20 >> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>=20 >> only my 2 cents.=20 >=20 > With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. > Thanks for the useful reference to the RDP of RFC1151. >=20 > RD=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail-117--924649142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-14 =E0 = 06:51, Maoke a =E9crit :



2012/3/13 R=E9mi = Despr=E9s <despres.remi@laposte.net>
2012-03-13 12:02, Maoke = :
2012/3/13 = R=E9mi Despr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for = protocols that have ports at their usual place (all existing protocols = that have ports have them at the same place, even if using another = checksum algorithm like SCTP).
=

=
may you have a check on the statement of "all existing = protocols" again? i noticed RFC908/RFC1151. sorry if that are not a = transport protocol over IP. 

I missed this = one.
None of the proposed stateless solutions supports = it, but it remains that you are right: it has ports at a different = place.

alright. so 4rd-U doesn't not support "all = existing transport protocol" either. =

Never said that = without qualifying which protocols.

but i suppose you may make an update in the = 4rd-u-06 so that a new "if...else..." is added the port pick-up logic, = and surely the CNP is not a problem for RDP because the old version = (RFC908) has 32bit checksum but not involving pseudo-header while the = newer version (RFC1151) changed to use TCP-checksum. no big deal but = only needs a new patch to the draft.

In the Note in 4.4 (7), the = first sentence is:
"This guarantees that, = for all protocols that use the same checksum algorithm as TCP, = Tunnel packets are valid IPv6 packets, and this independently from = where the checksum field is placed for each protocol."
It can become: 
"This guarantees that, for all = protocols that use the same checksum algorithm as TCP and have = ports at the same place, Tunnel packets are valid IPv6 packets, and = this independently from where the checksum field is placed for each = protocol."

Similarly, in the comparison table, H6 = is:
"For shared IPv4 addresses, DCCP and UDP-Lite = supported, as well as future  protocols using the TCP = checksum algorithm"
It can become:
"For shared IPv4 addresses, DCCP and UDP-Lite supported, as = well any future protocol that might use the TCP checksum algorithm = and ports at the same place"   =  

then it is fine. with these statement, 4rd-U can = support 
- TCP 
- UDP
- = DCCP
- any future or less well-known protocol as long as it = uses TCP checksum and port at the same place

as a counterpart, we may suggest MAP-T to state it = supports 
- TCP
- UDP
- DCCP (with = enforcing it rather than RFC6145's "optional") 
- any = future or less well-known protocol, no matter what layout it is nor how = the checksum is defined, with the similar logic of L4 checksum = recalculation 

Maybe= I get the point you are making: you implicitly consider that BR = and CE modifications can be synchronized. This is feasible if ISPs = provide all CE nodes, but not in the general = case.
  
Changing DCCP support from = optional to mandatory in RFC6145 isn't backward compatible (an upgraded = node isn't guaranteed to interwork with a non upgraded = node).
 
To be even more precise, H6 of the = comparison table can be:
"For ISPs that don't provide all CE = nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, = as well as future protocols using the TCP checksum algorithm and ports = at the same place"

Does this cover the = point?

RD




= =

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=




= --Apple-Mail-117--924649142-- From fibrib@gmail.com Wed Mar 14 02:46:08 2012 Return-Path: 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 7912D21F8718 for ; Wed, 14 Mar 2012 02:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 j3sRhlDkyB4m for ; Wed, 14 Mar 2012 02:46:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33CBF21F871C for ; Wed, 14 Mar 2012 02:46:07 -0700 (PDT) Received: by yenm5 with SMTP id m5so1801490yen.31 for ; Wed, 14 Mar 2012 02:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pxWPz0TauCkON/+3IOT5Wo3EVvn8yfEQyvx4t6h/Jxk=; b=xaZ4AQGEeEeghQzqwhM43Ayqnzuwrz7JoIGzTzeCzudsC26EtLQbYDRiqaPfMk3wc5 iVtBULurPKXsfWSxOh3WxXhybjROA9Zvvpeg5oTuemdZTX8HswMhBhr2eWCgUjeUtw7Y bauSvQJMjsHs+8D9Ch96M3UVxqL7GbMld4ZznUBN0wQKDPkS4ZSUMlPq3NoFJWRDY8II 5wprYpKEtZ8hH9V/L5spYQtS/XllHndO2hNDcGzDpzGM1Czv0K0UzcCdzuXDW7LcdgGF xR3mEruWkIyRUw1XIuwBSmCq4AjmAD2w3xrbaY1P7oCep6tZvQCRt5a3iNVVCB7SgBTJ /Caw== MIME-Version: 1.0 Received: by 10.224.101.130 with SMTP id c2mr2218230qao.47.1331718366558; Wed, 14 Mar 2012 02:46:06 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Wed, 14 Mar 2012 02:46:06 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> Date: Wed, 14 Mar 2012 09:46:06 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b7942dfb4d04bb30d8b6 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:46:08 -0000 --20cf3074b7942dfb4d04bb30d8b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/14 R=E9mi Despr=E9s > > Le 2012-03-14 =E0 10:00, Maoke a =E9crit : > > > > 2012/3/14 R=E9mi Despr=E9s > >> >> Le 2012-03-14 =E0 06:51, Maoke a =E9crit : >> >> >> >> 2012/3/13 R=E9mi Despr=E9s >> >>> 2012-03-13 12:02, Maoke : >>> >>> 2012/3/13 R=E9mi Despr=E9s >>> >>> ... >>> >>> The 4rd mechanism is for protocols that have ports at their usual >>>>> place (all existing protocols that have ports have them at the same p= lace, >>>>> even if using another checksum algorithm like SCTP). >>>>> >>>> >>> may you have a check on the statement of "all existing protocols" >>> again? i noticed RFC908/RFC1151. sorry if that are not a transport prot= ocol >>> over IP. >>> >>> >>> I missed this one. >>> None of the proposed stateless solutions supports it, but it remains >>> that you are right: it has ports at a different place. >>> >> >> alright. so 4rd-U doesn't not support "all existing transport protocol" >> either. >> >> >> Never said that without qualifying which protocols. >> >> but i suppose you may make an update in the 4rd-u-06 so that a new >> "if...else..." is added the port pick-up logic, and surely the CNP is no= t a >> problem for RDP because the old version (RFC908) has 32bit checksum but = not >> involving pseudo-header while the newer version (RFC1151) changed to use >> TCP-checksum. no big deal but only needs a new patch to the draft. >> >> >> In the Note in 4.4 (7), the first sentence is: >> "This guarantees that, for all protocols that use the same checksum >> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this >> independently from where the checksum field is placed for each protocol.= " >> It can become: >> "This guarantees that, for all protocols that use the same checksum >> algorithm as TCP and have ports at the same place, Tunnel packets are >> valid IPv6 packets, and this independently from where the checksum field= is >> placed for each protocol." >> >> Similarly, in the comparison table, H6 is: >> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as >> future protocols using the TCP checksum algorithm" >> It can become: >> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any >> future protocol that might use the TCP checksum algorithm and ports at t= he >> same place" >> > > then it is fine. with these statement, 4rd-U can support > - TCP > - UDP > - DCCP > - any future or less well-known protocol as long as it uses TCP checksum > and port at the same place > > as a counterpart, we may suggest MAP-T to state it supports > - TCP > - UDP > - DCCP (with enforcing it rather than RFC6145's "optional") > - any future or less well-known protocol, no matter what layout it is nor > how the checksum is defined, with the similar logic of L4 checksum > recalculation > > > Maybe I get the point you are making: you implicitly consider that BR and > CE modifications can be synchronized. This is feasible if ISPs provide al= l > CE nodes, but not in the general case. > i don't consider their modifications are synced but i do consider that each device, either BR or CE, should has a specification on its supported functionalities. > > Changing DCCP support from optional to mandatory in RFC6145 isn't backwar= d > compatible (an upgraded node isn't guaranteed to interwork with a non > upgraded node). > the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. > > To be even more precise, H6 of the comparison table can be: > "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, > DCCP and UDP-Lite are supported, as well as future protocols using the TC= P > checksum algorithm and ports at the same place" > i actually think the original text is fine. "For .... shared IPv4 addresses" is not needed for 4rd-U, to my understanding, nor needed to MAP-T. maoke > > Does this cover the point? > > RD > > > > > > ;-) > maoke > > >> >> but this is not my point. my point is: there must be something we don't >> know ("non omnia possumus omnes"). even we have gone through the RFCs, >> there might be some other proprietary L4 protocols, or experimental >> protocols. even they are minority, i don't think ignoring their existanc= e >> in our solution fits the spirit of the Internet. it might be argued that >> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner ma= y >> makes his own NAT44, either attached to the CE or separated. if 4rd-U >> respects such an effort, it should state "currently blahblabla L4 protoc= ols >> are supported". the similar statement applies to the RFC6145 or MAP as w= ell. >> >> >> i somehow am hard to accept words like "far fetched theoretical problem"= . >> >> >> If I had thought it might be so, I would have avoided the word. >> >> >> the L4-recalculate is a generic, architectural solution, surely needing >> codes for every L4 protocol. but this generality in architecture makes >> RFC6145 or MAP-T equipment be easily enhanced to support anything new wi= th >> the same logic. but for the 4rd-U BR, it looks to me we cannot have the >> unified logic for all (even limited to existing and well-known) L4 >> protocols. >> >> only my 2 cents. >> >> >> With amendments above, the point is AFAIK completely covered: everything >> is rigorously true, and worth noting. >> Thanks for the useful reference to the RDP of RFC1151. >> >> RD >> >> >> >> >> > > --20cf3074b7942dfb4d04bb30d8b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-14 =E0 10:00, = Maoke a =E9crit :



2012/3/14 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-14 =E0 06:51, = Maoke a =E9crit :



2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte= .net>
2012-03-13 12:02, Maoke :
2012/3/13 R=E9mi Des= pr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for prot= ocols that have ports at their usual place (all existing protocols that hav= e ports have them at the same place, even if using another checksum algorit= hm like SCTP).

may you have a check on the statement of "all existing prot= ocols" again? i noticed RFC908/RFC1151. sorry if that are not a transp= ort protocol over IP.=A0

I missed this one.
None o= f the=A0proposed stateless solutions supports it, but it remains that you a= re right: it has ports at a different place.

= alright. so 4rd-U doesn't not support "all existing transport prot= ocol" either.

Never= said that without qualifying which protocols.

but i su= ppose you may make an update in the 4rd-u-06 so that a new "if...else.= .." is added the port pick-up logic, and surely the CNP is not a probl= em for RDP because the old version (RFC908) has 32bit checksum but not invo= lving pseudo-header while the newer version (RFC1151) changed to use TCP-ch= ecksum. no big deal but only needs a new patch to the draft.

In the Note in 4.4 (7), the first s= entence is:
"This guarantees that, for all protocols th= at use the=A0same checksum algorithm as TCP, Tunnel packets are valid=A0IPv= 6 packets, and this independently from where the=A0checksum field is placed= for each protocol."
It can become:=A0
"This guarantees that, for all = protocols that use the=A0same checksum algorithm as TCP and have ports at t= he same place, Tunnel packets are valid=A0IPv6 packets, and this independen= tly from where the=A0checksum field is placed for each protocol."

Similarly, in the comparison table, H6 is:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as well = as future=A0=A0protocols using the TCP checksum=A0algorithm"
It can become:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as wel= l any future protocol that might use the TCP checksum=A0algorithm and ports= at the same place"=A0=A0 =A0

<= /div>
then it is fine. with these statement, 4rd-U can support=A0
- TCP= =A0
- UDP
- DCCP
- any future or less well-kn= own protocol as long as it uses TCP checksum and port at the same place

as a counterpart, we may suggest MAP-T to state it supp= orts=A0
- TCP
- UDP
- DCCP (with enforcing it= rather than RFC6145's "optional")=A0
- any future = or less well-known protocol, no matter what layout it is nor how the checks= um is defined, with the similar logic of L4 checksum recalculation=A0

Maybe I get the poi= nt you are making:=A0you implicitly consider that BR and CE modifications c= an be synchronized. This is feasible if ISPs provide all CE nodes, but not = in the general case.

i don't consider the= ir modifications are synced but i do consider that each device, either BR o= r CE, should has a specification on its supported functionalities.=A0
=A0
=A0=A0
Changing DCCP support from optional t= o mandatory in RFC6145 isn't backward compatible (an upgraded node isn&= #39;t guaranteed to interwork with a non upgraded node).

the CE/BR spe= cified RFC6145-compliant might be a problem but MAP-T is still in developme= nt. if we state to enforce DCCP mandatorily rather than optional in MAP-T, = a MAP-T-compliant CE/BR won't has the backward compatible problem. to t= his extend, MAP-T is at the same kick-off line of the 4rd-U.=A0
=A0
=A0
To be even more precise, H6 of the compa= rison table can be:
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0






--20cf3074b7942dfb4d04bb30d8b6-- From despres.remi@laposte.net Wed Mar 14 03:39:37 2012 Return-Path: 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 86CEE21F8617 for ; Wed, 14 Mar 2012 03:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 XAoBW0PHuz+Z for ; Wed, 14 Mar 2012 03:39:36 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C36B521F85FB for ; Wed, 14 Mar 2012 03:39:22 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id E617E94003E; Wed, 14 Mar 2012 11:39:14 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 11:39:13 +0100 Message-Id: To: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] MAP support of IPv4 prefixes? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:39:37 -0000 Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, Sec. 1 says:: "the residual IPv4 over IPv6 mechanisms must be capable = of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 = address." (We all agree, I think, that this is important.) Sec.5.2 says: " The MAP IPv6 address is created by concatenating the End-user IPv6 = prefix with the MAP subnet-id and the interface-id as specified in = Section 6." Sec6 says: "The Interface identifier format is based on the format specified in = section 2.2 of [RFC6052], with the added PSID format field" (i.e. with = at least a full embedded IPv4 address) What should be done for a CE that is provisioned an IPv4 prefix, i.e. = several IPv4 addresses, is in my understanding unclear. Could you please clarify the intent? Thanks, RD From adurand@juniper.net Wed Mar 14 04:11:31 2012 Return-Path: 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 5F92F21F878E for ; Wed, 14 Mar 2012 04:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fVN3NVoZPYL6 for ; Wed, 14 Mar 2012 04:11:30 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3D21F8793 for ; Wed, 14 Mar 2012 04:11:27 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT2B814CrrO0kv9dFTZ8Jg07zi0IkampM@postini.com; Wed, 14 Mar 2012 04:11:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 14 Mar 2012 04:10:37 -0700 From: Alain Durand To: " " Date: Wed, 14 Mar 2012 04:10:39 -0700 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0B0xVsAvetz5yBS0OxavXS5XEhww== Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 11:11:31 -0000 Hi Med, see inline response to your questions wrt sd-nat-02 On Mar 13, 2012, at 10:58 AM, > > wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the corr= ect IPv4 address and port by the CPE before being encapsulated in IPv6. In = that scenario, the AFTR decapsulate the traffic, check IPv4 address & port = range are indeed assigned to that IPv6 user, then forward the packet. There= is only one level of NAT, done by the CPE In 'compatibility' mode, if the CPE fails to enforce the proper port range,= the AFTR will perform a second level of NAT. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or DS-= lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassign]. Bes= ides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoord] f= or one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to imp= lementation is a serious shortcoming. We need to standardize one method. (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.". Question 5-1: Why "MUST"? IMHO, this is deployment-specific. Same as above, we need to have one common technology that is implemented by= everyone. This is the only way to guaranty interoperability. Question 5-2: By "external IPv4 address", do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? The IPv4 address to put as src address of v4 traffic by the CPE before enca= psulating in IPv6 and sending to AFTR. (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? No Alain. From pengwu.thu@gmail.com Wed Mar 14 05:07:36 2012 Return-Path: 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 4694921F875A for ; Wed, 14 Mar 2012 05:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] 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 WyblE7Zkoweh for ; Wed, 14 Mar 2012 05:07:35 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6574D21F8757 for ; Wed, 14 Mar 2012 05:07:35 -0700 (PDT) Received: by yenm5 with SMTP id m5so1963842yen.31 for ; Wed, 14 Mar 2012 05:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qBsl0/X1uf4eV0q06/LUyUlBqwvhXUvevElf/4n2vMw=; b=zGeiR3dRHhWEBilgTHtbDjADKuRPcyBGuHSiEpAege/cVrBjrQPdJKNffMhpJ0tv4G Mm2l6/W21LAri6p3PDQ7SCYi/eAqa4rA9nQBGhWpgls5tkqfr3kEY+IA9nRmm6xn2qmE EAXVpKKzCHstD8Zse+KMtTdD4c/4Ln3ptBwVVIq7nWI1YH9/SdiOw1sGRM6yp44wc8Mv E1fwlhRvk+hNw2CYAOZ78f5D9Kmtxd/P5nc/av0aVQhob4AafSvhwtPZMu4ZJu/KUNuJ mgFr1r/yvGLT2/jdvzb1nMz0Wti+T/kIlOFLVFByFzt2lGoSZtfs5zF5s/eGjJZpKQcW oMmQ== MIME-Version: 1.0 Received: by 10.68.220.129 with SMTP id pw1mr3006751pbc.27.1331726854726; Wed, 14 Mar 2012 05:07:34 -0700 (PDT) Received: by 10.68.213.2 with HTTP; Wed, 14 Mar 2012 05:07:34 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 14 Mar 2012 20:07:34 +0800 Message-ID: From: Peng Wu To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:07:36 -0000 Hi Alain, It's a little confusing now. Let me try to get things clear. So the sd-nat-02 is not quite similar to the earlier version, the mechanism somehow changes. In my understanding, now the principle of the mechanism is similar to the lightweight 4over6 draft, but I may miss something here. My question is, how is it stateless or deterministic, and how is IPv6 anycast for multiple AFTRs working? Seems the draft is suggesting that we put an identical profile on each AFTR, the content of which is the mapping between IPv6 address and IPv4 address+port range for all the CPEs (And of course, we can try to find some protocol to synchronize the mapping automatically). Did I get this correctly? 2012/3/14 Alain Durand : > Hi Med, see inline response to your questions wrt sd-nat-02 > > On Mar 13, 2012, at 10:58 AM, > > wrote: > > > > =A0 =A0 =A0(*) Question 1: It is not clear in text if there is a second N= AT > =A0 =A0 =A0in the AFTR or not. =A0Could you please confirm/infirm a secon= d NAT > =A0 =A0 =A0is present? > > > in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the co= rrect IPv4 address and port by the CPE before being encapsulated in IPv6. I= n that scenario, the AFTR decapsulate the traffic, check IPv4 address & por= t range are indeed assigned to that IPv6 user, then forward the packet. The= re is only one level of NAT, done by the CPE > > In 'compatibility' mode, if the CPE fails to enforce the proper port rang= e, the AFTR will perform a second level of NAT. > > =A0 =A0 =A0(*) Question 2: If yes, is there any reason why you want to > =A0 =A0 =A0maintain that second NAT? > > > in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or D= S-lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. > > > =A0 =A0 =A0(*) Question 3: If the public IP address assigned by the AFTR = is > =A0 =A0 =A0not known to the port-restricted CPE, some applications may fa= il > =A0 =A0 =A0(referral). =A0How the CPE will make a distinction between the > =A0 =A0 =A0external IP address to be assigned in the WAN and the one used= in > =A0 =A0 =A0the AFTR? =A0If UPnP is used, the WAN IP address should not be > =A0 =A0 =A0returned. > > In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 > > > =A0 (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > =A0 provisioning means for port ranges; a list of alternatives is > =A0 provided in draft-cui-* without any preference (this is deployment- > =A0 specific): > > =A0 o =A0DHCPv4: the DHCPv4 protocol should be extended to support port-s= et > =A0 =A0 =A0allocation [I-D.bajko-pripaddrassign= ]. =A0Besides, the DHCP message > =A0 =A0 =A0should send to the concentrator over IPv6. =A0The concentrator= can > =A0 =A0 =A0be the DHCP server or DHCP relay > =A0 =A0 =A0agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. > > =A0 o =A0PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP > =A0 =A0 =A0requests simultaneously to acquire a number ports within the s= ame > =A0 =A0 =A0IPv4 address, or use [I-D.tsou-pcp-natcoord] for one-time port-set > =A0 =A0 =A0allocation. > > =A0 o =A0DHCPv6: the DHCPv6 protocol should be extended to support port-s= et > =A0 =A0 =A0allocation [I-D.boucadair-dhcpv6-shared-address-option]. > > =A0 o =A0IPCP: IPCP should be extended to carry the port-set. =A0[RFC6431= ] > =A0 =A0 =A0gives an example. > > =A0 =A0 =A0(*) Question 4: Given this list, is there really a need for th= e > =A0 =A0 =A0proposed ICMP-based solution? > > > IMHO, not specifying the technology to get pot range and living this to i= mplementation is a serious shortcoming. > We need to standardize one method. > > > =A0 =A0 =A0(*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE M= UST > =A0 =A0 =A0implement the DHCPv4 client relay option defined in [I-D.ietf-= dhc- > =A0 =A0 =A0dhcpv4-over-ipv6] to learn is external IPv4 address.". > > =A0 =A0 =A0 =A0 Question 5-1: Why "MUST"? =A0IMHO, this is deployment-spe= cific. > > > Same as above, we need to have one common technology that is implemented = by everyone. This is the only way > to guaranty interoperability. > > > > =A0 =A0 =A0 =A0 Question 5-2: By "external IPv4 address", do you mean the > =A0 =A0 =A0 =A0 address to be assigned in the AFTR (if any)? or the one t= o be > =A0 =A0 =A0 =A0 used in the WAN interface of the CPE? > > > The IPv4 address to put as src address of v4 traffic by the CPE before en= capsulating in IPv6 and sending to AFTR. > > > > =A0 =A0(3) draft-penno-* advocates it is deterministic but this feature c= an > > =A0 be enforced in any IPv4 address sharing technique: > > =A0 =A0 =A0(*) Question 6: Is there any particular reason draft-penno-* d= oes > =A0 =A0 =A0not mention draft-donley-behave-deterministic-cgn? > > > No > > Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ot@cisco.com Wed Mar 14 05:18:17 2012 Return-Path: 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 3326821F8780 for ; Wed, 14 Mar 2012 05:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 gxM2wZmziNGQ for ; Wed, 14 Mar 2012 05:18:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 390BF21F877F for ; Wed, 14 Mar 2012 05:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=1206; q=dns/txt; s=iport; t=1331727496; x=1332937096; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NZwpN23n/+dbJaOBEmPttYuVYke350usKhTkZYDwni0=; b=S1NnaYG2UMH1I9NVdOEd77qD7CkW0P8jvcNc1QTjz4hKAlDKxzGjqk6s hCAG602qyt6aiwc4NkbgvsMHejrkJZDix/RHtS51K5jtsW4LaBl01dpi3 B5VFMRELRTx9oz8nrfEUJEx6MUtPspEgMrkslx8LF3Z3wOM0HMwhcv6yJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADmLYE+Q/khR/2dsb2JhbABDtiqBB4IJAQEBAwESASc/BQsLRlcGNYdjBZ0PnyiQG2MEiFeMf45AgWiDBg X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="132278235" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 12:18:14 +0000 Received: from dhcp-10-61-96-156.cisco.com (dhcp-10-61-96-156.cisco.com [10.61.96.156]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2ECIDri019045; Wed, 14 Mar 2012 12:18:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 14 Mar 2012 05:17:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] MAP support of IPv4 prefixes? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:18:17 -0000 Remi, > Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, >=20 > Sec. 1 says:: > "the residual IPv4 over IPv6 mechanisms must be capable = of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 = address." > (We all agree, I think, that this is important.) >=20 > Sec.5.2 says: > " The MAP IPv6 address is created by concatenating the End-user IPv6 = prefix with the MAP subnet-id and the interface-id as specified in = Section 6." >=20 > Sec6 says: > "The Interface identifier format is based on the format specified in = section 2.2 of [RFC6052], with the added PSID format field" (i.e. with = at least a full embedded IPv4 address) >=20 > What should be done for a CE that is provisioned an IPv4 prefix, i.e. = several IPv4 addresses, is in my understanding unclear. > Could you please clarify the intent? section 6 says: In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeroes up to 32 bits. The PSID field is left-padded to create a 16 bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero. if you find this unclear, feel free to contribute better text. cheers, Ole= From Francis.Dupont@fdupont.fr Wed Mar 14 05:44:25 2012 Return-Path: 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 686F421F87A7 for ; Wed, 14 Mar 2012 05:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] 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 YA+WL31vzUQT for ; Wed, 14 Mar 2012 05:44:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id C9FCF21F86F7 for ; Wed, 14 Mar 2012 05:44:15 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2ECiBDo062533; Wed, 14 Mar 2012 13:44:11 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203141244.q2ECiBDo062533@givry.fdupont.fr> From: Francis Dupont To: Qiong In-reply-to: Your message of Wed, 14 Mar 2012 07:50:27 +0800. Date: Wed, 14 Mar 2012 13:44:11 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:44:25 -0000 In your previous mail you wrote: > > In your previous mail you wrote: > > > > > (*) Question 1: It is not clear in text if there is a second NAT > > > in the AFTR or not. Could you please confirm/infirm a second NAT > > > is present? > > > > => there is one but: > > - it translates only port numbers following an algorithm > > > > - the NAT is not strictly required: one can imagine to assign > > directly to a CPE its port range as it is visible from the Internet > > (note: 1- it should be not what we want as it makes CPEs trivial > > to track, 2- it doesn't remove the mandatory check on source ports > > in the from CPE to the Internet way) > > > [Qiong] Thanks for clarification. It seems this is not mentioned when to > adopt and how to process the second NAT in current version of sd-nat. But > still, I would prefer a solution without double-NAT. => my answer is simple: 1- it is technically possible but IMHO should not be deployed in the real world. 2- one can avoid only the second NAT itself, not the packet reassembly for instance. 3- the second NAT is a pretty simple one and is stateless (i.e., you can drop the CGN box and hotplug a replacement box with the same config: customers should see only the packets dropped during the operation. BTW we have a plan to show this at the next IETF meeting). > > => but the ICMP-based solution is deeply broken so is it a real > > advantage? > > > [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the > "ICMP processing" in section 10. And we have verified that it works fine in > all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. => my comment was about the ICMP-base solution for the configuration in Reinaldo Penno's I-D. Of course I have no concern about raising admin prohib ICMPs when a port out-of-range packet is filtered (in fact it is a great idea). For the ICMP echo service you can map it using the ID as the (source) port, it works well but if you'd like to use this from the Internet side you need a modified ping where you can set the ID to use (I can provide one if you want to try: IMHO it is better to be able to ping SD-CPEs and not only the SD-CGN). > > > Question 5-1: Why "MUST"? IMHO, this is deployment-specific. > > > => no such specific: > > - it makes the reasonable assumption than IPv4 addresses are assigned > > using DHCPv4 > > - it states "DS-Lite" so there is no direct IPv4 available > > - so IMHO the question is more about the DHCPv4-over-IPv6 application > > and is more for the DHC WG (BTW please don't bounce this issue between > > the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 > > itself) > > > [Qiong] I still think it is deployment-specific. For operators who perfer > to deploy PCP solution, it is nature for them to adopt PCP-base or > PCP-extension (pcp-natcoord). For operators who would like to deploy > DHCPv4-over-IPv6, port-range can be assigned in this way. => I misunderstood your concern: in fact you prefer something which provides the whole config, not only the IPv4 address. So the issue is not the 2.1 but the 2.1 and 2.2 (i.e., DHCPv4 over IPv6 for the external address, and ICMP for the port range) together, and you already know what I think about 2.2. > [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm > which has been discusses widely in the WG. => yes, it has many advantages. But to come back to the first point, it is for the second NAT (:-)! Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange.com Wed Mar 14 05:47:58 2012 Return-Path: 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 3607721F87B0 for ; Wed, 14 Mar 2012 05:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 fjLYjzFdshyS for ; Wed, 14 Mar 2012 05:47:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA921F87A9 for ; Wed, 14 Mar 2012 05:47:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3B8513B45CB; Wed, 14 Mar 2012 13:47:56 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1239D23807C; Wed, 14 Mar 2012 13:47:56 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 14 Mar 2012 13:47:56 +0100 From: To: Alain Durand Date: Wed, 14 Mar 2012 13:47:54 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0B0xVsAvetz5yBS0OxavXS5XEhwwACg84g Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:47:58 -0000 Re-, Thanks Alain for the answers. Please see inline. Cheers, Med > -----Message d'origine----- > De : Alain Durand [mailto:adurand@juniper.net]=20 > Envoy=E9 : mercredi 14 mars 2012 12:11 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : draft-penno-softwire-sdnat@tools.ietf.org; Softwires WG;=20 > draft-cui-softwire-b4-translated-ds-lite > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite >=20 > Hi Med, see inline response to your questions wrt sd-nat-02 >=20 > On Mar 13, 2012, at 10:58 AM,=20 > com>>=20 > com>> wrote: > (*) Question 1: It is not clear in text if there is a second NAT > in the AFTR or not. Could you please confirm/infirm a=20 > second NAT > is present? >=20 > in sd-nat, packets originated by an sd-CPE will be 'shaped'=20 > to use the correct IPv4 address and port by the CPE before=20 > being encapsulated in IPv6. In that scenario, the AFTR=20 > decapsulate the traffic, check IPv4 address & port range are=20 > indeed assigned to that IPv6 user, then forward the packet.=20 > There is only one level of NAT, done by the CPE Med: Ok, got it. This is the same as per draft-cui-*. > In 'compatibility' mode, if the CPE fails to enforce the=20 > proper port range, the AFTR will perform a second level of NAT. Med: If the ultimate target is to remove the NAT module from the AFTR, I wo= uld see this compatibility mode as an implementation detail. BTW, why a CPE= will fail to restrict the port? I see at least two cases:=20 (1) want to grab more ports but this is not legitimate; I would vote for di= scarding those packets instead of NATing them. (2) the CPE does not support port-restriction: in that case why not use cla= ssic DS-Lite instead of NATing twice. =20 >=20 > (*) Question 3: If the public IP address assigned by the AFTR is > not known to the port-restricted CPE, some applications may fail > (referral). How the CPE will make a distinction between the > external IP address to be assigned in the WAN and the=20 > one used in > the AFTR? If UPnP is used, the WAN IP address should not be > returned. >=20 > In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 Med: Ok, thanks. So for draft-penno-* two provisioning means are required (= compared to basic DS-Lite) * DHCPv4 for IPv4 address allocation * ICMP for port range configuration. I must admit the rationale behind this choice is not clear to me. > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? >=20 > IMHO, not specifying the technology to get pot range and=20 > living this to implementation is a serious shortcoming. > We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using por= t-restricted DHCPv4 options for instance? From despres.remi@laposte.net Wed Mar 14 05:48:06 2012 Return-Path: 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 1647821F87B8 for ; Wed, 14 Mar 2012 05:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 xDU4LKYhVCeN for ; Wed, 14 Mar 2012 05:48:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1121F87B6 for ; Wed, 14 Mar 2012 05:48:03 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 472ED9400D6; Wed, 14 Mar 2012 13:47:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 14 Mar 2012 13:47:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] MAP support of IPv4 prefixes? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:48:06 -0000 Le 2012-03-14 =E0 13:17, Ole Tr=F8an a =E9crit : > Remi, >=20 >> Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, >>=20 >> Sec. 1 says:: >> "the residual IPv4 over IPv6 mechanisms must be capable = of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 = address." >> (We all agree, I think, that this is important.) >>=20 >> Sec.5.2 says: >> " The MAP IPv6 address is created by concatenating the End-user IPv6 = prefix with the MAP subnet-id and the interface-id as specified in = Section 6." >>=20 >> Sec6 says: >> "The Interface identifier format is based on the format specified in = section 2.2 of [RFC6052], with the added PSID format field" (i.e. with = at least a full embedded IPv4 address) >>=20 >> What should be done for a CE that is provisioned an IPv4 prefix, i.e. = several IPv4 addresses, is in my understanding unclear. >> Could you please clarify the intent? >=20 > section 6 says: > In the case of an IPv4 prefix, the IPv4 address field is = right-padded > with zeroes up to 32 bits. The PSID field is left-padded to create = a > 16 bit field. For an IPv4 prefix or a complete IPv4 address, the > PSID field is zero. OK=20 > if you find this unclear, feel free to contribute better text. I have to agree that the spec is already clear enough.=20 Sorry for how I asked the question. Maybe you could improve the first sentence of sec. 6 to say:: "The Interface identifier format is based on the format specified in = section 2.2 of [RFC6052], with the added PSID format field, or with an = IPv4 prefix instead of an IPv4 address."=20 Thanks, RD >=20 > cheers, > Ole From despres.remi@laposte.net Wed Mar 14 06:24:08 2012 Return-Path: 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 1E55E21F873D for ; Wed, 14 Mar 2012 06:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 gCoR9Tjj+Zv6 for ; Wed, 14 Mar 2012 06:24:07 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 6153C21F870F for ; Wed, 14 Mar 2012 06:24:06 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id lRPR1i00S37Y3f403RQ4Yi; Wed, 14 Mar 2012 14:24:05 +0100 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 14:24:04 +0100 Message-Id: To: Ole Troan , Tomasz Mrugalski Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] Question about hub-and-spoke operation in MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:24:08 -0000 Ole, Tomek, I couldn't figure out by how CEs can be required to work hub-and-spoke = without some DHCPv6 indication: - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do = they know whether their ISP expects direct paths between them (mesh) or = BR hairpinning (hub-and-spoke)? Sorry for bothering you if I missed something obvious. RD From Francis.Dupont@fdupont.fr Wed Mar 14 06:34:24 2012 Return-Path: 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 D01CF21F862F for ; Wed, 14 Mar 2012 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 MeTNaNfOGweQ for ; Wed, 14 Mar 2012 06:34:24 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53F21F8625 for ; Wed, 14 Mar 2012 06:34:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2EDYMKE065833; Wed, 14 Mar 2012 14:34:22 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203141334.q2EDYMKE065833@givry.fdupont.fr> From: Francis Dupont To: GangChen In-reply-to: Your message of Wed, 14 Mar 2012 13:39:42 +0800. Date: Wed, 14 Mar 2012 14:34:22 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:34:25 -0000 In your previous mail you wrote: > However, the draft seems give people impression there is only one NAT > at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is > responsible for decapsulation and IPv4 package validation. Did I miss > something? => yes, the SD-CGN (the SD-AFTR with DS-Lite) runs a second NAT but only on port (vs. address and port) and following algorithm (aka stateless). Regards Francis.Dupont@fdupont.fr PS: you can expand the algorithm application to a table of static mapping rules (it provides an easy way to configure a standard NAT as a SD-CGN without a line of C code :-). From Francis.Dupont@fdupont.fr Wed Mar 14 07:01:29 2012 Return-Path: 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 C1E4C21F8778 for ; Wed, 14 Mar 2012 07:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] 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 5wfvouw2EkMG for ; Wed, 14 Mar 2012 07:01:29 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id D446E21F84EF for ; Wed, 14 Mar 2012 07:01:28 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2EE1RP9067575; Wed, 14 Mar 2012 15:01:27 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203141401.q2EE1RP9067575@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Wed, 14 Mar 2012 07:42:06 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB696@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 14 Mar 2012 15:01:27 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:01:29 -0000 In your previous mail you wrote: => I leave the draft-penno-* unclear items to Reinaldo... > > (note: 1- it should be not what we want as it makes CPEs trivial > > to track, 2- it doesn't remove the mandatory check on source ports > > in the from CPE to the Internet way) > > Med: I failed to get your first point. Could you please clarify? Thanks. => when what you can see from the Internet is a big port range per customer it is trivial to track/trace customers. So what I call "none" algorithm (i.e., no port translation by the SD-CGN) or "direct" algorithm (i.e., port translation by adding a constant, the difference between the first/base port of ranges) are bad according to (quoting draft-tsou-softwire-port-set-algorithms-analysis): A good port set definition algorithm must be reversible, easy to implement, and should be able to define non-continuous or random port sets for better security, be able to exclude the well known ports, 0 ~ 1023 or 0 ~ 4095, etc. (BTW the last point doesn't apply to ICMP echo IDs) The note is about no second NAT, i.e., "none" algorithm. > Med: applications using referral need to know the external IP address. => this comment is about the second NAT so as it doesn't translate the IP address is out of context (but I agree there are more needs for the external address than the external port) > > => no such specific: > > - it makes the reasonable assumption than IPv4 addresses are assigned > > using DHCPv4 > > Med: It is not "reasonable" when you don't have a DHCPv4 server but use PCP > for instance. => PCP doesn't provide your IPv4 address. In fact, if you don't know your assigned IPv4 address you can't run PCP, nor any applications over IPv4 (note DHCPv4 is not over IPv4 exactly for this reason). > Med: We don't have the constraint of MAP so I would not exclude > pseudo-random port set algos (see > draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3) => I have no concern about them as soon as enough information is given to SD-CPEs (including SD-B4s in the DS-Lite case) so they can compute external ports as visible from the Internet. Regards Francis.Dupont@fdupont.fr PS: in fact for implementing a PCP/NAT-PMP/UPnP-IGD/etc service on a SD-CPE you need the SD-CGN algo parameters to implement: - something giving the next local (i.e., SD-CPE WAN side) external port. Note ++ is never enough as one must stay inside the allowed port range. - something (I call it map) giving the external port as visible from the Internet from the local external port value (i.e., applying the SD-CGN algo in the CPE to Internet way). Note this must not fail when the input is a valid (i.e., in range) value. - something (I call it unmap) giving the local external port from the value as visible from the Internet. Note this can be failed if the port doesn't belong to the customer translated port range (nothing really new: we already know a random external port is likely unavailable on a CGN). From yiu_lee@cable.comcast.com Wed Mar 14 07:04:52 2012 Return-Path: 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 C61C021F880B for ; Wed, 14 Mar 2012 07:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.546 X-Spam-Level: X-Spam-Status: No, score=-100.546 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 eGF+jfAXf7zX for ; Wed, 14 Mar 2012 07:04:51 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0DD21F8809 for ; Wed, 14 Mar 2012 07:04:51 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.9214988; Wed, 14 Mar 2012 07:53:09 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 10:04:40 -0400 From: "Lee, Yiu" To: Maoke , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd Thread-Index: AQHNAetlfML3/2YZmUGo6B6DmWtvng== Date: Wed, 14 Mar 2012 14:04:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3414564279_365049" MIME-Version: 1.0 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:04:52 -0000 --B_3414564279_365049 Content-type: multipart/alternative; boundary="B_3414564278_359334" --B_3414564278_359334 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Maoke and Remi, Thanks very much for discussing this issue on the mailing-list. I guess the points are now clear for both options. IMHO, there is no one better than th= e other, it is all about choice of implementation. Perhaps it is time for mor= e people to comment how they feel for both options. Thanks again for the great discussion. B.R., Yiu From: Maoke Date: Wed, 14 Mar 2012 09:46:06 +0000 To: R=E9mi Despr=E9s Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd 2012/3/14 R=E9mi Despr=E9s >=20 > Le 2012-03-14 =E0 10:00, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/14 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-14 =E0 06:51, Maoke a =E9crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/13 R=E9mi Despr=E9s >>>>> 2012-03-13 12:02, Maoke : >>>>>> 2012/3/13 R=E9mi Despr=E9s >>>>> ... >>>>>=20 >>>>>>> The 4rd mechanism is for protocols that have ports at their usual p= lace >>>>>>> (all existing protocols that have ports have them at the same place= , >>>>>>> even if using another checksum algorithm like SCTP). >>>>>=20 >>>>>> may you have a check on the statement of "all existing protocols" ag= ain? >>>>>> i noticed RFC908/RFC1151. sorry if that are not a transport protocol= over >>>>>> IP.=20 >>>>>=20 >>>>> I missed this one. >>>>> None of the proposed stateless solutions supports it, but it remains = that >>>>> you are right: it has ports at a different place. >>>=20 >>>> alright. so 4rd-U doesn't not support "all existing transport protocol= " >>>> either.=20 >>>=20 >>> Never said that without qualifying which protocols. >>>=20 >>>> but i suppose you may make an update in the 4rd-u-06 so that a new >>>> "if...else..." is added the port pick-up logic, and surely the CNP is = not a >>>> problem for RDP because the old version (RFC908) has 32bit checksum bu= t not >>>> involving pseudo-header while the newer version (RFC1151) changed to u= se >>>> TCP-checksum. no big deal but only needs a new patch to the draft. >>>=20 >>> In the Note in 4.4 (7), the first sentence is: >>> "This guarantees that, for all protocols that use the same checksum >>> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this >>> independently from where the checksum field is placed for each protocol= ." >>> It can become:=20 >>> "This guarantees that, for all protocols that use the same checksum >>> algorithm as TCP and have ports at the same place, Tunnel packets are v= alid >>> IPv6 packets, and this independently from where the checksum field is p= laced >>> for each protocol." >>>=20 >>> Similarly, in the comparison table, H6 is: >>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as fut= ure >>> protocols using the TCP checksum algorithm" >>> It can become: >>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any fu= ture >>> protocol that might use the TCP checksum algorithm and ports at the sam= e >>> place" =20 >>=20 >> then it is fine. with these statement, 4rd-U can support >> - TCP=20 >> - UDP >> - DCCP >> - any future or less well-known protocol as long as it uses TCP checksum= and >> port at the same place >>=20 >> as a counterpart, we may suggest MAP-T to state it supports >> - TCP >> - UDP >> - DCCP (with enforcing it rather than RFC6145's "optional") >> - any future or less well-known protocol, no matter what layout it is no= r how >> the checksum is defined, with the similar logic of L4 checksum recalcula= tion >=20 > Maybe I get the point you are making: you implicitly consider that BR and= CE > modifications can be synchronized. This is feasible if ISPs provide all C= E > nodes, but not in the general case. i don't consider their modifications are synced but i do consider that each device, either BR or CE, should has a specification on its supported functionalities.=20 =20 > =20 > Changing DCCP support from optional to mandatory in RFC6145 isn't backwar= d > compatible (an upgraded node isn't guaranteed to interwork with a non upg= raded > node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optiona= l in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem= . to this extend, MAP-T is at the same kick-off line of the 4rd-U. =20 > =20 > To be even more precise, H6 of the comparison table can be: > "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses,= DCCP > and UDP-Lite are supported, as well as future protocols using the TCP che= cksum > algorithm and ports at the same place" i actually think the original text is fine. "For .... shared IPv4 addresses= " is not needed for 4rd-U, to my understanding, nor needed to MAP-T. maoke=20 =20 >=20 > Does this cover the point? >=20 > RD >=20 >=20 >=20 >=20 >>=20 >> ;-) >> maoke=20 >> =20 >>>=20 >>>> but this is not my point. my point is: there must be something we don'= t >>>> know ("non omnia possumus omnes"). even we have gone through the RFCs, >>>> there might be some other proprietary L4 protocols, or experimental >>>> protocols. even they are minority, i don't think ignoring their exista= nce >>>> in our solution fits the spirit of the Internet. it might be argued th= at >>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner = may >>>> makes his own NAT44, either attached to the CE or separated. if 4rd-U >>>> respects such an effort, it should state "currently blahblabla L4 prot= ocols >>>> are supported". the similar statement applies to the RFC6145 or MAP as >>>> well. >>>=20 >>>> i somehow am hard to accept words like "far fetched theoretical probl= em". >>>=20 >>> If I had thought it might be so, I would have avoided the word. >>>=20 >>>=20 >>>> the L4-recalculate is a generic, architectural solution, surely needin= g >>>> codes for every L4 protocol. but this generality in architecture makes >>>> RFC6145 or MAP-T equipment be easily enhanced to support anything new = with >>>> the same logic. but for the 4rd-U BR, it looks to me we cannot have th= e >>>> unified logic for all (even limited to existing and well-known) L4 >>>> protocols.=20 >>>>=20 >>>> only my 2 cents. >>>=20 >>> With amendments above, the point is AFAIK completely covered: everythin= g is >>> rigorously true, and worth noting. >>> Thanks for the useful reference to the RDP of RFC1151. >>>=20 >>> RD=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --B_3414564278_359334 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Maoke and Remi,

Thanks very much for discussing this issue on the mailing-li= st. I guess the points are now clear for both options. IMHO, there is no one= better than the other, it is all about choice of implementation. Perhaps it= is time for more people to comment how they feel for both options.

Thanks again for the great discussion.

=
B.R.,
Yiu


From: Maoke <fibrib= @gmail.com>
Date: Wed, 14 M= ar 2012 09:46:06 +0000
To: R=E9mi De= spr=E9s <despres.remi@laposte.net= >
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] IPv4 Residual D= eployment - Unified-standard proposal 4rd



2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012= -03-14 =E0 10:00, Maoke a =E9crit :



2012/3/14 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-14 =E0 06:51, Maoke a =E9crit :



2012/3/13= R=E9mi Despr=E9s <despres.remi@laposte.net>
=
2012-03-13 12:02, Maoke :
2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for protocols that have port= s at their usual place (all existing protocols that have ports have them at = the same place, even if using another checksum algorithm like SCTP).

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex">
=
ma= y you have a check on the statement of "all existing protocols" again? i not= iced RFC908/RFC1151. sorry if that are not a transport protocol over IP.&nbs= p;

I missed this one.
None of the proposed stateless solutions supports it, but it remains t= hat you are right: it has ports at a different place.

alright. so 4rd-U doesn't not support "all existing transport protocol" e= ither.

Never said that wi= thout qualifying which protocols.

but i suppose you may make an update in the 4rd-u-= 06 so that a new "if...else..." is added the port pick-up logic, and surely = the CNP is not a problem for RDP because the old version (RFC908) has 32bit = checksum but not involving pseudo-header while the newer version (RFC1151) c= hanged to use TCP-checksum. no big deal but only needs a new patch to the dr= aft.

In the Note in 4.4 (7), th= e first sentence is:
"This guarantees that, for all protocols= that use the same checksum algorithm as TCP, Tunnel packets are valid&= nbsp;IPv6 packets, and this independently from where the checksum field= is placed for each protocol."
It can become: 
"This guarantees that, for all protocols that use the same checksum a= lgorithm as TCP and have ports at the same place, Tunnel packets are valid&n= bsp;IPv6 packets, and this independently from where the checksum field = is placed for each protocol."

Similarly, in the com= parison table, H6 is:
"For shared IPv4 addresses, DCCP and&nb= sp;UDP-Lite supported, as well as future  protocols using the TCP = checksum algorithm"
It can become:
"For shared IPv4= addresses, DCCP and UDP-Lite supported, as well any future protocol th= at might use the TCP checksum algorithm and ports at the same place"&nb= sp;   

then it is fine. with these statement, 4rd-U can support 
- = TCP 
- UDP
- DCCP
- any future or less we= ll-known protocol as long as it uses TCP checksum and port at the same place=

as a counterpart, we may suggest MAP-T to state it= supports 
- TCP
- UDP
- DCCP (with enfor= cing it rather than RFC6145's "optional") 
- any future or le= ss well-known protocol, no matter what layout it is nor how the checksum is = defined, with the similar logic of L4 checksum recalculation 

Maybe I get the point yo= u are making: you implicitly consider that BR and CE modifications can = be synchronized. This is feasible if ISPs provide all CE nodes, but not in t= he general case.

i d= on't consider their modifications are synced but i do consider that each dev= ice, either BR or CE, should has a specification on its supported functional= ities. 
 
  
Changing DCCP suppo= rt from optional to mandatory in RFC6145 isn't backward compatible (an upgra= ded node isn't guaranteed to interwork with a non upgraded node).
=

the CE/BR specified= RFC6145-compliant might be a problem but MAP-T is still in development. if = we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-= compliant CE/BR won't has the backward compatible problem. to this extend, M= AP-T is at the same kick-off line of the 4rd-U. 
 
=
&= nbsp;
To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv4 add= resses, DCCP and UDP-Lite are supported, as well as future protocols using t= he TCP checksum algorithm and ports at the same place"

i actually think the original text is fin= e. "For .... shared IPv4 addresses" is not needed for 4rd-U, to my understan= ding, nor needed to MAP-T. 

maoke 
<= div> 
=

Does this cover the point?

RD





;-)
maoke 
 
but this is not my po= int. my point is: there must be something we don't know ("non omnia possumus= omnes"). even we have gone through the RFCs, there might be some other prop= rietary L4 protocols, or experimental protocols. even they are minority, i d= on't think ignoring their existance in our solution fits the spirit of the I= nternet. it might be argued that NAT44 doesn't support such L4 protocols now= , but an L4 protocol owner may makes his own NAT44, either attached to the C= E or separated. if 4rd-U respects such an effort, it should state "currently= blahblabla L4 protocols are supported". the similar statement applies to th= e RFC6145 or MAP as well.

i somehow am hard to accept words like "far= fetched theoretical problem". 

=
If I had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, su= rely needing codes for every L4 protocol. but this generality in architectur= e makes RFC6145 or MAP-T equipment be easily enhanced to support anything ne= w with the same logic. but for the 4rd-U BR, it looks to me we cannot have t= he unified logic for all (even limited to existing and well-known) L4 protoc= ols. 

only my 2 cents. 

With amendments above, the point is AF= AIK completely covered: everything is rigorously true, and worth noting.
Thanks for the useful reference to the RDP of RFC1151.

=
RD 

<= div>





_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.= org/mailman/listinfo/softwires --B_3414564278_359334-- --B_3414564279_365049 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSxI3+E vm71vvdRn00s7NORVI0HpTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMTQxNDA0MzhaMA0GCSqGSIb3DQEBAQUABIIBAMFTTS5UR+MeyaQfRPlIhVwW DiatGiHIyQFd6NG2qs1L07Wiwia83bgBdPUuErruxjXzaQwiIBNIMoJpdiY7TunF4JVVW4xU bDT5CiBYJU63MxtQn2T3tWPRuToqaSFV27PGzatmniZschHci02Nucks3hcbdLuKYqSg325R r4F+9zlvLWe2PxiqUpooWKGfqtFZlwiJ7MC/dji77JleJIN+Hxz8flLQmoP/i6GZ+7OhvFH3 8u/rXe4ILqYN3hmrtTc5ReLMnjRt1pMa6Ng/+WcVIW+DtXvlJk7ANhc2PYj4pgQN7hUGhclB VoHP6W6eBn8xu83N6LCqhPnQQoUmCJE= --B_3414564279_365049-- From ot@cisco.com Wed Mar 14 07:12:33 2012 Return-Path: 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 57E1521F880C for ; Wed, 14 Mar 2012 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 mQMFwTbWHImE for ; Wed, 14 Mar 2012 07:12:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2021F880D for ; Wed, 14 Mar 2012 07:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=425; q=dns/txt; s=iport; t=1331734348; x=1332943948; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lZOB0/b3JNEAYfRz5B46TYrzw4c0J2xE5mmYSaFmAQg=; b=d46tthM5DdBnTIRVCyK4zICJliM6y1M++1Q+uFfhL9YjEP1FxgJcsFVB rrBdHachcj9zMnQbj1JMeEoZJdZiNXX8OchKDNguIeXgKwps4biI07s0X Uc0TtygmabGh+2HXqdJY3lItW+oSwR2id8IgqdVyhP9zajTPT2f16oOBo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGWmYE+Q/khN/2dsb2JhbABDtiuBB4IJAQEBAwESASc/BQsLRlcGNYdjBZ0VnyuQG2MEiFeMf45AgWiDBg X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="132293476" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 14:12:27 +0000 Received: from dhcp-10-61-98-97.cisco.com (dhcp-10-61-98-97.cisco.com [10.61.98.97]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2EECOmY000346; Wed, 14 Mar 2012 14:12:25 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 14 Mar 2012 06:29:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] Question about hub-and-spoke operation in MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:12:33 -0000 Remi, > I couldn't figure out by how CEs can be required to work hub-and-spoke = without some DHCPv6 indication: > - If two CEs apply the same BMR to their delegated IPv6 prefixes, how = do they know whether their ISP expects direct paths between them (mesh) = or BR hairpinning (hub-and-spoke)? >=20 that's correct it needs to be provisioned. either explicitly or = implicitly (via the rules). cheers, Ole= From mohamed.boucadair@orange.com Wed Mar 14 07:16:02 2012 Return-Path: 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 7073221F87B5 for ; Wed, 14 Mar 2012 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 5HjYcryq96ZE for ; Wed, 14 Mar 2012 07:16:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C07EC21F87B0 for ; Wed, 14 Mar 2012 07:16:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8C3053B46ED; Wed, 14 Mar 2012 15:16:00 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6D2994C13A; Wed, 14 Mar 2012 15:16:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 14 Mar 2012 15:16:00 +0100 From: To: "Francis.Dupont@fdupont.fr" Date: Wed, 14 Mar 2012 15:15:59 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0B6vTJJJMoZjdDRdy4v79cpIgBXgAAOG7A Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB913@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 14 Mar 2012 07:42:06 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB696@PUEXCB1B.nanterre.francetelecom.fr> <201203141401.q2EE1RP9067575@givry.fdupont.fr> In-Reply-To: <201203141401.q2EE1RP9067575@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.14.121514 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:16:02 -0000 Re-, Please see inline. Cheers, Med=20 > -----Message d'origine----- > De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 > Envoy=E9 : mercredi 14 mars 2012 15:01 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : draft-penno-softwire-sdnat@tools.ietf.org; Softwires WG;=20 > draft-cui-softwire-b4-translated-ds-lite > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite=20 > > =20 > > =20 > > Med: It is not "reasonable" when you don't have a DHCPv4=20 > server but use PCP > > for instance. >=20 > =3D> PCP doesn't provide your IPv4 address. In fact, if you=20 > don't know your > assigned IPv4 address you can't run PCP, nor any applications=20 > over IPv4 > (note DHCPv4 is not over IPv4 exactly for this reason). Med: Why you need an IPv4 address to run PCP? An implementation example wou= ld be as follows: * At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 P= CP mode and the new opcode and options defined in http://tools.ietf.org/htm= l/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set = of port.=20 * The IP address + port range returned in PCP will be used by CPE to enforc= e its NAT. From yiu_lee@cable.comcast.com Wed Mar 14 07:33:03 2012 Return-Path: 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 E197E21E803B for ; Wed, 14 Mar 2012 07:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.16 X-Spam-Level: X-Spam-Status: No, score=-101.16 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 rnTsKVw4lQSt for ; Wed, 14 Mar 2012 07:33:03 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 47FFF21E8017 for ; Wed, 14 Mar 2012 07:33:03 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.5956346; Wed, 14 Mar 2012 10:27:28 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 10:32:54 -0400 From: "Lee, Yiu" To: "mohamed.boucadair@orange.com" , Alain Durand Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: AQHNAe9WrvKvCxCxaUq1+Y60hSPQIw== Date: Wed, 14 Mar 2012 14:32:53 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3414565961_490311" MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:33:04 -0000 --B_3414565961_490311 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I am a little lost. Let's put the double-nat aside for a moment. Except the fact that sd-nat uses icmp for port-set provisioning, what else different between Lightweight 4over6 vs. sd-nat? Am I missing something? For Lightweight 4over6, we can use anycast for redundancy. I fail to see what sd-nat does more than Lightweight 4over6. /Yiu On 3/14/12 8:47 AM, "mohamed.boucadair@orange.com" wrote: >Med: But the question is why ICMP-based method is needed? Why not using >port-restricted DHCPv4 options for instance? > --B_3414565961_490311 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTL1ycx Y5ZVFdjggXVXh84GaL4i2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMTQxNDMyMzlaMA0GCSqGSIb3DQEBAQUABIIBABu5G+j7ye9wozYWrpiIbZcD 07ToZbRRmioA/DLbnQiuM+Ivhq850+58c1mVFTJGGrsqlITGvdGcFlQOHo3BvH+NbhpNwXtx WCHp2d4apRbtLmCy6jeMmDkFZuw7kTom+nEFrbpUPH5LQjiTpyFiNmLdSpGBpmEdMu22ekCx MpxUAJgQyGj2jnj2oAMvTDaKSrvUFVAKEfVfRqXElV/bhDRLIhu34RtUymFzrztBIUmx5dj9 Uqzgo/Whx3wiDU+rgu25XssPnDKbF3H4DtZBNr7sS8JrOoAr4uai5VO1FSFQnS8WPgskOvo7 BklQ/5hcYLlJGngif/O+IbTpNcLf7pU= --B_3414565961_490311-- From Francis.Dupont@fdupont.fr Wed Mar 14 08:13:06 2012 Return-Path: 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 0F9FF21F87E2 for ; Wed, 14 Mar 2012 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 W9R31IWVdatR for ; Wed, 14 Mar 2012 08:13:05 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAED21F87DE for ; Wed, 14 Mar 2012 08:13:04 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2EFD3pa072567; Wed, 14 Mar 2012 16:13:03 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203141513.q2EFD3pa072567@givry.fdupont.fr> From: Francis Dupont To: Alain Durand In-reply-to: Your message of Wed, 14 Mar 2012 04:10:39 MST. Date: Wed, 14 Mar 2012 16:13:03 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:13:06 -0000 In your previous mail you wrote: > (*) Question 1: It is not clear in text if there is a second NAT > in the AFTR or not. Could you please confirm/infirm a second NAT > is present? > > > in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the > correct IPv4 address and port by the CPE before being encapsulated in > IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 > address & port range are indeed assigned to that IPv6 user, then > forward the packet. There is only one level of NAT, done by the CPE => this means the port range will be visible as it in the Internet, IMHO this is not acceptable. And IMHO it is not the job of the SD-CPE (i.e., it is the SD-CGN one) to translate the port range to something far harder to track/trace. > In 'compatibility' mode, if the CPE fails to enforce the proper port > range, the AFTR will perform a second level of NAT. => if I understand well the compatibility mode is just the standard DS-Lite where the B4 performs spurious and useless translation? So in particular the only change for the AFTR is the customer IPv4 address? > (*) Question 2: If yes, is there any reason why you want to > maintain that second NAT? > > > in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs > or DS-lite + B4 translated CPEs to interoperate with stateless DS-Lite > CPEs. => I believe it is more 'to be supported' than 'to interoperate with stateless DS-Lite CPEs. > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > provisioning means for port ranges; a list of alternatives is > provided in draft-cui-* without any preference (this is deployment- > specific): > > o DHCPv4: the DHCPv4 protocol should be extended to support > port-set allocation > [I-D.bajko-pripaddrassign draft-cui-softwire-b4-translated-ds-lite-05# > ref-I-D.bajko-pripaddrassign>]. > Besides, the DHCP message should send to the concentrator over > IPv6. The concentrator can be the DHCP server or DHCP relay > agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. => the IPv6-Transport DHCP Relay Agent (TRA, vs, the CRA, IPv6-Transport Client Relay Agent) > o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP > requests simultaneously to acquire a number ports within the > same IPv4 address, => I can't see how this has a real chance to work... > IMHO, not specifying the technology to get port range and living this > to implementation is a serious shortcoming. We need to standardize > one method. => I agree (on the one method, *not* on the proposed method). Thanks Francis.Dupont@fdupont.fr From mohamed.boucadair@orange.com Wed Mar 14 08:35:49 2012 Return-Path: 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 4B2F421F87A8 for ; Wed, 14 Mar 2012 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 H2hGGGibWDem for ; Wed, 14 Mar 2012 08:35:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8F21F879B for ; Wed, 14 Mar 2012 08:35:46 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id E0BE23B4570; Wed, 14 Mar 2012 16:35:45 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C2FB94C06D; Wed, 14 Mar 2012 16:35:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 14 Mar 2012 16:35:46 +0100 From: To: "Francis.Dupont@fdupont.fr" , Alain Durand Date: Wed, 14 Mar 2012 16:35:44 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0B9PqVF2S4CXlBQrqknKGt4Dea3QAAk24A Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB999@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 14 Mar 2012 04:10:39 MST. <201203141513.q2EFD3pa072567@givry.fdupont.fr> In-Reply-To: <201203141513.q2EFD3pa072567@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.14.135414 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:35:49 -0000 Please see below. Cheers, Med > -----Message d'origine----- > De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 > Envoy=E9 : mercredi 14 mars 2012 16:13 > =C0 : Alain Durand > Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG;=20 > draft-cui-softwire-b4-translated-ds-lite;=20 > draft-penno-softwire-sdnat@tools.ietf.org > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite=20 >=20 >=20 > =3D> the IPv6-Transport DHCP Relay Agent (TRA, vs, the CRA,=20 > IPv6-Transport > Client Relay Agent) >=20 > > o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP > > requests simultaneously to acquire a number ports within the > > same IPv4 address, >=20 > =3D> I can't see how this has a real chance to work... Med: The PCP case has been demoed. Please refer to http://www.internetsocie= ty.org/articles/new-technology-demo-pcp; in particular you can read: "In the second demonstration scenario, the CPE requested several sets of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and draft-zhou-softwire-b4-nat-02). Upon receipt of the corresponding PCP request sent by the client, the PCP server requested the CGN to assign port forwarding and to bypass NAT on the requested port ranges. The NAT function was performed on the CPE from this point forward, thus reducing the NAT processing requirement on the CGN router." From bingxuere@gmail.com Wed Mar 14 09:16:01 2012 Return-Path: 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 177AF21F86FA for ; Wed, 14 Mar 2012 09:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 k9CFENRFPJyt for ; Wed, 14 Mar 2012 09:16:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADFC221F85D3 for ; Wed, 14 Mar 2012 09:15:59 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1134529eaa.31 for ; Wed, 14 Mar 2012 09:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UwfXtTXACoC/k9thFv0iWOClxhlIbP52lbxFEBVqQSQ=; b=I1zS+3LYEYrDUlHRVcdjcU9dvk1/X+mpQOnfD0gLmmfUYM5dxF73Ruzz9a35txPH9a tM6heBG4MupgijI3FjUCZpDI863ifXzLPNwUjg/IagfHHxb/FNlNJa58UOdFKGaILrnd q9BE+8tMlN7IBWNoOZkgTE2mMGzCCAuKKPAOKIDKbbFUPS2EI34Db/sbRewVtrSXGg9C NaDzcaBhBi96PrxPYshlzPljHdlB8BsB+vSqaTMZcwWQQDcY1fclCGdrWRcVUeGHiYgx EMYKzCE82BshgChWskFnYkW+mNPMauCpLDTo8CV+VjkaMY9Kh+bWDLBdYu3j9+YI2ifw fTaw== Received: by 10.50.159.161 with SMTP id xd1mr12891475igb.15.1331741758312; Wed, 14 Mar 2012 09:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.137.135 with HTTP; Wed, 14 Mar 2012 09:15:17 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E281DB999@PUEXCB1B.nanterre.francetelecom.fr> References: <201203141513.q2EFD3pa072567@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F36E281DB999@PUEXCB1B.nanterre.francetelecom.fr> From: Qiong Date: Thu, 15 Mar 2012 00:15:17 +0800 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=14dae9340b936fd12a04bb364a7c Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:16:01 -0000 --14dae9340b936fd12a04bb364a7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, Please see inline . On Wed, Mar 14, 2012 at 11:35 PM, wrote: > > Please see below. > > Cheers, > Med > > > -----Message d'origine----- > > De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > > Envoy=C3=A9 : mercredi 14 mars 2012 16:13 > > =C3=80 : Alain Durand > > Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; > > draft-cui-softwire-b4-translated-ds-lite; > > draft-penno-softwire-sdnat@tools.ietf.org > > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. > > draft-cui-softwire-b4-translated-ds-lite > > > > > > =3D> the IPv6-Transport DHCP Relay Agent (TRA, vs, the CRA, > > IPv6-Transport > > Client Relay Agent) > > > > > o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP > > > requests simultaneously to acquire a number ports within the > > > same IPv4 address, > > > > =3D> I can't see how this has a real chance to work... > > Med: The PCP case has been demoed. Please refer to > http://www.internetsociety.org/articles/new-technology-demo-pcp; in > particular you can read: > > "In the second demonstration scenario, the CPE requested several sets > of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and > draft-zhou-softwire-b4-nat-02). Upon receipt of the corresponding > PCP request sent by the client, the PCP server requested the CGN to > assign port forwarding and to bypass NAT on the requested port > ranges. The NAT function was performed on the CPE from this point > forward, thus reducing the NAT processing requirement on the CGN > router." > [Qiong] We also have implemented and demoed in IETF 81th. Please refer to http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in Appendix section. Best wishes Qiong > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae9340b936fd12a04bb364a7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

Please see inline .

On = Wed, Mar 14, 2012 at 11:35 PM, <mohamed.boucadair@orange.com> wrot= e:

Please see below.

Cheers,
Med

> -----Message d'origine-----
> De : Francis.Dupont@fdupo= nt.fr [mailto:Francis.Dupo= nt@fdupont.fr]
> Envoy=C3=A9 : mercredi 14 mars 2012 16:13
> =C3=80 : Alain Durand
> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; > draft-cui-softwire-b4-translated-ds-lite;
> draft-pen= no-softwire-sdnat@tools.ietf.org
> Objet : Re: [Softwires] draft-penno-softwire-s= dnat vs.
> draft-cui-softwire-b4-translated-ds-lite
>
>
> =3D> the IPv6-Transport DHCP Relay Agent (T= RA, vs, the CRA,
> IPv6-Transport
> Client Relay Agent)
>
> > =C2=A0 =C2=A0 o PCP[I-D.ietf-pcp-base]: an initiator can launch m= ultiple PCP
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0requests simultaneously to acquire a n= umber ports within the
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0same IPv4 address,
>
> =3D> I can't see how this has a real chance to work...

Med: The PCP case has been demoed. Please refer to http://www.internetsociety.org/articles/new-technology-demo-pcp; in pa= rticular you can read:

=C2=A0 "In the second demonstration scenario, the CPE requested sever= al sets
=C2=A0 of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and =C2=A0 draft-zhou-softwire-b4-nat-02). =C2=A0Upon receipt of the correspon= ding
=C2=A0 PCP request sent by the client, the PCP server requested the CGN to=
=C2=A0 assign port forwarding and to bypass NAT on the requested port
=C2=A0 ranges. =C2=A0The NAT function was performed on the CPE from this p= oint
=C2=A0 forward, thus reducing the NAT processing requirement on the CGN =C2=A0 router."

[Qiong]=20 We also have implemented and demoed in IETF 81th. Please refer to=20 http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite= -04.txt in Appendix section.

Best wishes

Qiong
=C2=A0=



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--14dae9340b936fd12a04bb364a7c-- From bingxuere@gmail.com Wed Mar 14 09:24:13 2012 Return-Path: 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 78F8521F8777 for ; Wed, 14 Mar 2012 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 BqzpOdeGJw5J for ; Wed, 14 Mar 2012 09:24:12 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBE821F875B for ; Wed, 14 Mar 2012 09:24:12 -0700 (PDT) Received: by eeke51 with SMTP id e51so1160733eek.31 for ; Wed, 14 Mar 2012 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rXOdWROtMDPZRGjisiUaa5bRn/I3DZU/8syJEBoMDoQ=; b=aGL6FFg1HI52t+KRXgd4lr1w8txFCdEQMAyyLJSWAzf4IHLyPkoMtv7h83T/LhgsCC syQRNYjxnqPP/fzfaf0hrX/mE+QqFdw2VCcpw+NpPEmQEUkaliVnv9T/KoGR/CGDDGVL wku+K0/gXCZNAwwlLnkQa/Roku2+b8sUA9hLM7PsEPPPuLMLUpSWeNCAJ5ctrnT1wKsk 6qNNG6qs+zcKFIBn3I378aBvpzJl+VDQmr0/7NNlbFGyWb8LMnQ4xFDk0ZzAwIOjs3M/ /RTJdVAOh6kmtCID3zyOS30LS+TxhrBWhNivPaK2OKSRH2Pv8PwfqQlPJwb55DwFLfqS GOGA== Received: by 10.50.15.227 with SMTP id a3mr5703352igd.15.1331742249709; Wed, 14 Mar 2012 09:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.137.135 with HTTP; Wed, 14 Mar 2012 09:23:29 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> From: Qiong Date: Thu, 15 Mar 2012 00:23:29 +0800 Message-ID: To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=14dae93403e5b9ef0704bb366799 Cc: Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:24:13 -0000 --14dae93403e5b9ef0704bb366799 Content-Type: text/plain; charset=UTF-8 Me too. And another comment: In sd-nat, it says "More importantly, that draft (lightweight 4over6) does not explain how this solution can be deployed in a regular DS-Lite environment." I think this is a deployment issue and lightweight 4over6 can definitely be deployed in a regular DS-Lite environment. We have run a "Coexistent test with DS-Lite" (refer to http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in Appendix 1.3). It would be very easy and simple. Thoughts? Best wishes Qiong On Wed, Mar 14, 2012 at 10:32 PM, Lee, Yiu wrote: > I am a little lost. Let's put the double-nat aside for a moment. Except > the fact that sd-nat uses icmp for port-set provisioning, what else > different between Lightweight 4over6 vs. sd-nat? Am I missing something? > For Lightweight 4over6, we can use anycast for redundancy. I fail to see > what sd-nat does more than Lightweight 4over6. > > /Yiu > > > On 3/14/12 8:47 AM, "mohamed.boucadair@orange.com" > wrote: > > >Med: But the question is why ICMP-based method is needed? Why not using > >port-restricted DHCPv4 options for instance? > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --14dae93403e5b9ef0704bb366799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Me too.

And another comment:

In sd-nat, it says "More im= portantly, that draft (lightweight 4over6) does not explain how this soluti= on can be deployed in a regular DS-Lite environment."

I think t= his is a deployment issue and lightweight 4over6 can definitely be deployed= in a regular DS-Lite environment. We have run a "Coexistent test with= DS-Lite" (refer to http://tools.ietf.org/id/draft-cui-softw= ire-b4-translated-ds-lite-04.txt in Appendix 1.3). It would be very eas= y and simple. Thoughts?

Best wishes

Qiong

On Wed, Mar = 14, 2012 at 10:32 PM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I am a little lost. Let's put the double-nat aside for a moment. Except=
the fact that sd-nat uses icmp for port-set provisioning, what else
different between Lightweight 4over6 vs. sd-nat? Am I missing something? For Lightweight 4over6, we can use anycast for redundancy. I fail to see what sd-nat does more than Lightweight 4over6.

/Yiu


On 3/14/12 8:47 AM, "m= ohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

>Med: But the question is why ICMP-based method is needed? Why not using=
>port-restricted DHCPv4 options for instance?
>

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--14dae93403e5b9ef0704bb366799-- From fibrib@gmail.com Wed Mar 14 18:04:40 2012 Return-Path: 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 CB6A911E8073 for ; Wed, 14 Mar 2012 18:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 v6vVHEXBzTBq for ; Wed, 14 Mar 2012 18:04:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32E6621F87B5 for ; Wed, 14 Mar 2012 18:04:39 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2842239ggm.31 for ; Wed, 14 Mar 2012 18:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vfs8Cx0laYO6mlBLLNAmnHg4rR7VRmluBHoirZkpsV8=; b=S8CspdpDJZ3Uo/0tqk06CMGpbgbAgDz+owfhN3T0rLREg4eKLZbCfvZdHDYsPhq2Uq ng2SlS91+jcEZHvd0GjOQZ2aYK++icNsRC3wx2AwplmTRpg8YbJvzs8zQaKpOHNNoQsF fjmBLHzKzOfB7hPzL44Uq1vbUX3mvsYMhfEWNuK5G+jb+CaCt2iC9DH/wr7OONqjL8HU RUM34VJkLFoqWxONaoigJnTF8VeN0fFyy75VqsUpAzAUoBbYHvw20UT60ym7KNUGkEVQ oH2FAKQxNCIusy5Z8r3L6B2yVvMK2Aal/Wz0nP+lxbnXvGiZQgy3yhm7ff/6VJuaxcUr SNDg== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr5774692qab.39.1331773478787; Wed, 14 Mar 2012 18:04:38 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Wed, 14 Mar 2012 18:04:38 -0700 (PDT) In-Reply-To: <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> Date: Thu, 15 Mar 2012 01:04:38 +0000 Message-ID: From: Maoke To: Washam Fan , Softwires WG , Yong Cui Content-Type: multipart/alternative; boundary=20cf3074b47e1fd9af04bb3dad76 Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 01:04:40 -0000 --20cf3074b47e1fd9af04bb3dad76 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/14 R=E9mi Despr=E9s > > Le 2012-03-14 =E0 10:46, Maoke a =E9crit : > > > > 2012/3/14 R=E9mi Despr=E9s > >> >> Le 2012-03-14 =E0 10:00, Maoke a =E9crit : >> >> >> >> 2012/3/14 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-14 =E0 06:51, Maoke a =E9crit : >>> >>> >>> >>> 2012/3/13 R=E9mi Despr=E9s >>> >>>> 2012-03-13 12:02, Maoke : >>>> >>>> 2012/3/13 R=E9mi Despr=E9s >>>> >>>> ... >>>> >>>> The 4rd mechanism is for protocols that have ports at their usual >>>>>> place (all existing protocols that have ports have them at the same = place, >>>>>> even if using another checksum algorithm like SCTP). >>>>>> >>>>> >>>> may you have a check on the statement of "all existing protocols" >>>> again? i noticed RFC908/RFC1151. sorry if that are not a transport pro= tocol >>>> over IP. >>>> >>>> >>>> I missed this one. >>>> None of the proposed stateless solutions supports it, but it remains >>>> that you are right: it has ports at a different place. >>>> >>> >>> alright. so 4rd-U doesn't not support "all existing transport protocol" >>> either. >>> >>> >>> Never said that without qualifying which protocols. >>> >>> but i suppose you may make an update in the 4rd-u-06 so that a new >>> "if...else..." is added the port pick-up logic, and surely the CNP is n= ot a >>> problem for RDP because the old version (RFC908) has 32bit checksum but= not >>> involving pseudo-header while the newer version (RFC1151) changed to us= e >>> TCP-checksum. no big deal but only needs a new patch to the draft. >>> >>> >>> In the Note in 4.4 (7), the first sentence is: >>> "This guarantees that, for all protocols that use the same checksum >>> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this >>> independently from where the checksum field is placed for each protocol= ." >>> It can become: >>> "This guarantees that, for all protocols that use the same checksum >>> algorithm as TCP and have ports at the same place, Tunnel packets are >>> valid IPv6 packets, and this independently from where the checksum fiel= d is >>> placed for each protocol." >>> >>> Similarly, in the comparison table, H6 is: >>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as >>> future protocols using the TCP checksum algorithm" >>> It can become: >>> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any >>> future protocol that might use the TCP checksum algorithm and ports at = the >>> same place" >>> >> >> then it is fine. with these statement, 4rd-U can support >> - TCP >> - UDP >> - DCCP >> - any future or less well-known protocol as long as it uses TCP checksum >> and port at the same place >> >> as a counterpart, we may suggest MAP-T to state it supports >> - TCP >> - UDP >> - DCCP (with enforcing it rather than RFC6145's "optional") >> - any future or less well-known protocol, no matter what layout it is no= r >> how the checksum is defined, with the similar logic of L4 checksum >> recalculation >> >> >> Maybe I get the point you are making: you implicitly consider that BR an= d >> CE modifications can be synchronized. This is feasible if ISPs provide a= ll >> CE nodes, but not in the general case. >> > > i don't consider their modifications are synced but i do consider that > each device, either BR or CE, should has a specification on its supported > functionalities. > > >> >> Changing DCCP support from optional to mandatory in RFC6145 isn't >> backward compatible (an upgraded node isn't guaranteed to interwork with= a >> non upgraded node). >> > > the CE/BR specified RFC6145-compliant might be a problem but MAP-T is > still in development. if we state to enforce DCCP mandatorily rather than > optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward > compatible problem. to this extend, MAP-T is at the same kick-off line of > the 4rd-U. > > > 1. I agree that, between CEs and BRs, there can be no problem for DCCP > (provided the draft is completed to this effect). The comparison table wa= s > explicitly made with existing drafts, and intended to be updatable. > > 2. The MAP-T draft is also claimed to allow "communication between > IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only > servers in the domain that are using IPv4-mapped IPv6 address". In this > case, AFAIK, the backward compatibility problem exists > Thought? > surely it does not exist. that statement applies to the MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same deployment of equipments should support double-translation, single-translation, and native IPv6 accesses simultanenously. that's one of the points of the MAP-T. - maoke > > > To be even more precise, H6 of the comparison table can be: >> "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses= , >> DCCP and UDP-Lite are supported, as well as future protocols using the T= CP >> checksum algorithm and ports at the same place" >> > > i actually think the original text is fine. "For .... shared IPv4 > addresses" is not needed for 4rd-U, to my understanding, nor needed to > MAP-T. > > > Will see what to do, then, when changes to the MAP-T draft concerning DCC= P > are known. > > RD > > > > > maoke > > >> >> Does this cover the point? >> >> RD >> >> >> >> >> >> ;-) >> maoke >> >> >>> >>> but this is not my point. my point is: there must be something we >>> don't know ("non omnia possumus omnes"). even we have gone through the >>> RFCs, there might be some other proprietary L4 protocols, or experiment= al >>> protocols. even they are minority, i don't think ignoring their existan= ce >>> in our solution fits the spirit of the Internet. it might be argued tha= t >>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner m= ay >>> makes his own NAT44, either attached to the CE or separated. if 4rd-U >>> respects such an effort, it should state "currently blahblabla L4 proto= cols >>> are supported". the similar statement applies to the RFC6145 or MAP as = well. >>> >>> >>> i somehow am hard to accept words like "far fetched theoretical >>> problem". >>> >>> >>> If I had thought it might be so, I would have avoided the word. >>> >>> >>> the L4-recalculate is a generic, architectural solution, surely needing >>> codes for every L4 protocol. but this generality in architecture makes >>> RFC6145 or MAP-T equipment be easily enhanced to support anything new w= ith >>> the same logic. but for the 4rd-U BR, it looks to me we cannot have the >>> unified logic for all (even limited to existing and well-known) L4 >>> protocols. >>> >>> only my 2 cents. >>> >>> >>> With amendments above, the point is AFAIK completely covered: everythin= g >>> is rigorously true, and worth noting. >>> Thanks for the useful reference to the RDP of RFC1151. >>> >>> RD >>> >>> >>> >>> >>> >> >> > > --20cf3074b47e1fd9af04bb3dad76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :



2012/3/14 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-14 =E0 10:00, = Maoke a =E9crit :



2012/3/14 R=E9mi Despr=E9s <despres.remi@lap= oste.net>

Le 2012-03-14 =E0 06:51, = Maoke a =E9crit :



2012/3/13 R=E9mi Despr=E9s <despres.remi@laposte= .net>
2012-03-13 12:02, Maoke :
2012/3/13 R=E9mi Des= pr=E9s <despres.remi@laposte.net>
...

The 4rd mechanism is for prot= ocols that have ports at their usual place (all existing protocols that hav= e ports have them at the same place, even if using another checksum algorit= hm like SCTP).

may you have a check on the statement of "all existing prot= ocols" again? i noticed RFC908/RFC1151. sorry if that are not a transp= ort protocol over IP.=A0

I missed this one.
None o= f the=A0proposed stateless solutions supports it, but it remains that you a= re right: it has ports at a different place.

= alright. so 4rd-U doesn't not support "all existing transport prot= ocol" either.

Never= said that without qualifying which protocols.

but i su= ppose you may make an update in the 4rd-u-06 so that a new "if...else.= .." is added the port pick-up logic, and surely the CNP is not a probl= em for RDP because the old version (RFC908) has 32bit checksum but not invo= lving pseudo-header while the newer version (RFC1151) changed to use TCP-ch= ecksum. no big deal but only needs a new patch to the draft.

In the Note in 4.4 (7), the first s= entence is:
"This guarantees that, for all protocols th= at use the=A0same checksum algorithm as TCP, Tunnel packets are valid=A0IPv= 6 packets, and this independently from where the=A0checksum field is placed= for each protocol."
It can become:=A0
"This guarantees that, for all = protocols that use the=A0same checksum algorithm as TCP and have ports at t= he same place, Tunnel packets are valid=A0IPv6 packets, and this independen= tly from where the=A0checksum field is placed for each protocol."

Similarly, in the comparison table, H6 is:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as well = as future=A0=A0protocols using the TCP checksum=A0algorithm"
It can become:
"For shared IPv4 addresses, DCCP and=A0UDP-Lite supported, as wel= l any future protocol that might use the TCP checksum=A0algorithm and ports= at the same place"=A0=A0 =A0

<= /div>
then it is fine. with these statement, 4rd-U can support=A0
- TCP= =A0
- UDP
- DCCP
- any future or less well-kn= own protocol as long as it uses TCP checksum and port at the same place

as a counterpart, we may suggest MAP-T to state it supp= orts=A0
- TCP
- UDP
- DCCP (with enforcing it= rather than RFC6145's "optional")=A0
- any future = or less well-known protocol, no matter what layout it is nor how the checks= um is defined, with the similar logic of L4 checksum recalculation=A0

Maybe I get the poi= nt you are making:=A0you implicitly consider that BR and CE modifications c= an be synchronized. This is feasible if ISPs provide all CE nodes, but not = in the general case.

i don't consider the= ir modifications are synced but i do consider that each device, either BR o= r CE, should has a specification on its supported functionalities.=A0
=A0
=A0=A0
Changing DCCP support from optional t= o mandatory in RFC6145 isn't backward compatible (an upgraded node isn&= #39;t guaranteed to interwork with a non upgraded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








--20cf3074b47e1fd9af04bb3dad76-- From fibrib@gmail.com Wed Mar 14 19:09:56 2012 Return-Path: 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 3BF5A11E8086 for ; Wed, 14 Mar 2012 19:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 usZE95YPrpZM for ; Wed, 14 Mar 2012 19:09:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4361411E8075 for ; Wed, 14 Mar 2012 19:09:55 -0700 (PDT) Received: by yenm5 with SMTP id m5so2891227yen.31 for ; Wed, 14 Mar 2012 19:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=A6jecMR7enSJks4Mdy4r9M3fIsbZVwxSzii80HkOw5g=; b=sgexdMoYs2gXuCDBWgHUHrxyyj8cYLWCsQga7/uICbqI6354XvRtWJLgE+Z0QynmEo yXZllMo02vFHeUkqpD2mP+6v9h8L4/zyft51qe6hs9EhgTwaXZrLNmt5V0IS+vPfdra6 qEfkHqPU22/26XHrEwvA0HHSO/GNxV25U7VvcvqvZA1JsziqVa+rUB1Ow2iWH+jlEGds pPJ0oUZytNixNlEMUxTp5aQq0m8y5P26aBzyrwxAnGOGnfrKQBFZMqCcXlqFTez8POfp BZBpLGg7jJ/PygqC8/VlgXHI9ACoKGS8zTYxBhDano5NCnqwpSRaiWTuapmJILkLp6+Y jwnQ== MIME-Version: 1.0 Received: by 10.229.134.196 with SMTP id k4mr1710996qct.29.1331777394835; Wed, 14 Mar 2012 19:09:54 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Wed, 14 Mar 2012 19:09:54 -0700 (PDT) Date: Thu, 15 Mar 2012 02:09:54 +0000 Message-ID: From: Maoke To: Wojciech Dec , Congxiao Bao , Softwires-wg Content-Type: multipart/alternative; boundary=00248c6a86e28a012504bb3e9639 Subject: [Softwires] L4 checksum spec in MAP-T X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:09:56 -0000 --00248c6a86e28a012504bb3e9639 Content-Type: text/plain; charset=ISO-8859-1 hi Woj, prof. Bao and others, as i discussed with Remi in the thread http://www.ietf.org/mail-archive/web/softwires/current/msg03641.html , i found that RFC6145 leaving DCCP support as optional may cause a asymmetric-process when it is applied for double translation, and there was not an explicit statement on the support for other L4 protocols. i do suggest to consider this issue in MAP-T. my humble suggestion is adding two paragraph in the introduction, after the first paragraph, stating that: Regarding the L4 checksum calculation at the address-family boundary (CE or BR), RFC6145 mandates TCP and UDP but leaves DCCP as optional. In a double-translation environment, if only IPv4-to-IPv6 translator adjusts the checksum of DCCP but the IPv6-to-IPv4 side doesn't, the IPv4 destination may receive DCCP packets with wrong checksum. MAP-T ensures DCCP support by updating its checksum at CE or BR whenever the DCCP packets are passing through. Listing all possible transportation protocols is not feasible nor necessary. For a transportation protocol not mentioned explicitly here or in RFC6145, a MAP-T-compliant equipment MUST either discard packets of that protocol (as unsupported) or have the corresponding code for the L4 checksum adjustification. * Throughout this document, whenever RFC6145 is cited, the above considerations are also involved, even without explicit statement. if anyone thinks support of DCCP and/or other less-well-known transportation protocols is fairly not significant, please also respond. thanks a lot for the concern. regards, maoke --00248c6a86e28a012504bb3e9639 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Woj, prof. Bao and others,=A0

as i dis= cussed with Remi in the thread http://www.ietf.org/mail-archive/web/s= oftwires/current/msg03641.html , i found that RFC6145 leaving DCCP supp= ort as optional may cause a asymmetric-process when it is applied for doubl= e translation, and there was not an explicit statement on the support for o= ther L4 protocols. i do suggest to consider this issue in MAP-T. my humble = suggestion is adding two paragraph in the introduction, after the first par= agraph, stating that:=A0

=A0 =A0Regarding the L4 checksum calculation at the add= ress-family boundary (CE or BR),
=A0 =A0RFC6145 mandates TCP and= UDP but leaves DCCP as optional. In a double-translation=A0
=A0 = =A0environment, if only IPv4-to-IPv6 translator adjusts the checksum of DCC= P but the
=A0 =A0IPv6-to-IPv4 side doesn't, the IPv4 destination may receive= DCCP packets with wrong
=A0 =A0checksum. MAP-T ensures DCCP sup= port by updating its checksum at CE or BR whenever=A0
=A0 =A0the = DCCP packets are passing through.=A0

=A0 =A0Listing all possible transportation protocols is= not feasible nor necessary. For=A0
=A0 =A0a transportation proto= col not mentioned explicitly here or in RFC6145, a
=A0 =A0MAP-T-= compliant equipment MUST either discard packets of that protocol (as=A0
=A0 =A0unsupported) or have the corresponding code for the L4 checksum= adjustification.=A0

=A0 =A0* Throughout this docu= ment, whenever RFC6145 is cited, the above considerations=A0
=A0 = =A0are also involved, even without explicit statement.=A0

if anyone thinks support of DCCP and/or other less-well= -known transportation protocols is fairly not significant, please also resp= ond. thanks a lot for the concern.=A0

regards,
maoke
--00248c6a86e28a012504bb3e9639-- From tom.taylor.stds@gmail.com Wed Mar 14 20:26:08 2012 Return-Path: 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 84BC721F86EE for ; Wed, 14 Mar 2012 20:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kLrBYFV1z4Va for ; Wed, 14 Mar 2012 20:26:08 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2721F86EB for ; Wed, 14 Mar 2012 20:26:07 -0700 (PDT) Received: by dald2 with SMTP id d2so5239788dal.27 for ; Wed, 14 Mar 2012 20:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=3x63i5thMJ97cuzjtXqPlKiwpPFLnKJY71GJi24mFEQ=; b=Nfb0XHFClrd1C/Nc20c4/OnwberNDIGtXg9ypvAGnzBZm9jpCbczWEE3SNsBDZT50a nTqYQCpiyAiGgR9d/lOZmtsCOxzo4ZbmWsnOxbeykO3u7sejpsTA0fD7OHXBEJE2XKZC 3NzC/y17ADWtzqpw9uvEug0tAZeq505a3fvNpYkH69mSReSF6rKs8FL/Ka6Qoj18GAn8 vbms9mRTSLDA9tfFt6UOSPgeKFTstYxq3uwUhBj3LsWEXgfKu/DZZN9l9LyUAu91B0SL 0BDOhVr61XLEr3JFtSeh31Zmc5r4xo14DkgMg5g/BH9BIClAmkVsvWc2B4WZS46w0CWr Gkaw== Received: by 10.68.232.2 with SMTP id tk2mr1328876pbc.68.1331781967760; Wed, 14 Mar 2012 20:26:07 -0700 (PDT) Received: from [127.0.0.1] (dsl-209-90-147-217.tor.primus.ca. [209.90.147.217]) by mx.google.com with ESMTPS id d4sm844854pbe.36.2012.03.14.20.26.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 20:26:07 -0700 (PDT) Message-ID: <4F61614D.9040101@gmail.com> Date: Wed, 14 Mar 2012 23:26:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120314-1, 14/03/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Apology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 03:26:08 -0000 Behcet, I apologize. Even if we differ on what constitutes a multicast solution, I was wrong to refer to your drafts in a pejorative manner. Tom Taylor From adurand@juniper.net Wed Mar 14 23:26:11 2012 Return-Path: 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 D6EE721F8700 for ; Wed, 14 Mar 2012 23:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 6Bzo6bpESvph for ; Wed, 14 Mar 2012 23:26:11 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 553E621F86FC for ; Wed, 14 Mar 2012 23:26:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT2GLdjcoF5YwDVCXpCj57sWXNsFTAhZn@postini.com; Wed, 14 Mar 2012 23:26:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 14 Mar 2012 23:24:03 -0700 From: Alain Durand To: Peng Wu Date: Wed, 14 Mar 2012 23:24:04 -0700 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0CdDevImEhmBiwSkebkQyy8O0oHg== Message-ID: <780BCDDC-276F-45C8-8001-2D93C3FFFE01@juniper.net> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 06:26:12 -0000 On Mar 14, 2012, at 1:07 PM, Peng Wu wrote: > Hi Alain, >=20 > It's a little confusing now. Let me try to get things clear. >=20 > So the sd-nat-02 is not quite similar to the earlier version, the > mechanism somehow changes. One drawback of sdnat-01 was that the AFTR would still have to do ALG work,= so it was not purely stateless. So, instead of asking each CPE to use ports 1024 to 1024+max and then slide= this range into the correct one in the AFTR, sdnat-02 tells each CPE which actual port range min..max to use through th= e newly defined ICMP message. The net result is that the AFTR does not need to perform any ALG work anymo= re, making it truly stateless > In my understanding, now the principle of the mechanism is similar to > the lightweight 4over6 draft, but I may miss something here. The general idea is the same, however loghtweight 4over6 does not specify h= ow to achieve it, it leaves the technique to assign address and port open. stateless DS-lite (aka sdnat-02) does spec= ify exactly how you achieve this. > My question is, how is it stateless or deterministic, and how is IPv6 > anycast for multiple AFTRs working? See above, the AFTR is now entirely stateless. The port range is fixed, thu= s deterministic and no logs are necessary. > Seems the draft is suggesting that we put an identical profile on each > AFTR, the content of which is the mapping between IPv6 address and > IPv4 address+port range for all the CPEs (And of course, we can try to > find some protocol to synchronize the mapping automatically). Did I > get this correctly? Yes, this is correct. For a group of user sharing the same AFTR set, each A= FTR in the set is configured with the same anycast IPv6 address and the same IPv4 address = pool and per-subscriber mapping table. That IPv4 pool is announced as an anycast IPv= 4 route upstream by all AFTRs in the set. From mohamed.boucadair@orange.com Wed Mar 14 23:35:47 2012 Return-Path: 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 5C01621F8783 for ; Wed, 14 Mar 2012 23:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 Oq1d0vIRC3LA for ; Wed, 14 Mar 2012 23:35:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2B78721F877C for ; Wed, 14 Mar 2012 23:35:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1707B3B40B5; Thu, 15 Mar 2012 07:35:45 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EE18523813F; Thu, 15 Mar 2012 07:35:44 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 15 Mar 2012 07:35:44 +0100 From: To: Alain Durand , Peng Wu Date: Thu, 15 Mar 2012 07:35:43 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0CdDevImEhmBiwSkebkQyy8O0oHgAAPOvg Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DBA99@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <780BCDDC-276F-45C8-8001-2D93C3FFFE01@juniper.net> In-Reply-To: <780BCDDC-276F-45C8-8001-2D93C3FFFE01@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.15.53316 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 06:35:47 -0000 =20 > -----Message d'origine----- > De : softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] De la part de Alain Durand > Envoy=E9 : jeudi 15 mars 2012 07:24 > =C0 : Peng Wu > Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite;=20 > draft-penno-softwire-sdnat@tools.ietf.org > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite >=20 >=20 > > In my understanding, now the principle of the mechanism is=20 > similar to > > the lightweight 4over6 draft, but I may miss something here. >=20 > The general idea is the same, however loghtweight 4over6 does=20 > not specify how to achieve it, it leaves the technique > to assign address and port open. stateless DS-lite (aka=20 > sdnat-02) does specify exactly how you achieve this. >=20 Med: I'm sorry to say this is not true. Please read: http://tools.ietf.org/= html/draft-cui-softwire-b4-translated-ds-lite-05#section-5. Four provisioning alternatives are listed there. If the WG want to make a d= ecision on the ** mandatory ** one, this will be reflected in future versio= n of the document. = From despres.remi@laposte.net Thu Mar 15 01:54:49 2012 Return-Path: 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 6FE0221F8661 for ; Thu, 15 Mar 2012 01:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Zk9i-+CkqEMw for ; Thu, 15 Mar 2012 01:54:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9435E21F8665 for ; Thu, 15 Mar 2012 01:54:46 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id lkui1i00g37Y3f403kujxY; Thu, 15 Mar 2012 09:54:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-122--840318983 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 09:54:42 +0100 Message-Id: <021B203F-E4AB-4835-BCEF-833ACCEC12A1@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 08:54:49 -0000 --Apple-Mail-122--840318983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is = AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite = translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, = i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate = DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those = complying with previous versions wouldn't be guaranteed to interwork for = DCCP. If we don't agree on this, there is still something to be clarified = between us. If we agree, I have nothing else on this point. Regards, RD If, as you suggest,=20 2012-03-15 02:04, Maoke: > 2012/3/14 R=E9mi Despr=E9s >=20 > Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>=20 >> 2012/3/14 R=E9mi Despr=E9s ... >> =20 >> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>=20 >> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is = still in development. if we state to enforce DCCP mandatorily rather = than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward = compatible problem. to this extend, MAP-T is at the same kick-off line = of the 4rd-U.=20 >=20 > 1. I agree that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be updatable.=20= >=20 > 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 > Thought?=20 >=20 > surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >=20 > - maoke > =20 >=20 >=20 >> To be even more precise, H6 of the comparison table can be: >> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>=20 >> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >=20 > Will see what to do, then, when changes to the MAP-T draft concerning = DCCP are known.=20 >=20 > RD >=20 >=20 >> =20 >>=20 >> maoke=20 >> =20 >>=20 >> Does this cover the point? >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>>=20 >>> ;-) >>> maoke=20 >>> =20 >>>=20 >>>> but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>=20 >>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>=20 >>> If I had thought it might be so, I would have avoided the word. >>>=20 >>>=20 >>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>=20 >>>> only my 2 cents.=20 >>>=20 >>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>> Thanks for the useful reference to the RDP of RFC1151. >>>=20 >>> RD=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-122--840318983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s = <despres.remi@laposte.net>
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=







_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

= = --Apple-Mail-122--840318983-- From fibrib@gmail.com Thu Mar 15 02:02:15 2012 Return-Path: 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 96B1D21F86B8 for ; Thu, 15 Mar 2012 02:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 AgHDxn8TEe+R for ; Thu, 15 Mar 2012 02:02:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15221F86B6 for ; Thu, 15 Mar 2012 02:02:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3169207ghb.31 for ; Thu, 15 Mar 2012 02:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DrIMYodsDSQ6lDBl92PlIzb+wzdsw07xBcGkrEiLmAU=; b=XR+XyWAynUURzY60U7wJ5Msr0tYPfVVTMbHHvwNq+yQeERjBtQaa9sXtkomJTBDvMJ 2j9lx+HWNBMXpzM8qTyEFuqfyCRgU8pvsMuou6I6OgdjUn/4va1LDm99596NQusz6Nw+ mRql4ZdWpu5pGMdsCAOYL62/pzYr8g2lOrQP7qV7BIDcZASeeXpQzrVThirt12kLjZFX yYtkAatyG04ESgphoPJGRgEq8FS2RK0f0Lq16iTUhL83Z/TNIGEAZ8BSwXpczStVdO5h EaTxm0Ptz+c9Q8exHfoi9IO2iGo1Ij4EH+g2azRYeSrSQPT4VnG9naAw8CHmTtVaYF8l ljOg== MIME-Version: 1.0 Received: by 10.229.136.200 with SMTP id s8mr2031481qct.9.1331802133644; Thu, 15 Mar 2012 02:02:13 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:02:13 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> Date: Thu, 15 Mar 2012 09:02:13 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=002354530350164e9604bb44591d Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:02:15 -0000 --002354530350164e9604bb44591d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > Maoke, > > Let's try, once more, to understand each other. > > If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which > is AFAIAC a positive result of our discussion): > a) Such a CE can communicate with an IPv6-only host including in DCCP. > b) The same would apply to UDP lite if MAP-T would also require UDP-lite > translation. > c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e= . > with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (= as > permitted by RFC6145). > d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCC= P > translation, nodes complying with modified versions and those complying > with previous versions wouldn't be guaranteed to interwork for DCCP. > > If we don't agree on this, there is still something to be clarified > between us. > surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. - maoke > If we agree, I have nothing else on this point. > > Regards, > RD > > > > If, as you suggest, > 2012-03-15 02:04, Maoke: > > 2012/3/14 R=E9mi Despr=E9s > >> >> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >> >> >> 2012/3/14 R=E9mi Despr=E9s >> >> ... > > >>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>> backward compatible (an upgraded node isn't guaranteed to interwork wit= h a >>> non upgraded node). >>> >> >> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >> still in development. if we state to enforce DCCP mandatorily rather tha= n >> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >> compatible problem. to this extend, MAP-T is at the same kick-off line o= f >> the 4rd-U. >> >> >> 1. I agree that, between CEs and BRs, there can be no problem for DCCP >> (provided the draft is completed to this effect). The comparison table w= as >> explicitly made with existing drafts, and intended to be updatable. >> >> 2. The MAP-T draft is also claimed to allow "communication between >> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >> servers in the domain that are using IPv4-mapped IPv6 address". In this >> case, AFAIK, the backward compatibility problem exists >> Thought? >> > > surely it does not exist. that statement applies to the MAP-T-compliant > equipments, when it is used as a IPv4-to-IPv6 single translator or as an > native IPv6 router. same deployment of equipments should support > double-translation, single-translation, and native IPv6 accesses > simultanenously. that's one of the points of the MAP-T. > > - maoke > > >> >> >> To be even more precise, H6 of the comparison table can be: >>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>> addresses, DCCP and UDP-Lite are supported, as well as future protocols >>> using the TCP checksum algorithm and ports at the same place" >>> >> >> i actually think the original text is fine. "For .... shared IPv4 >> addresses" is not needed for 4rd-U, to my understanding, nor needed to >> MAP-T. >> >> >> Will see what to do, then, when changes to the MAP-T draft concerning >> DCCP are known. >> > >> RD >> >> >> >> >> maoke >> >> >>> >>> Does this cover the point? >>> >>> RD >>> >>> >>> >>> >>> >>> ;-) >>> maoke >>> >>> >>>> >>>> but this is not my point. my point is: there must be something we >>>> don't know ("non omnia possumus omnes"). even we have gone through the >>>> RFCs, there might be some other proprietary L4 protocols, or experimen= tal >>>> protocols. even they are minority, i don't think ignoring their exista= nce >>>> in our solution fits the spirit of the Internet. it might be argued th= at >>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner = may >>>> makes his own NAT44, either attached to the CE or separated. if 4rd-U >>>> respects such an effort, it should state "currently blahblabla L4 prot= ocols >>>> are supported". the similar statement applies to the RFC6145 or MAP as= well. >>>> >>>> >>>> i somehow am hard to accept words like "far fetched theoretical >>>> problem". >>>> >>>> >>>> If I had thought it might be so, I would have avoided the word. >>>> >>>> >>>> the L4-recalculate is a generic, architectural solution, surely needin= g >>>> codes for every L4 protocol. but this generality in architecture makes >>>> RFC6145 or MAP-T equipment be easily enhanced to support anything new = with >>>> the same logic. but for the 4rd-U BR, it looks to me we cannot have th= e >>>> unified logic for all (even limited to existing and well-known) L4 >>>> protocols. >>>> >>>> only my 2 cents. >>>> >>>> >>>> With amendments above, the point is AFAIK completely covered: >>>> everything is rigorously true, and worth noting. >>>> Thanks for the useful reference to the RDP of RFC1151. >>>> >>>> RD >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --002354530350164e9604bb44591d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr&g= t;
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:=A0

=A0 =A0T= he current specification only defines how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

- maoke
=A0
=
If = we agree, I have nothing else on this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


--002354530350164e9604bb44591d-- From despres.remi@laposte.net Thu Mar 15 02:09:08 2012 Return-Path: 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 9CEBE21F84B9 for ; Thu, 15 Mar 2012 02:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.079, 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 n-2f-CaNwZJu for ; Thu, 15 Mar 2012 02:09:02 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 216CA21F84BF for ; Thu, 15 Mar 2012 02:09:00 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id ll8x1i00G37Y3f403l8xyh; Thu, 15 Mar 2012 10:08:59 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-123--839465194 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 10:08:56 +0100 Message-Id: <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:09:08 -0000 --Apple-Mail-123--839465194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s > Maoke, >=20 > Let's try, once more, to understand each other. >=20 > If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion): > a) Such a CE can communicate with an IPv6-only host including in DCCP. > b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. > c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, = i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate = DCCP (as permitted by RFC6145). > d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those = complying with previous versions wouldn't be guaranteed to interwork for = DCCP. >=20 > If we don't agree on this, there is still something to be clarified = between us. >=20 > surely do not. RFC6146 clearly states: > The current specification only defines how stateful NAT64 = translates > unicast packets carrying TCP, UDP, and ICMP traffic. Multicast > packets and other protocols, including the Stream Control > Transmission Protocol (SCTP), the Datagram Congestion Control > Protocol (DCCP), and IPsec, are out of the scope of this > specification. I said "If RFC614... would be modified to also impose DCCP translation" = =3D> I take the point that you are not interested in that, but I don't = think there was a contradiction. OK? RD >=20 > - maoke > =20 > If we agree, I have nothing else on this point. >=20 > Regards, > RD >=20 >=20 >=20 > If, as you suggest,=20 > 2012-03-15 02:04, Maoke: >=20 >> 2012/3/14 R=E9mi Despr=E9s >>=20 >> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>=20 >>> 2012/3/14 R=E9mi Despr=E9s > ... >>> =20 >>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>=20 >>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T = is still in development. if we state to enforce DCCP mandatorily rather = than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward = compatible problem. to this extend, MAP-T is at the same kick-off line = of the 4rd-U.=20 >>=20 >> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>=20 >> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >> Thought?=20 >>=20 >> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>=20 >> - maoke >> =20 >>=20 >>=20 >>> To be even more precise, H6 of the comparison table can be: >>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>=20 >>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>=20 >> Will see what to do, then, when changes to the MAP-T draft concerning = DCCP are known.=20 >>=20 >> RD >>=20 >>=20 >>> =20 >>>=20 >>> maoke=20 >>> =20 >>>=20 >>> Does this cover the point? >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> ;-) >>>> maoke=20 >>>> =20 >>>>=20 >>>>> but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>=20 >>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>=20 >>>> If I had thought it might be so, I would have avoided the word. >>>>=20 >>>>=20 >>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>=20 >>>>> only my 2 cents.=20 >>>>=20 >>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>> Thanks for the useful reference to the RDP of RFC1151. >>>>=20 >>>> RD=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-123--839465194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification only = defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I said = "If RFC614... would be modified to also impose DCCP translation" = =3D> I take the point that you are not interested in that, but I = don't think there was a = contradiction.
OK?

RD



- = maoke
 
If we = agree, I have nothing else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-123--839465194-- From fibrib@gmail.com Thu Mar 15 02:22:16 2012 Return-Path: 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 7D96821F8690 for ; Thu, 15 Mar 2012 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 7tmVQnMhkTUi for ; Thu, 15 Mar 2012 02:22:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2C721F86A1 for ; Thu, 15 Mar 2012 02:22:14 -0700 (PDT) Received: by yenm5 with SMTP id m5so3187845yen.31 for ; Thu, 15 Mar 2012 02:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cFZvU6SiZPHMOVZRpkFob5+PbIaxV0Ljm9TAAg1WgDQ=; b=VgkgaXqzVvopEkNE0gvt+O9GD5tiJHyACDCkdZpCJNTQMLRO4Nk2l9tgFdjaPbfv7a uxfY3jQWE0/nbGqJmpl4WJKZyQ9Dg7edE+ve9H9zy5GaOYgP6qq+OR91XLJhwg9Y5wAC 3Q4RkbMmjRlTD+CFT6y5aXFQDPfF5UzT17ygpA/ulKEqp5ZS9Zny8z13cxgnBBwMfbcr n6+ag2L7Q5e+7e37BpyyUPzYPxSu9g3LAbSGHb7Upz0mnujJDDKyZ4OBIkITKjX47rLq jxLNtrx8Da0V0tf2p9IFsQcXu9JaUtoTCh+OcBHDFs/1/o7wxOxkNurgcfXTZVpqr42w 4Ztw== MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr2018651qct.49.1331803333908; Thu, 15 Mar 2012 02:22:13 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:22:13 -0700 (PDT) In-Reply-To: <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> Date: Thu, 15 Mar 2012 09:22:13 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c767e96a0dac504bb44a005 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:22:17 -0000 --00248c767e96a0dac504bb44a005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 10:02, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> Maoke, >> >> Let's try, once more, to understand each other. >> >> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >> is AFAIAC a positive result of our discussion): >> a) Such a CE can communicate with an IPv6-only host including in DCCP. >> b) The same would apply to UDP lite if MAP-T would also require UDP-lite >> translation. >> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate >> DCCP (as permitted by RFC6145). >> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >> DCCP translation, nodes complying with modified versions and those >> complying with previous versions wouldn't be guaranteed to interwork for >> DCCP. >> >> If we don't agree on this, there is still something to be clarified >> between us. >> > > surely do not. RFC6146 clearly states: > > The current specification only defines how stateful NAT64 translates > unicast packets carrying TCP, UDP, and ICMP traffic. Multicast > packets and other protocols, including the Stream Control > Transmission Protocol (SCTP), the Datagram Congestion Control > Protocol (DCCP), and IPsec, are out of the scope of this > specification. > > > I said "If RFC614... would be modified to also impose DCCP translation" = =3D> > I take the point that you are not interested in that, but I don't think > there was a contradiction. > OK? > it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? maoke > > RD > > > > - maoke > > >> If we agree, I have nothing else on this point. >> >> Regards, >> RD >> >> >> >> If, as you suggest, >> 2012-03-15 02:04, Maoke: >> >> 2012/3/14 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>> >>> >>> 2012/3/14 R=E9mi Despr=E9s >>> >>> ... >> >> >>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>> backward compatible (an upgraded node isn't guaranteed to interwork wi= th a >>>> non upgraded node). >>>> >>> >>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >>> still in development. if we state to enforce DCCP mandatorily rather th= an >>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>> compatible problem. to this extend, MAP-T is at the same kick-off line = of >>> the 4rd-U. >>> >>> >>> 1. I agree that, between CEs and BRs, there can be no problem for DCCP >>> (provided the draft is completed to this effect). The comparison table = was >>> explicitly made with existing drafts, and intended to be updatable. >>> >>> 2. The MAP-T draft is also claimed to allow "communication between >>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >>> servers in the domain that are using IPv4-mapped IPv6 address". In this >>> case, AFAIK, the backward compatibility problem exists >>> Thought? >>> >> >> surely it does not exist. that statement applies to the MAP-T-compliant >> equipments, when it is used as a IPv4-to-IPv6 single translator or as an >> native IPv6 router. same deployment of equipments should support >> double-translation, single-translation, and native IPv6 accesses >> simultanenously. that's one of the points of the MAP-T. >> >> - maoke >> >> >>> >>> >>> To be even more precise, H6 of the comparison table can be: >>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>> addresses, DCCP and UDP-Lite are supported, as well as future protocol= s >>>> using the TCP checksum algorithm and ports at the same place" >>>> >>> >>> i actually think the original text is fine. "For .... shared IPv4 >>> addresses" is not needed for 4rd-U, to my understanding, nor needed to >>> MAP-T. >>> >>> >>> Will see what to do, then, when changes to the MAP-T draft concerning >>> DCCP are known. >>> >> >>> RD >>> >>> >>> >>> >>> maoke >>> >>> >>>> >>>> Does this cover the point? >>>> >>>> RD >>>> >>>> >>>> >>>> >>>> >>>> ;-) >>>> maoke >>>> >>>> >>>>> >>>>> but this is not my point. my point is: there must be something we >>>>> don't know ("non omnia possumus omnes"). even we have gone through th= e >>>>> RFCs, there might be some other proprietary L4 protocols, or experime= ntal >>>>> protocols. even they are minority, i don't think ignoring their exist= ance >>>>> in our solution fits the spirit of the Internet. it might be argued t= hat >>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner= may >>>>> makes his own NAT44, either attached to the CE or separated. if 4rd-U >>>>> respects such an effort, it should state "currently blahblabla L4 pro= tocols >>>>> are supported". the similar statement applies to the RFC6145 or MAP a= s well. >>>>> >>>>> >>>>> i somehow am hard to accept words like "far fetched theoretical >>>>> problem". >>>>> >>>>> >>>>> If I had thought it might be so, I would have avoided the word. >>>>> >>>>> >>>>> the L4-recalculate is a generic, architectural solution, surely >>>>> needing codes for every L4 protocol. but this generality in architect= ure >>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anythi= ng new >>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot h= ave >>>>> the unified logic for all (even limited to existing and well-known) L= 4 >>>>> protocols. >>>>> >>>>> only my 2 cents. >>>>> >>>>> >>>>> With amendments above, the point is AFAIK completely covered: >>>>> everything is rigorously true, and worth noting. >>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> > > --00248c767e96a0dac504bb44a005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :


=
2012/3/15 R=E9mi Despr=E9s <remi.despres= @free.fr>
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not yet mo= dified. with the current statement of RFC6146, the current equipment doesn&= #39;t support DCCP. if it is modified, the update may state mandatory impos= ement for DCCP. i don't see any problem here. on the other hand, i cann= ot understand how the CNP helps stateful checksum validity. may you please = to clarify?=A0

maoke
=A0

RD



- maoke
= =A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires




--00248c767e96a0dac504bb44a005-- From fibrib@gmail.com Thu Mar 15 02:29:28 2012 Return-Path: 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 A401E21F8661 for ; Thu, 15 Mar 2012 02:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 m6ym4vigYbEL for ; Thu, 15 Mar 2012 02:29:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0121F865F for ; Thu, 15 Mar 2012 02:29:26 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3196551ggm.31 for ; Thu, 15 Mar 2012 02:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kI471ijo0sFeIak3NUMWdx3XBXUKS1jkOlyhgvDHmpM=; b=PwUkxZl/H3uhALS4oDVBR9i9LXf/eDCChCDtttfJCbcAe9kZ1+omNLfcYt812as+IK xNbJLMWh3WMldsSPJH+hKNxSYClkDofIobHpZOGgWThq2ru900rQYvN1qHKpVj1thbjx 3wlsBKsbh3w9yf9o4E+yEzfgnD0UdyIlQQAJmoGUHnsQAouRlut3l0IgvwdUanB7hSjr TaHGVgQ1lBsLTXM5r/Nw9McmPdjhGao1W3MGD1e8Mc0eaio9JH2qP8hL+DZ+vUZXWKW3 stEC+l/qI8lQzdNxfpo+uR8LRHJroDkc17VQ72lLmAn9lOZnpVBRnxQA1ofCoQj9M89q Z2bA== MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr2024681qct.49.1331803765658; Thu, 15 Mar 2012 02:29:25 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:29:25 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> Date: Thu, 15 Mar 2012 09:29:25 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c767e965cd41f04bb44baf6 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:29:28 -0000 --00248c767e965cd41f04bb44baf6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 Maoke > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >> >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> Maoke, >>> >>> Let's try, once more, to understand each other. >>> >>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>> is AFAIAC a positive result of our discussion): >>> a) Such a CE can communicate with an IPv6-only host including in DCCP. >>> b) The same would apply to UDP lite if MAP-T would also require UDP-lit= e >>> translation. >>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate >>> DCCP (as permitted by RFC6145). >>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >>> DCCP translation, nodes complying with modified versions and those >>> complying with previous versions wouldn't be guaranteed to interwork fo= r >>> DCCP. >>> >>> If we don't agree on this, there is still something to be clarified >>> between us. >>> >> >> surely do not. RFC6146 clearly states: >> >> The current specification only defines how stateful NAT64 translates >> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >> packets and other protocols, including the Stream Control >> Transmission Protocol (SCTP), the Datagram Congestion Control >> Protocol (DCCP), and IPsec, are out of the scope of this >> specification. >> >> >> I said "If RFC614... would be modified to also impose DCCP translation" >> =3D> I take the point that you are not interested in that, but I don't t= hink >> there was a contradiction. >> OK? >> > > it is not yet modified. with the current statement of RFC6146, the curren= t > equipment doesn't support DCCP. if it is modified, the update may state > mandatory imposement for DCCP. i don't see any problem here. > more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no "interwork" between NAT64 who has been modified with the NAT64 who has not. incorrect? > on the other hand, i cannot understand how the CNP helps stateful checksu= m > validity. may you please to clarify? > > maoke > > >> >> RD >> >> >> >> - maoke >> >> >>> If we agree, I have nothing else on this point. >>> >>> Regards, >>> RD >>> >>> >>> >>> If, as you suggest, >>> 2012-03-15 02:04, Maoke: >>> >>> 2012/3/14 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>> >>>> >>>> 2012/3/14 R=E9mi Despr=E9s >>>> >>>> ... >>> >>> >>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>> backward compatible (an upgraded node isn't guaranteed to interwork w= ith a >>>>> non upgraded node). >>>>> >>>> >>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >>>> still in development. if we state to enforce DCCP mandatorily rather t= han >>>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>>> compatible problem. to this extend, MAP-T is at the same kick-off line= of >>>> the 4rd-U. >>>> >>>> >>>> 1. I agree that, between CEs and BRs, there can be no problem for DCCP >>>> (provided the draft is completed to this effect). The comparison table= was >>>> explicitly made with existing drafts, and intended to be updatable. >>>> >>>> 2. The MAP-T draft is also claimed to allow "communication between >>>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >>>> servers in the domain that are using IPv4-mapped IPv6 address". In >>>> this case, AFAIK, the backward compatibility problem exists >>>> Thought? >>>> >>> >>> surely it does not exist. that statement applies to the MAP-T-compliant >>> equipments, when it is used as a IPv4-to-IPv6 single translator or as a= n >>> native IPv6 router. same deployment of equipments should support >>> double-translation, single-translation, and native IPv6 accesses >>> simultanenously. that's one of the points of the MAP-T. >>> >>> - maoke >>> >>> >>>> >>>> >>>> To be even more precise, H6 of the comparison table can be: >>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>> addresses, DCCP and UDP-Lite are supported, as well as future protoco= ls >>>>> using the TCP checksum algorithm and ports at the same place" >>>>> >>>> >>>> i actually think the original text is fine. "For .... shared IPv4 >>>> addresses" is not needed for 4rd-U, to my understanding, nor needed to >>>> MAP-T. >>>> >>>> >>>> Will see what to do, then, when changes to the MAP-T draft concerning >>>> DCCP are known. >>>> >>> >>>> RD >>>> >>>> >>>> >>>> >>>> maoke >>>> >>>> >>>>> >>>>> Does this cover the point? >>>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ;-) >>>>> maoke >>>>> >>>>> >>>>>> >>>>>> but this is not my point. my point is: there must be something we >>>>>> don't know ("non omnia possumus omnes"). even we have gone through t= he >>>>>> RFCs, there might be some other proprietary L4 protocols, or experim= ental >>>>>> protocols. even they are minority, i don't think ignoring their exis= tance >>>>>> in our solution fits the spirit of the Internet. it might be argued = that >>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owne= r may >>>>>> makes his own NAT44, either attached to the CE or separated. if 4rd-= U >>>>>> respects such an effort, it should state "currently blahblabla L4 pr= otocols >>>>>> are supported". the similar statement applies to the RFC6145 or MAP = as well. >>>>>> >>>>>> >>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>> problem". >>>>>> >>>>>> >>>>>> If I had thought it might be so, I would have avoided the word. >>>>>> >>>>>> >>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>> needing codes for every L4 protocol. but this generality in architec= ture >>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anyth= ing new >>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot = have >>>>>> the unified logic for all (even limited to existing and well-known) = L4 >>>>>> protocols. >>>>>> >>>>>> only my 2 cents. >>>>>> >>>>>> >>>>>> With amendments above, the point is AFAIK completely covered: >>>>>> everything is rigorously true, and worth noting. >>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >> >> > --00248c767e965cd41f04bb44baf6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr= =E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr= >
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not = yet modified. with the current statement of RFC6146, the current equipment = doesn't support DCCP. if it is modified, the update may state mandatory= imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful NAT6= 4, i think, only needs to be done once in a delivery, therefore either the = DCCP is supported or it is not. there's no "interwork" betwee= n NAT64 who has been modified with the NAT64 who has not. incorrect?=A0
=A0
on the other hand, i cannot understand how the CNP helps stateful checksu= m validity. may you please to clarify?=A0

maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires




--00248c767e965cd41f04bb44baf6-- From despres.remi@laposte.net Thu Mar 15 02:31:21 2012 Return-Path: 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 78E0321F86C3 for ; Thu, 15 Mar 2012 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Uf5BzI42jgF7 for ; Thu, 15 Mar 2012 02:31:20 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id A4FBD21F854A for ; Thu, 15 Mar 2012 02:31:18 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id llXF1i00H37Y3f403lXFD5; Thu, 15 Mar 2012 10:31:17 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-124--838126842 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 10:31:14 +0100 Message-Id: <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:31:21 -0000 --Apple-Mail-124--838126842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 10:22, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >> Maoke, >>=20 >> Let's try, once more, to understand each other. >>=20 >> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion): >> a) Such a CE can communicate with an IPv6-only host including in = DCCP. >> b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. >> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, = i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate = DCCP (as permitted by RFC6145). >> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those = complying with previous versions wouldn't be guaranteed to interwork for = DCCP. >>=20 >> If we don't agree on this, there is still something to be clarified = between us. >>=20 >> surely do not. RFC6146 clearly states: >> The current specification only defines how stateful NAT64 = translates >> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >> packets and other protocols, including the Stream Control >> Transmission Protocol (SCTP), the Datagram Congestion Control >> Protocol (DCCP), and IPsec, are out of the scope of this >> specification. >=20 > I said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in that, = but I don't think there was a contradiction. > OK? >=20 > it is not yet modified. with the current statement of RFC6146, the = current equipment doesn't support DCCP. if it is modified, the update = may state mandatory imposement for DCCP. i don't see any problem here. OK, we are now in sync on this point :-). > on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 On this new subject, could you be more precise on what you mean by = "stateful checksum validity"?=20 RD >=20 > maoke > =20 >=20 > RD >=20 >=20 >>=20 >> - maoke >> =20 >> If we agree, I have nothing else on this point. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> If, as you suggest,=20 >> 2012-03-15 02:04, Maoke: >>=20 >>> 2012/3/14 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>=20 >>>> 2012/3/14 R=E9mi Despr=E9s >> ... >>>> =20 >>>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>>=20 >>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T = is still in development. if we state to enforce DCCP mandatorily rather = than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward = compatible problem. to this extend, MAP-T is at the same kick-off line = of the 4rd-U.=20 >>>=20 >>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>=20 >>> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >>> Thought?=20 >>>=20 >>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>=20 >>> - maoke >>> =20 >>>=20 >>>=20 >>>> To be even more precise, H6 of the comparison table can be: >>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>=20 >>>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>>=20 >>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>=20 >>> RD >>>=20 >>>=20 >>>> =20 >>>>=20 >>>> maoke=20 >>>> =20 >>>>=20 >>>> Does this cover the point? >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> ;-) >>>>> maoke=20 >>>>> =20 >>>>>=20 >>>>>> but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>=20 >>>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>>=20 >>>>> If I had thought it might be so, I would have avoided the word. >>>>>=20 >>>>>=20 >>>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>>=20 >>>>>> only my 2 cents.=20 >>>>>=20 >>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>=20 >>>>> RD=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 --Apple-Mail-124--838126842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-15 =E0 = 10:02, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification = only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I = said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in = that, but I don't think there was a contradiction.
OK?

it is not yet = modified. with the current statement of RFC6146, the current equipment = doesn't support DCCP. if it is modified, the update may state mandatory = imposement for DCCP. i don't see any problem here. =

OK, we are now in sync on = this point :-).

on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

On this new = subject, could you be more precise on what you mean by "stateful = checksum = validity"? 

RD


=



maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires





= --Apple-Mail-124--838126842-- From despres.remi@laposte.net Thu Mar 15 02:38:16 2012 Return-Path: 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 7060621F86C5 for ; Thu, 15 Mar 2012 02:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.075, 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 yRm9KFAOcUrn for ; Thu, 15 Mar 2012 02:38:15 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8821F86C7 for ; Thu, 15 Mar 2012 02:38:13 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id lleA1i00K37Y3f403leARp; Thu, 15 Mar 2012 10:38:12 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-125--837711319 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 10:38:10 +0100 Message-Id: <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:38:16 -0000 --Apple-Mail-125--837711319 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >=20 >=20 > 2012/3/15 Maoke >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >> Maoke, >>=20 >> Let's try, once more, to understand each other. >>=20 >> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion): >> a) Such a CE can communicate with an IPv6-only host including in = DCCP. >> b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. >> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, = i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate = DCCP (as permitted by RFC6145). >> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those = complying with previous versions wouldn't be guaranteed to interwork for = DCCP. >>=20 >> If we don't agree on this, there is still something to be clarified = between us. >>=20 >> surely do not. RFC6146 clearly states: >> The current specification only defines how stateful NAT64 = translates >> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >> packets and other protocols, including the Stream Control >> Transmission Protocol (SCTP), the Datagram Congestion Control >> Protocol (DCCP), and IPsec, are out of the scope of this >> specification. >=20 > I said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in that, = but I don't think there was a contradiction. > OK? >=20 > it is not yet modified. with the current statement of RFC6146, the = current equipment doesn't support DCCP. if it is modified, the update = may state mandatory imposement for DCCP. i don't see any problem here. >=20 > more clearly speaking: stateful NAT64, i think, only needs to be done = once in a delivery, therefore either the DCCP is supported or it is not. = there's no "interwork" between NAT64 who has been modified with the = NAT64 who has not. incorrect?=20 The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be = modified to also impose DCCP translation, nodes complying with modified = versions and those complying with previous versions wouldn't be = guaranteed to interwork for DCCP."=20 I assumed an RFC6145 complying node can talk to a NAT64, right or not? (A NAT64 talking to another NAT64 was part of what I wrote!!!) RD > =20 > on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >=20 > maoke > =20 >=20 > RD >=20 >=20 >>=20 >> - maoke >> =20 >> If we agree, I have nothing else on this point. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> If, as you suggest,=20 >> 2012-03-15 02:04, Maoke: >>=20 >>> 2012/3/14 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>=20 >>>> 2012/3/14 R=E9mi Despr=E9s >> ... >>>> =20 >>>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>>=20 >>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T = is still in development. if we state to enforce DCCP mandatorily rather = than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward = compatible problem. to this extend, MAP-T is at the same kick-off line = of the 4rd-U.=20 >>>=20 >>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>=20 >>> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >>> Thought?=20 >>>=20 >>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>=20 >>> - maoke >>> =20 >>>=20 >>>=20 >>>> To be even more precise, H6 of the comparison table can be: >>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>=20 >>>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>>=20 >>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>=20 >>> RD >>>=20 >>>=20 >>>> =20 >>>>=20 >>>> maoke=20 >>>> =20 >>>>=20 >>>> Does this cover the point? >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> ;-) >>>>> maoke=20 >>>>> =20 >>>>>=20 >>>>>> but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>=20 >>>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>>=20 >>>>> If I had thought it might be so, I would have avoided the word. >>>>>=20 >>>>>=20 >>>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>>=20 >>>>>> only my 2 cents.=20 >>>>>=20 >>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>=20 >>>>> RD=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail-125--837711319 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:02, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification = only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I = said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in = that, but I don't think there was a contradiction.
OK?

it is = not yet modified. with the current statement of RFC6146, the current = equipment doesn't support DCCP. if it is modified, the update may state = mandatory imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful = NAT64, i think, only needs to be done once in a delivery, therefore = either the DCCP is supported or it is not. there's no "interwork" = between NAT64 who has been modified with the NAT64 who has not. = incorrect? 

The full = sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be modified to = also impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP." 

I assumed an RFC6145 = complying node can talk to a NAT64, right or not?
(A NAT64 = talking to another NAT64 was part of what I = wrote!!!)

RD


<= br>
 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=


= --Apple-Mail-125--837711319-- From fibrib@gmail.com Thu Mar 15 02:38:26 2012 Return-Path: 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 4C08B21F86C5 for ; Thu, 15 Mar 2012 02:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 dpQYyhL7dzaU for ; Thu, 15 Mar 2012 02:38:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B132221F86CE for ; Thu, 15 Mar 2012 02:38:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so3202799yen.31 for ; Thu, 15 Mar 2012 02:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6zpvl5iPsnnje+7ttCaLxk9UmCSa+FLZAhZUU1MEb1Q=; b=iRAJclQoC6J6aWkkOvJ8XGtirhcIrJq1MM2uVTopySFYQDwLyBsDX05mnCSDGX68zK z4uTZSI02dzVPbOgdV5jAtLENPNqqMdJvqdaHOJMN+I4pa30DP9tjlhFbfkWZYaE/N8u IpwsNI3EO/aYbTC8tMilgbAuLBfiyqQkuwlGWVG3sKmD9RUt4jiDIUR0oObPzwzGivGD lNXxdr/H6EDJjNEemGctnNszgR9lohx8LAcSNCz3VJ+kkjHXoUt4YBSPKzbxlVi/rFgW pXXvcRXX2ZM8gDvsridwxTJXW2UIjDVpjw0DMLk0iyskj6oR408AutyaJKMT9fnO6jUK XSQg== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr7070190qab.13.1331804304242; Thu, 15 Mar 2012 02:38:24 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:38:24 -0700 (PDT) In-Reply-To: <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> Date: Thu, 15 Mar 2012 09:38:24 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef776f69104bb44da42 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:38:26 -0000 --20cf30363ef776f69104bb44da42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 10:22, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >> >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> Maoke, >>> >>> Let's try, once more, to understand each other. >>> >>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>> is AFAIAC a positive result of our discussion): >>> a) Such a CE can communicate with an IPv6-only host including in DCCP. >>> b) The same would apply to UDP lite if MAP-T would also require UDP-lit= e >>> translation. >>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate >>> DCCP (as permitted by RFC6145). >>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >>> DCCP translation, nodes complying with modified versions and those >>> complying with previous versions wouldn't be guaranteed to interwork fo= r >>> DCCP. >>> >>> If we don't agree on this, there is still something to be clarified >>> between us. >>> >> >> surely do not. RFC6146 clearly states: >> >> The current specification only defines how stateful NAT64 translates >> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >> packets and other protocols, including the Stream Control >> Transmission Protocol (SCTP), the Datagram Congestion Control >> Protocol (DCCP), and IPsec, are out of the scope of this >> specification. >> >> >> I said "If RFC614... would be modified to also impose DCCP translation" >> =3D> I take the point that you are not interested in that, but I don't t= hink >> there was a contradiction. >> OK? >> > > it is not yet modified. with the current statement of RFC6146, the curren= t > equipment doesn't support DCCP. if it is modified, the update may state > mandatory imposement for DCCP. i don't see any problem here. > > > OK, we are now in sync on this point :-). > > on the other hand, i cannot understand how the CNP helps stateful checksu= m > validity. may you please to clarify? > > > On this new subject, could you be more precise on what you mean > by "stateful checksum validity"? > i mean i didn't understand the how the stateful NAT64 benefits from CNP. maoke > > RD > > > > > > maoke > > >> >> RD >> >> >> >> - maoke >> >> >>> If we agree, I have nothing else on this point. >>> >>> Regards, >>> RD >>> >>> >>> >>> If, as you suggest, >>> 2012-03-15 02:04, Maoke: >>> >>> 2012/3/14 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>> >>>> >>>> 2012/3/14 R=E9mi Despr=E9s >>>> >>>> ... >>> >>> >>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>> backward compatible (an upgraded node isn't guaranteed to interwork w= ith a >>>>> non upgraded node). >>>>> >>>> >>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >>>> still in development. if we state to enforce DCCP mandatorily rather t= han >>>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>>> compatible problem. to this extend, MAP-T is at the same kick-off line= of >>>> the 4rd-U. >>>> >>>> >>>> 1. I agree that, between CEs and BRs, there can be no problem for DCCP >>>> (provided the draft is completed to this effect). The comparison table= was >>>> explicitly made with existing drafts, and intended to be updatable. >>>> >>>> 2. The MAP-T draft is also claimed to allow "communication between >>>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >>>> servers in the domain that are using IPv4-mapped IPv6 address". In >>>> this case, AFAIK, the backward compatibility problem exists >>>> Thought? >>>> >>> >>> surely it does not exist. that statement applies to the MAP-T-compliant >>> equipments, when it is used as a IPv4-to-IPv6 single translator or as a= n >>> native IPv6 router. same deployment of equipments should support >>> double-translation, single-translation, and native IPv6 accesses >>> simultanenously. that's one of the points of the MAP-T. >>> >>> - maoke >>> >>> >>>> >>>> >>>> To be even more precise, H6 of the comparison table can be: >>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>> addresses, DCCP and UDP-Lite are supported, as well as future protoco= ls >>>>> using the TCP checksum algorithm and ports at the same place" >>>>> >>>> >>>> i actually think the original text is fine. "For .... shared IPv4 >>>> addresses" is not needed for 4rd-U, to my understanding, nor needed to >>>> MAP-T. >>>> >>>> >>>> Will see what to do, then, when changes to the MAP-T draft concerning >>>> DCCP are known. >>>> >>> >>>> RD >>>> >>>> >>>> >>>> >>>> maoke >>>> >>>> >>>>> >>>>> Does this cover the point? >>>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ;-) >>>>> maoke >>>>> >>>>> >>>>>> >>>>>> but this is not my point. my point is: there must be something we >>>>>> don't know ("non omnia possumus omnes"). even we have gone through t= he >>>>>> RFCs, there might be some other proprietary L4 protocols, or experim= ental >>>>>> protocols. even they are minority, i don't think ignoring their exis= tance >>>>>> in our solution fits the spirit of the Internet. it might be argued = that >>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owne= r may >>>>>> makes his own NAT44, either attached to the CE or separated. if 4rd-= U >>>>>> respects such an effort, it should state "currently blahblabla L4 pr= otocols >>>>>> are supported". the similar statement applies to the RFC6145 or MAP = as well. >>>>>> >>>>>> >>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>> problem". >>>>>> >>>>>> >>>>>> If I had thought it might be so, I would have avoided the word. >>>>>> >>>>>> >>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>> needing codes for every L4 protocol. but this generality in architec= ture >>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anyth= ing new >>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot = have >>>>>> the unified logic for all (even limited to existing and well-known) = L4 >>>>>> protocols. >>>>>> >>>>>> only my 2 cents. >>>>>> >>>>>> >>>>>> With amendments above, the point is AFAIK completely covered: >>>>>> everything is rigorously true, and worth noting. >>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >> >> > > --20cf30363ef776f69104bb44da42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 10:22, = Maoke a =E9crit :


=
2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr= >
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not yet mo= dified. with the current statement of RFC6146, the current equipment doesn&= #39;t support DCCP. if it is modified, the update may state mandatory impos= ement for DCCP. i don't see any problem here.

OK, we are now in sync on this= point :-).

on the other hand, i cannot understand how the CNP he= lps stateful checksum validity. may you please to clarify?=A0

On this new subject, could you= be more precise on what you mean by=A0"stateful checksum validity&quo= t;?=A0

i mean i didn'= t understand the how the stateful NAT64 benefits from CNP.=A0

maoke
=A0

RD




maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires






--20cf30363ef776f69104bb44da42-- From despres.remi@laposte.net Thu Mar 15 02:59:48 2012 Return-Path: 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 94CBE21F85E5 for ; Thu, 15 Mar 2012 02:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 25BvwKeM9wnl for ; Thu, 15 Mar 2012 02:59:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4121021F85E1 for ; Thu, 15 Mar 2012 02:59:43 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id llzi1i00637Y3f403lzi1G; Thu, 15 Mar 2012 10:59:43 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 10:59:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:59:48 -0000 Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... > i didn't understand the how the stateful NAT64 benefits from CNP.=20 The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus = becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.=20 Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs These CEs need not being dependent on which NAT64 supports which = protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that = host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 = payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm) RD =20 From fibrib@gmail.com Thu Mar 15 03:40:53 2012 Return-Path: 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 7CE5021F8562 for ; Thu, 15 Mar 2012 03:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0X-OMEOB8SLP for ; Thu, 15 Mar 2012 03:40:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAE6321F854C for ; Thu, 15 Mar 2012 03:40:51 -0700 (PDT) Received: by yenm5 with SMTP id m5so3266132yen.31 for ; Thu, 15 Mar 2012 03:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mFseBoCkezKXZL9ENpy+DCzKeVKCT+YCRefmn7dRgog=; b=MD0rk7Hh1BelK4fFcLsxRzndfa+Ja1RDtJL1YiUKzvgAT6ONl1GLzP7RxBXVexO1oH GcDQRBn6QGWVf+Tde3RKZ6RVyB5xopwqf4Iw/MQUk27MFXCu2hL2aOndaVbCV4+KPGBx Fd16Q4XZxEBj0SMTPmUinTdZ2OHGiB3F/YIyGQaL2B2g+G+qZeGQMn2Q0mJnMam1o/zZ /fvuFbt7ga0s8yPC2zjyB3J/gaJw9eYnw+6Ehi8ZkLrTd7P5sGeYWtgCflGQBv1RVzZU LGUIqsOAO+CMLYNBVaqra+qLFgubvZkMyhPyUUpZt6iCoS8KWo5Wb/CorF8U9qFXt3qJ Vkcw== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr7198674qab.39.1331808051318; Thu, 15 Mar 2012 03:40:51 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 03:40:51 -0700 (PDT) In-Reply-To: <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> Date: Thu, 15 Mar 2012 10:40:51 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47ececf4104bb45b97e Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:40:53 -0000 --20cf3074b47ececf4104bb45b97e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 10:29, Maoke a =E9crit : > > > > 2012/3/15 Maoke > >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>> >>> >>> >>> 2012/3/15 R=E9mi Despr=E9s >>> >>>> Maoke, >>>> >>>> Let's try, once more, to understand each other. >>>> >>>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>>> is AFAIAC a positive result of our discussion): >>>> a) Such a CE can communicate with an IPv6-only host including in DCCP. >>>> b) The same would apply to UDP lite if MAP-T would also require >>>> UDP-lite translation. >>>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >>>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translat= e >>>> DCCP (as permitted by RFC6145). >>>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >>>> DCCP translation, nodes complying with modified versions and those >>>> complying with previous versions wouldn't be guaranteed to interwork f= or >>>> DCCP. >>>> >>>> If we don't agree on this, there is still something to be clarified >>>> between us. >>>> >>> >>> surely do not. RFC6146 clearly states: >>> >>> The current specification only defines how stateful NAT64 translates >>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>> packets and other protocols, including the Stream Control >>> Transmission Protocol (SCTP), the Datagram Congestion Control >>> Protocol (DCCP), and IPsec, are out of the scope of this >>> specification. >>> >>> >>> I said "If RFC614... would be modified to also impose DCCP translation" >>> =3D> I take the point that you are not interested in that, but I don't = think >>> there was a contradiction. >>> OK? >>> >> >> it is not yet modified. with the current statement of RFC6146, the >> current equipment doesn't support DCCP. if it is modified, the update ma= y >> state mandatory imposement for DCCP. i don't see any problem here. >> > > more clearly speaking: stateful NAT64, i think, only needs to be done onc= e > in a delivery, therefore either the DCCP is supported or it is not. there= 's > no "interwork" between NAT64 who has been modified with the NAT64 who has > not. incorrect? > > > The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be > modified to also impose DCCP translation, nodes complying with modified > versions and those complying with previous versions wouldn't be guarantee= d > to interwork for DCCP." > > I assumed an RFC6145 complying node can talk to a NAT64, right or not? > you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right that RFC6145 complying node can talk to a NAT64. let's see the details: model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 translator --- B because A would be translated by NAT64 to an arbitrary IPv6 address, A', which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translator cannot handle it statelessly for any end-to-end communication. the box in front of B should be another NAT64, and as i said previously, no problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the other doesn't support, it drops DCCP. no case of asymmetrically processed but end-to-end deliverable DCCP here. - maoke > (A NAT64 talking to another NAT64 was part of what I wrote!!!) > > RD > > > > > >> on the other hand, i cannot understand how the CNP helps stateful >> checksum validity. may you please to clarify? >> >> maoke >> >> >>> >>> RD >>> >>> >>> >>> - maoke >>> >>> >>>> If we agree, I have nothing else on this point. >>>> >>>> Regards, >>>> RD >>>> >>>> >>>> >>>> If, as you suggest, >>>> 2012-03-15 02:04, Maoke: >>>> >>>> 2012/3/14 R=E9mi Despr=E9s >>>> >>>>> >>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>> >>>>> >>>>> 2012/3/14 R=E9mi Despr=E9s >>>>> >>>>> ... >>>> >>>> >>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>>> backward compatible (an upgraded node isn't guaranteed to interwork = with a >>>>>> non upgraded node). >>>>>> >>>>> >>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >>>>> still in development. if we state to enforce DCCP mandatorily rather = than >>>>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>>>> compatible problem. to this extend, MAP-T is at the same kick-off lin= e of >>>>> the 4rd-U. >>>>> >>>>> >>>>> 1. I agree that, between CEs and BRs, there can be no problem for DCC= P >>>>> (provided the draft is completed to this effect). The comparison tabl= e was >>>>> explicitly made with existing drafts, and intended to be updatable. >>>>> >>>>> 2. The MAP-T draft is also claimed to allow "communication between >>>>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >>>>> servers in the domain that are using IPv4-mapped IPv6 address". In >>>>> this case, AFAIK, the backward compatibility problem exists >>>>> Thought? >>>>> >>>> >>>> surely it does not exist. that statement applies to the MAP-T-complian= t >>>> equipments, when it is used as a IPv4-to-IPv6 single translator or as = an >>>> native IPv6 router. same deployment of equipments should support >>>> double-translation, single-translation, and native IPv6 accesses >>>> simultanenously. that's one of the points of the MAP-T. >>>> >>>> - maoke >>>> >>>> >>>>> >>>>> >>>>> To be even more precise, H6 of the comparison table can be: >>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>>> addresses, DCCP and UDP-Lite are supported, as well as future protoc= ols >>>>>> using the TCP checksum algorithm and ports at the same place" >>>>>> >>>>> >>>>> i actually think the original text is fine. "For .... shared IPv4 >>>>> addresses" is not needed for 4rd-U, to my understanding, nor needed t= o >>>>> MAP-T. >>>>> >>>>> >>>>> Will see what to do, then, when changes to the MAP-T draft concerning >>>>> DCCP are known. >>>>> >>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> maoke >>>>> >>>>> >>>>>> >>>>>> Does this cover the point? >>>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ;-) >>>>>> maoke >>>>>> >>>>>> >>>>>>> >>>>>>> but this is not my point. my point is: there must be something we >>>>>>> don't know ("non omnia possumus omnes"). even we have gone through = the >>>>>>> RFCs, there might be some other proprietary L4 protocols, or experi= mental >>>>>>> protocols. even they are minority, i don't think ignoring their exi= stance >>>>>>> in our solution fits the spirit of the Internet. it might be argued= that >>>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol own= er may >>>>>>> makes his own NAT44, either attached to the CE or separated. if 4rd= -U >>>>>>> respects such an effort, it should state "currently blahblabla L4 p= rotocols >>>>>>> are supported". the similar statement applies to the RFC6145 or MAP= as well. >>>>>>> >>>>>>> >>>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>>> problem". >>>>>>> >>>>>>> >>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>> >>>>>>> >>>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>>> needing codes for every L4 protocol. but this generality in archite= cture >>>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anyt= hing new >>>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot= have >>>>>>> the unified logic for all (even limited to existing and well-known)= L4 >>>>>>> protocols. >>>>>>> >>>>>>> only my 2 cents. >>>>>>> >>>>>>> >>>>>>> With amendments above, the point is AFAIK completely covered: >>>>>>> everything is rigorously true, and worth noting. >>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>> >>>>>>> RD >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >>>> >>> >>> >> > > --20cf3074b47ececf4104bb45b97e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

Le 2012-03-15 =E0 10:29, = Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr= >
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not = yet modified. with the current statement of RFC6146, the current equipment = doesn't support DCCP. if it is modified, the update may state mandatory= imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful NAT6= 4, i think, only needs to be done once in a delivery, therefore either the = DCCP is supported or it is not. there's no "interwork" betwee= n NAT64 who has been modified with the NAT64 who has not. incorrect?=A0

The full sentence was: "I= f RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP tran= slation, nodes complying with modified versions and those complying with pr= evious versions wouldn't be guaranteed to interwork for DCCP."=A0<= /div>

I assumed an RFC6145 complying node can talk to a NAT64= , right or not?

you mean = the stateful NAT64-ed IPv4 host (let's call it A) having access to an I= Pv4 host (let's call it B) behind a stateless RFC6145 translator, mappe= d to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right= that RFC6145 complying node can talk to a NAT64. let's see the details= : =A0

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6= cloud)--- RFC6145 translator --- B=A0

because A w= ould be translated by NAT64 to an arbitrary IPv6 address, A', which is = not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translat= or cannot handle it statelessly for any end-to-end communication. the box i= n front of B should be another NAT64, and as i said previously, no problem = in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the o= ther doesn't support, it drops DCCP. no case of asymmetrically processe= d but end-to-end deliverable DCCP here.=A0

- maoke=A0
=A0
(A NAT64 talking to ano= ther NAT64 was part of what I wrote!!!)

RD
<= br>


=A0
on the other hand, i cannot understand how the CNP helps stateful checksu= m validity. may you please to clarify?=A0

maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the= point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires






--20cf3074b47ececf4104bb45b97e-- From despres.remi@laposte.net Thu Mar 15 03:40:59 2012 Return-Path: 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 6E94F21F8562 for ; Thu, 15 Mar 2012 03:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 WbKvbOoNkOwQ for ; Thu, 15 Mar 2012 03:40:58 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B921F85FC for ; Thu, 15 Mar 2012 03:40:55 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0536C94013C; Thu, 15 Mar 2012 11:40:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 11:40:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> To: Maoke Chen X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:40:59 -0000 Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : > Maoke, >=20 > Thanks for this question. > This subject being new, I take it on a new thread. >=20 > 2012-03-15 10:38, Maoke: > ... >> i didn't understand the how the stateful NAT64 benefits from CNP.=20 >=20 > The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.=20 > Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs > These CEs need not being dependent on which NAT64 supports which = protocols. >=20 > Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence.=20 RD >=20 > RD >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Mar 15 03:45:47 2012 Return-Path: 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 F383B21F854C for ; Thu, 15 Mar 2012 03:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 VnRYaU6rIrQu for ; Thu, 15 Mar 2012 03:45:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F021F854B for ; Thu, 15 Mar 2012 03:45:46 -0700 (PDT) Received: by yhkk25 with SMTP id k25so233677yhk.31 for ; Thu, 15 Mar 2012 03:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uKErDImS9rgTdhNCLumH+pJvUCc/TV8fdTMG1lfTg2A=; b=A4CdSsaZflRV7ggOexZtBTQqzsJ70UZHD6bQdrxIkxgSto5ol7LGNfzGE/MnrvwbrI hmpbMo0uNrAUD5TTOaIj/V+4ycHLz4Qfkw9vOX7k9mmYBReoZq2eeXOywyE0s1nRj2fg Dujj0sIm1c3YCX5uqPFhXr7WfVz4Muz8cnOA3YDhuKzunaWAAB7OhMTD704bjD5fqgjb yX6ay8Wij9BaMaoUxPYCVlK8IN/34U9OAuDhEfSbGPeAA9fJsEUvkvXpmHX5lehhBAmR PpGqMjKowEBytXm71Ax/shy8lUUNbZ4DmfjR1RGiH0eBAcrvs3ckMbsObfvE72Gg/4bt 7vZQ== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr7213357qab.39.1331808345696; Thu, 15 Mar 2012 03:45:45 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 03:45:45 -0700 (PDT) In-Reply-To: <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> Date: Thu, 15 Mar 2012 10:45:45 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47e5aa9e204bb45cb47 Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:45:47 -0000 --20cf3074b47e5aa9e204bb45cb47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address. in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. - maoke 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : > > > Maoke, > > > > Thanks for this question. > > This subject being new, I take it on a new thread. > > > > 2012-03-15 10:38, Maoke: > > ... > >> i didn't understand the how the stateful NAT64 benefits from CNP. > > > > The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus > becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. > > Any protocol that this NAT64 supports is then supported e2e for 4rd-u C= Es > > These CEs need not being dependent on which NAT64 supports which > protocols. > > > > Note that the NAT64 doesn't need to have CNP code. It just happens that > host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 > payloads are the same for all protocols that have ports at the same place > as TCP/UDP/..., and the same checksum algorithm) > > Oops. > This is only true for the IPv6 host address. To construct an IPv6 address > when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This i= s > to maintain the property that that middleboxes can treat tunnel packets a= s > valid IPv6 packets. Not a big deal, but necessary). > Sorry for having hastily added this sentence. > > RD > > > > > RD > > > > > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > --20cf3074b47e5aa9e204bb45cb47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i understand NAT64 makes translation between arbitrary IPv6 address to arbi= trary IPv4 address. i don't understand how you make CNP in any IPv6 add= ress. in other words, we cannot limit NAT64 stateful service only serve tho= se IPv6 addresses with CNP. - maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


--20cf3074b47e5aa9e204bb45cb47-- From despres.remi@laposte.net Thu Mar 15 03:58:56 2012 Return-Path: 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 9D53721F85FF for ; Thu, 15 Mar 2012 03:58:56 -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 5Lp992CJcFWz for ; Thu, 15 Mar 2012 03:58:56 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7283121F85AE for ; Thu, 15 Mar 2012 03:58:54 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id lmyt1i00E37Y3f403myt1z; Thu, 15 Mar 2012 11:58:54 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-126--832868819 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 11:58:52 +0100 Message-Id: <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453 A-8409-B499BD3582F7@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:58:56 -0000 --Apple-Mail-126--832868819 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 11:45, Maoke a =E9crit : > i understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address. > in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. That's no the case at all(!).=20 A NAT64+ is a *backward compatible* extension of NAT64 (everything that = worked before still works completely unchanged). The draft says: "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd = tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address = format." Because 4rd IPv6 addresses of CEs are distinguishable from all other = IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY = for addresses that actually are 4rd CE addresses. RD=20 > - maoke=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >=20 > > Maoke, > > > > Thanks for this question. > > This subject being new, I take it on a new thread. > > > > 2012-03-15 10:38, Maoke: > > ... > >> i didn't understand the how the stateful NAT64 benefits from CNP. > > > > The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. > > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs > > These CEs need not being dependent on which NAT64 supports which = protocols. > > > > Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm) >=20 > Oops. > This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). > Sorry for having hastily added this sentence. >=20 > RD >=20 > > > > RD > > > > > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-126--832868819 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
i = understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address.


in other words, we cannot limit NAT64 stateful service = only serve those IPv6 addresses with = CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of = NAT64 (everything that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
Because 4rd IPv6 addresses of CEs = are distinguishable from all other IPv6 addresses (due to the V octet), = NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd = CE = addresses.

RD 


- maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-126--832868819-- From despres.remi@laposte.net Thu Mar 15 04:02:28 2012 Return-Path: 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 C086621F85F7 for ; Thu, 15 Mar 2012 04:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.069, 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 KU42oTN4pX3Y for ; Thu, 15 Mar 2012 04:02:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 61CE221F8652 for ; Thu, 15 Mar 2012 04:02:22 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id ln2J1i00D37Y3f403n2JqT; Thu, 15 Mar 2012 12:02:20 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-127--832663536 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 12:02:18 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:02:28 -0000 --Apple-Mail-127--832663536 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 11:40, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 Maoke >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>> Maoke, >>>=20 >>> Let's try, once more, to understand each other. >>>=20 >>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion): >>> a) Such a CE can communicate with an IPv6-only host including in = DCCP. >>> b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. >>> c) If a MAP-T CE communicates via a NAT64 (which is based on = RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't = translate DCCP (as permitted by RFC6145). >>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP. >>>=20 >>> If we don't agree on this, there is still something to be clarified = between us. >>>=20 >>> surely do not. RFC6146 clearly states: >>> The current specification only defines how stateful NAT64 = translates >>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>> packets and other protocols, including the Stream Control >>> Transmission Protocol (SCTP), the Datagram Congestion Control >>> Protocol (DCCP), and IPsec, are out of the scope of this >>> specification. >>=20 >> I said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in that, = but I don't think there was a contradiction. >> OK? >>=20 >> it is not yet modified. with the current statement of RFC6146, the = current equipment doesn't support DCCP. if it is modified, the update = may state mandatory imposement for DCCP. i don't see any problem here. >>=20 >> more clearly speaking: stateful NAT64, i think, only needs to be done = once in a delivery, therefore either the DCCP is supported or it is not. = there's no "interwork" between NAT64 who has been modified with the = NAT64 who has not. incorrect?=20 >=20 > The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be = modified to also impose DCCP translation, nodes complying with modified = versions and those complying with previous versions wouldn't be = guaranteed to interwork for DCCP."=20 >=20 > I assumed an RFC6145 complying node can talk to a NAT64, right or not? Just referring to: DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet Is this excluded? RD >=20 > you mean the stateful NAT64-ed IPv4 host (let's call it A) having = access to an IPv4 host (let's call it B) behind a stateless RFC6145 = translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if = so, it is not right that RFC6145 complying node can talk to a NAT64. = let's see the details: =20 >=20 > model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- = RFC6145 translator --- B=20 >=20 > because A would be translated by NAT64 to an arbitrary IPv6 address, = A', which is not an IPv4-converted one either in MAP or in RFC6052, the = RFC6145 translator cannot handle it statelessly for any end-to-end = communication. the box in front of B should be another NAT64, and as i = said previously, no problem in interwork. if one NAT64 supports DCCP, it = adjusts the checksum; if the other doesn't support, it drops DCCP. no = case of asymmetrically processed but end-to-end deliverable DCCP here.=20= >=20 > - maoke=20 > =20 > (A NAT64 talking to another NAT64 was part of what I wrote!!!) >=20 > RD >=20 >=20 >=20 >> =20 >> on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >>=20 >> maoke >> =20 >>=20 >> RD >>=20 >>=20 >>>=20 >>> - maoke >>> =20 >>> If we agree, I have nothing else on this point. >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>> If, as you suggest,=20 >>> 2012-03-15 02:04, Maoke: >>>=20 >>>> 2012/3/14 R=E9mi Despr=E9s >>>>=20 >>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>=20 >>>>> 2012/3/14 R=E9mi Despr=E9s >>> ... >>>>> =20 >>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>>>=20 >>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T = is still in development. if we state to enforce DCCP mandatorily rather = than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward = compatible problem. to this extend, MAP-T is at the same kick-off line = of the 4rd-U.=20 >>>>=20 >>>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>>=20 >>>> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >>>> Thought?=20 >>>>=20 >>>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>>=20 >>>> - maoke >>>> =20 >>>>=20 >>>>=20 >>>>> To be even more precise, H6 of the comparison table can be: >>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>>=20 >>>>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>>>=20 >>>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>> =20 >>>>>=20 >>>>> maoke=20 >>>>> =20 >>>>>=20 >>>>> Does this cover the point? >>>>>=20 >>>>> RD >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> ;-) >>>>>> maoke=20 >>>>>> =20 >>>>>>=20 >>>>>>> but this is not my point. my point is: there must be something = we don't know ("non omnia possumus omnes"). even we have gone through = the RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>>=20 >>>>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>>>=20 >>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>=20 >>>>>>=20 >>>>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>>>=20 >>>>>>> only my 2 cents.=20 >>>>>>=20 >>>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>=20 >>>>>> RD=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-127--832663536 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:29, Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:02, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification = only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I = said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in = that, but I don't think there was a contradiction.
OK?

it is = not yet modified. with the current statement of RFC6146, the current = equipment doesn't support DCCP. if it is modified, the update may state = mandatory imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful = NAT64, i think, only needs to be done once in a delivery, therefore = either the DCCP is supported or it is not. there's no "interwork" = between NAT64 who has been modified with the NAT64 who has not. = incorrect? 

The full sentence was: "If = RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP = translation, nodes complying with modified versions and those complying = with previous versions wouldn't be guaranteed to interwork for = DCCP." 

I assumed an RFC6145 complying node can talk to a = NAT64, right or = not?

=
Just referring to:

DS-RFC6145-host = --(v4net) -- NAPT64 -- IPv4 Internet

Is this = excluded?

RD



you = mean the stateful NAT64-ed IPv4 host (let's call it A) having access to = an IPv4 host (let's call it B) behind a stateless RFC6145 translator, = mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is = not right that RFC6145 complying node can talk to a NAT64. let's see the = details:  

model: A ---(IPv4 network)--- NAT64 (stateful) = ---(IPv6 cloud)--- RFC6145 translator --- = B 

because A would be translated by NAT64 = to an arbitrary IPv6 address, A', which is not an IPv4-converted one = either in MAP or in RFC6052, the RFC6145 translator cannot handle it = statelessly for any end-to-end communication. the box in front of B = should be another NAT64, and as i said previously, no problem in = interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the = other doesn't support, it drops DCCP. no case of asymmetrically = processed but end-to-end deliverable DCCP here. 

- maoke 
 
(A = NAT64 talking to another NAT64 was part of what I wrote!!!)

RD



 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=




= --Apple-Mail-127--832663536-- From adurand@juniper.net Thu Mar 15 04:11:23 2012 Return-Path: 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 3853A21F8649 for ; Thu, 15 Mar 2012 04:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OpcmuUwYT7Xj for ; Thu, 15 Mar 2012 04:11:22 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1693121F861D for ; Thu, 15 Mar 2012 04:11:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT2HOVJhmtsz2iDL3ljaw+NFSi5BdRMWM@postini.com; Thu, 15 Mar 2012 04:11:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 15 Mar 2012 04:10:31 -0700 From: Alain Durand To: " " Date: Thu, 15 Mar 2012 04:10:30 -0700 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0CnDu8IKQyhgXLR++hH3+5I6ueDg== Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:11:23 -0000 On Mar 14, 2012, at 1:47 PM, > > wrote: In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. Med: If the ultimate target is to remove the NAT module from the AFTR, I wo= uld see this compatibility mode as an implementation detail. BTW, why a CPE= will fail to restrict the port? I see at least two cases: (1) want to grab more ports but this is not legitimate; I would vote for di= scarding those packets instead of NATing them. (2) the CPE does not support port-restriction: in that case why not use cla= ssic DS-Lite instead of NATing twice. This is a deployment issue. You have 3 variants of DS-Lite CPEs: a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. You want to be able able to accommodate all 3 variants from the same AFTR. Re-Nating instead of dropping ensure that if a subscriber uses a variant b)= when he is provisioned to use port restricted, then traffic still flows. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 Med: Ok, thanks. So for draft-penno-* two provisioning means are required (= compared to basic DS-Lite) * DHCPv4 for IPv4 address allocation * ICMP for port range configuration. I must admit the rationale behind this choice is not clear to me. You are right, the sdnat-02 does not provide enough rationale. We will have= to had text in the next version. See my answer in the next question. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using por= t-restricted DHCPv4 options for instance? 1) - we would have to define the DHCP port option. Not difficult but same a= mount of work as defining a new ICMP type. 2) - with the ICMP message, the ISP can change the port range without havin= g to wait for the lease time of the DHCP option to expire. This allows for more flexibility in micro-managing ports. 3) - if we use a DHCP option, the client has to proactively ask for it. If = it does not, it will think it has the full IP address. That leads to situat= ions that may be difficult to debug, as the customer will not understand wh= y some TCP session works and some don't, the root cause being that the CPE = does not have any feedback from the NAT in the AFTR 4) - so we'll need a new ICMP message anyway to signal the CPE that somethi= ng is wrong if/when it sends packets outside of the range. The advantage of the DHCP option is that the CPE does not need to send the = packet with src port 0 at regular intervals, this is all taken care by the = DHCP machinery. IMHO, this does not outweight the issues mentioned above, e= specially 3) & 4). Alain From despres.remi@laposte.net Thu Mar 15 04:19:25 2012 Return-Path: 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 815C621F852D for ; Thu, 15 Mar 2012 04:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.067, 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 gMUwI8Mu1Pd6 for ; Thu, 15 Mar 2012 04:19:24 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 8998921F852C for ; Thu, 15 Mar 2012 04:19:23 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id lnKM1i00g37Y3f403nKNFK; Thu, 15 Mar 2012 12:19:22 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-128--831640039 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 12:19:21 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:19:25 -0000 --Apple-Mail-128--831640039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 12:02, R=E9mi Despr=E9s a =E9crit : >=20 > Le 2012-03-15 =E0 11:40, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/15 Maoke >>>=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/15 R=E9mi Despr=E9s >>>> Maoke, >>>>=20 >>>> Let's try, once more, to understand each other. >>>>=20 >>>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP = (which is AFAIAC a positive result of our discussion): >>>> a) Such a CE can communicate with an IPv6-only host including in = DCCP. >>>> b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. >>>> c) If a MAP-T CE communicates via a NAT64 (which is based on = RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't = translate DCCP (as permitted by RFC6145). >>>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP. >>>>=20 >>>> If we don't agree on this, there is still something to be clarified = between us. >>>>=20 >>>> surely do not. RFC6146 clearly states: >>>> The current specification only defines how stateful NAT64 = translates >>>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>>> packets and other protocols, including the Stream Control >>>> Transmission Protocol (SCTP), the Datagram Congestion Control >>>> Protocol (DCCP), and IPsec, are out of the scope of this >>>> specification. >>>=20 >>> I said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in that, = but I don't think there was a contradiction. >>> OK? >>>=20 >>> it is not yet modified. with the current statement of RFC6146, the = current equipment doesn't support DCCP. if it is modified, the update = may state mandatory imposement for DCCP. i don't see any problem here. >>>=20 >>> more clearly speaking: stateful NAT64, i think, only needs to be = done once in a delivery, therefore either the DCCP is supported or it is = not. there's no "interwork" between NAT64 who has been modified with the = NAT64 who has not. incorrect?=20 >>=20 >> The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be = modified to also impose DCCP translation, nodes complying with modified = versions and those complying with previous versions wouldn't be = guaranteed to interwork for DCCP."=20 >>=20 >> I assumed an RFC6145 complying node can talk to a NAT64, right or = not? >=20 >=20 > Just referring to: >=20 > DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet Oops again (v6net) instead of (v4net) ... of course. > Is this excluded? >=20 > RD >=20 >=20 >>=20 >> you mean the stateful NAT64-ed IPv4 host (let's call it A) having = access to an IPv4 host (let's call it B) behind a stateless RFC6145 = translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if = so, it is not right that RFC6145 complying node can talk to a NAT64. = let's see the details: =20 >>=20 >> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- = RFC6145 translator --- B=20 >>=20 >> because A would be translated by NAT64 to an arbitrary IPv6 address, = A', which is not an IPv4-converted one either in MAP or in RFC6052, the = RFC6145 translator cannot handle it statelessly for any end-to-end = communication. the box in front of B should be another NAT64, and as i = said previously, no problem in interwork. if one NAT64 supports DCCP, it = adjusts the checksum; if the other doesn't support, it drops DCCP. no = case of asymmetrically processed but end-to-end deliverable DCCP here.=20= >>=20 >> - maoke=20 >> =20 >> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>=20 >> RD >>=20 >>=20 >>=20 >>> =20 >>> on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >>>=20 >>> maoke >>> =20 >>>=20 >>> RD >>>=20 >>>=20 >>>>=20 >>>> - maoke >>>> =20 >>>> If we agree, I have nothing else on this point. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>> If, as you suggest,=20 >>>> 2012-03-15 02:04, Maoke: >>>>=20 >>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>=20 >>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>=20 >>>>>> 2012/3/14 R=E9mi Despr=E9s >>>> ... >>>>>> =20 >>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>>>>=20 >>>>>> the CE/BR specified RFC6145-compliant might be a problem but = MAP-T is still in development. if we state to enforce DCCP mandatorily = rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the = backward compatible problem. to this extend, MAP-T is at the same = kick-off line of the 4rd-U.=20 >>>>>=20 >>>>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>>>=20 >>>>> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >>>>> Thought?=20 >>>>>=20 >>>>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>>>=20 >>>>> - maoke >>>>> =20 >>>>>=20 >>>>>=20 >>>>>> To be even more precise, H6 of the comparison table can be: >>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>>>=20 >>>>>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>>>>=20 >>>>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>>>=20 >>>>> RD >>>>>=20 >>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> maoke=20 >>>>>> =20 >>>>>>=20 >>>>>> Does this cover the point? >>>>>>=20 >>>>>> RD >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> ;-) >>>>>>> maoke=20 >>>>>>> =20 >>>>>>>=20 >>>>>>>> but this is not my point. my point is: there must be something = we don't know ("non omnia possumus omnes"). even we have gone through = the RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>>>=20 >>>>>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>>>>=20 >>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>=20 >>>>>>>=20 >>>>>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>>>>=20 >>>>>>>> only my 2 cents.=20 >>>>>>>=20 >>>>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>=20 >>>>>>> RD=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-128--831640039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Le = 2012-03-15 =E0 11:40, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:29, Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:02, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification = only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I = said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in = that, but I don't think there was a contradiction.
OK?

it is = not yet modified. with the current statement of RFC6146, the current = equipment doesn't support DCCP. if it is modified, the update may state = mandatory imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful = NAT64, i think, only needs to be done once in a delivery, therefore = either the DCCP is supported or it is not. there's no "interwork" = between NAT64 who has been modified with the NAT64 who has not. = incorrect? 

The full sentence was: "If = RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP = translation, nodes complying with modified versions and those complying = with previous versions wouldn't be guaranteed to interwork for = DCCP." 

I assumed an RFC6145 complying node can talk to a = NAT64, right or = not?

=
Just referring to:

DS-RFC6145-host = --(v4net) -- NAPT64 -- IPv4 = Internet

Oops again (v6net) = instead of (v4net) ... of course.

Is this = excluded?

RD



you = mean the stateful NAT64-ed IPv4 host (let's call it A) having access to = an IPv4 host (let's call it B) behind a stateless RFC6145 translator, = mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is = not right that RFC6145 complying node can talk to a NAT64. let's see the = details:  

model: A ---(IPv4 network)--- NAT64 (stateful) = ---(IPv6 cloud)--- RFC6145 translator --- = B 

because A would be translated by NAT64 = to an arbitrary IPv6 address, A', which is not an IPv4-converted one = either in MAP or in RFC6052, the RFC6145 translator cannot handle it = statelessly for any end-to-end communication. the box in front of B = should be another NAT64, and as i said previously, no problem in = interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the = other doesn't support, it drops DCCP. no case of asymmetrically = processed but end-to-end deliverable DCCP here. 

- maoke 
 
(A = NAT64 talking to another NAT64 was part of what I wrote!!!)

RD



 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this = cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=



=
_____________________________________________= __
Softwires mailing list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-128--831640039-- From yiu_lee@cable.comcast.com Thu Mar 15 06:18:50 2012 Return-Path: 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 3B62C21F85AE for ; Thu, 15 Mar 2012 06:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.143 X-Spam-Level: X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 pfOKYrNyU+yB for ; Thu, 15 Mar 2012 06:18:49 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3708A21F8581 for ; Thu, 15 Mar 2012 06:18:49 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6082364; Thu, 15 Mar 2012 09:13:11 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 09:18:40 -0400 From: "Lee, Yiu" To: Alain Durand , " " Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: AQHNAq4jjpk3cZgFiE2DD16c/OQrCA== Date: Thu, 15 Mar 2012 13:18:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3414647918_217373" MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:18:50 -0000 --B_3414647918_217373 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > > > >This is a deployment issue. You have 3 variants of DS-Lite CPEs: >a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. >You want to be able able to accommodate all 3 variants from the same AFTR. >Re-Nating instead of dropping ensure that if a subscriber uses a variant >b) when >he is provisioned to use port restricted, then traffic still flows. > I failed to see how Stateless DS-Lite is different from B4 translated DS-lite. We need to first understand what sd-NAT is trying to solve, then decide whether it is needed or not. > > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? > >IMHO, not specifying the technology to get pot range and >living this to implementation is a serious shortcoming. >We need to standardize one method. We can easily define a method in the B4 translated DS-lite draft. We have few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We can ask the WG to decide which one should be in the base spec. This is how RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333 doesn't have any provision method defined except referring to RFC6334. > >Med: But the question is why ICMP-based method is needed? Why not using >port-restricted DHCPv4 options for instance? > > >1) - we would have to define the DHCP port option. Not difficult but same >amount of work as defining a new ICMP type. >2) - with the ICMP message, the ISP can change the port range without >having to wait for the lease time of the DHCP option to expire. > This allows for more flexibility in micro-managing ports. I need use cases. We don't have any issue using dhcp to manage ip address, I fail to see why we need a different method to manage port-set. In the end, A+P is extending the address with more bits from the port. Also, if the ISP suddenly changes the port range, what happens to the existing sessions? The CPE should close all the existing sessions or wait until the sessions are done? Case 1, it will affect user experience; Case 2, sd-aftr must keep track of the ports and don't assign them to another user until the sessions are done. This sounds adding load to the aftr. If dynamic port assignment is so important, why not use ds-lite instead? >3) - if we use a DHCP option, the client has to proactively ask for it. >If it does not, it will think it has the full IP address. That leads to >situations that may be difficult to debug, as the customer will not >understand why some TCP session works and some don't, the root cause >being that the CPE does not have any feedback from the NAT in the AFTR If the CPE was configured to get A+P but only asked for A, I consider this is a configuration error. Even aftr used icmp to provision the port, the CPE could still think it has the full address. I don't see how icmp could solve configuration error. >4) - so we'll need a new ICMP message anyway to signal the CPE that >something is wrong if/when it sends packets outside of the range. > >The advantage of the DHCP option is that the CPE does not need to send >the packet with src port 0 at regular intervals, this is all taken care >by the DHCP machinery. IMHO, this does not outweight the issues mentioned >above, especially 3) & 4). > >Alain >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3414647918_217373 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTxPeWZ ZsTq96Cz5+4UwnEqfNMygjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMTUxMzE4MzZaMA0GCSqGSIb3DQEBAQUABIIBALoEdXbb2j4CsNNV4Gsr0III JeahqNIZ2h5COhY2bZtU5fzrW4xlbIQHUDd2zAHhnzwhkpJOsWrSQSnx345pOVvJ5ilRLNOH exTySi//PoOy+wKLqi7+nTrhVya83xQkxuYJQi0T6TZqxL/A9fifDtlGf9+NX7q3ySQ9kK+C X1WYsPbH3enlgZJHPABSaJmrl7+UqKIqPjEA6aB0jPEdumDCrcs2Ql7foo2xSQPmDUhgItoP 0Kw05dq2/rF2C+BxUyZoI8Zylh9SCWigL3pACnH3oX+41V4GCtNBz0e6cINcv2lhUjPkhGMa kd92aPTVFpcrRoTcZXV3JzqVrg0D9aI= --B_3414647918_217373-- From fibrib@gmail.com Thu Mar 15 06:47:59 2012 Return-Path: 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 697A521F869A for ; Thu, 15 Mar 2012 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 fuNw7H7BSKJ0 for ; Thu, 15 Mar 2012 06:47:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5421F8667 for ; Thu, 15 Mar 2012 06:47:58 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3495337ggm.31 for ; Thu, 15 Mar 2012 06:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mKztPJgADpK8qFmzegPnFTgxB1t8ku9IjQrXh6ACfgo=; b=bW++gPCl/d7cvlQzbnN7qVnsI8pjUrSePuN3C6l4OjWy1n9rZvwUGXSoSpX7hXnmkU 4pWXkYaklj7xUzz7quu8rT8hssWO2WNeyh/nOcDcamMSlPVHJZc6qySFhFYKT+Wct+x1 GnAJuaivipUWVs4qGDsGVjwB/13Hdy3yVmW/W3ystFRPe85/wURQjEoIvtM99xDulW38 tQoWcQ6hMqglsOrII/AwVqpIJKeFlBruwFU4oS0SBKgxX46cELlR4R6U06Xck4Q0R7bR aB2qAjEtcI8528aEfpUDhV/m0VaYAqjlPmVCc0/PCLwFpCoFmxZGzbdr0YxpE2SfBB51 KCfQ== MIME-Version: 1.0 Received: by 10.229.75.139 with SMTP id y11mr2323019qcj.69.1331819278014; Thu, 15 Mar 2012 06:47:58 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 06:47:57 -0700 (PDT) In-Reply-To: <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> Date: Thu, 15 Mar 2012 22:47:57 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023544719acf8990c04bb48565d Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:47:59 -0000 --0023544719acf8990c04bb48565d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 11:45, Maoke a =E9crit : > > i understand NAT64 makes translation between arbitrary IPv6 address to > arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 > address. > > > > in other words, we cannot limit NAT64 stateful service only serve those > IPv6 addresses with CNP. > > > That's no the case at all(!). > A NAT64+ is a *backward compatible* extension of NAT64 (everything that > worked before still works completely unchanged). > > The draft says: > "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support > 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address > format." > > this phrase is not understood yet. do you mean using 4rd-IPv6-address format for stateful translation service? please draw an example of A <---> B communication as i did for clarification. > > Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 > addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for > addresses that actually are 4rd CE addresses. > > we need to make sure if the NAT64s make both src and dst addresses checksum-neutral. i cannot imagine what the use case is. please specify! - maoke > > > RD > > > - maoke > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >> >> > Maoke, >> > >> > Thanks for this question. >> > This subject being new, I take it on a new thread. >> > >> > 2012-03-15 10:38, Maoke: >> > ... >> >> i didn't understand the how the stateful NAT64 benefits from CNP. >> > >> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s >> becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. >> > Any protocol that this NAT64 supports is then supported e2e for 4rd-u >> CEs >> > These CEs need not being dependent on which NAT64 supports which >> protocols. >> > >> > Note that the NAT64 doesn't need to have CNP code. It just happens tha= t >> host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 >> payloads are the same for all protocols that have ports at the same plac= e >> as TCP/UDP/..., and the same checksum algorithm) >> >> Oops. >> This is only true for the IPv6 host address. To construct an IPv6 addres= s >> when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This = is >> to maintain the property that that middleboxes can treat tunnel packets = as >> valid IPv6 packets. Not a big deal, but necessary). >> Sorry for having hastily added this sentence. >> >> RD >> >> > >> > RD >> > >> > >> > >> > >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >> >> > > --0023544719acf8990c04bb48565d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 11:45, = Maoke a =E9crit :

i un= derstand NAT64 makes translation between arbitrary IPv6 address to arbitrar= y IPv4 address. i don't understand how you make CNP in any IPv6 address= .


in other words, we = cannot limit NAT64 stateful service only serve those IPv6 addresses with CN= P.

That's no the case at all(!).= =A0
A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t worked before still works completely unchanged).

The draft says:
"NAT64+: =A0An ISP NAT64 of [RFC6146] that = is upgraded to support 4rd=A0tunneling when IPv6 addresses it deals with ha= ve the 4rd-IPv6-address format."
=A0
=A0
this phrase is no= t understood yet. do you mean using 4rd-IPv6-address format for stateful tr= anslation service? please draw an example of A <---> B communication = as i did for clarification.
=A0
=A0
Because 4rd IPv6 addresses of CEs are distinguishable from all other I= Pv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for= addresses that actually are 4rd CE addresses.
=A0
=A0
we need to make sure if the NAT64s make bot= h src and dst addresses checksum-neutral. i cannot imagine what the use cas= e is. please specify!
=A0
- maoke
=A0
=A0

RD=A0

=
- maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires




--0023544719acf8990c04bb48565d-- From mohamed.boucadair@orange.com Thu Mar 15 06:50:12 2012 Return-Path: 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 1BC6521F85BE for ; Thu, 15 Mar 2012 06:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 P8CzZPMBB1BK for ; Thu, 15 Mar 2012 06:50:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4F07521F85BB for ; Thu, 15 Mar 2012 06:50:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 787223B481D; Thu, 15 Mar 2012 14:50:10 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 42E9823811D; Thu, 15 Mar 2012 14:50:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 15 Mar 2012 14:50:10 +0100 From: To: Alain Durand Date: Thu, 15 Mar 2012 14:50:09 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0CnDu8IKQyhgXLR++hH3+5I6ueDgAEuk7w Message-ID: <94C682931C08B048B7A8645303FDC9F36E285575F2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E281DB886@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:50:12 -0000 Re-, Please see inline. Cheers, Med=20 > -----Message d'origine----- > De : Alain Durand [mailto:adurand@juniper.net]=20 > Envoy=E9 : jeudi 15 mars 2012 12:11 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : draft-penno-softwire-sdnat@tools.ietf.org; Softwires WG;=20 > draft-cui-softwire-b4-translated-ds-lite > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite > This is a deployment issue. You have 3 variants of DS-Lite CPEs: > a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c)=20 > Stateless DS-Lite. > You want to be able able to accommodate all 3 variants from=20 > the same AFTR. > Re-Nating instead of dropping ensure that if a subscriber=20 > uses a variant b) when > he is provisioned to use port restricted, then traffic still flows. Med: This is deployment-specific. The behaviour to follow when a port-restr= icted device issues port out of its allocated range should be IMO SP specif= ic and can not be dictated by the specification.=20 >=20 >=20 > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? >=20 > IMHO, not specifying the technology to get pot range and > living this to implementation is a serious shortcoming. > We need to standardize one method. >=20 > Med: But the question is why ICMP-based method is needed? Why=20 > not using port-restricted DHCPv4 options for instance? >=20 >=20 > 1) - we would have to define the DHCP port option. Not=20 > difficult but same amount of work as defining a new ICMP type. > 2) - with the ICMP message, the ISP can change the port range=20 > without having to wait for the lease time of the DHCP option=20 > to expire. Med: Changing the size of the port range is part of planned operations. Wit= h DHCP, an SP can change the port range much in advance. This is nothing so= mething which can be done without advanced planning. I don't see an advanta= ge of ICMP here. > This allows for more flexibility in micro-managing ports. Med: This is also doable with DHCP and PCP by tweaking the Lease and the Li= fetime. > 3) - if we use a DHCP option, the client has to proactively=20 > ask for it. If it does not, it will think it has the full IP=20 > address. That leads to situations that may be difficult to=20 > debug, as the customer will not understand why some TCP=20 > session works and some don't, the root cause being that the=20 > CPE does not have any feedback from the NAT in the AFTR Med: This doable with existing ICMP messages. Nothing prevent the AFTR to d= rop the packet and send back an ICMP Destination Unreachable message Code 3= "Port unreachable error" or Code 13 "Communication administratively prohib= ited". > 4) - so we'll need a new ICMP message anyway to signal the=20 > CPE that something is wrong if/when it sends packets outside=20 > of the range. Med: No need to define a new ICMP message for this. Why not using e.g. ICMP= Type 3 Code 13? From fibrib@gmail.com Thu Mar 15 06:52:59 2012 Return-Path: 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 7948621F85D7 for ; Thu, 15 Mar 2012 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 QBqdDM-8x5BG for ; Thu, 15 Mar 2012 06:52:58 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34821F85D0 for ; Thu, 15 Mar 2012 06:52:57 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1672360eaa.31 for ; Thu, 15 Mar 2012 06:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gRUq8huvsjuw9C8JpQdwSxHat4NVhoZm+J6BWNxFUKo=; b=M7LAFgqkhuawd+DUHMORQHlB3Ow/HdMf6hmEXpqRwxqY6Cy3bf8csG4Gl8IZ7aJ335 xeGLrlxV9pFMsUrHOg18oiIk4ktFvIocU+/zklvWiEx6AbKo9Jx3ZHFn1RzpM7ceyyci BQY+RAoTcEnTGeji+Jn89gLkWA8yJhSOyCGKG1aukKo7UziIAve449QuMDJv+EqEP9n1 Qf7TiugxeMTjuvMJo7B+tm3wzLTUeHn1ycWfvDMEziuWjMUYs9nFqh2aiopyiyYkz1nz lZYi4C4LOjgCXKHj33+ubkX2ai5jyR1juJWJfZ7dcsLsbUgo1P21OVfI9GF7ZtMkCe5m ocVQ== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr8088465qab.13.1331819575946; Thu, 15 Mar 2012 06:52:55 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 06:52:55 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> Date: Thu, 15 Mar 2012 22:52:55 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef7baadd104bb4868b9 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:52:59 -0000 --20cf30363ef7baadd104bb4868b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 11:40, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >> >> >> >> 2012/3/15 Maoke >> >>> >>> >>> 2012/3/15 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>>> >>>> >>>> >>>> 2012/3/15 R=E9mi Despr=E9s >>>> >>>>> Maoke, >>>>> >>>>> Let's try, once more, to understand each other. >>>>> >>>>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>>>> is AFAIAC a positive result of our discussion): >>>>> a) Such a CE can communicate with an IPv6-only host including in DCCP= . >>>>> b) The same would apply to UDP lite if MAP-T would also require >>>>> UDP-lite translation. >>>>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >>>>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't transla= te >>>>> DCCP (as permitted by RFC6145). >>>>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >>>>> DCCP translation, nodes complying with modified versions and those >>>>> complying with previous versions wouldn't be guaranteed to interwork = for >>>>> DCCP. >>>>> >>>>> If we don't agree on this, there is still something to be clarified >>>>> between us. >>>>> >>>> >>>> surely do not. RFC6146 clearly states: >>>> >>>> The current specification only defines how stateful NAT64 translate= s >>>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>>> packets and other protocols, including the Stream Control >>>> Transmission Protocol (SCTP), the Datagram Congestion Control >>>> Protocol (DCCP), and IPsec, are out of the scope of this >>>> specification. >>>> >>>> >>>> I said "If RFC614... would be modified to also impose DCCP translation= " >>>> =3D> I take the point that you are not interested in that, but I don't= think >>>> there was a contradiction. >>>> OK? >>>> >>> >>> it is not yet modified. with the current statement of RFC6146, the >>> current equipment doesn't support DCCP. if it is modified, the update m= ay >>> state mandatory imposement for DCCP. i don't see any problem here. >>> >> >> more clearly speaking: stateful NAT64, i think, only needs to be done >> once in a delivery, therefore either the DCCP is supported or it is not. >> there's no "interwork" between NAT64 who has been modified with the NAT6= 4 >> who has not. incorrect? >> >> >> The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be >> modified to also impose DCCP translation, nodes complying with modified >> versions and those complying with previous versions wouldn't be guarante= ed >> to interwork for DCCP." >> >> I assumed an RFC6145 complying node can talk to a NAT64, right or not? >> > > > Just referring to: > > DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet > > what is RFC6145-host?? (seeing you have corrected the v4net with v6net) if it is a host connected to an IPv6 network, it is the case of single NAT64, where we have the problem of "interwork"? - maoke > > > Is this excluded? > > RD > > > > you mean the stateful NAT64-ed IPv4 host (let's call it A) having access > to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, > mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is no= t > right that RFC6145 complying node can talk to a NAT64. let's see the > details: > > model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 > translator --- B > > because A would be translated by NAT64 to an arbitrary IPv6 address, A', > which is not an IPv4-converted one either in MAP or in RFC6052, the RFC61= 45 > translator cannot handle it statelessly for any end-to-end communication. > the box in front of B should be another NAT64, and as i said previously, = no > problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum= ; > if the other doesn't support, it drops DCCP. no case of asymmetrically > processed but end-to-end deliverable DCCP here. > > - maoke > > >> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >> >> RD >> >> >> >> >> >>> on the other hand, i cannot understand how the CNP helps stateful >>> checksum validity. may you please to clarify? >>> >>> maoke >>> >>> >>>> >>>> RD >>>> >>>> >>>> >>>> - maoke >>>> >>>> >>>>> If we agree, I have nothing else on this point. >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>> >>>>> If, as you suggest, >>>>> 2012-03-15 02:04, Maoke: >>>>> >>>>> 2012/3/14 R=E9mi Despr=E9s >>>>> >>>>>> >>>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>> >>>>>> >>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>> >>>>>> ... >>>>> >>>>> >>>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>>>> backward compatible (an upgraded node isn't guaranteed to interwork= with a >>>>>>> non upgraded node). >>>>>>> >>>>>> >>>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T i= s >>>>>> still in development. if we state to enforce DCCP mandatorily rather= than >>>>>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>>>>> compatible problem. to this extend, MAP-T is at the same kick-off li= ne of >>>>>> the 4rd-U. >>>>>> >>>>>> >>>>>> 1. I agree that, between CEs and BRs, there can be no problem for >>>>>> DCCP (provided the draft is completed to this effect). The compariso= n table >>>>>> was explicitly made with existing drafts, and intended to be updatab= le. >>>>>> >>>>>> 2. The MAP-T draft is also claimed to allow "communication between >>>>>> IPv4-only, as well as any IPv6 enabled end hosts, to native >>>>>> IPv6-only servers in the domain that are using IPv4-mapped IPv6 >>>>>> address". In this case, AFAIK, the backward compatibility problem >>>>>> exists >>>>>> Thought? >>>>>> >>>>> >>>>> surely it does not exist. that statement applies to the >>>>> MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single >>>>> translator or as an native IPv6 router. same deployment of equipments >>>>> should support double-translation, single-translation, and native IPv= 6 >>>>> accesses simultanenously. that's one of the points of the MAP-T. >>>>> >>>>> - maoke >>>>> >>>>> >>>>>> >>>>>> >>>>>> To be even more precise, H6 of the comparison table can be: >>>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>>>> addresses, DCCP and UDP-Lite are supported, as well as future proto= cols >>>>>>> using the TCP checksum algorithm and ports at the same place" >>>>>>> >>>>>> >>>>>> i actually think the original text is fine. "For .... shared IPv4 >>>>>> addresses" is not needed for 4rd-U, to my understanding, nor needed = to >>>>>> MAP-T. >>>>>> >>>>>> >>>>>> Will see what to do, then, when changes to the MAP-T draft concernin= g >>>>>> DCCP are known. >>>>>> >>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> maoke >>>>>> >>>>>> >>>>>>> >>>>>>> Does this cover the point? >>>>>>> >>>>>>> RD >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ;-) >>>>>>> maoke >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> but this is not my point. my point is: there must be something we >>>>>>>> don't know ("non omnia possumus omnes"). even we have gone through= the >>>>>>>> RFCs, there might be some other proprietary L4 protocols, or exper= imental >>>>>>>> protocols. even they are minority, i don't think ignoring their ex= istance >>>>>>>> in our solution fits the spirit of the Internet. it might be argue= d that >>>>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol ow= ner may >>>>>>>> makes his own NAT44, either attached to the CE or separated. if 4r= d-U >>>>>>>> respects such an effort, it should state "currently blahblabla L4 = protocols >>>>>>>> are supported". the similar statement applies to the RFC6145 or MA= P as well. >>>>>>>> >>>>>>>> >>>>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>>>> problem". >>>>>>>> >>>>>>>> >>>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>> >>>>>>>> >>>>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>>>> needing codes for every L4 protocol. but this generality in archit= ecture >>>>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support any= thing new >>>>>>>> with the same logic. but for the 4rd-U BR, it looks to me we canno= t have >>>>>>>> the unified logic for all (even limited to existing and well-known= ) L4 >>>>>>>> protocols. >>>>>>>> >>>>>>>> only my 2 cents. >>>>>>>> >>>>>>>> >>>>>>>> With amendments above, the point is AFAIK completely covered: >>>>>>>> everything is rigorously true, and worth noting. >>>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>> >>>>>>>> RD >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > --20cf30363ef7baadd104bb4868b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 11:40, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <= span dir=3D"ltr"><despres.remi@laposte.net>

Le 2012-03-15 =E0 10:29, = Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr= >
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not = yet modified. with the current statement of RFC6146, the current equipment = doesn't support DCCP. if it is modified, the update may state mandatory= imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful NAT6= 4, i think, only needs to be done once in a delivery, therefore either the = DCCP is supported or it is not. there's no "interwork" betwee= n NAT64 who has been modified with the NAT64 who has not. incorrect?=A0

The full sentence was: "I= f RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP tran= slation, nodes complying with modified versions and those complying with pr= evious versions wouldn't be guaranteed to interwork for DCCP."=A0<= /div>

I assumed an RFC6145 complying node can talk to a NAT64= , right or not?

<= /div>

Just referring to:

DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet
=A0
=A0
what is RFC6145-host?? (seeing you = have corrected the v4net with v6net) if it is a host connected to an IPv6 n= etwork, it is the case of single NAT64, where we have the problem of "= interwork"?
=A0
- maoke
=A0
=A0

Is this excluded?

RD
=



you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless R= FC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain= . if so, it is not right that RFC6145 complying node can talk to a NAT64. l= et's see the details: =A0

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6= cloud)--- RFC6145 translator --- B=A0

because A w= ould be translated by NAT64 to an arbitrary IPv6 address, A', which is = not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translat= or cannot handle it statelessly for any end-to-end communication. the box i= n front of B should be another NAT64, and as i said previously, no problem = in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the o= ther doesn't support, it drops DCCP. no case of asymmetrically processe= d but end-to-end deliverable DCCP here.=A0

- maoke=A0
=A0
(A NAT64 talking to another NAT64 was part of what I wrote!!!)

RD
<= br>


=A0
on the other= hand, i cannot understand how the CNP helps stateful checksum validity. ma= y you please to clarify?=A0

maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires








--20cf30363ef7baadd104bb4868b9-- From mohamed.boucadair@orange.com Thu Mar 15 06:55:42 2012 Return-Path: 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 EE58D21F85E0 for ; Thu, 15 Mar 2012 06:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 GBgY3nmqlCSx for ; Thu, 15 Mar 2012 06:55:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2F21F85D9 for ; Thu, 15 Mar 2012 06:55:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6423D2DC791; Thu, 15 Mar 2012 14:55:40 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4072123807C; Thu, 15 Mar 2012 14:55:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 15 Mar 2012 14:55:40 +0100 From: To: "Lee, Yiu" , Alain Durand Date: Thu, 15 Mar 2012 14:55:38 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: AQHNAq4jjpk3cZgFiE2DD16c/OQrCJZrYBdA Message-ID: <94C682931C08B048B7A8645303FDC9F36E285575FC@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:55:43 -0000 > -----Message d'origine----- > De : Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 > Envoy=E9 : jeudi 15 mars 2012 14:19 > =C0 : Alain Durand; BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite;=20 > draft-penno-softwire-sdnat@tools.ietf.org > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 > draft-cui-softwire-b4-translated-ds-lite > > > >IMHO, not specifying the technology to get pot range and > >living this to implementation is a serious shortcoming. > >We need to standardize one method. >=20 > We can easily define a method in the B4 translated DS-lite=20 > draft. We have > few on the table (i.e. dhcpv4 over v6 transport, dhcpv6,=20 > radius, pcp). We > can ask the WG to decide which one should be in the base=20 > spec. This is how > RFC5959 was written. Alternatively, we can do what RFC6333=20 > does. RFC6333 > doesn't have any provision method defined except referring to RFC6334. Med: I fully agree. From despres.remi@laposte.net Thu Mar 15 08:05:36 2012 Return-Path: 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 B904F21F8723 for ; Thu, 15 Mar 2012 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 i0jJOBtSw-nq for ; Thu, 15 Mar 2012 08:05:35 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id AEA0821F8717 for ; Thu, 15 Mar 2012 08:05:32 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 36209940034; Thu, 15 Mar 2012 16:05:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-129--818084249 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 16:05:17 +0100 Message-Id: <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <1A6C1DA5-A352-4BF7-8553-45332790261 9@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:05:36 -0000 --Apple-Mail-129--818084249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 14:52, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 11:40, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/15 Maoke >>>=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/15 R=E9mi Despr=E9s >>>> Maoke, >>>>=20 >>>> Let's try, once more, to understand each other. >>>>=20 >>>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP = (which is AFAIAC a positive result of our discussion): >>>> a) Such a CE can communicate with an IPv6-only host including in = DCCP. >>>> b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation. >>>> c) If a MAP-T CE communicates via a NAT64 (which is based on = RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't = translate DCCP (as permitted by RFC6145). >>>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP. >>>>=20 >>>> If we don't agree on this, there is still something to be clarified = between us. >>>>=20 >>>> surely do not. RFC6146 clearly states: >>>> The current specification only defines how stateful NAT64 = translates >>>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>>> packets and other protocols, including the Stream Control >>>> Transmission Protocol (SCTP), the Datagram Congestion Control >>>> Protocol (DCCP), and IPsec, are out of the scope of this >>>> specification. >>>=20 >>> I said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in that, = but I don't think there was a contradiction. >>> OK? >>>=20 >>> it is not yet modified. with the current statement of RFC6146, the = current equipment doesn't support DCCP. if it is modified, the update = may state mandatory imposement for DCCP. i don't see any problem here. >>>=20 >>> more clearly speaking: stateful NAT64, i think, only needs to be = done once in a delivery, therefore either the DCCP is supported or it is = not. there's no "interwork" between NAT64 who has been modified with the = NAT64 who has not. incorrect?=20 >>=20 >> The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be = modified to also impose DCCP translation, nodes complying with modified = versions and those complying with previous versions wouldn't be = guaranteed to interwork for DCCP."=20 >>=20 >> I assumed an RFC6145 complying node can talk to a NAT64, right or = not? >=20 >=20 > Just referring to: >=20 > DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet > =20 > =20 > what is RFC6145-host?? E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports = IPv4 applications and is attached to an IPv6-only network. Clear enough? > (seeing you have corrected the v4net with v6net) if it is a host = connected to an IPv6 network, it is the case of single NAT64, where we = have the problem of "interwork"? See above. RD > =20 > - maoke > =20 > =20 >=20 > Is this excluded? >=20 > RD >=20 >=20 >>=20 >> you mean the stateful NAT64-ed IPv4 host (let's call it A) having = access to an IPv4 host (let's call it B) behind a stateless RFC6145 = translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if = so, it is not right that RFC6145 complying node can talk to a NAT64. = let's see the details: =20 >>=20 >> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- = RFC6145 translator --- B=20 >>=20 >> because A would be translated by NAT64 to an arbitrary IPv6 address, = A', which is not an IPv4-converted one either in MAP or in RFC6052, the = RFC6145 translator cannot handle it statelessly for any end-to-end = communication. the box in front of B should be another NAT64, and as i = said previously, no problem in interwork. if one NAT64 supports DCCP, it = adjusts the checksum; if the other doesn't support, it drops DCCP. no = case of asymmetrically processed but end-to-end deliverable DCCP here.=20= >>=20 >> - maoke=20 >> =20 >> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>=20 >> RD >>=20 >>=20 >>=20 >>> =20 >>> on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >>>=20 >>> maoke >>> =20 >>>=20 >>> RD >>>=20 >>>=20 >>>>=20 >>>> - maoke >>>> =20 >>>> If we agree, I have nothing else on this point. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>> If, as you suggest,=20 >>>> 2012-03-15 02:04, Maoke: >>>>=20 >>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>=20 >>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>=20 >>>>>> 2012/3/14 R=E9mi Despr=E9s >>>> ... >>>>>> =20 >>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't = backward compatible (an upgraded node isn't guaranteed to interwork with = a non upgraded node). >>>>>>=20 >>>>>> the CE/BR specified RFC6145-compliant might be a problem but = MAP-T is still in development. if we state to enforce DCCP mandatorily = rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the = backward compatible problem. to this extend, MAP-T is at the same = kick-off line of the 4rd-U.=20 >>>>>=20 >>>>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>>>=20 >>>>> 2. The MAP-T draft is also claimed to allow "communication between = IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only = servers in the domain that are using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward compatibility problem exists =20 >>>>> Thought?=20 >>>>>=20 >>>>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>>>=20 >>>>> - maoke >>>>> =20 >>>>>=20 >>>>>=20 >>>>>> To be even more precise, H6 of the comparison table can be: >>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>>>=20 >>>>>> i actually think the original text is fine. "For .... shared IPv4 = addresses" is not needed for 4rd-U, to my understanding, nor needed to = MAP-T. >>>>>=20 >>>>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>>>=20 >>>>> RD >>>>>=20 >>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> maoke=20 >>>>>> =20 >>>>>>=20 >>>>>> Does this cover the point? >>>>>>=20 >>>>>> RD >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> ;-) >>>>>>> maoke=20 >>>>>>> =20 >>>>>>>=20 >>>>>>>> but this is not my point. my point is: there must be something = we don't know ("non omnia possumus omnes"). even we have gone through = the RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>>>=20 >>>>>>>> i somehow am hard to accept words like "far fetched theoretical = problem".=20 >>>>>>>=20 >>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>=20 >>>>>>>=20 >>>>>>>> the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols.=20 >>>>>>>>=20 >>>>>>>> only my 2 cents.=20 >>>>>>>=20 >>>>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>=20 >>>>>>> RD=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-129--818084249 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-15 =E0 = 11:40, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:29, Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 10:02, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <remi.despres@free.fr>
Maoke,

Let's try, = once more, to understand each other.

If we = assume that MAP-T CEs (and BRs) now MUST translate DCCP (which = is AFAIAC a positive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in = DCCP.
b) The same would apply to UDP lite if MAP-T would also = require UDP-lite translation.
c) If a MAP-T CE communicates = via a NAT64 (which is based on RFC6145, i.e. with DCCP = optional), DCCP is broken if the NAT64 doesn't translate DCCP = (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also = impose DCCP translation, nodes complying with modified versions and = those complying with previous versions wouldn't be guaranteed to = interwork for DCCP.

If we don't agree on this, there is still = something to be clarified between = us.

surely do not. RFC6146 = clearly states:
   The current specification = only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. = Multicast
   packets and other protocols, including the = Stream Control
   Transmission Protocol (SCTP), the = Datagram Congestion Control
   Protocol (DCCP), and IPsec, = are out of the scope of this
  =  specification.

I = said "If RFC614... would be modified to also impose DCCP = translation" =3D> I take the point that you are not interested in = that, but I don't think there was a contradiction.
OK?

it is = not yet modified. with the current statement of RFC6146, the current = equipment doesn't support DCCP. if it is modified, the update may state = mandatory imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful = NAT64, i think, only needs to be done once in a delivery, therefore = either the DCCP is supported or it is not. there's no "interwork" = between NAT64 who has been modified with the NAT64 who has not. = incorrect? 

The full sentence was: "If = RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP = translation, nodes complying with modified versions and those complying = with previous versions wouldn't be guaranteed to interwork for = DCCP." 

I assumed an RFC6145 complying node can talk to a = NAT64, right or = not?

=
Just referring to:

DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 = Internet
 
 
wh= at is RFC6145-host??

E.g. a = host with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 = applications and is attached to an IPv6-only network.
Clear = enough?

(seeing you have corrected the v4net with = v6net) if it is a host connected to an IPv6 network, it is the case of = single NAT64, where we have the problem of "interwork"? =

See = above.

RD


 
- maoke
 
 

Is this = excluded?

RD



you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless = RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 = domain. if so, it is not right that RFC6145 complying node can talk to a = NAT64. let's see the details:  

model: A ---(IPv4 network)--- NAT64 (stateful) = ---(IPv6 cloud)--- RFC6145 translator --- = B 

because A would be translated by NAT64 = to an arbitrary IPv6 address, A', which is not an IPv4-converted one = either in MAP or in RFC6052, the RFC6145 translator cannot handle it = statelessly for any end-to-end communication. the box in front of B = should be another NAT64, and as i said previously, no problem in = interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the = other doesn't support, it drops DCCP. no case of asymmetrically = processed but end-to-end deliverable DCCP here. 

- maoke 
 
(A NAT64 talking to another NAT64 was part of what I = wrote!!!)

RD



 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=






= --Apple-Mail-129--818084249-- From despres.remi@laposte.net Thu Mar 15 08:30:48 2012 Return-Path: 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 9023521F872B for ; Thu, 15 Mar 2012 08:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.066, 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 xHy6fSSp9HsF for ; Thu, 15 Mar 2012 08:30:46 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8C29C21F869E for ; Thu, 15 Mar 2012 08:30:44 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id lrWh1i01F37Y3f403rWiV7; Thu, 15 Mar 2012 16:30:42 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-130--816559922 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 16:30:41 +0100 Message-Id: <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453 A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:30:48 -0000 --Apple-Mail-130--816559922 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >=20 >> i understand NAT64 makes translation between arbitrary IPv6 address = to arbitrary IPv4 address. i don't understand how you make CNP in any = IPv6 address. >=20 >=20 >> in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. >=20 > That's no the case at all(!).=20 > A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely unchanged). >=20 > The draft says: > "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd = tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address = format." > =20 > =20 > this phrase is not understood yet. do you mean using 4rd-IPv6-address = format for stateful translation service? Yes (but, &s said, only for CE nodes that are 4rd capable (with the = advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). > please draw an example of A <---> B communication as i did for = clarification. Here is an example scenario: v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH uses = RFC6145)=20 A1 | =20 :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server | UDP-lite UDP-lite v4Appli-4rdCE --' capable B A2 =3D> A-B OK > Because 4rd IPv6 addresses of CEs are distinguishable from all other = IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY = for addresses that actually are 4rd CE addresses. > =20 > =20 > we need to make sure if the NAT64s make both src and dst addresses = checksum-neutral. Correct, iff the host address has the V octet. > i cannot imagine what the use case is. please specify! Hope the picture above helps. RD > =20 > - maoke > =20 > =20 >=20 > RD=20 >=20 >=20 >> - maoke=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>=20 >> > Maoke, >> > >> > Thanks for this question. >> > This subject being new, I take it on a new thread. >> > >> > 2012-03-15 10:38, Maoke: >> > ... >> >> i didn't understand the how the stateful NAT64 benefits from CNP. >> > >> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >> > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs >> > These CEs need not being dependent on which NAT64 supports which = protocols. >> > >> > Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm) >>=20 >> Oops. >> This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >> Sorry for having hastily added this sentence. >>=20 >> RD >>=20 >> > >> > RD >> > >> > >> > >> > >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 --Apple-Mail-130--816559922 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-15 =E0 = 11:45, Maoke a =E9crit :

i understand NAT64 makes translation between arbitrary = IPv6 address to arbitrary IPv4 address. i don't understand how you make = CNP in any IPv6 address.


in other words, = we cannot limit NAT64 stateful service only serve those IPv6 addresses = with CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
 
 
this = phrase is not understood yet. do you mean using 4rd-IPv6-address format = for stateful translation service? =

Yes (but, &s said, only for = CE nodes that are 4rd capable (with the advantage of better IPv4 = transparency between CEs and NAT64+ than between RFC6145 and = NAT64).

please draw an example of A <---> B = communication as i did for clarification. =

Here is an example = scenario:

v4appli-BIH ----. =3D> A>B NOK = (because, according to RFC6535, BIH uses RFC6145) 
  =    A1         |    =  
                = :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
  =               |       =          UDP-lite         =             =  UDP-lite
v4Appli-4rdCE --'         =         capable        =                 =  B
     A2         =  =3D> A-B = OK



Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE = addresses.
 
 
we need to make sure if the NAT64s = make both src and dst addresses = checksum-neutral.

Correct, iff = the host address has the V octet.

i cannot imagine what the = use case is. please = specify!

Hope the picture = above = helps.

RD



=
 
- = maoke
 
 

RD 


- = maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires





= --Apple-Mail-130--816559922-- From adurand@juniper.net Thu Mar 15 09:49:11 2012 Return-Path: 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 A1F8D21F84C9 for ; Thu, 15 Mar 2012 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 05V99FI8nLoA for ; Thu, 15 Mar 2012 09:49:11 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B171B21F84D6 for ; Thu, 15 Mar 2012 09:48:58 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT2Idd7IdZdCk+OW/MfSlVCOOqUwiy54a@postini.com; Thu, 15 Mar 2012 09:49:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 15 Mar 2012 09:48:22 -0700 From: Alain Durand To: Francis Dupont Date: Thu, 15 Mar 2012 09:48:20 -0700 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0Cy25oFAz8dDqCR2aRZcrSn+fnGA== Message-ID: <12B8A484-148F-45E3-A95D-67F5CD676A15@juniper.net> References: <201203141334.q2EDYMKE065833@givry.fdupont.fr> In-Reply-To: <201203141334.q2EDYMKE065833@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:49:11 -0000 On Mar 14, 2012, at 2:34 PM, Francis Dupont wrote: > In your previous mail you wrote: >=20 >> However, the draft seems give people impression there is only one NAT >> at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is >> responsible for decapsulation and IPv4 package validation. Did I miss >> something? >=20 > =3D> yes, the SD-CGN (the SD-AFTR with DS-Lite) runs a second NAT but > only on port (vs. address and port) and following algorithm (aka stateles= s). This 2nd NAT was the case in sdnat-01. This has changed in sdnat-02, where = the SD-CPE pre-shape IPv4 traffic with both address & port, so the SD-AFTR does only d= ecapsulation and ACL check. No NAT is done at all in the SD-AFTR. - Alain. From Francis.Dupont@fdupont.fr Thu Mar 15 11:22:22 2012 Return-Path: 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 DDFBB21F8811 for ; Thu, 15 Mar 2012 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 U-OuxcP55zPU for ; Thu, 15 Mar 2012 11:22:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34021F8807 for ; Thu, 15 Mar 2012 11:22:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FIMKrI071934; Thu, 15 Mar 2012 19:22:20 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203151822.q2FIMKrI071934@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Wed, 14 Mar 2012 15:15:59 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB913@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 15 Mar 2012 19:22:20 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:22:23 -0000 In your previous mail you wrote: > Med: Why you need an IPv4 address to run PCP? An implementation > example would be as follows: > > * At bootstrap of the CPE, once an AFTR is discovered, use the Plain > IPv6 PCP mode and the new opcode and options defined in > http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 > to retrieve an IPv4 address and set of port. => the retrieval of the external address is a function which was explicitely put out of PCP by the WG, for the second you'd like to use an extension which was never discussed. To finish there is a difference between discussing about getting the IPv4 address or getting it with other parameters as port ranges, and my comment is only about the first problem. Regards Francis.Dupont@fdupont.fr PS: I should add another dimension: do we want a solution for DS-Lite or a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? From Francis.Dupont@fdupont.fr Thu Mar 15 11:32:37 2012 Return-Path: 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 AF01321F8621 for ; Thu, 15 Mar 2012 11:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] 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 et35NVPutXnY for ; Thu, 15 Mar 2012 11:32:37 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E140321F85E1 for ; Thu, 15 Mar 2012 11:32:36 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FIWZrV072640; Thu, 15 Mar 2012 19:32:35 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203151832.q2FIWZrV072640@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Wed, 14 Mar 2012 16:35:44 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB999@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 15 Mar 2012 19:32:35 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:32:37 -0000 In your previous mail you wrote: > Med: The PCP case has been demoed. => My comment is about PCP without any extension. > "In the second demonstration scenario, the CPE requested several sets > of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and > draft-zhou-softwire-b4-nat-02). => so this doesn't apply. Regards Francis.Dupont@fdupont.fr PS: we already have a configuration protocol, it is named DHCP. From Francis.Dupont@fdupont.fr Thu Mar 15 11:42:06 2012 Return-Path: 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 AE6EA21F8730 for ; Thu, 15 Mar 2012 11:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] 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 3OgWl+qPOQ4L for ; Thu, 15 Mar 2012 11:42:06 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id D4B4021F8574 for ; Thu, 15 Mar 2012 11:42:05 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FIg4cx073303; Thu, 15 Mar 2012 19:42:04 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203151842.q2FIg4cx073303@givry.fdupont.fr> From: Francis Dupont To: Qiong In-reply-to: Your message of Thu, 15 Mar 2012 00:15:17 +0800. Date: Thu, 15 Mar 2012 19:42:04 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:42:06 -0000 In your previous mail you wrote: > [Qiong] We also have implemented and demoed in IETF 81th. Please refer to > http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in > Appendix section. => same: my comment is about the base PCP for port range discovery. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 15 16:16:30 2012 Return-Path: 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 0698A21E8040 for ; Thu, 15 Mar 2012 16:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 J8qPaaEqhVN1 for ; Thu, 15 Mar 2012 16:16:29 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76921E800F for ; Thu, 15 Mar 2012 16:16:28 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FNGR1v091279; Fri, 16 Mar 2012 00:16:27 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203152316.q2FNGR1v091279@givry.fdupont.fr> From: Francis Dupont To: Alain Durand In-reply-to: Your message of Thu, 15 Mar 2012 04:10:30 MST. Date: Fri, 16 Mar 2012 00:16:27 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:16:30 -0000 In your previous mail you wrote: > 1) - we would have to define the DHCP port option. Not difficult but > same amount of work as defining a new ICMP type. => is it a joke? DHCP has an extension mechanism, not ICMP. > 2) - with the ICMP message, the ISP can change the port range > without having to wait for the lease time of the DHCP option to > expire. => I don't understand the argument: - there is no lease time for an option - when the ISP change the port range it raises an ICMP error for the first packet which falls outside the new range - when the CPE receives the ICMP error it refreshes the port range info So the mechanism doesn't rely in the info being carried in the ICMP. Note this doesn't solves 2 cases where the ICMP can't help: - when the port range is in fact the ICMP echo ID range - when the port range is extended > 3) - if we use a DHCP option, the client has to proactively ask for > it. If it does not, it will think it has the full IP address. => there are many ways to solve this, for instance the server can refuse to give an IP address or recognize the CPE as being not SD-CPE capable, etc. > 4) - so we'll need a new ICMP message anyway to signal the CPE that > something is wrong if/when it sends packets outside of the range. => ICMPv4 administratively prohibited (no need for a new message). > The advantage of the DHCP option is that the CPE does not need to > send the packet with src port 0 at regular intervals, this is all > taken care by the DHCP machinery. IMHO, this does not outweight the > issues mentioned above, especially 3) & 4). => port 0 is invalid so will be likely drop sooner than expected. I don't even believe the ICMP stuff of draft-penno-softwire-sdnat could work in a lab, so in the real world... Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 15 16:38:01 2012 Return-Path: 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 A755A21E803A for ; Thu, 15 Mar 2012 16:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] 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 RsA-woZCX+jb for ; Thu, 15 Mar 2012 16:38:01 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B693121E800F for ; Thu, 15 Mar 2012 16:38:00 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FNbvwF092502; Fri, 16 Mar 2012 00:37:58 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203152337.q2FNbvwF092502@givry.fdupont.fr> From: Francis Dupont To: "Lee, Yiu" In-reply-to: Your message of Thu, 15 Mar 2012 13:18:40 GMT. Date: Fri, 16 Mar 2012 00:37:57 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:38:01 -0000 In your previous mail you wrote: > I failed to see how Stateless DS-Lite is different from B4 translated > DS-lite. We need to first understand what sd-NAT is trying to solve, then > decide whether it is needed or not. => I agree and IMHO they have the same issue: the per-CPE port range is far too easy to track from the Internet side. IMHO the port restricted CPE is a good idea (it should be deployable in most existing CPEs without changing a bit to kernels) but CGN should provide an algorithmic (including the identity) port translation to shuffle CPE port ranges. > We can easily define a method in the B4 translated DS-lite draft. We have > few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We > can ask the WG to decide which one should be in the base spec. This is how > RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333 > doesn't have any provision method defined except referring to RFC6334. => I agree on the principle but we should answer to a question first: do we want a mechanism for DS-Lite only or a mechanism applicable to DS-Lite, NAT44 and any other IPv4 CGN? > I need use cases. We don't have any issue using dhcp to manage ip address, > I fail to see why we need a different method to manage port-set. => me too. > Also, if the ISP suddenly changes the port range, what happens to > the existing sessions? The CPE should close all the existing > sessions or wait until the sessions are done? => I had the same question and there are two solutions: a smooth hard to implement and a rude easy to implement, beginning with the second: - flush the whole context (your first case) - kill only connections which are no longer valid (there is nothing to do for them and you can be lucky...) To wait is not an option because they are already blocked by the CGN. > Case 2, sd-aftr must keep track of the ports and don't assign them > to another user until the sessions are done. This sounds adding > load to the aftr. => this is incompatible with port ranges and the fact the lifetime of a session is potentially unbound. So there is nothing smooth/ user-friendly you can do on the SD-CGN other than never restrict assigned port ranges. > port assignment is so important, why not use ds-lite instead? => perhaps to try to make port reassignment of a lower order of annoyance than address reassignment? Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 15 16:42:44 2012 Return-Path: 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 C5DB721E8048 for ; Thu, 15 Mar 2012 16:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 z6Mk5AAThy+k for ; Thu, 15 Mar 2012 16:42:44 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4921E800F for ; Thu, 15 Mar 2012 16:42:43 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FNggQB092812; Fri, 16 Mar 2012 00:42:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203152342.q2FNggQB092812@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Thu, 15 Mar 2012 14:50:09 +0100. <94C682931C08B048B7A8645303FDC9F36E285575F2@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 16 Mar 2012 00:42:42 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:42:44 -0000 In your previous mail you wrote: +1 > > Re-, > > Please see inline. > (I cut here: too long and unreable with not-ASCII characters, quoted-printable silly coding and long lines) Regards Francis.Dupont@fdupont.fr From fibrib@gmail.com Thu Mar 15 17:27:39 2012 Return-Path: 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 641A821F854E for ; Thu, 15 Mar 2012 17:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 QRgKT-gMoEyc for ; Thu, 15 Mar 2012 17:27:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4421F854D for ; Thu, 15 Mar 2012 17:27:37 -0700 (PDT) Received: by werb10 with SMTP id b10so4188966wer.31 for ; Thu, 15 Mar 2012 17:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vd0xuGfquV8342LrlUrqMYPuVVkQKe+YWWOHC4sSS9I=; b=Ibl4zsGyvkLu/q8IqQZXFLgxnK3aV0dU5mZXnsAcexyl/YAVVVVbJ+5R8vBORYTsy7 aenm7kqytzlo5feG70N1oQsajed+7fp6/d9FaY+mXxXeSnlh4/7zGvXtXtGM6vmlBp10 UMA4fHYFBqK37oUAXK/vKNqIbsiMxP6bAQvjA9QhOup/qcfr+iUjw1grOyzFpbw7EzTI jx4Nmcp+bG453uKAuGiFbQkLJMHuBXRVqAM2U3mzIKfT1OaSrcZ7gdFLDw1lBbdOSqGZ D8DWIQuS6x/ltHkvHWCzwS3YSmbCPnoThpFN/dGs9kbfutYOIXfndK+hTLUFC9g3zLhn 3WAQ== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr1677316wib.15.1331857656509; Thu, 15 Mar 2012 17:27:36 -0700 (PDT) Received: by 10.216.175.198 with HTTP; Thu, 15 Mar 2012 17:27:36 -0700 (PDT) In-Reply-To: <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> Date: Fri, 16 Mar 2012 00:27:36 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0444803581f2ee04bb514668 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:27:39 -0000 --f46d0444803581f2ee04bb514668 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 14:52, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 11:40, Maoke a =E9crit : >> >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-15 =E0 10:29, Maoke a =E9crit : >>> >>> >>> >>> 2012/3/15 Maoke >>> >>>> >>>> >>>> 2012/3/15 R=E9mi Despr=E9s >>>> >>>>> >>>>> Le 2012-03-15 =E0 10:02, Maoke a =E9crit : >>>>> >>>>> >>>>> >>>>> 2012/3/15 R=E9mi Despr=E9s >>>>> >>>>>> Maoke, >>>>>> >>>>>> Let's try, once more, to understand each other. >>>>>> >>>>>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>>>>> is AFAIAC a positive result of our discussion): >>>>>> a) Such a CE can communicate with an IPv6-only host including in DCC= P. >>>>>> b) The same would apply to UDP lite if MAP-T would also require >>>>>> UDP-lite translation. >>>>>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145= , >>>>>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't transl= ate >>>>>> DCCP (as permitted by RFC6145). >>>>>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impos= e >>>>>> DCCP translation, nodes complying with modified versions and those >>>>>> complying with previous versions wouldn't be guaranteed to interwork= for >>>>>> DCCP. >>>>>> >>>>>> If we don't agree on this, there is still something to be clarified >>>>>> between us. >>>>>> >>>>> >>>>> surely do not. RFC6146 clearly states: >>>>> >>>>> The current specification only defines how stateful NAT64 translat= es >>>>> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >>>>> packets and other protocols, including the Stream Control >>>>> Transmission Protocol (SCTP), the Datagram Congestion Control >>>>> Protocol (DCCP), and IPsec, are out of the scope of this >>>>> specification. >>>>> >>>>> >>>>> I said "If RFC614... would be modified to also impose DCCP >>>>> translation" =3D> I take the point that you are not interested in tha= t, but I >>>>> don't think there was a contradiction. >>>>> OK? >>>>> >>>> >>>> it is not yet modified. with the current statement of RFC6146, the >>>> current equipment doesn't support DCCP. if it is modified, the update = may >>>> state mandatory imposement for DCCP. i don't see any problem here. >>>> >>> >>> more clearly speaking: stateful NAT64, i think, only needs to be done >>> once in a delivery, therefore either the DCCP is supported or it is not= . >>> there's no "interwork" between NAT64 who has been modified with the NAT= 64 >>> who has not. incorrect? >>> >>> >>> The full sentence was: "If RFC6146 (NAT64) and/or RFC6145 would be >>> modified to also impose DCCP translation, nodes complying with modified >>> versions and those complying with previous versions wouldn't be guarant= eed >>> to interwork for DCCP." >>> >>> I assumed an RFC6145 complying node can talk to a NAT64, right or not? >>> >> >> >> Just referring to: >> >> DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet >> >> > > what is RFC6145-host?? > > > E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports > IPv4 applications and is attached to an IPv6-only network. > then inside the host, there a RFC6145 module, right? my point is, if there is no NAT64 module, this cannot talk with another NAT64 box elsewhere as only one of the (src,dst)-pair is stateless IPv4-converted IPv6 address. my previous analysis doesn't matter whether the translator and the end host are separated or integrated into one box. - maoke > Clear enough? > > (seeing you have corrected the v4net with v6net) if it is a host connecte= d > to an IPv6 network, it is the case of single NAT64, where we have the > problem of "interwork"? > > > See above. > > RD > > > > - maoke > > >> >> >> Is this excluded? >> >> RD >> >> >> >> you mean the stateful NAT64-ed IPv4 host (let's call it A) having access >> to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, >> mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is n= ot >> right that RFC6145 complying node can talk to a NAT64. let's see the >> details: >> >> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC614= 5 >> translator --- B >> >> because A would be translated by NAT64 to an arbitrary IPv6 address, A', >> which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6= 145 >> translator cannot handle it statelessly for any end-to-end communication= . >> the box in front of B should be another NAT64, and as i said previously,= no >> problem in interwork. if one NAT64 supports DCCP, it adjusts the checksu= m; >> if the other doesn't support, it drops DCCP. no case of asymmetrically >> processed but end-to-end deliverable DCCP here. >> >> - maoke >> >> >>> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>> >>> RD >>> >>> >>> >>> >>> >>>> on the other hand, i cannot understand how the CNP helps stateful >>>> checksum validity. may you please to clarify? >>>> >>>> maoke >>>> >>>> >>>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> - maoke >>>>> >>>>> >>>>>> If we agree, I have nothing else on this point. >>>>>> >>>>>> Regards, >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> If, as you suggest, >>>>>> 2012-03-15 02:04, Maoke: >>>>>> >>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>> >>>>>>> >>>>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>> >>>>>>> >>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>>> >>>>>>> ... >>>>>> >>>>>> >>>>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>>>>> backward compatible (an upgraded node isn't guaranteed to interwor= k with a >>>>>>>> non upgraded node). >>>>>>>> >>>>>>> >>>>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T >>>>>>> is still in development. if we state to enforce DCCP mandatorily ra= ther >>>>>>> than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backw= ard >>>>>>> compatible problem. to this extend, MAP-T is at the same kick-off l= ine of >>>>>>> the 4rd-U. >>>>>>> >>>>>>> >>>>>>> 1. I agree that, between CEs and BRs, there can be no problem for >>>>>>> DCCP (provided the draft is completed to this effect). The comparis= on table >>>>>>> was explicitly made with existing drafts, and intended to be updata= ble. >>>>>>> >>>>>>> 2. The MAP-T draft is also claimed to allow "communication between >>>>>>> IPv4-only, as well as any IPv6 enabled end hosts, to native >>>>>>> IPv6-only servers in the domain that are using IPv4-mapped IPv6 >>>>>>> address". In this case, AFAIK, the backward compatibility problem >>>>>>> exists >>>>>>> Thought? >>>>>>> >>>>>> >>>>>> surely it does not exist. that statement applies to the >>>>>> MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single >>>>>> translator or as an native IPv6 router. same deployment of equipment= s >>>>>> should support double-translation, single-translation, and native IP= v6 >>>>>> accesses simultanenously. that's one of the points of the MAP-T. >>>>>> >>>>>> - maoke >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> To be even more precise, H6 of the comparison table can be: >>>>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>>>>> addresses, DCCP and UDP-Lite are supported, as well as future prot= ocols >>>>>>>> using the TCP checksum algorithm and ports at the same place" >>>>>>>> >>>>>>> >>>>>>> i actually think the original text is fine. "For .... shared IPv4 >>>>>>> addresses" is not needed for 4rd-U, to my understanding, nor needed= to >>>>>>> MAP-T. >>>>>>> >>>>>>> >>>>>>> Will see what to do, then, when changes to the MAP-T draft >>>>>>> concerning DCCP are known. >>>>>>> >>>>>> >>>>>>> RD >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> maoke >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Does this cover the point? >>>>>>>> >>>>>>>> RD >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ;-) >>>>>>>> maoke >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> but this is not my point. my point is: there must be something >>>>>>>>> we don't know ("non omnia possumus omnes"). even we have gone thr= ough the >>>>>>>>> RFCs, there might be some other proprietary L4 protocols, or expe= rimental >>>>>>>>> protocols. even they are minority, i don't think ignoring their e= xistance >>>>>>>>> in our solution fits the spirit of the Internet. it might be argu= ed that >>>>>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may >>>>>>>>> makes his own NAT44, either attached to the CE or separated. if 4= rd-U >>>>>>>>> respects such an effort, it should state "currently blahblabla L4= protocols >>>>>>>>> are supported". the similar statement applies to the RFC6145 or M= AP as well. >>>>>>>>> >>>>>>>>> >>>>>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>>>>> problem". >>>>>>>>> >>>>>>>>> >>>>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>>> >>>>>>>>> >>>>>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>>>>> needing codes for every L4 protocol. but this generality in archi= tecture >>>>>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support an= ything new >>>>>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cann= ot have >>>>>>>>> the unified logic for all (even limited to existing and well-know= n) L4 >>>>>>>>> protocols. >>>>>>>>> >>>>>>>>> only my 2 cents. >>>>>>>>> >>>>>>>>> >>>>>>>>> With amendments above, the point is AFAIK completely covered: >>>>>>>>> everything is rigorously true, and worth noting. >>>>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>>> >>>>>>>>> RD >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > --f46d0444803581f2ee04bb514668 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 14:52, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-15 =E0 11:40, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@lap= oste.net>

Le 2012-03-15 =E0 10:29, = Maoke a =E9crit :



2012/3/15 Maoke <fibrib@gmail.com>


2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:02, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <remi.despres@free.fr= >
Maoke,

Let's try= , once more, to understand each other.

If we assum= e that MAP-T CEs (and BRs) now MUST translate DCCP (which is=A0AFAIAC=A0a p= ositive result of our discussion):
a) Such a CE can communicate with an IPv6-only host including in DCCP.=
b) The same would apply to UDP lite if MAP-T would also require = UDP-lite translation.
c) If a MAP-T CE communicates via a NAT64 (= which is based on RFC6145, i.e. with DCCP optional),=A0DCCP is broken=A0if = the NAT64 doesn't translate DCCP (as permitted by RFC6145).
d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose = DCCP translation, nodes complying with modified versions and those complyin= g with previous versions wouldn't be guaranteed to interwork for DCCP.<= /div>

If we don't agree on this,=A0there is still somethi= ng to be clarified between us.

= surely do not. RFC6146 clearly states:
=A0 =A0The current specification only defin= es how stateful NAT64 translates
=A0 =A0unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
= =A0 =A0packets and other protocols, including the Stream Control
=A0 = =A0Transmission Protocol (SCTP), the Datagram Congestion Control
=A0 = =A0Protocol (DCCP), and IPsec, are out of the scope of this
=A0 =A0specification.

I = said "If RFC614...=A0would be modified to also impose DCCP translation= " =3D> I take the point that you are not interested in that, but I = don't think there was a contradiction.
OK?

it is not = yet modified. with the current statement of RFC6146, the current equipment = doesn't support DCCP. if it is modified, the update may state mandatory= imposement for DCCP. i don't see any problem here.

more clearly speaking: stateful NAT6= 4, i think, only needs to be done once in a delivery, therefore either the = DCCP is supported or it is not. there's no "interwork" betwee= n NAT64 who has been modified with the NAT64 who has not. incorrect?=A0

The full sentence was: "I= f RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP tran= slation, nodes complying with modified versions and those complying with pr= evious versions wouldn't be guaranteed to interwork for DCCP."=A0<= /div>

I assumed an RFC6145 complying node can talk to a NAT64= , right or not?

<= /div>

Just referring to:

DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet
=A0
=A0
what is RFC6145-host??
=

E.g. a host with BIH (RFC6535)= or with 464XLAT, i.e. one that supports IPv4 applications and is attached = to an IPv6-only network.

then inside the host, there a = RFC6145 module, right? my point is, if there is no NAT64 module, this canno= t talk with another NAT64 box elsewhere as only one of the (src,dst)-pair i= s stateless IPv4-converted IPv6 address. my previous analysis doesn't m= atter whether the translator and the end host are separated or integrated i= nto one box.=A0

- maoke
=A0
Clear enough?

(seeing you h= ave corrected the v4net with v6net) if it is a host connected to an IPv6 ne= twork, it is the case of single NAT64, where we have the problem of "i= nterwork"?

See above.

RD


=A0
- maoke
=A0
=A0

Is this excluded?

RD


=

you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless R= FC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain= . if so, it is not right that RFC6145 complying node can talk to a NAT64. l= et's see the details: =A0

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6= cloud)--- RFC6145 translator --- B=A0

because A w= ould be translated by NAT64 to an arbitrary IPv6 address, A', which is = not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translat= or cannot handle it statelessly for any end-to-end communication. the box i= n front of B should be another NAT64, and as i said previously, no problem = in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the o= ther doesn't support, it drops DCCP. no case of asymmetrically processe= d but end-to-end deliverable DCCP here.=A0

- maoke=A0
=A0
(A NAT64 talking to another NAT64 was part of what I wrote!!!)

RD
<= br>


=A0
on the other= hand, i cannot understand how the CNP helps stateful checksum validity. ma= y you please to clarify?=A0

maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires










--f46d0444803581f2ee04bb514668-- From fibrib@gmail.com Thu Mar 15 17:59:34 2012 Return-Path: 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 065EC21F852B for ; Thu, 15 Mar 2012 17:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 weXL4zqOJ0MD for ; Thu, 15 Mar 2012 17:59:33 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6921F852C for ; Thu, 15 Mar 2012 17:59:32 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so158416wib.1 for ; Thu, 15 Mar 2012 17:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpSyQOf1kFj2fPj9Yw4G0fQV8ZFVq8XdaOEEZxB52k4=; b=TGyj/JAig0NIPmhps07P5nfwv7owTtF2hz+YO7WVMJr2+tKLNvJpnxqPJQ15gIsIMz W0tpVSgzbCRLtgbB+rXNNJ3SvsBjV47B1nnJWdCZMui75QukHCZMNanwvXaozzNGyb+P ebiHxldhArib/7XJGdwCYCeBD5STsdiUqW4WmPvsyRJa299WXYY4XVzDVg/z86CGlp+d XXefjIRn71Nd6ldJqIuNRXo1y5IuYI5gyVfpsgXW9bMJkmclv/xoZe12zoYLyuQWSnNS qe7n+1C/2Xw16LdVwk61dYdXMkMHg+IclFntki0EoxlYUEINDoxn4FToafpIauSdtTUJ n5KQ== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr1846407wib.15.1331859571673; Thu, 15 Mar 2012 17:59:31 -0700 (PDT) Received: by 10.216.175.198 with HTTP; Thu, 15 Mar 2012 17:59:31 -0700 (PDT) In-Reply-To: <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> Date: Fri, 16 Mar 2012 00:59:31 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04448035a90beb04bb51b88c Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:59:34 -0000 --f46d04448035a90beb04bb51b88c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/15 R=E9mi Despr=E9s > > Le 2012-03-15 =E0 14:47, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >> >> i understand NAT64 makes translation between arbitrary IPv6 address to >> arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 >> address. >> >> >> >> in other words, we cannot limit NAT64 stateful service only serve those >> IPv6 addresses with CNP. >> >> >> That's no the case at all(!). >> A NAT64+ is a *backward compatible* extension of NAT64 (everything that >> worked before still works completely unchanged). >> >> The draft says: >> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support >> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-addres= s >> format." >> >> > > this phrase is not understood yet. do you mean using 4rd-IPv6-address > format for stateful translation service? > > > Yes (but, &s said, only for CE nodes that are 4rd capable (with the > advantage of better IPv4 transparency between CEs and NAT64+ than between > RFC6145 and NAT64). > > please draw an example of A <---> B communication as i did for > clarification. > > > Here is an example scenario: > > v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH uses > RFC6145) > A1 | > :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server > | UDP-lite UDP-lite > v4Appli-4rdCE --' capable B > A2 =3D> A-B OK > > yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, if the "not support" means passing-it-through without checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing with the L4, right? B --> A is a question mark, if we use the NAT64+ which does nothing with the L4 checksum, it is also not a problem. however, if we use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that may updates the checksum while the BIH doesn't know that. my point here is: what is the use case with the details of addressing? if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address to serve B for the communications, A1 BIH or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't such a address pool for B, things will fail because only one among src and dst is checksum-neutral. > > > Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 >> addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for >> addresses that actually are 4rd CE addresses. >> >> > > we need to make sure if the NAT64s make both src and dst addresses > checksum-neutral. > > Correct, iff the host address has the V octet. > 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from others. 2. even with the V-octet, do you mean B's IPv4 address also translated (by the NAT64+) to a CNP-and-V-containing IPv6 address? if 2 is true, why you use stateful NAT64+ here for B rather than a stateless one? if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B's communications, and such a case results only A's mapped address is checksum-neutral, and thus anyway L4 adjustment is needed. if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 address pool in use. 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit this for the time being). - maoke > > i cannot imagine what the use case is. please specify! > > > Hope the picture above helps. > > RD > > > > > - maoke > > >> >> >> RD >> >> >> - maoke >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>> >>> > Maoke, >>> > >>> > Thanks for this question. >>> > This subject being new, I take it on a new thread. >>> > >>> > 2012-03-15 10:38, Maoke: >>> > ... >>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>> > >>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels >>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloa= ds. >>> > Any protocol that this NAT64 supports is then supported e2e for 4rd-u >>> CEs >>> > These CEs need not being dependent on which NAT64 supports which >>> protocols. >>> > >>> > Note that the NAT64 doesn't need to have CNP code. It just happens >>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 >>> payloads are the same for all protocols that have ports at the same pla= ce >>> as TCP/UDP/..., and the same checksum algorithm) >>> >>> Oops. >>> This is only true for the IPv6 host address. To construct an IPv6 >>> address when transmitting to a 4rd-u CE, the NAT64 should compute a CN= P. >>> (This is to maintain the property that that middleboxes can treat tunne= l >>> packets as valid IPv6 packets. Not a big deal, but necessary). >>> Sorry for having hastily added this sentence. >>> >>> RD >>> >>> > >>> > RD >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Softwires mailing list >>> > Softwires@ietf.org >>> > https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >> > > --f46d04448035a90beb04bb51b88c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-15 =E0 14:47, = Maoke a =E9crit :


=
2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 11:45, = Maoke a =E9crit :

i understand NAT6= 4 makes translation between arbitrary IPv6 address to arbitrary IPv4 addres= s. i don't understand how you make CNP in any IPv6 address.


in other words, we = cannot limit NAT64 stateful service only serve those IPv6 addresses with CN= P.

That's no the case at all(!).= =A0
A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t worked before still works completely unchanged).

The draft says:
"NAT64+: =A0An ISP NAT64 of [RFC6146] that = is upgraded to support 4rd=A0tunneling when IPv6 addresses it deals with ha= ve the 4rd-IPv6-address format."
=A0
=A0
this phrase is no= t understood yet. do you mean using 4rd-IPv6-address format for stateful tr= anslation service?

Yes (but, = &s said, only for CE nodes that are 4rd capable (with the advantage of = better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NA= T64).

please draw an example of A <---> B communication as i did = for clarification.

Here = is an example scenario:

v4appli-BIH ----. =3D> A>B NOK (because, accordin= g to RFC6535, BIH uses RFC6145)=A0
=A0 =A0 =A0A1 =A0 =A0 =A0 =A0 = |=A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :----(v6net)----- NA= T64+ ---(IPv4 Internet)--- Server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-l= ite =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-lite
v4Appli-4= rdCE --' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0capable=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B
=A0 =A0 =A0A2 =A0 =A0 =A0 =A0 = =A0=3D> A-B OK


yes, BIH uses = RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, i= f the "not support" means passing-it-through without checksum adj= ustment, A --> B is fine because neither BIH nor NAT64+ does nothing wit= h the L4, right? B --> A is a question mark, if we use the NAT64+ which = does nothing with the L4 checksum, it is also not a problem. however, if we= use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that ma= y updates the checksum while the BIH doesn't know that.=A0

my point here is: what is the use case with the details= of addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 add= ress to serve B for the communications, A1 BIH or A2 CE may do the stateles= s processing successfuly. if NAT64+ hasn't such a address pool for B, t= hings will fail because only one among src and dst is checksum-neutral.=A0<= /div>
=A0


Because 4rd IPv6 addresses of CEs are distinguishable from all other I= Pv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for= addresses that actually are 4rd CE addresses.
=A0
=A0
we need to make sure if the NAT64s make bot= h src and dst addresses checksum-neutral.
Correct, iff the host address has = the V octet.

1. without the V-o= ctet, CE and NAT64 can also distinguish the 4rd-CE addresses from others.= =A0
2. even with the V-octet, do you mean B's IPv4 address also transl= ated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=A0
<= br>
if 2 is true, why you use stateful NAT64+ here for B rather t= han a stateless one? if 2 is not true, then the NAT64 can use any arbitrary= IPv6 address for B's communications, and such a case results only A= 9;s mapped address is checksum-neutral, and thus anyway L4 adjustment is ne= eded.=A0

if 2 is true, i do suggest you naming NAT64+ as NAT64- = instead, because NAT64 doesn't have the limitation on the IPv6 address = pool in use.=A0

3. RFC6535 states, explicitly, &qu= ot;Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but= the above technical discussion can omit this for the time being).=A0

- maoke=A0
=A0

i cannot imagine what the use case is. ple= ase specify!

Hope the pic= ture above helps.

RD



=A0
- maoke
= =A0
=A0

RD=A0


- maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires






--f46d04448035a90beb04bb51b88c-- From fibrib@gmail.com Thu Mar 15 18:07:06 2012 Return-Path: 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 C8A8C21F856F for ; Thu, 15 Mar 2012 18:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 tF9lFAHHsZOp for ; Thu, 15 Mar 2012 18:07:06 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB621F856D for ; Thu, 15 Mar 2012 18:07:04 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so61541wib.13 for ; Thu, 15 Mar 2012 18:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PSHsGMbia8zr4HoE0WY3KwzinSw7dUUDY1TaG6ftt5A=; b=QXgkQTpBCavquA11MFqSKqJBK6+q34J5ORZppe6TmgwLCaZPBemSACe7eiBJB7mwKz Z7dUEwWFz/fCdz+IXd+xc18903nvsKKhATvBM5M/3fh9iM7S2knyH8D4BlPyJycW45KO bBYHdD6u3kKYsqHWgahsWL7ltJIegkjSilQMaOnDAeYTbjCmMDKlhaWXghnl3N78qTtD sv3Ahguy7ZOp+tUBfyxy9tr2ILd1RzmQdQaf6qPR30ByVtR8CrAG/ZKZma3AlIAt1Czh dSmmMUUGOxjLnoUXDH2t1AieEtTt3rBsf4Wmjhdqtqn3gTCwhRwlV9y2Y/WXWcBlswtS m/Hg== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr1888775wib.15.1331860024023; Thu, 15 Mar 2012 18:07:04 -0700 (PDT) Received: by 10.216.175.198 with HTTP; Thu, 15 Mar 2012 18:07:03 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> Date: Fri, 16 Mar 2012 01:07:03 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d044480359f5a2004bb51d3ef Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:07:06 -0000 --f46d044480359f5a2004bb51d3ef Content-Type: text/plain; charset=ISO-8859-1 on the other hand, may i suggest not to term "4rd tunnel" anymore? it confuses. i emphasized it is NOT a TUNNEL to the common understanding at all (but it seems you never?seldom respond to this point, nor to the ICMP issue details. ) - maoke --f46d044480359f5a2004bb51d3ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

on the other hand, may i suggest not to term "4rd = tunnel" anymore? it confuses. i emphasized it is NOT a TUNNEL to the c= ommon understanding at all (but it seems you never?seldom respond to this p= oint, nor to the ICMP issue details. ) - maoke

--f46d044480359f5a2004bb51d3ef-- From washam.fan@gmail.com Thu Mar 15 22:44:05 2012 Return-Path: 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 8A40321F8692; Thu, 15 Mar 2012 22:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NxBAijA6jSrO; Thu, 15 Mar 2012 22:44:04 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56621F8686; Thu, 15 Mar 2012 22:44:04 -0700 (PDT) Received: by werb10 with SMTP id b10so4368540wer.31 for ; Thu, 15 Mar 2012 22:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4FcV+geIf4n47FqH/0c4vtbYl2nyvPUepFeouompF3o=; b=D1Bapb/UGSAIciCHlqPJCgeIHDtxcO/483cEd4GKU1DKAdqrIPUJjKK4KpKiPNwMfH toQwH7RJfXwkpFFZhK5xU+hPTRCho2BrlO1szZUEATUYU2r6gFzCyArmzgw6NfkMnBcl +3Sm8r9YYKAlhoMFWfjR6vjfp+22RyS4lKZQWiaPKgoFO4BHofbqHKflarveCOwKCBpp lWWh9pibuHikrJW9edtHQYc29CdJS8jkLn8bgzjS89AVRowggOUoi+aroIQSGn6IQckn hTEug7JMg/USPaEEmDFL2+WbZWOD4RX5oLOI4O8S2a2avS2vvElzrpA5xKxo4BJpBSDt nzZQ== MIME-Version: 1.0 Received: by 10.180.104.65 with SMTP id gc1mr3363568wib.13.1331876643410; Thu, 15 Mar 2012 22:44:03 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Thu, 15 Mar 2012 22:44:03 -0700 (PDT) In-Reply-To: <20120312124455.5382.26454.idtracker@ietfa.amsl.com> References: <20120312124455.5382.26454.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 13:44:03 +0800 Message-ID: From: Washam Fan To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, i-d-announce@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 05:44:05 -0000 Hi Authors, For section 5.3, I think 2 things should be explicitly stated. 1. hairpinning should be supported on the 4over6 concentrator 2. when 4-in-6 packets received, the inner ipv4 src ip address should be checked against outter ipv6 src ip to see if they are match. (Actually, this should be mentioned in security consideration section) Thanks, washam 2012/3/12 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Softwires Working Group of the IETF= . > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Public IPv4 over IPv6 Access N= etwork > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Yong Cui > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jianping Wu > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Peng Wu > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Chris Metz > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Olivier Vautrin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu L. Lee > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-public-4over= 6-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 When the service provider networks are upgraded to IPv6, IPv4 > =A0 connectivity will still be demanded by network users, at least in the > =A0 recent future. =A0This draft proposes a mechanism for end hosts or > =A0 networks in IPv6 access networks to build bidirectional IPv4 > =A0 communication with the IPv4 Internet. =A0The mechanism follows the > =A0 softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic > =A0 method to traverse IPv6 network. =A0The bi-directionality of end-to-e= nd > =A0 communication is achieved by allocating public IPv4 addresses to end > =A0 hosts/networks. =A0This mechanism is an IPv4 access method for networ= k > =A0 users in IPv6. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.= txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.t= xt > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From pengwu.thu@gmail.com Thu Mar 15 22:48:03 2012 Return-Path: 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 E65FF21F8698 for ; Thu, 15 Mar 2012 22:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sTR87LJ0d9Ki for ; Thu, 15 Mar 2012 22:48:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4FF21F8686 for ; Thu, 15 Mar 2012 22:48:03 -0700 (PDT) Received: by ggmi1 with SMTP id i1so4375054ggm.31 for ; Thu, 15 Mar 2012 22:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2Ghl1nVCcXRGIDVub6m3n//F9yQGaHqMOCl8bPcLTsY=; b=RqgaCbutOztqj3NwHPC5o0DMvaijvoVG2ifqnbhYX5OWQYp6v/vQhq/Vz2rHcm7J/O QzzfPChl4nIgDTjLRnoi4qT+Dc2qjlGCb328VEdLwTWvPleAh/UlmS6Dtqw69w2FHfWn YBaGn5HgGMXjsLWKK5gwXbK0/hiJDHnXAeVovbB2PlSBzmgzwE41AlUKY14bM7ba6L95 UDuWZjEuR1OKUMTAXosB188LOEP+7rXM6ihFP8ObQy2rMdg7TIdAuz6JLLkzD664UNB9 1OBCjdiECrYAtCKgbg6SfSkc3+rOdWEtDnlG5lHNI0mBho5/zfvRU+dV1gWDHaOGuKkp oiiQ== MIME-Version: 1.0 Received: by 10.68.73.103 with SMTP id k7mr10927284pbv.132.1331876882280; Thu, 15 Mar 2012 22:48:02 -0700 (PDT) Received: by 10.68.11.199 with HTTP; Thu, 15 Mar 2012 22:48:02 -0700 (PDT) In-Reply-To: References: <20120312124455.5382.26454.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 13:48:02 +0800 Message-ID: From: Peng Wu To: Washam Fan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 05:48:04 -0000 Hi Washam, Good points. Will add them in the next version. 2012/3/16 Washam Fan : > Hi Authors, > > For section 5.3, I think 2 things should be explicitly stated. > 1. hairpinning should be supported on the 4over6 concentrator > 2. when 4-in-6 packets received, the inner ipv4 src ip address should > be checked against outter ipv6 src ip to see if they are match. > (Actually, this should be mentioned in security consideration section) > > Thanks, > washam > > 2012/3/12 =A0: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the Softwires Working Group of the IET= F. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Public IPv4 over IPv6 Access = Network >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Yong Cui >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jianping Wu >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Peng Wu >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Chris Metz >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Olivier Vautrin >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu L. Lee >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-public-4ove= r6-01.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 >> >> =A0 When the service provider networks are upgraded to IPv6, IPv4 >> =A0 connectivity will still be demanded by network users, at least in th= e >> =A0 recent future. =A0This draft proposes a mechanism for end hosts or >> =A0 networks in IPv6 access networks to build bidirectional IPv4 >> =A0 communication with the IPv4 Internet. =A0The mechanism follows the >> =A0 softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basi= c >> =A0 method to traverse IPv6 network. =A0The bi-directionality of end-to-= end >> =A0 communication is achieved by allocating public IPv4 addresses to end >> =A0 hosts/networks. =A0This mechanism is an IPv4 access method for netwo= rk >> =A0 users in IPv6. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01= .txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.= txt >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Thu Mar 15 23:29:42 2012 Return-Path: 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 64C8D21E8036 for ; Thu, 15 Mar 2012 23:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 UBkxqwDZuiGv for ; Thu, 15 Mar 2012 23:29:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AECD421E801B for ; Thu, 15 Mar 2012 23:29:41 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 5AE3C264629; Fri, 16 Mar 2012 07:29:40 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 40D5335C143; Fri, 16 Mar 2012 07:29:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 16 Mar 2012 07:29:40 +0100 From: To: "Francis.Dupont@fdupont.fr" Date: Fri, 16 Mar 2012 07:29:38 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0C2JE5uvTuivuPRy+ZlKYLaNDQiwAZPwcA Message-ID: <94C682931C08B048B7A8645303FDC9F36E285577D3@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 14 Mar 2012 15:15:59 +0100. <94C682931C08B048B7A8645303FDC9F36E281DB913@PUEXCB1B.nanterre.francetelecom.fr> <201203151822.q2FIMKrI071934@givry.fdupont.fr> In-Reply-To: <201203151822.q2FIMKrI071934@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 06:29:42 -0000 Hi Francis, Yes, you are right. There is no explicit method in PCP to get the external = IP address. You know we have both asked for it in early days of PCP but the= WG consensus was that we can mimic this by using MAP with short lifetime. As for your PS, this a discussion point for the PCP WG.=20 Cheers, Med=20 >-----Message d'origine----- >De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 >Envoy=E9 : jeudi 15 mars 2012 19:22 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : draft-penno-softwire-sdnat@tools.ietf.org; Softwires WG;=20 >draft-cui-softwire-b4-translated-ds-lite >Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 >draft-cui-softwire-b4-translated-ds-lite=20 > > In your previous mail you wrote: > >> Med: Why you need an IPv4 address to run PCP? An implementation >> example would be as follows: >> =20 >> * At bootstrap of the CPE, once an AFTR is discovered, use the Plain >> IPv6 PCP mode and the new opcode and options defined in >> http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 >> to retrieve an IPv4 address and set of port. > >=3D> the retrieval of the external address is a function which was >explicitely put out of PCP by the WG, for the second you'd like to use >an extension which was never discussed. To finish there is a difference >between discussing about getting the IPv4 address or getting it with >other parameters as port ranges, and my comment is only about the first >problem. > >Regards > >Francis.Dupont@fdupont.fr > >PS: I should add another dimension: do we want a solution for=20 >DS-Lite or >a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? >= From despres.remi@laposte.net Fri Mar 16 01:28:28 2012 Return-Path: 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 1347221F86E0 for ; Fri, 16 Mar 2012 01:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 Ke7jBeThgEek for ; Fri, 16 Mar 2012 01:28:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDCF21F8707 for ; Fri, 16 Mar 2012 01:28:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id m8UN1i00E37Y3f4038UNZn; Fri, 16 Mar 2012 09:28:23 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-131--755499739 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 16 Mar 2012 09:28:22 +0100 Message-Id: <0274D023-948D-48A4-BA70-979407F27208@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453 A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 08:28:28 -0000 --Apple-Mail-131--755499739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-03-16 02:07, Maoke: >=20 > on the other hand, may i suggest not to term "4rd tunnel" anymore? it = confuses. i emphasized it is NOT a TUNNEL to the common understanding at = all A "4rd" tunnel isn't "any" tunnel.=20 It is only that which is defined by the 4rd-u specification. > (but it seems you never?seldom respond to this point, nor to the ICMP = issue details. ) - maoke Having already answered (see just below), and having received so far no = reaction on this subject, I don't think I should have done more. Your complaining about my insufficiently answering is therefore = undeserved (IMHO). Please restate the ICMP issue you still have in mind. I will try to answer (as usual). "2012-03-09 09:49, R=E9mi Despr=E9s : >> ... >> i don't incline to use the term "tunneling" since tunnel could have a = variety of forms, among which encapsulation is one but not the only one.=20= >=20 > Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation = tunnels." The fact is that there is no noticeable difference, e2e, between: - IPv4 packets that are only natively routed - IPv4 packets that are tunneled on their way any number of times (be it = with 4rd tunnels or any other tunnels). We have, I think, more important subjects to debate. RD= --Apple-Mail-131--755499739 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

on the other hand, may i suggest not = to term "4rd tunnel" anymore? it confuses. i emphasized it is NOT a = TUNNEL to the common understanding at all =

A "4rd" tunnel isn't "any" = tunnel. 
It is only that which is defined by the 4rd-u = specification.


(but= it seems you never?seldom respond to this point, nor to the ICMP issue = details. ) - maoke

Having already answered (see just below), = and having received so far no reaction on this subject, I don't think I = should have done more.
Your complaining about my = insufficiently answering is therefore undeserved = (IMHO).

Please restate the ICMP issue you still = have in mind.
I will try to answer (as = usual).


"2012-03-09 09:49, = R=E9mi Despr=E9s :
...
i don't incline to use the = term "tunneling" since tunnel could have a variety of forms, among which = encapsulation is one but not the only = one. 

Exactly: 4rd uses = header-mapping tunnels, and MAP-E uses encapsulation = tunnels."


The = fact is that there is no noticeable difference, e2e, = between:
- IPv4 packets that are only natively = routed
- IPv4 packets that are tunneled on their way any = number of times (be it with 4rd tunnels or any other = tunnels).

We have, I think, more important = subjects to debate.

RD
= --Apple-Mail-131--755499739-- From despres.remi@laposte.net Fri Mar 16 02:14:37 2012 Return-Path: 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 EA07E21F8682 for ; Fri, 16 Mar 2012 02:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aY+zdDkzy5EO for ; Fri, 16 Mar 2012 02:14:34 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id BC6CF21F868A for ; Fri, 16 Mar 2012 02:14:33 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id m9EW1i00B37Y3f4039EWho; Fri, 16 Mar 2012 10:14:31 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-132--752731845 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 16 Mar 2012 10:14:29 +0100 Message-Id: <8513C911-64AD-4F51-B4E3-7BFE7145DEA2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 09:14:38 -0000 --Apple-Mail-132--752731845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, In a forthcoming answer to another of you emails, on thread "4rd-u = tunnels and stateful NAT64s", I will try to describe more completely = what the latest 4rd brings in the stateful NAT64 context. Le 2012-03-16 =E0 01:27, Maoke a =E9crit : > 2012/3/15 R=E9mi Despr=E9s > Le 2012-03-15 =E0 14:52, Maoke a =E9crit : >> 2012/3/15 R=E9mi Despr=E9s ... >>=20 >> Just referring to: >>=20 >> DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet (Typo corrected, as indicated in another email) >> =20 >> =20 >> what is RFC6145-host?? >=20 > E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports = IPv4 applications and is attached to an IPv6-only network. >=20 > then inside the host, there a RFC6145 module, right? Right: - RFC6535 says: "When BIH is implemented at the network layer, the IPv4 packets are = intercepted and converted to IPv6 using the IP conversion mechanism = defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. - The v6ops draft on 464XLAT says that it combines "existing and = well-known stateful protocol translation RFC 6146 in the core and = stateless protocol translation RFC 6145 at the edge".=20 > my point is, if there is no NAT64 module, this cannot talk with = another NAT64 box elsewhere as only one of the (src,dst)-pair is = stateless IPv4-converted IPv6 address. In my understanding, this discussion is about *stateful* NAT64s (those = that work for hosts having no assigned public IPv4 address). There is then no "stateless IPv4-converted IPv6 address" in this = context. > my previous analysis doesn't matter whether the translator and the end = host are separated or integrated into one box. Not sure to understand the point (which translator, and why separated?). Yet, I think there is no problem here. RFC6535 on BIH says: "The IETF recommends using solutions based on dual stack or tunneling = for IPv6 transition and specifically recommends against deployments = utilizing double protocol translation." This is why it is AFAIK useful, in BIH- and/or 464XLAT-capable hosts, to = add support of 4rd NAT64+ mapping rules.=20 Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd tunneling), = DS hosts having no public IPv4 address can reach IPv4 servers without = any RFC6145 translation (avoiding transparency limitations) In the answer I will send on on the other thread, I plan to restate = this, and explain in more details.=20 If you agree, we could limit this discussion to the other thread. Regards, RD =20 > =20 >=20 > - maoke > =20 > Clear enough? >=20 >> (seeing you have corrected the v4net with v6net) if it is a host = connected to an IPv6 network, it is the case of single NAT64, where we = have the problem of "interwork"? >=20 > See above. >=20 > RD >=20 >=20 >> =20 >> - maoke >> =20 >> =20 >>=20 >> Is this excluded? >>=20 >> RD >>=20 >>=20 >>>=20 >>> you mean the stateful NAT64-ed IPv4 host (let's call it A) having = access to an IPv4 host (let's call it B) behind a stateless RFC6145 = translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if = so, it is not right that RFC6145 complying node can talk to a NAT64. = let's see the details: =20 >>>=20 >>> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- = RFC6145 translator --- B=20 >>>=20 >>> because A would be translated by NAT64 to an arbitrary IPv6 address, = A', which is not an IPv4-converted one either in MAP or in RFC6052, the = RFC6145 translator cannot handle it statelessly for any end-to-end = communication. the box in front of B should be another NAT64, and as i = said previously, no problem in interwork. if one NAT64 supports DCCP, it = adjusts the checksum; if the other doesn't support, it drops DCCP. no = case of asymmetrically processed but end-to-end deliverable DCCP here.=20= >>>=20 >>> - maoke=20 >>> =20 >>> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>> =20 >>>> on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >>>>=20 >>>> maoke >>>> =20 >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>>=20 >>>>> - maoke >>>>> =20 >>>>> If we agree, I have nothing else on this point. >>>>>=20 >>>>> Regards, >>>>> RD >>>>>=20 >>>>>=20 >>>>>=20 >>>>> If, as you suggest,=20 >>>>> 2012-03-15 02:04, Maoke: >>>>>=20 >>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>>=20 >>>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>>=20 >>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>> ... >>>>>>> =20 >>>>>>> Changing DCCP support from optional to mandatory in RFC6145 = isn't backward compatible (an upgraded node isn't guaranteed to = interwork with a non upgraded node). >>>>>>>=20 >>>>>>> the CE/BR specified RFC6145-compliant might be a problem but = MAP-T is still in development. if we state to enforce DCCP mandatorily = rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the = backward compatible problem. to this extend, MAP-T is at the same = kick-off line of the 4rd-U.=20 >>>>>>=20 >>>>>> 1. I agree that, between CEs and BRs, there can be no problem for = DCCP (provided the draft is completed to this effect). The comparison = table was explicitly made with existing drafts, and intended to be = updatable.=20 >>>>>>=20 >>>>>> 2. The MAP-T draft is also claimed to allow "communication = between IPv4-only, as well as any IPv6 enabled end hosts, to native = IPv6-only servers in the domain that are using IPv4-mapped IPv6 = address". In this case, AFAIK, the backward compatibility problem exists = =20 >>>>>> Thought?=20 >>>>>>=20 >>>>>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>>>>=20 >>>>>> - maoke >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>>> To be even more precise, H6 of the comparison table can be: >>>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>>>>=20 >>>>>>> i actually think the original text is fine. "For .... shared = IPv4 addresses" is not needed for 4rd-U, to my understanding, nor needed = to MAP-T. >>>>>>=20 >>>>>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>>>>=20 >>>>>> RD >>>>>>=20 >>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> maoke=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Does this cover the point? >>>>>>>=20 >>>>>>> RD >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> ;-) >>>>>>>> maoke=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>> but this is not my point. my point is: there must be something = we don't know ("non omnia possumus omnes"). even we have gone through = the RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>>>>=20 >>>>>>>>> i somehow am hard to accept words like "far fetched = theoretical problem".=20 >>>>>>>>=20 >>>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> the L4-recalculate is a generic, architectural solution, = surely needing codes for every L4 protocol. but this generality in = architecture makes RFC6145 or MAP-T equipment be easily enhanced to = support anything new with the same logic. but for the 4rd-U BR, it looks = to me we cannot have the unified logic for all (even limited to existing = and well-known) L4 protocols.=20 >>>>>>>>>=20 >>>>>>>>> only my 2 cents.=20 >>>>>>>>=20 >>>>>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>>=20 >>>>>>>> RD=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-132--752731845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


Le 2012-03-16 =E0 = 01:27, Maoke a =E9crit :
2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Le 2012-03-15 =E0 14:52, = Maoke a =E9crit :
2012/3/15 R=E9mi Despr=E9s = <despres.remi@laposte.net>
...

Just referring = to:

DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 = Internet
(Typo corrected, as indicated in = another email)
 
&n= bsp;
what is RFC6145-host?? =

E.g. a host = with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 = applications and is attached to an IPv6-only network.

then inside the host, there = a RFC6145 module, right? =

Right:
- RFC6535 = says:
"When BIH is implemented at the network layer, the IPv4 = packets are intercepted and converted to IPv6 using the IP conversion = mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) = [RFC6145].
- The v6ops draft on 464XLAT says that it combines = "existing and well-known stateful protocol translation RFC 6146 in the = core and stateless protocol translation RFC 6145 at the = edge". 


my point is, if there is no NAT64 module, = this cannot talk with another NAT64 box elsewhere as only one of the = (src,dst)-pair is stateless IPv4-converted IPv6 = address.

In my understanding, = this discussion is about *stateful* NAT64s (those that work for hosts = having no assigned public IPv4 address).
There is then no = "stateless IPv4-converted IPv6 address" in this = context.

my previous analysis doesn't matter whether = the translator and the end host are separated or integrated into one = box.

Not sure to understand = the point (which translator, and why separated?).
Yet, I think = there is no problem here.

RFC6535 on BIH = says:
"The IETF recommends using solutions based on dual stack = or tunneling for IPv6 transition and specifically recommends against = deployments utilizing double protocol = translation."


This is why it is = AFAIK useful, in BIH- and/or 464XLAT-capable hosts, to add support = of 4rd NAT64+ mapping rules. 
Benefit is that, with = upgraded NAT64s (NAT64+ supporting 4rd tunneling), DS hosts having = no public IPv4 address  can reach IPv4 servers without any RFC6145 = translation (avoiding transparency = limitations)

In the answer I will send on on = the other thread, I plan to restate this, and explain in more = details. 
If you agree, we could limit this discussion to = the other = thread.

Regards,
RD


 


 

- maoke
 
Clear enough?

(seeing = you have corrected the v4net with v6net) if it is a host connected to an = IPv6 network, it is the case of single NAT64, where we have the problem = of "interwork"?

See = above.

RD


 
- maoke
 
 

Is this = excluded?

RD



you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless = RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 = domain. if so, it is not right that RFC6145 complying node can talk to a = NAT64. let's see the details:  

model: A ---(IPv4 network)--- NAT64 (stateful) = ---(IPv6 cloud)--- RFC6145 translator --- = B 

because A would be translated by NAT64 = to an arbitrary IPv6 address, A', which is not an IPv4-converted one = either in MAP or in RFC6052, the RFC6145 translator cannot handle it = statelessly for any end-to-end communication. the box in front of B = should be another NAT64, and as i said previously, no problem in = interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the = other doesn't support, it drops DCCP. no case of asymmetrically = processed but end-to-end deliverable DCCP here. 

- maoke 
 
(A NAT64 talking to another NAT64 was part of what I = wrote!!!)

RD



 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=









= --Apple-Mail-132--752731845-- From fibrib@gmail.com Fri Mar 16 02:59:45 2012 Return-Path: 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 BE45B21F85AD for ; Fri, 16 Mar 2012 02:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 MHircFGr9a92 for ; Fri, 16 Mar 2012 02:59:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9D21F856A for ; Fri, 16 Mar 2012 02:59:44 -0700 (PDT) Received: by yenm5 with SMTP id m5so4529781yen.31 for ; Fri, 16 Mar 2012 02:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m04J2Qlfo/p7b2LxTOrH7PEve0qmbDaW6wvGHmC4VOE=; b=XDFsS++NF1/pAgipNl+62+Pv8ahO6jqPTJSoKQKRlpJKnDiW8trNblZ/G6L/Mgz+Ir UVXOvE2QOR29epcnyYWTkaNuqQmRPlQGRBDkxFw5S4t3skz+ZDdjwPPFuLSElhI+ygaq 1L5nTPXwMpaj1ToOtgdByLDg8sdarFrzdUN3BaaDeicPjrYmB4hJVFMHsHFguUGpyvUv VNQeXjiyLlgAzy/pSg9BxOch7HeMlQ9cBGPDIs/gPMqM2ntLxHKs7uc0wFceHdq00Lt/ I7cEeZezVA0z9rqeQnEvoT6aHnJVtIFik1eXEzk1r2mJAEwrenP4x0cOdZmzGYZ2bxf1 UDlg== MIME-Version: 1.0 Received: by 10.229.75.139 with SMTP id y11mr698026qcj.69.1331891984557; Fri, 16 Mar 2012 02:59:44 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Fri, 16 Mar 2012 02:59:44 -0700 (PDT) In-Reply-To: <0274D023-948D-48A4-BA70-979407F27208@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <0274D023-948D-48A4-BA70-979407F27208@laposte.net> Date: Fri, 16 Mar 2012 09:59:44 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023544719ac9e686904bb59445d Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 09:59:45 -0000 --0023544719ac9e686904bb59445d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/16 R=E9mi Despr=E9s > > 2012-03-16 02:07, Maoke: > > > on the other hand, may i suggest not to term "4rd tunnel" anymore? it > confuses. i emphasized it is NOT a TUNNEL to the common understanding at > all > > > A "4rd" tunnel isn't "any" tunnel. > "a white horse is not a horse. " - ancient Chinese proverb. ;-) anyway i won't be stubborn on this anymore. :) > It is only that which is defined by the 4rd-u specification. > > > (but it seems you never?seldom respond to this point, nor to the ICMP > issue details. ) - maoke > > > Having already answered (see just below), and having received so far no > reaction on this subject, I don't think I should have done more. > Your complaining about my insufficiently answering is therefore undeserve= d > (IMHO). > > Please restate the ICMP issue you still have in mind. > I will try to answer (as usual). > http://www.ietf.org/mail-archive/web/softwires/current/msg03626.html i don't think that's only a replicate of our previous discussion. even if so, i guess this is the first time in the mail list. regards, maoke > > > "2012-03-09 09:49, R=E9mi Despr=E9s : > > ... > i don't incline to use the term "tunneling" since tunnel could have a > variety of forms, among which encapsulation is one but not the only one. > > > Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation > tunnels." > > > > The fact is that there is no noticeable difference, e2e, between: > - IPv4 packets that are only natively routed > - IPv4 packets that are tunneled on their way any number of times (be it > with 4rd tunnels or any other tunnels). > > We have, I think, more important subjects to debate. > > RD > --0023544719ac9e686904bb59445d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

2012-03-16 02:07, Maoke:<= /div>


on= the other hand, may i suggest not to term "4rd tunnel" anymore? = it confuses. i emphasized it is NOT a TUNNEL to the common understanding at= all

A "4rd" tunnel isn't &= quot;any" tunnel.=A0

"a white horse is not a horse. " - ancient Chinese proverb. ;-) = anyway i won't be stubborn on this anymore. :)=A0
=A0
It is only that which is defined by the 4rd-u specification= .


(but it= seems you never?seldom respond to this point, nor to the ICMP issue detail= s. ) - maoke

Having already answered (see just below),= and having received so far no reaction on this subject, I don't think = I should have done more.
Your complaining about my insufficiently= answering is therefore undeserved (IMHO).

Please restate the ICMP issue you still have in mind.
I will try to answer (as usual).

=
i don't think that's only a replicate of our previous discussi= on. even if so, i guess this is the first time in the mail list.=A0

regards,
maoke
=A0


"2012-03-09 09:49, R=E9mi Despr=E9s :
=
...
i don= 't incline to use the term "tunneling" since tunnel could hav= e a variety of forms, among which encapsulation is one but not the only one= .=A0

Exactly: 4rd uses header-mapping tun= nels, and MAP-E uses encapsulation tunnels."
=

The fact is that there is no noticeable diffe= rence, e2e, between:
- IPv4 packets that are only natively routed
- IPv4 packets = that are tunneled on their way any number of times (be it with 4rd tunnels = or any other tunnels).

We have, I think, more impo= rtant subjects to debate.

RD

--0023544719ac9e686904bb59445d-- From fibrib@gmail.com Fri Mar 16 03:34:25 2012 Return-Path: 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 CFE7321F8571 for ; Fri, 16 Mar 2012 03:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 7aj+lcKPIJ5P for ; Fri, 16 Mar 2012 03:34:24 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E901121F856F for ; Fri, 16 Mar 2012 03:34:23 -0700 (PDT) Received: by qcsq13 with SMTP id q13so217041qcs.31 for ; Fri, 16 Mar 2012 03:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j5kOeWH3A9KehTvobtjcJyHH2fcAyby7kGkknqqWQBk=; b=ms8VayjvybCuPzjFs6WddB4Tvkgc7qiPqaZTqXoaPwjlKoeQH+pRzHL2MqTGuVBcak ilQHk+AG5fhgOnqZt2U9j605gS+ohhn042WDWs6t+wZd09Hl/l4Ij1hLBwl+wTzpDJPb UgKDjv2mM0cmxhSDvYMmtbIuGWWlm92G9I3q5XuIROUXwvgpdjWmCnQJTUczhSXGas2+ nFFDGbHf3DCpz4oLs4B0m0gIHkJm+fftxY19OsVzzQGb3uFw92v+TSxEcnBG5NTthplT rbwfyl3MQolwNIMMpTqc30CxnlsNoGC5kSdTXNo4VKnjMItECYrItdtRQFrhIic9EVIh IAbA== MIME-Version: 1.0 Received: by 10.229.134.196 with SMTP id k4mr751490qct.29.1331894063369; Fri, 16 Mar 2012 03:34:23 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Fri, 16 Mar 2012 03:34:23 -0700 (PDT) In-Reply-To: <8513C911-64AD-4F51-B4E3-7BFE7145DEA2@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> <8513C911-64AD-4F51-B4E3-7BFE7145DEA2@laposte.net> Date: Fri, 16 Mar 2012 10:34:23 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c6a86e2868f3a04bb59c0c4 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 10:34:25 -0000 --00248c6a86e2868f3a04bb59c0c4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/16 R=E9mi Despr=E9s > Maoke, > > In a forthcoming answer to another of you emails, on thread "4rd-u tunnel= s > and stateful NAT64s", I will try to describe more completely what the > latest 4rd brings in the stateful NAT64 context. > > > Le 2012-03-16 =E0 01:27, Maoke a =E9crit : > > 2012/3/15 R=E9mi Despr=E9s > >> Le 2012-03-15 =E0 14:52, Maoke a =E9crit : >> >> 2012/3/15 R=E9mi Despr=E9s >> >> ... > > >>> Just referring to: >>> >>> DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet >>> >> (Typo corrected, as indicated in another email) > > >>> >> >> what is RFC6145-host?? >> >> >> E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports >> IPv4 applications and is attached to an IPv6-only network. >> > > then inside the host, there a RFC6145 module, right? > > > Right: > - RFC6535 says: > "When BIH is implemented at the network layer, the IPv4 packets are > intercepted and converted to IPv6 using the IP conversion mechanism defin= ed > in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. > no different understanding here. > - The v6ops draft on 464XLAT says that it combines "existing and > well-known stateful protocol translation RFC 6146 in the core and statele= ss > protocol translation RFC 6145 at the edge". > > well, a new topic. i don't think you plan to apply CNP into v6ops-464xlat /96 address format. do you? > > my point is, if there is no NAT64 module, this cannot talk with another > NAT64 box elsewhere as only one of the (src,dst)-pair is stateless > IPv4-converted IPv6 address. > > > In my understanding, this discussion is about *stateful* NAT64s (those > that work for hosts having no assigned public IPv4 address). > There is then no "stateless IPv4-converted IPv6 address" in this context. > ok. then in BIH case, no case of stateless translator talking with stateful NAT64. cleared. > > my previous analysis doesn't matter whether the translator and the end > host are separated or integrated into one box. > > > Not sure to understand the point (which translator, and why separated?). > Yet, I think there is no problem here. > > RFC6535 on BIH says: > "The IETF recommends using solutions based on dual stack or tunneling for > IPv6 transition and specifically recommends against deployments utilizing > double protocol translation." > i remember people has clarified this. but my question is: do you mean 4rd tunneling is a sort of the recommended tunneling? but the other message of you said 4rd tunnel is not of "any" tunnel. > > > This is why it is AFAIK useful, in BIH- and/or 464XLAT-capable hosts, to > add support of 4rd NAT64+ mapping rules. > Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd tunneling), > DS hosts having no public IPv4 address can reach IPv4 servers without an= y > RFC6145 translation (avoiding transparency limitations) > actually i must say "NAT64+ mapping rule" is a very confusing concept. may i understand it is a rule that, when the stateful translation is performed, the translator using an (IPv4 addr, CNP) combination for the IID for an IPv4 remote peer out of the domain? may i ask you for a detailed example on how this NAT64+ address is used, with specifying a pair of source and destination addresses, and explaining how such a scenario happens. > > In the answer I will send on on the other thread, I plan to restate this, > and explain in more details. > If you agree, we could limit this discussion to the other thread. > > Regards, > RD > > > > > > > > - maoke > > >> Clear enough? >> >> (seeing you have corrected the v4net with v6net) if it is a host >> connected to an IPv6 network, it is the case of single NAT64, where we h= ave >> the problem of "interwork"? >> >> >> See above. >> >> RD >> >> >> >> - maoke >> >> >>> >>> >>> Is this excluded? >>> >>> RD >>> >>> >>> >>> you mean the stateful NAT64-ed IPv4 host (let's call it A) having acces= s >>> to an IPv4 host (let's call it B) behind a stateless RFC6145 translator= , >>> mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is = not >>> right that RFC6145 complying node can talk to a NAT64. let's see the >>> details: >>> >>> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- >>> RFC6145 translator --- B >>> >>> because A would be translated by NAT64 to an arbitrary IPv6 address, A'= , >>> which is not an IPv4-converted one either in MAP or in RFC6052, the RFC= 6145 >>> translator cannot handle it statelessly for any end-to-end communicatio= n. >>> the box in front of B should be another NAT64, and as i said previously= , no >>> problem in interwork. if one NAT64 supports DCCP, it adjusts the checks= um; >>> if the other doesn't support, it drops DCCP. no case of asymmetrically >>> processed but end-to-end deliverable DCCP here. >>> >>> - maoke >>> >>> >>>> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>>> >>>> RD >>>> >>>> >>>> >>>> >>>> >>>>> on the other hand, i cannot understand how the CNP helps stateful >>>>> checksum validity. may you please to clarify? >>>>> >>>>> maoke >>>>> >>>>> >>>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> - maoke >>>>>> >>>>>> >>>>>>> If we agree, I have nothing else on this point. >>>>>>> >>>>>>> Regards, >>>>>>> RD >>>>>>> >>>>>>> >>>>>>> >>>>>>> If, as you suggest, >>>>>>> 2012-03-15 02:04, Maoke: >>>>>>> >>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>>> >>>>>>>> >>>>>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>>> >>>>>>>> >>>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>>>> >>>>>>>> ... >>>>>>> >>>>>>> >>>>>>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>>>>>> backward compatible (an upgraded node isn't guaranteed to interwo= rk with a >>>>>>>>> non upgraded node). >>>>>>>>> >>>>>>>> >>>>>>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T >>>>>>>> is still in development. if we state to enforce DCCP mandatorily r= ather >>>>>>>> than optional in MAP-T, a MAP-T-compliant CE/BR won't has the back= ward >>>>>>>> compatible problem. to this extend, MAP-T is at the same kick-off = line of >>>>>>>> the 4rd-U. >>>>>>>> >>>>>>>> >>>>>>>> 1. I agree that, between CEs and BRs, there can be no problem for >>>>>>>> DCCP (provided the draft is completed to this effect). The compari= son table >>>>>>>> was explicitly made with existing drafts, and intended to be updat= able. >>>>>>>> >>>>>>>> 2. The MAP-T draft is also claimed to allow "communication between >>>>>>>> IPv4-only, as well as any IPv6 enabled end hosts, to native >>>>>>>> IPv6-only servers in the domain that are using IPv4-mapped IPv6 >>>>>>>> address". In this case, AFAIK, the backward compatibility problem >>>>>>>> exists >>>>>>>> Thought? >>>>>>>> >>>>>>> >>>>>>> surely it does not exist. that statement applies to the >>>>>>> MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 singl= e >>>>>>> translator or as an native IPv6 router. same deployment of equipmen= ts >>>>>>> should support double-translation, single-translation, and native I= Pv6 >>>>>>> accesses simultanenously. that's one of the points of the MAP-T. >>>>>>> >>>>>>> - maoke >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> To be even more precise, H6 of the comparison table can be: >>>>>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>>>>>> addresses, DCCP and UDP-Lite are supported, as well as future pro= tocols >>>>>>>>> using the TCP checksum algorithm and ports at the same place" >>>>>>>>> >>>>>>>> >>>>>>>> i actually think the original text is fine. "For .... shared IPv4 >>>>>>>> addresses" is not needed for 4rd-U, to my understanding, nor neede= d to >>>>>>>> MAP-T. >>>>>>>> >>>>>>>> >>>>>>>> Will see what to do, then, when changes to the MAP-T draft >>>>>>>> concerning DCCP are known. >>>>>>>> >>>>>>> >>>>>>>> RD >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> maoke >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Does this cover the point? >>>>>>>>> >>>>>>>>> RD >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ;-) >>>>>>>>> maoke >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> but this is not my point. my point is: there must be something >>>>>>>>>> we don't know ("non omnia possumus omnes"). even we have gone th= rough the >>>>>>>>>> RFCs, there might be some other proprietary L4 protocols, or exp= erimental >>>>>>>>>> protocols. even they are minority, i don't think ignoring their = existance >>>>>>>>>> in our solution fits the spirit of the Internet. it might be arg= ued that >>>>>>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol = owner may >>>>>>>>>> makes his own NAT44, either attached to the CE or separated. if = 4rd-U >>>>>>>>>> respects such an effort, it should state "currently blahblabla L= 4 protocols >>>>>>>>>> are supported". the similar statement applies to the RFC6145 or = MAP as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>>>>>> problem". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If I had thought it might be so, I would have avoided the word. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>>>>>> needing codes for every L4 protocol. but this generality in arch= itecture >>>>>>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support a= nything new >>>>>>>>>> with the same logic. but for the 4rd-U BR, it looks to me we can= not have >>>>>>>>>> the unified logic for all (even limited to existing and well-kno= wn) L4 >>>>>>>>>> protocols. >>>>>>>>>> >>>>>>>>>> only my 2 cents. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With amendments above, the point is AFAIK completely covered: >>>>>>>>>> everything is rigorously true, and worth noting. >>>>>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>>>> >>>>>>>>>> RD >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Softwires mailing list >>>>>>> Softwires@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > > --00248c6a86e2868f3a04bb59c0c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Maoke,

In a forthcom= ing answer to another of you emails, on thread "4rd-u tunnels and stat= eful NAT64s", I will try to describe more completely what the latest 4= rd brings in the stateful NAT64 context.


Le 2012-03-16 =E0 01:27, Maoke a =E9crit = :
2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>
Le 2012-03-15 =E0 14:52, Maok= e a =E9crit :
2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>=
=
...

Just referring to:<= /div>

DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet
(Typo corrected, as indicated in another email)

=A0
= =A0
what is RFC6145-host??

E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one= that supports IPv4 applications and is attached to an IPv6-only network.

then inside the host, there a = RFC6145 module, right?

R= ight:
- RFC6535 says:
"When BIH is implemented at = the network layer, the IPv4 packets are intercepted and converted to IPv6 u= sing the IP conversion mechanism defined in the Stateless IP/ICMP Translati= on Algorithm (SIIT) [RFC6145].

no different understandi= ng here.=A0
=A0
- The v6ops draft on 464XLAT says that it combines "exi= sting and well-known stateful protocol translation RFC 6146 in the core and= =A0stateless protocol translation RFC 6145 at the edge".=A0


wel= l, a new topic. i don't think you plan to apply CNP into v6ops-464xlat = /96 address format. do you?
=A0

my point is, if there is= no NAT64 module, this cannot talk with another NAT64 box elsewhere as only= one of the (src,dst)-pair is stateless IPv4-converted IPv6 address.

In my understanding, this discussio= n is about *stateful* NAT64s (those that work for hosts having no assigned = public IPv4 address).
There is then no "stateless IPv4-conve= rted IPv6 address" in this context.

ok. then in BIH case, no case = of stateless translator talking with stateful NAT64. cleared.=A0
= =A0

my previous analysis do= esn't matter whether the translator and the end host are separated or i= ntegrated into one box.

Not sure to understand the poi= nt (which translator, and why separated?).=A0
Yet, I think there is no= problem here.

RFC6535 on BIH says:
&quo= t;The IETF recommends using solutions based on dual stack or tunneling for = IPv6 transition and specifically recommends against deployments utilizing d= ouble protocol translation."

i remember people has cl= arified this. but my question is: do you mean 4rd tunneling is a sort of th= e recommended tunneling? but the other message of you said 4rd tunnel is no= t of "any" tunnel.=A0
=A0


This is why it is AFAIK = useful, in BIH- and/or 464XLAT-capable hosts,=A0to add support of 4rd NAT64= + mapping rules.=A0
Benefit is that,=A0with upgraded NAT64s (NAT64+=A0supporting 4rd tunne= ling), DS hosts having no public IPv4 address =A0can reach IPv4 servers wit= hout any RFC6145 translation (avoiding transparency limitations)

actually i must say "NAT64+ map= ping rule" is a very confusing concept. may i understand it is a rule = that, when the stateful translation is performed, the translator using an (= IPv4 addr, CNP) combination for the IID for an IPv4 remote peer out of the = domain? may i ask you for a detailed example on how this NAT64+ address is = used, with specifying a pair of source and destination addresses, and expla= ining how such a scenario happens.=A0
=A0

In the answer I will send on on the oth= er thread, I plan to restate this, and explain in more details.=A0
If you agree, we could limit this discussion to the other thread.=A0

Regards,
RD


=A0


=A0

- maoke
=A0
Clear enough?

(seeing you h= ave corrected the v4net with v6net) if it is a host connected to an IPv6 ne= twork, it is the case of single NAT64, where we have the problem of "i= nterwork"?

See above.

RD


<= blockquote type=3D"cite">
=A0
- maoke
=A0
=A0

Is this excluded?

RD


=

you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless R= FC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain= . if so, it is not right that RFC6145 complying node can talk to a NAT64. l= et's see the details: =A0

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6= cloud)--- RFC6145 translator --- B=A0

because A w= ould be translated by NAT64 to an arbitrary IPv6 address, A', which is = not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translat= or cannot handle it statelessly for any end-to-end communication. the box i= n front of B should be another NAT64, and as i said previously, no problem = in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the o= ther doesn't support, it drops DCCP. no case of asymmetrically processe= d but end-to-end deliverable DCCP here.=A0

- maoke=A0
=A0
(A NAT64 talking to another NAT64 was part of what I wrote!!!)

RD
<= br>


=A0
on the other= hand, i cannot understand how the CNP helps stateful checksum validity. ma= y you please to clarify?=A0

maoke
=A0

RD



- maoke
=A0
If we agree, I have nothing else o= n this point.

Regards,
RD



If, as you suggest,=A0
2012-03-15 02:04,= Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>=

Le 2012-03-14 =E0 10:46, = Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte= .net>
= ...
=A0=A0
Changin= g DCCP support from optional to mandatory in RFC6145 isn't backward com= patible (an upgraded node isn't guaranteed to interwork with a non upgr= aded node).

the CE/BR specified RFC6= 145-compliant might be a problem but MAP-T is still in development. if we s= tate to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-com= pliant CE/BR won't has the backward compatible problem. to this extend,= MAP-T is at the same kick-off line of the 4rd-U.=A0

1. I agree that,=A0betwe= en CEs and BRs,=A0there can be no problem for DCCP (provided the draft is c= ompleted to this effect). The comparison table was explicitly made with exi= sting drafts, and intended to be updatable.=A0

2.=A0The MAP-T draft is also claimed to allow "communication betwe= en IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in = the domain that are using IPv4-mapped IPv6 address".=A0In this case,=A0AFAIK,=A0the backward compatibility= problem exists =A0
Thought?

surely it does not = exist. that statement applies to the MAP-T-compliant equipments, when it is= used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same= deployment of equipments should support double-translation, single-transla= tion, and native IPv6 accesses simultanenously. that's one of the point= s of the MAP-T.=A0

- maoke
=A0


To be even more precise, H6 of the comparison table can be:<= /div>
"For ISPs that don't provide all CE nodes, and for shared IPv= 4 addresses, DCCP and UDP-Lite are supported, as well as future protocols u= sing the TCP checksum algorithm and ports at the same place"

i actually think the ori= ginal text is fine. "For .... shared IPv4 addresses" is not neede= d for 4rd-U, to my understanding, nor needed to MAP-T.

Will see what to do, then, when changes to the MAP-T d= raft concerning DCCP are known.=A0

=
RD


=
=A0

maoke=A0
=A0

Does this cover the point?

RD




;-)
maoke=A0
=A0

but this is not my point. my point is: there must be something we don&= #39;t know ("non omnia possumus omnes"). even we have gone throug= h the RFCs, there might be some other proprietary L4 protocols, or experime= ntal protocols. even they are minority, i don't think ignoring their ex= istance in our solution fits the spirit of the Internet. it might be argued= that NAT44 doesn't support such L4 protocols now, but an L4 protocol o= wner may makes his own NAT44, either attached to the CE or separated. if 4r= d-U respects such an effort, it should state "currently blahblabla L4 = protocols are supported". the similar statement applies to the RFC6145= or MAP as well.

i somehow am hard to accept words like "far fetched theoretical= problem".=A0

If I h= ad thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely needin= g codes for every L4 protocol. but this generality in architecture makes RF= C6145 or MAP-T equipment be easily enhanced to support anything new with th= e same logic. but for the 4rd-U BR, it looks to me we cannot have the unifi= ed logic for all (even limited to existing and well-known) L4 protocols.=A0=

only my 2 cents.=A0

With amendments above, the point is AFAIK completely co= vered: everything is rigorously true, and worth noting.
Thanks fo= r the useful reference to the RDP of RFC1151.

RD=A0








_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires












--00248c6a86e2868f3a04bb59c0c4-- From despres.remi@laposte.net Fri Mar 16 04:05:17 2012 Return-Path: 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 EED4E21F867C for ; Fri, 16 Mar 2012 04:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 9zUZP7lsbIKe for ; Fri, 16 Mar 2012 04:05:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A826D21F8656 for ; Fri, 16 Mar 2012 04:05:13 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 748F694019F; Fri, 16 Mar 2012 12:05:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-134--746096564 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 16 Mar 2012 12:05:05 +0100 Message-Id: <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 11:05:18 -0000 --Apple-Mail-134--746096564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, First: - My apologies for having not answered this email before receiving a = reminder (it was by mistake lost in a stack of non-urgent things to do). - Thanks for the clear and detailed analysis. More comments in line. Le 2012-03-13 =E0 10:53, Maoke a =E9crit : > Remi,=20 >=20 > discussion on R-16 of Sec 4.7: >=20 > > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it > > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet > > MUST contain the first 8 octets of the discarded-packet IP > > payload. >=20 > now the ICMPv6 error message contains the payload as the = "header-mapped" IPv6 PDU of the discarded packet. right? so does 4rd-U = CE or BR translates this ICMPv6 payload to ICMPv4 payload as RFC6145 = does? does 4rd-U applies the checksum adjustment algorithm between = ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP doesn't = help) >=20 > if it does, you'd better cite RFC6145 here. if it doesn't, please = specify.=20 >=20 > > If the CE or BR has a global IPv4 address, this > > address MUST be used as source of this packet. Otherwise, the > > unspecified address 0.0.0.0 SHOULD be used as this source. >=20 > let me draw an example for that: >=20 > A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; = router R2 here)--- B >=20 > 1. consider ICMPv6 error happens at R1 >=20 > original IPv4 packet at A, sent to B: > +---------+----------------------------------------------+ > | IPv4 | payload | > | hdr, H1 | P1 | > +---------+----------------------------------------------+ >=20 > CE translates (precisely speaking, "header-maps") it to:=20 > +------------+----------------------------------------------+ > | IPv6 | payload | > | header, H2 | P1 | > +------------+----------------------------------------------+ >=20 > R1 found a error for this IPv6 packet, it generates an ICMPv6 report: > +------------+--------+-----------+-------------------------+ > | IPv6 | ICMPv6 | IPv6 | payload (truncated to | > | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | > +------------+--------+-----------+-------------------------+ > \_______________ ___________________/ > V > as the ICMPv6 error message body >=20 > this message feedbacked to CE, who will translate it to: > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > \__________ __________/ > V > as the ICMPv4 error message body >=20 > it is clear that 4rd-U address mapping is applied for=20 >=20 > H1 -> H2 -> H4 >=20 > H3 has the source address of R1 while the destination address as the = CE. >=20 > then, CE's (or BR's for the case of B --> A) global IPv4 address or = 0.0.0.0 will be used in H5, right? Right. > first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address = represents either a host not yet having gained an IPv4 address on the = LOCAL network or an application listening on any addresses of a host. > packet with 0.0.0.0 might be dropped by any intermediate routers of = current implementations.=20 This address never appears on any IPv4 link. Intermediate routers being IPv6, there is no problem. OK? >=20 > > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unreachable, No > > route to destination") MUST be translated into ICMPv4 Type =3D 3 > > and Code =3D 0 (Destination unreachable, Net unreachable). > > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit > > exceeded in transit) MUST be translated into ICMPv4 Type =3D 11 > > and Code =3D 0 (Time exceeded, Time to live exceeded in > > transit). >=20 > for C1 -> C2 translation, i have the following comments: >=20 > 1) here 4rd-U uses the CE's global IPv4 address > (i think "global" refers to a non-shared one, right?) Global address is used as a synonymous of public address. If somewhere it seems to mean non-shared address, it must be a mistake. > to represent all the error generator inside in the IPv6 domain. this = surely fits a "tunnel" behavior that attempts to treat the delivery from = CE to BR as a "link", and therefore the error is responded by the link's = end point.=20 > 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit = exceeded and ICMPv6 unreachable node should be translated as ICMPv4 = destination unreachable (Type =3D 3) host unreachable (Code =3D 1), = because it should indicates the link problem of the tunnel. > 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a = typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter = consumes the TTL per physical hop. for example, if we set TTL =3D 32 in = H1, tunneling means from A to B communication may succeed as long as = (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well = connected; while current 4rd-U means from A to B communication may = succeed only when total numbers of intermediate routers doesn't exceed = 31.=20 >=20 > this is why typical tunneling solutions initialize the out-header's = IPv6 Hop Limit to 255. when routing loop happens in the IPv6 domain and = Hop Limit is consumed out, the link is considered broken. I don't see any problem with having, at tunnel exit, the TTL decreased = by the number of traversed routers. =20 >=20 > 2. consider ICMPv4 error happens at R2:=20 >=20 > R2 sees original IPv4 packet at A, sent to B: > +---------+----------------------------------------------+ > | IPv4 | payload | > | hdr, H1 | P1 | > +---------+----------------------------------------------+ >=20 > R2 has found some error with that packet, issuing an ICMPv4 message = and sending to A: > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > \__________ __________/ > V > as the ICMPv4 error message body >=20 > 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): > +------------+--------+--------+--------------+ > | IPv6 | ICMPv4 | IPv4 | truncated | > | header, H7 | hdr, C3| hdr, H1| payload, P3 | > +------------+--------+--------+--------------+ >=20 > woops, unfortunately, R1 also found something wrong. R1 generates an = ICMPv6 report, responding back to B:=20 > +------------+--------+------------+--------+--------+--------------+ > | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | > | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | > +------------+--------+------------+--------+--------+--------------+ >=20 > BR sees this and makes translation to:=20 > +---------+--------+---------+--------+--------+------------+ > | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| > +---------+--------+---------+--------+--------+------------+ > |<------- 8 octet ----------->| > \___________________ __________________/ > V > as the ICMPv4 error message body >=20 > here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. = here 4rd-U can have two options: > 1) let it be but depends on the IPv4 Internet routers, or host B = itself to drop the ICMP of ICMP;=20 > 2) actively check the header in the ICMPv4 message body (H9 above) and = identify if the protocol of the discard-packet is ICMPv4 too; if so, BR = drops the packet.=20 >=20 > i doubt either is good. anyway, no matter which is used, 4rd-U must = deal with this issue. (sorry if i missed some text where it has been = done.) The right choice is clearly 2 (RFC792 rightly says: "To avoid the = infinite regress of messages about messages etc., no ICMP messages are = sent about ICMP messages.") It can be made more explicit in the specification. Thanks. Cheers, RD >=20 > cheers, > maoke >=20 > 2012/3/12 R=E9mi Despr=E9s > Hello, all, >=20 > An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >=20 > Differences with -04 include: > - DHCPv6 options are now specified > - various errors and typos are corrected > - some clarifications are added, following received questions and = comments > - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs) > - An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs. > - Document layout has been adjusted as a result of other = modifications. > - the authors list has been completed. >=20 > Questions and comments are most welcome. >=20 > Regards, > RD >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-134--746096564 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Remi, 

discussion = on R-16 of Sec 4.7:

  > R-16: If a CE = or BR receives an ICMPv6 error message [RFC4443], it
  = > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet
  > MUST contain the first 8 octets of the = discarded-packet IP
  > payload. =

now the ICMPv6 error message contains the = payload as the "header-mapped" IPv6 PDU of the discarded packet. right? = so does 4rd-U CE or BR translates this ICMPv6 payload to ICMPv4 payload = as RFC6145 does? does 4rd-U applies the checksum adjustment algorithm = between ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP = doesn't help)

if it does, you'd better cite RFC6145 here. if it = doesn't, please specify. 

  > If = the CE or BR has a global IPv4 address, this
  > = address MUST be used as source of this packet. Otherwise, the
  > unspecified address 0.0.0.0 SHOULD be used as this = source.

let me draw an example for = that:

A --- CE ----(IPv6 domain; router R1 = here)---- BR ----(IPv4 Internet; router R2 here)--- B

1. consider ICMPv6 error happens at = R1

original IPv4 packet at A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

CE translates (precisely speaking, = "header-maps") it to: 
=
+------------+----------------------------------------------+
| IPv6       | payload       =                     =            |
| header, H2 | P1 =                    =                     =    |
=
+------------+----------------------------------------------+

R1 found a error for this IPv6 packet, it generates an = ICMPv6 = report:
+------------+--------+-----------+----------------= ---------+
| IPv6       | ICMPv6 | IPv6     =  | payload (truncated to   |
| header, H3 | hdr, C1| = header, H2| fit in min IPv6 MTU),P2 = |
+------------+--------+-----------+-------------------------+<= /div>
                    =    \_______________ = ___________________/
        =                     =            V
    =                     =  as the ICMPv6 error message body

this = message feedbacked to CE, who will translate it to:
+---------+--------+--------+--------------+
| IPv4 =    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H5 | hdr, C2| hdr, H4| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

it is clear that 4rd-U address mapping is applied = for 

  H1 -> H2 -> = H4

H3 has the source address of R1 while the = destination address as the CE.

then, CE's (or BR's for the case of B --> A) = global IPv4 address or 0.0.0.0 will be used in H5, = right?

Right.

first of all, the 0.0.0.0 might be a wrong = choice. Unspecified Address represents either a host not yet having = gained an IPv4 address on the LOCAL network or an application listening = on any addresses of a host.

packet with 0.0.0.0 might be dropped by any = intermediate routers of current = implementations. 

This = address never appears on any IPv4 link.
Intermediate routers = being IPv6, there is no problem.
OK?


  > ICMPv6 Type =3D 1 and Code =3D 0 = (Destination unreachable, No
  > route to = destination") MUST be translated into ICMPv4 Type =3D 3
  = > and Code =3D 0 (Destination unreachable, Net unreachable).
  > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop = limit
  > exceeded in transit) MUST be translated = into ICMPv4 Type =3D 11
  > and Code =3D 0 (Time = exceeded, Time to live exceeded in
  > transit).

for C1 -> C2 = translation, i have the following = comments:

1) here 4rd-U uses the CE's = global IPv4 address

(i think "global" refers to a non-shared one, = right?)

Global address is = used as a synonymous of public address.
If somewhere it seems = to mean non-shared address, it must be a = mistake.


to = represent all the error generator inside in the IPv6 domain. this surely = fits a "tunnel" behavior that attempts to treat the delivery from CE to = BR as a "link", and therefore the error is responded by the link's end = point. 
2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit = exceeded and ICMPv6 unreachable node should be translated as ICMPv4 = destination unreachable (Type =3D 3) host unreachable (Code =3D 1), = because it should indicates the link problem of the tunnel.
3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is = a typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter = consumes the TTL per physical hop. for example, if we set TTL =3D 32 in = H1, tunneling means from A to B communication may succeed as long as = (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well = connected; while current 4rd-U means from A to B communication may = succeed only when total numbers of intermediate routers doesn't exceed = 31. 

this is why typical tunneling solutions = initialize the out-header's IPv6 Hop Limit to 255. when routing loop = happens in the IPv6 domain and Hop Limit is consumed out, the link is = considered broken.

I don't = see any problem with having, at tunnel exit, the TTL decreased = by the number of traversed = routers.
 


2. consider ICMPv4 error happens at = R2: 

R2 sees original IPv4 packet at = A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

R2 has found some error with that packet, = issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H6 | hdr, C3| hdr, H1| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as = payload of = IPv6):
+------------+--------+--------+--------------+
| IPv6       | ICMPv4 | IPv4   | = truncated    |
| header, H7 | hdr, C3| hdr, H1| payload, P3  = |
+------------+--------+--------+--------------+

=
woops, unfortunately, R1 also found something wrong. R1 = generates an ICMPv6 report, responding back to B: 
=
+------------+--------+------------+--------+--------+----------= ----+
| IPv6       | ICMPv6 | IPv6 =       | ICMPv4 | IPv4   | truncated   =  |
| header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| = payload, P3  |
=
+------------+--------+------------+--------+--------+--------------+=

BR sees this and = makes translation = to: 
+---------+--------+----= -----+--------+--------+------------+
| IPv4    | ICMPv4 | IPv4    | ICMPv4 | = IPv4   | truncated  |
| hdr, H10| hdr, C5| hdr, = H9 | hdr, C3| hdr, H1| payload, = P4|
+---------+--------+---------+--------+--------+------------= +
        =                     =  |<------- 8 octet  = ----------->|
        =             \___________________ = __________________/
        =                     =             V
                  =        as the ICMPv4 error message = body

here an "ICMP of ICMP", which is not = allowed in ICMPv4, is generated. here 4rd-U can have two = options:
1) let it be but depends on the IPv4 Internet = routers, or host B itself to drop the ICMP of ICMP; 
2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet. 

i doubt either is = good. anyway, no matter which is used, 4rd-U must deal with this issue. = (sorry if i missed some text where it has been = done.)

The = right choice is clearly 2 (RFC792 rightly says: "To avoid the infinite = regress of messages about messages etc., no ICMP messages are sent about = ICMP messages.")
It can be made more explicit in the = specification. = Thanks.


Cheers,
RD
=




=

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 05

Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and = comments
- the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other = modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-134--746096564-- From despres.remi@laposte.net Fri Mar 16 07:17:10 2012 Return-Path: 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 B714021F86B8 for ; Fri, 16 Mar 2012 07:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 g8A+v9LbC0xV for ; Fri, 16 Mar 2012 07:17:09 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E070221F8638 for ; Fri, 16 Mar 2012 07:17:06 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5F277940053; Fri, 16 Mar 2012 15:16:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-135--734583845 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 16 Mar 2012 15:16:57 +0100 Message-Id: <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <5A41CA6D-581B-453 A-8409-B499BD3582F7@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:17:10 -0000 --Apple-Mail-135--734583845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Let me try a more complete picture than before: A1 -----. =20 RFC6145-host| .-- 4rd BR --.=20 | | | A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 4rd-CE | | | UDP Lite appli = =20 (no IPv4 @) | '-- NAT64+ --'=20 | =20 A3 -----'=20 4rd-CE =20 (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:=20 A2 =3D> B (via NAT64+) A3 <=3D> B (via 4rd BR) (There is no A1-B connectivity) Anything missed? Other detailed comments follow. Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >=20 >=20 > 2012/3/15 R=E9mi Despr=E9s >=20 > Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>=20 >>> i understand NAT64 makes translation between arbitrary IPv6 address = to arbitrary IPv4 address. i don't understand how you make CNP in any = IPv6 address. >>=20 >>=20 >>> in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. >>=20 >> That's no the case at all(!).=20 >> A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely unchanged). >>=20 >> The draft says: >> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd = tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address = format." >> =20 >> =20 >> this phrase is not understood yet. do you mean using 4rd-IPv6-address = format for stateful translation service? >=20 > Yes (but, &s said, only for CE nodes that are 4rd capable (with the = advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). >=20 >> please draw an example of A <---> B communication as i did for = clarification. >=20 > Here is an example scenario: >=20 > v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH = uses RFC6145)=20 > A1 | =20 > :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server > | UDP-lite = UDP-lite > v4Appli-4rdCE --' capable B > A2 =3D> A-B OK >=20 >=20 > yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but = exactly speaking, if the "not support" means passing-it-through without = checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right? A NAT64 that supports UDP Lite MUST update checksum for hosts that have = native IPv6 addresses. That's why A1 =3D> B doesn't work unless the NAT64 recognizes which = packets are those of IPv4 applications in DS hosts. > B --> A is a question mark, if we use the NAT64+ which does nothing = with the L4 checksum, it is also not a problem. > however, if we use, as you mentioned before, an UDP-Lite-aware update = of RFC6146, that may updates the checksum while the BIH doesn't know = that.=20 Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to = support more protocols than the two required by the RFC. It is just an = extension which cannot break anything (backward compatible). >=20 > my point here is: what is the use case with the details of addressing? = if and only if A1 or A2 is configured with an RFC6052 or a MAP or a = 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address = to serve B for the communications, A1 BIH or A2 CE may do the stateless = processing successfuly. if NAT64+ hasn't such a address pool for B, = things will fail because only one among src and dst is checksum-neutral.=20= Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address = reaches the NAT64+ at this IPv6 address: +-------------------------------+---+---+-------------+------+ | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | +-------------------------------+---+---+-------------+------+ : 64 : 8 : 8 : 32 : 16 : In the reverse direction, and for the same IPv4 address, it is the same = IPv6 address that must be synthesized by the NAT64+. This is I suppose implicit, but it can advantageously be made explicit = in the draft. Thanks. >> Because 4rd IPv6 addresses of CEs are distinguishable from all other = IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY = for addresses that actually are 4rd CE addresses. >> =20 >> =20 >> we need to make sure if the NAT64s make both src and dst addresses = checksum-neutral. >=20 > Correct, iff the host address has the V octet. >=20 > 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE = addresses from others.=20 True, but while testing the V octet is sufficient in 4rd, the NAT64 has = in MAP to process mapping rules to find for null subnet IDs whose = lengths depend on which mapping rule applies. That's IMHO one instance where the V-octet potential is clear. > 2. even with the V-octet, do you mean B's IPv4 address also translated = (by the NAT64+) to a CNP-and-V-containing IPv6 address?=20 Yes (see above). > if 2 is true, why you use stateful NAT64+ here for B rather than a = stateless one? Because we consider hosts that are not assigned any public IPv4 address, = even shared. > if 2 is not true, then the NAT64 can use any arbitrary IPv6 address = for B's communications, and such a case results only A's mapped address = is checksum-neutral, and thus anyway L4 adjustment is needed.=20 >=20 > if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, = because NAT64 doesn't have the limitation on the IPv6 address pool in = use.=20 Suggestion not retained ;-). What you call the IPv6 address pool isn't a reserved pool: as explained = above, NAT64+ synthesizes its IPv6 source addresses using its unchanged = /64 prefix.=20 > 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is = NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit = this for the time being).=20 Right. RD >=20 > - maoke=20 > =20 >=20 >> i cannot imagine what the use case is. please specify! >=20 > Hope the picture above helps. >=20 > RD >=20 >=20 >=20 >> =20 >> - maoke >> =20 >> =20 >>=20 >> RD=20 >>=20 >>=20 >>> - maoke=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>=20 >>> > Maoke, >>> > >>> > Thanks for this question. >>> > This subject being new, I take it on a new thread. >>> > >>> > 2012-03-15 10:38, Maoke: >>> > ... >>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>> > >>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >>> > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs >>> > These CEs need not being dependent on which NAT64 supports which = protocols. >>> > >>> > Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm) >>>=20 >>> Oops. >>> This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >>> Sorry for having hastily added this sentence. >>>=20 >>> RD >>>=20 >>> > >>> > RD >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Softwires mailing list >>> > Softwires@ietf.org >>> > https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-135--734583845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-15 =E0 = 14:47, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 11:45, Maoke a =E9crit :

i = understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address.


in other words, = we cannot limit NAT64 stateful service only serve those IPv6 addresses = with CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
 
 
this = phrase is not understood yet. do you mean using 4rd-IPv6-address format = for stateful translation service? =

Yes (but, &s said, = only for CE nodes that are 4rd capable (with the advantage of better = IPv4 transparency between CEs and NAT64+ than between RFC6145 and = NAT64).

please draw an example of A <---> B = communication as i did for clarification. =

Here is an example = scenario:

v4appli-BIH ----. =3D> A>B NOK (because, = according to RFC6535, BIH uses RFC6145) 
    =  A1         |    =  
                = :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
                |   =              UDP-lite     =                 =  UDP-lite
v4Appli-4rdCE --'         =         capable        =                 =  B
     A2         =  =3D> A-B OK


yes, BIH = uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly = speaking, if the "not support" means passing-it-through without checksum = adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, = right?

A NAT64 that supports = UDP Lite MUST update checksum for hosts that have native IPv6 = addresses.
That's why A1 =3D> B doesn't work unless the = NAT64 recognizes which packets are those of IPv4 applications in DS = hosts.

= B --> A is a question mark, if we use the NAT64+ which does nothing = with the L4 checksum, it is also not a problem. =


however, if we use, as you mentioned before, = an UDP-Lite-aware update of RFC6146, that may updates the checksum while = the BIH doesn't know = that. 

Note that an upgrade = of RFC6146 isn't needed for A NAT64 (and NAT64+) to support more = protocols than the two required by the RFC. It is just an extension = which cannot break anything (backward compatible).


my point here is: what is the use case with the = details of addressing? if and only if A1 or A2 is configured with an = RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of = checksum-neutral IPv6 address to serve B for the communications, A1 BIH = or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't = such a address pool for B, things will fail because only one among src = and dst is = checksum-neutral. 

Sec = 4.4 (8) says that a CE that targets an off-domain IPv4 address reaches = the NAT64+ at this IPv6 = address:

+-------------------------------+--= -+---+-------------+------+
|      NAT64+ IPv6 = prefix       |"u"| 0 |DST IPv4 add.|  CNP = |
+-------------------------------+---+---+-------------+------+=
:               64   =            : 8 : 8 :     =  32     :  16 =  :

In the reverse direction, = and for the same IPv4 address, it is the same IPv6 address = that must be synthesized by the NAT64+.
This is I suppose = implicit, but it can advantageously be made explicit in the = draft.
Thanks.


Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE = addresses.
 
 
we need to make sure if the NAT64s = make both src and dst addresses = checksum-neutral.
Correct, iff the host address = has the V octet.

1. without = the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from = others. 

True, but = while testing the V octet is sufficient in 4rd, the NAT64 has in MAP to = process mapping rules to find for null subnet IDs whose lengths depend = on which mapping rule applies.
That's IMHO one instance where = the V-octet potential is clear.


2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 = address? 

Yes (see = above).

if 2 is true, why you use stateful NAT64+ = here for B rather than a stateless one? =

Because we consider hosts that = are not assigned any public IPv4 address, even = shared.

if 2 is not true, then the NAT64 can use any = arbitrary IPv6 address for B's communications, and such a case results = only A's mapped address is checksum-neutral, and thus anyway L4 = adjustment is needed. 

if 2 is true, i do suggest you naming NAT64+ as = NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 = address pool in = use. 

Suggestion not = retained ;-).
What you call the IPv6 address pool isn't a = reserved pool: as explained above, NAT64+ synthesizes its IPv6 source = addresses using its unchanged /64 = prefix. 


3. RFC6535 states, explicitly, "Use of BIH = together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above = technical discussion can omit this for the time = being). 

Right.

RD



=


- maoke 
 

i cannot imagine what the use case is. = please specify!

Hope = the picture above helps.

RD



 
- = maoke
 
 

RD 


- maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires







= --Apple-Mail-135--734583845-- From despres.remi@laposte.net Fri Mar 16 08:21:01 2012 Return-Path: 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 D641B21F8690 for ; Fri, 16 Mar 2012 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oOcQWjna2NaD for ; Fri, 16 Mar 2012 08:21:00 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2120821F863E for ; Fri, 16 Mar 2012 08:20:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id mFLu1i00J37Y3f403FLuT0; Fri, 16 Mar 2012 16:20:55 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-136--730747840 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 16 Mar 2012 16:20:53 +0100 Message-Id: <5EA4481B-E04A-496C-B335-076689EC203D@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <4C115973-974D-4D56-9420-47598D5D60DA@laposte.net> <21E5307F-2363-4D5E-BFFC-2D6227CF51F2@laposte.net> <8513C911-64AD-4F51-B4E3-7BFE7145DEA2@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:21:02 -0000 --Apple-Mail-136--730747840 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Please see inline. Le 2012-03-16 =E0 11:34, Maoke a =E9crit : > 2012/3/16 R=E9mi Despr=E9s > Maoke, >=20 > In a forthcoming answer to another of you emails, on thread "4rd-u = tunnels and stateful NAT64s", I will try to describe more completely = what the latest 4rd brings in the stateful NAT64 context. >=20 >=20 > Le 2012-03-16 =E0 01:27, Maoke a =E9crit : >> 2012/3/15 R=E9mi Despr=E9s >> Le 2012-03-15 =E0 14:52, Maoke a =E9crit : >>> 2012/3/15 R=E9mi Despr=E9s > ... >>>=20 >>> Just referring to: >>>=20 >>> DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet > (Typo corrected, as indicated in another email) >=20 >>> =20 >>> =20 >>> what is RFC6145-host?? >>=20 >> E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that = supports IPv4 applications and is attached to an IPv6-only network. >>=20 >> then inside the host, there a RFC6145 module, right? >=20 > Right: > - RFC6535 says: > "When BIH is implemented at the network layer, the IPv4 packets are = intercepted and converted to IPv6 using the IP conversion mechanism = defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. >=20 > no different understanding here.=20 > =20 > - The v6ops draft on 464XLAT says that it combines "existing and = well-known stateful protocol translation RFC 6146 in the core and = stateless protocol translation RFC 6145 at the edge".=20 >=20 >=20 > well, a new topic. i don't think you plan to apply CNP into = v6ops-464xlat /96 address format. do you? I don't plan to propose modifications of the informational draft on = 464XLAT discussed in v6ops. What I propose is entirely in 4rd-u draft-05. - The goal is to better treat the 464XLAT *use case* that with its = current protocol specification, exploiting for this what had been = initially designed in the context of stateless solutions. - This use case is AFAIK characterized by DS nodes (hosts and/or = routers) attached to an IPv6-only network in which they have no = statelessly assigned IPv4 addresses.=20 >> my point is, if there is no NAT64 module, this cannot talk with = another NAT64 box elsewhere as only one of the (src,dst)-pair is = stateless IPv4-converted IPv6 address. >=20 > In my understanding, this discussion is about *stateful* NAT64s (those = that work for hosts having no assigned public IPv4 address). > There is then no "stateless IPv4-converted IPv6 address" in this = context. >=20 > ok. then in BIH case, no case of stateless translator talking with = stateful NAT64. cleared.=20 > =20 >=20 >> my previous analysis doesn't matter whether the translator and the = end host are separated or integrated into one box. >=20 > Not sure to understand the point (which translator, and why = separated?).=20 > Yet, I think there is no problem here. >=20 > RFC6535 on BIH says: > "The IETF recommends using solutions based on dual stack or tunneling = for IPv6 transition and specifically recommends against deployments = utilizing double protocol translation." >=20 > i remember people has clarified this. but my question is: do you mean = 4rd tunneling is a sort of the recommended tunneling? but the other = message of you said 4rd tunnel is not of "any" tunnel. With 4rd tunnels between CE nodes and NAT64+, IPv4 applications in DS = nodes can access IPv4-only servers without using twice RFC5145. (RFC6145 = is actually not used at all, thus ensuring better IPv4 transparency.) > This is why it is AFAIK useful, in BIH- and/or 464XLAT-capable hosts, = to add support of 4rd NAT64+ mapping rules.=20 > Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd = tunneling), DS hosts having no public IPv4 address can reach IPv4 = servers without any RFC6145 translation (avoiding transparency = limitations) >=20 > actually i must say "NAT64+ mapping rule" is a very confusing concept. = may i understand it is a rule that, when the stateful translation is = performed, the translator using an (IPv4 addr, CNP) combination for the = IID for an IPv4 remote peer out of the domain? The draft defines the NAT64+ mapping rule as that which applies to IPv4 = addresses reachable via a NAT64+. It also says that its Rule IPv4 prefix is /0, that its EA-bits length is = 32, and that it is used by CEs that are assigned no public IPv4 address = (and that are in a Domains having a NAT64+). > may i ask you for a detailed example on how this NAT64+ address is = used, with specifying a pair of source and destination addresses, and = explaining how such a scenario happens. When you have seen further explanations I just gave on the specific = thread on NAT64+, we will see what you still find unclear. Regards, RD > =20 > =20 >=20 > In the answer I will send on on the other thread, I plan to restate = this, and explain in more details.=20 > If you agree, we could limit this discussion to the other thread.=20 >=20 > Regards, > RD >=20 >=20 > =20 >=20 >=20 >> =20 >>=20 >> - maoke >> =20 >> Clear enough? >>=20 >>> (seeing you have corrected the v4net with v6net) if it is a host = connected to an IPv6 network, it is the case of single NAT64, where we = have the problem of "interwork"? >>=20 >> See above. >>=20 >> RD >>=20 >>=20 >>> =20 >>> - maoke >>> =20 >>> =20 >>>=20 >>> Is this excluded? >>>=20 >>> RD >>>=20 >>>=20 >>>>=20 >>>> you mean the stateful NAT64-ed IPv4 host (let's call it A) having = access to an IPv4 host (let's call it B) behind a stateless RFC6145 = translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if = so, it is not right that RFC6145 complying node can talk to a NAT64. = let's see the details: =20 >>>>=20 >>>> model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- = RFC6145 translator --- B=20 >>>>=20 >>>> because A would be translated by NAT64 to an arbitrary IPv6 = address, A', which is not an IPv4-converted one either in MAP or in = RFC6052, the RFC6145 translator cannot handle it statelessly for any = end-to-end communication. the box in front of B should be another NAT64, = and as i said previously, no problem in interwork. if one NAT64 supports = DCCP, it adjusts the checksum; if the other doesn't support, it drops = DCCP. no case of asymmetrically processed but end-to-end deliverable = DCCP here.=20 >>>>=20 >>>> - maoke=20 >>>> =20 >>>> (A NAT64 talking to another NAT64 was part of what I wrote!!!) >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>> =20 >>>>> on the other hand, i cannot understand how the CNP helps stateful = checksum validity. may you please to clarify?=20 >>>>>=20 >>>>> maoke >>>>> =20 >>>>>=20 >>>>> RD >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> - maoke >>>>>> =20 >>>>>> If we agree, I have nothing else on this point. >>>>>>=20 >>>>>> Regards, >>>>>> RD >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> If, as you suggest,=20 >>>>>> 2012-03-15 02:04, Maoke: >>>>>>=20 >>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>>>=20 >>>>>>> Le 2012-03-14 =E0 10:46, Maoke a =E9crit : >>>>>>>>=20 >>>>>>>> 2012/3/14 R=E9mi Despr=E9s >>>>>> ... >>>>>>>> =20 >>>>>>>> Changing DCCP support from optional to mandatory in RFC6145 = isn't backward compatible (an upgraded node isn't guaranteed to = interwork with a non upgraded node). >>>>>>>>=20 >>>>>>>> the CE/BR specified RFC6145-compliant might be a problem but = MAP-T is still in development. if we state to enforce DCCP mandatorily = rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the = backward compatible problem. to this extend, MAP-T is at the same = kick-off line of the 4rd-U.=20 >>>>>>>=20 >>>>>>> 1. I agree that, between CEs and BRs, there can be no problem = for DCCP (provided the draft is completed to this effect). The = comparison table was explicitly made with existing drafts, and intended = to be updatable.=20 >>>>>>>=20 >>>>>>> 2. The MAP-T draft is also claimed to allow "communication = between IPv4-only, as well as any IPv6 enabled end hosts, to native = IPv6-only servers in the domain that are using IPv4-mapped IPv6 = address". In this case, AFAIK, the backward compatibility problem exists = =20 >>>>>>> Thought?=20 >>>>>>>=20 >>>>>>> surely it does not exist. that statement applies to the = MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single = translator or as an native IPv6 router. same deployment of equipments = should support double-translation, single-translation, and native IPv6 = accesses simultanenously. that's one of the points of the MAP-T.=20 >>>>>>>=20 >>>>>>> - maoke >>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> To be even more precise, H6 of the comparison table can be: >>>>>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place" >>>>>>>>=20 >>>>>>>> i actually think the original text is fine. "For .... shared = IPv4 addresses" is not needed for 4rd-U, to my understanding, nor needed = to MAP-T. >>>>>>>=20 >>>>>>> Will see what to do, then, when changes to the MAP-T draft = concerning DCCP are known.=20 >>>>>>>=20 >>>>>>> RD >>>>>>>=20 >>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> maoke=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Does this cover the point? >>>>>>>>=20 >>>>>>>> RD >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ;-) >>>>>>>>> maoke=20 >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> but this is not my point. my point is: there must be = something we don't know ("non omnia possumus omnes"). even we have gone = through the RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well. >>>>>>>>>=20 >>>>>>>>>> i somehow am hard to accept words like "far fetched = theoretical problem".=20 >>>>>>>>>=20 >>>>>>>>> If I had thought it might be so, I would have avoided the = word. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> the L4-recalculate is a generic, architectural solution, = surely needing codes for every L4 protocol. but this generality in = architecture makes RFC6145 or MAP-T equipment be easily enhanced to = support anything new with the same logic. but for the 4rd-U BR, it looks = to me we cannot have the unified logic for all (even limited to existing = and well-known) L4 protocols.=20 >>>>>>>>>>=20 >>>>>>>>>> only my 2 cents.=20 >>>>>>>>>=20 >>>>>>>>> With amendments above, the point is AFAIK completely covered: = everything is rigorously true, and worth noting. >>>>>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>>>>>=20 >>>>>>>>> RD=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Softwires mailing list >>>>>>> Softwires@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-136--730747840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Maoke,

In a = forthcoming answer to another of you emails, on thread "4rd-u tunnels = and stateful NAT64s", I will try to describe more completely what the = latest 4rd brings in the stateful NAT64 context.


Le 2012-03-16 =E0 01:27, Maoke a =E9crit= :
2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>
Le 2012-03-15 =E0 14:52, = Maoke a =E9crit :
2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...

Just referring = to:

DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 = Internet
(Typo corrected, as indicated in = another email)

 
&n= bsp;
what is RFC6145-host?? =

E.g. a host = with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 = applications and is attached to an IPv6-only network.

then inside the host, there = a RFC6145 module, right? =

Right:
- = RFC6535 says:
"When BIH is implemented at the network layer, = the IPv4 packets are intercepted and converted to IPv6 using the IP = conversion mechanism defined in the Stateless IP/ICMP Translation = Algorithm (SIIT) [RFC6145].

no different = understanding here. 
 
- The v6ops draft on 464XLAT says that it combines = "existing and well-known stateful protocol translation RFC 6146 in the = core and stateless protocol translation RFC 6145 at the = edge". 
=


we= ll, a new topic. i don't think you plan to apply CNP into v6ops-464xlat = /96 address format. do = you?

I don't plan to propose = modifications of the informational draft on 464XLAT discussed in = v6ops.

What I propose is entirely in 4rd-u = draft-05.
- The goal is to better treat the 464XLAT *use = case* that with its current protocol specification, exploiting for this = what had been initially designed in the context of stateless = solutions.
- This use case is AFAIK characterized by DS nodes = (hosts and/or routers) attached to an IPv6-only network in which = they have no statelessly assigned IPv4 = addresses. 


my point is, if there is = no NAT64 module, this cannot talk with another NAT64 box elsewhere as = only one of the (src,dst)-pair is stateless IPv4-converted IPv6 = address.

In my understanding, this = discussion is about *stateful* NAT64s (those that work for hosts having = no assigned public IPv4 address).
There is then no "stateless = IPv4-converted IPv6 address" in this context.

ok. then in BIH case, no = case of stateless translator talking with stateful NAT64. = cleared. 
 

my previous analysis doesn't matter whether = the translator and the end host are separated or integrated into one = box.

Not sure to understand the = point (which translator, and why = separated?). 
Yet, I think there is = no problem here.

RFC6535 on BIH = says:
"The IETF recommends using solutions based on dual stack = or tunneling for IPv6 transition and specifically recommends against = deployments utilizing double protocol translation."

i remember people has = clarified this. but my question is: do you mean 4rd tunneling is a sort = of the recommended tunneling? but the other message of you said 4rd = tunnel is not of "any" = tunnel.

With 4rd tunnels = between CE nodes and NAT64+, IPv4 applications in DS nodes can access = IPv4-only servers without using twice RFC5145. (RFC6145 is actually not = used at all, thus ensuring better IPv4 = transparency.)


This is why it is AFAIK = useful, in BIH- and/or 464XLAT-capable hosts, to add support of 4rd = NAT64+ mapping rules. 
Benefit is that, with upgraded NAT64s (NAT64+ supporting = 4rd tunneling), DS hosts having no public IPv4 address  can reach = IPv4 servers without any RFC6145 translation (avoiding transparency = limitations)

actually i must say "NAT64+ = mapping rule" is a very confusing concept. may i understand it is a rule = that, when the stateful translation is performed, the translator using = an (IPv4 addr, CNP) combination for the IID for an IPv4 remote peer out = of the domain?

The draft = defines the NAT64+ mapping rule as that which applies to IPv4 = addresses reachable via a NAT64+.
It also says that its = Rule IPv4 prefix is /0, that its EA-bits length is 32, and that it is = used by CEs that are assigned no public IPv4 address (and that are = in a Domains having a NAT64+).

may i ask you for a detailed example on how = this NAT64+ address is used, with specifying a pair of source and = destination addresses, and explaining how such a scenario = happens.

When you have seen = further explanations I just gave on the specific thread = on NAT64+, we will see what you still find = unclear.

Regards,
RD



 
 

In the = answer I will send on on the other thread, I plan to restate this, and = explain in more details. 
If you agree, we could limit this discussion to the other = thread. 

Regards,
RD


 


 

- maoke
 
Clear enough?

(seeing = you have corrected the v4net with v6net) if it is a host connected to an = IPv6 network, it is the case of single NAT64, where we have the problem = of "interwork"?

See = above.

RD


 
- maoke
 
 

Is this = excluded?

RD



you mean the stateful NAT64-ed IPv4 host (let's call it = A) having access to an IPv4 host (let's call it B) behind a stateless = RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 = domain. if so, it is not right that RFC6145 complying node can talk to a = NAT64. let's see the details:  

model: A ---(IPv4 network)--- NAT64 (stateful) = ---(IPv6 cloud)--- RFC6145 translator --- = B 

because A would be translated by NAT64 = to an arbitrary IPv6 address, A', which is not an IPv4-converted one = either in MAP or in RFC6052, the RFC6145 translator cannot handle it = statelessly for any end-to-end communication. the box in front of B = should be another NAT64, and as i said previously, no problem in = interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the = other doesn't support, it drops DCCP. no case of asymmetrically = processed but end-to-end deliverable DCCP here. 

- maoke 
 
(A NAT64 talking to another NAT64 was part of what I = wrote!!!)

RD



 
on the other hand, i cannot understand how = the CNP helps stateful checksum validity. may you please to = clarify? 

maoke
 

RD



- = maoke
 
If we agree, I have nothing = else on this point.
=

Regards,
RD



If, as you suggest, 
2012-03-15 = 02:04, Maoke:

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-14 =E0 = 10:46, Maoke a =E9crit :

2012/3/14 R=E9mi Despr=E9s <despres.remi@laposte.net>
=
...
  
Chang= ing DCCP support from optional to mandatory in RFC6145 isn't backward = compatible (an upgraded node isn't guaranteed to interwork with a non = upgraded node).

the CE/BR specified = RFC6145-compliant might be a problem but MAP-T is still in development. = if we state to enforce DCCP mandatorily rather than optional in MAP-T, a = MAP-T-compliant CE/BR won't has the backward compatible problem. to this = extend, MAP-T is at the same kick-off line of the 4rd-U. 

1. I agree = that, between CEs and BRs, there can be no problem for DCCP = (provided the draft is completed to this effect). The comparison table = was explicitly made with existing drafts, and intended to be = updatable. 

2. The MAP-T draft is = also claimed to allow "communication between IPv4-only, as well as any = IPv6 = enabled end hosts, to native IPv6-only servers in the domain that = are = using IPv4-mapped IPv6 address". In this = case, AFAIK, the backward = compatibility problem exists  
Thought? =

surely it does = not exist. that statement applies to the MAP-T-compliant equipments, = when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 = router. same deployment of equipments should support double-translation, = single-translation, and native IPv6 accesses simultanenously. that's one = of the points of the MAP-T. 

- maoke
 


To be even more precise, H6 of the comparison table can = be:
"For ISPs that don't provide all CE nodes, and for shared IPv4 = addresses, DCCP and UDP-Lite are supported, as well as future protocols = using the TCP checksum algorithm and ports at the same place"

i actually think the = original text is fine. "For .... shared IPv4 addresses" is not needed = for 4rd-U, to my understanding, nor needed to = MAP-T.

Will see what to do, then, when changes to the = MAP-T draft concerning DCCP are = known. 

RD


 

maoke 
 

Does this cover the point?

RD


=


=

;-)
maoke 
 

but this is not my point. my point is: there must be something we = don't know ("non omnia possumus omnes"). even we have gone through the = RFCs, there might be some other proprietary L4 protocols, or = experimental protocols. even they are minority, i don't think ignoring = their existance in our solution fits the spirit of the Internet. it = might be argued that NAT44 doesn't support such L4 protocols now, but an = L4 protocol owner may makes his own NAT44, either attached to the CE or = separated. if 4rd-U respects such an effort, it should state "currently = blahblabla L4 protocols are supported". the similar statement applies to = the RFC6145 or MAP as well.

i somehow am hard to accept words like "far = fetched theoretical = problem". 

If I = had thought it might be so, I would have avoided the word.


the L4-recalculate is a generic, architectural solution, surely = needing codes for every L4 protocol. but this generality in architecture = makes RFC6145 or MAP-T equipment be easily enhanced to support anything = new with the same logic. but for the 4rd-U BR, it looks to me we cannot = have the unified logic for all (even limited to existing and well-known) = L4 protocols. 

only my 2 = cents. 

With = amendments above, the point is AFAIK completely covered: everything is = rigorously true, and worth noting.
Thanks for the useful = reference to the RDP of RFC1151.

RD 


=





=


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


=











= --Apple-Mail-136--730747840-- From sunqi.csnet.thu@gmail.com Sat Mar 17 09:37:04 2012 Return-Path: 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 20DEE21F86A5 for ; Sat, 17 Mar 2012 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 7E2e4h341Fx6 for ; Sat, 17 Mar 2012 09:37:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8721F867C for ; Sat, 17 Mar 2012 09:37:03 -0700 (PDT) Received: by iazz13 with SMTP id z13so8261852iaz.31 for ; Sat, 17 Mar 2012 09:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=8pqnneNPPuK6URDCg+wKnIGzcwi4G3E1uaBtXAvetz8=; b=VbuorR8tprO7Ehw41EWaeRyZttNb3XfhhEw1i1c67XU3b4/skW82qppMshpEXCrfUi jy/INap4bYm16oP2TZTIfrHXguKdXDuxSD8uqrbkVH8sbClbsP7TW5nxCYgGO4rpa4c3 EvpywvRcwAI7ehBjJ0rnsIz0fEa3ze27wxbMO6S7j682i+V/ZxsqnZuZpobyJrpO2DFa b31Lb5K3mj35lzdHHvzL+EgUDqJB7myAQRMkcyyPv6ofrHiXl7zf9Y1Xo+OQJ5dPYYjq nuorP90BqCCHZ8BVBWRL41FovHsCMtguQQEwn7vP0/G0G+cCHxlocEzagk+ZyoxnFRIc i+ig== Received: by 10.50.182.168 with SMTP id ef8mr2275275igc.15.1332002222979; Sat, 17 Mar 2012 09:37:02 -0700 (PDT) Received: from sunqi ([59.64.255.54]) by mx.google.com with ESMTPS id hq3sm7967762igc.0.2012.03.17.09.36.59 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 09:37:02 -0700 (PDT) Date: Sun, 18 Mar 2012 00:36:52 +0800 From: "Qi Sun" To: "mohamed.boucadair@orange.com" , "draft-penno-softwire-sdnat@tools.ietf.org" References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> X-Priority: 3 X-GUID: C416832D-DDFF-45B4-94E8-4784354E39EE X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <201203180036521383506@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart100055678123_=----" Cc: softwires WG Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 16:37:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart100055678123_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTWVkLA0KDQogICAgICBJIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQtcGVubm8tKiBhbmQgSU1I TyBpdCBpcyByZWFzb25hYmxlIGluIHRoZSB2aWV3IG9mIGRlcGxveW1lbnQuICBCeSBjb25maWd1 cmluZyB0aGUgcHJvZmlsZSAoaS5lLiB0aGUgcGVyLXN1YnNjcmliZXIgbWFwcGluZyB0YWJsZSkg aW4gdGhlIEFGVFJzLCB0aGUgU1BzIGNhbiBhY2hpZXZlIGFuIGV4cGxpY2l0IGJpbmRpbmcgYmV0 d2VlbiB0aGUgSVB2NCBhZGRyZXNzICsgcG9ydC1zZXQgYW5kIHRoZSBjdXN0b21lci4gVGhpcyBj YW4gbWVhbiB0aGUgY3VzdG9tZXIgcGF5IGZvciB0aGUgb3duZXJzaGlwIG9mIHRoZSBJUHY0IGFk ZHJlc3MgKyBwb3J0LXNldC4gSXQgaXMgZWFzeSB0byBhc3NvY2lhdGUgYWRkcmVzcyhwb3J0LXNl dCkgYXNzaWdubWVudCB3aXRoIGF1dGhlbnRpY2F0aW9uLg0KDQogICAgDQpCZXN0IFJlZ2FyZHMN Cg0KDQoNCg0KUWkgU3Vu ------=_001_NextPart100055678123_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Med,
 
      I read through the= =20 draft-penno-* and IMHO it is reasonable in the view of deployment.  B= y=20 configuring the profile (i.e. the per-subscriber mapping table) in the AFT= Rs,=20 the SPs can achieve an explicit binding between the IPv4 address + port-se= t and=20 the customer. This can mean the customer pay for the ownership of the IPv4= =20 address + port-set. It is easy to associate address(port-set) assignment w= ith=20 authentication.
 
    
Best Regards
 
Qi Sun
 
------=_001_NextPart100055678123_=------ From sunqi.csnet.thu@gmail.com Sat Mar 17 09:44:36 2012 Return-Path: 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 1E58B21F865C for ; Sat, 17 Mar 2012 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qQ-vlQ7Yy07h for ; Sat, 17 Mar 2012 09:44:35 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9920B21F8598 for ; Sat, 17 Mar 2012 09:44:28 -0700 (PDT) Received: by dakl33 with SMTP id l33so8694921dak.31 for ; Sat, 17 Mar 2012 09:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MSqMc9hq2YnVJoEjIukk2mNoffm+Ap5asv/BmJnvmZI=; b=xdTLLno4ndwBt1PidD9a0YQefIeZmzD+GUGBwsS/LEMo+jG65HmzCdNobBRtUCo0eo GtnSpwNCIJlCbAZSU05hMz0DWFA9DnFS3rywJxl0AFi/tqmwddzhD2DTME0uxrRpWE6/ cBXe7RCw3es1P9cbwtsWxdFsEjzDUlrWyjCH5da03oLBsQmsnAh2zUZ9J2xZfVWnYwJ3 Mx2QV7mH0zciHWeWbQUiKRkVAYsPoPLHrIGyNUPMYGvtdr4/CXTqDBRTYO9+tD/27Qul 55SCO3IkR5I1hy6DjaQ7tsm6+zg5ngPi8aEBvSflkG32fhuzSEdhpu++TRHdESjD7dse sHTg== MIME-Version: 1.0 Received: by 10.68.74.197 with SMTP id w5mr24897925pbv.129.1332002668396; Sat, 17 Mar 2012 09:44:28 -0700 (PDT) Received: by 10.143.63.10 with HTTP; Sat, 17 Mar 2012 09:44:28 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 18 Mar 2012 00:44:28 +0800 Message-ID: From: Qi Sun To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d040fa1e8e3bf8104bb730950 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 16:44:36 -0000 --f46d040fa1e8e3bf8104bb730950 Content-Type: text/plain; charset=ISO-8859-1 Hi Med, I've read through the draft-penno-* and IMHO it is reasonable in the view of deployment. By configuring the profile (i.e. the per-subscriber mapping table) in the AFTRs, the SPs can achieve an explicit binding between the IPv4 address + port-set and the customer. This can mean the customer pay for the ownership of the IPv4 address + port-set. It is easy to associate address(port-set) assignment with authentication. Best Regards! Qi Sun > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --f46d040fa1e8e3bf8104bb730950 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med,

=A0 =A0 =A0 I've read=A0through=A0the=A0draf= t-penno-*=A0and=A0IMHO=A0it=A0is=A0reasonable=A0in=A0the=A0view=A0of=A0depl= oyment.=A0=A0By=A0configuring=A0the=A0profile=A0(i.e.=A0the=A0per-subscribe= r=A0mapping=A0table)=A0in=A0the=A0AFTRs,=A0the=A0SPs=A0can=A0achieve=A0an= =A0explicit=A0binding=A0between=A0the=A0IPv4=A0address=A0+=A0port-set=A0and= =A0the=A0customer.=A0This=A0can=A0mean=A0the=A0customer=A0pay=A0for=A0the= =A0ownership=A0of=A0the=A0IPv4=A0address=A0+=A0port-set.=A0It=A0is=A0easy= =A0to=A0associate=A0address(port-set)=A0assignment=A0with=A0authentication.=

Best Regards!

Qi Sun
=

=A0
=A0

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--f46d040fa1e8e3bf8104bb730950-- From sunqi.csnet.thu@gmail.com Sat Mar 17 20:51:23 2012 Return-Path: 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 7A5CA21F852B for ; Sat, 17 Mar 2012 20:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 Kzz-a5R7xuju for ; Sat, 17 Mar 2012 20:51:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10821F8527 for ; Sat, 17 Mar 2012 20:51:22 -0700 (PDT) Received: by iazz13 with SMTP id z13so8949778iaz.31 for ; Sat, 17 Mar 2012 20:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=zWxAeBH02A4WZTHsB0l43pY/57pQ0Q6y7JK4KFk/UtU=; b=XTrmiTcGUJ1Dx8g69t744uIUWcLjyD5XZ9V4qDtxd931sXaieFynm0KZkUvU+Agae4 LVC1dJ4lCFyw+jLs58yaOEMssQIMEsORpSqjUgFWTA0PXwOvEC4KfbEpV2Gc3KIsjWqg oamQQZHJ3i3huDrdcn71VHBiCDXoHpa16MzPmaQQloCQDC9hbp5xzf/2Un8KBK5WRkZ9 uODQY7kOJvf5he3da2NX/7Llxd62+MXZX1Cr9nv6p/dhWTu0xYQFGY/vOO4CH7XtYojJ 8B7kQSMclzkCkAeVu1dV6p4xKHBGm3tOGGyuRhS1KAYk+2d3srsmqFjWmqfVA3+YR4aG OZQA== Received: by 10.42.166.135 with SMTP id o7mr2647935icy.53.1332042682018; Sat, 17 Mar 2012 20:51:22 -0700 (PDT) Received: from sunqi ([59.64.255.54]) by mx.google.com with ESMTPS id b11sm4556494igq.7.2012.03.17.20.51.18 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 20:51:20 -0700 (PDT) Date: Sun, 18 Mar 2012 11:51:16 +0800 From: "Qi Sun" To: "Francis Dupont" References: <201203141244.q2ECiBDo062533@givry.fdupont.fr> X-Priority: 3 X-GUID: 2801E067-18F6-42AE-9A08-B4F3F8180E14 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012031811511648403448@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart888488822538_=----" Cc: softwires WG Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 03:51:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart888488822538_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmNpcywNCiAgICAgUGxlYXNlIHNlZSBpbmxpbmUsIGFuZCBzb3JyeSBpZiB0aGV5J3Zl IGJlZW4gZGlzY3Vzc2VkIGV2ZXIgOikNCg0KICAgICBMb29raW5nIGZvcndhcmQgdG8gdXIgcmVw bHl+DQoNCkJlc3QgUmVnYXJkcyAhDQoNCg0KDQoNClFpIFN1bg0KDQpGcm9tOiBGcmFuY2lzIER1 cG9udA0KRGF0ZTogMjAxMi0wMy0xNCAyMDo0NA0KVG86IFFpb25nDQpDQzogU29mdHdpcmVzIFdH OyBkcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlOyBkcmFmdC1wZW5uby1z b2Z0d2lyZS1zZG5hdEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIGRy YWZ0LXBlbm5vLXNvZnR3aXJlLXNkbmF0IHZzLiBkcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNs YXRlZC1kcy1saXRlDQogSW4geW91ciBwcmV2aW91cyBtYWlsIHlvdSB3cm90ZToNCg0KPiAgPiAg SW4geW91ciBwcmV2aW91cyBtYWlsIHlvdSB3cm90ZToNCj4gID4NCj4gID4gPiAgICAgICAgKCop IFF1ZXN0aW9uIDE6IEl0IGlzIG5vdCBjbGVhciBpbiB0ZXh0IGlmIHRoZXJlIGlzIGEgc2Vjb25k IE5BVA0KPiAgPiA+ICAgICAgICBpbiB0aGUgQUZUUiBvciBub3QuICBDb3VsZCB5b3UgcGxlYXNl IGNvbmZpcm0vaW5maXJtIGEgc2Vjb25kIE5BVA0KPiAgPiA+ICAgICAgICBpcyBwcmVzZW50Pw0K PiAgPg0KPiAgPiA9PiB0aGVyZSBpcyBvbmUgYnV0Og0KPiAgPiAgLSBpdCB0cmFuc2xhdGVzIG9u bHkgcG9ydCBudW1iZXJzIGZvbGxvd2luZyBhbiBhbGdvcml0aG0NCj4gID4NCj4gID4gIC0gdGhl IE5BVCBpcyBub3Qgc3RyaWN0bHkgcmVxdWlyZWQ6IG9uZSBjYW4gaW1hZ2luZSB0byBhc3NpZ24N Cj4gID4gICBkaXJlY3RseSB0byBhIENQRSBpdHMgcG9ydCByYW5nZSBhcyBpdCBpcyB2aXNpYmxl IGZyb20gdGhlIEludGVybmV0DQo+ICA+ICAgKG5vdGU6IDEtIGl0IHNob3VsZCBiZSBub3Qgd2hh dCB3ZSB3YW50IGFzIGl0IG1ha2VzIENQRXMgdHJpdmlhbA0KPiAgPiAgICB0byB0cmFjaywgMi0g aXQgZG9lc24ndCByZW1vdmUgdGhlIG1hbmRhdG9yeSBjaGVjayBvbiBzb3VyY2UgcG9ydHMNCj4g ID4gICAgaW4gdGhlIGZyb20gQ1BFIHRvIHRoZSBJbnRlcm5ldCB3YXkpDQo+ICA+DQo+ICBbUWlv bmddIFRoYW5rcyBmb3IgY2xhcmlmaWNhdGlvbi4gSXQgc2VlbXMgdGhpcyBpcyBub3QgbWVudGlv bmVkIHdoZW4gdG8NCj4gIGFkb3B0IGFuZCBob3cgdG8gcHJvY2VzcyB0aGUgc2Vjb25kIE5BVCBp biBjdXJyZW50IHZlcnNpb24gb2Ygc2QtbmF0LiBCdXQNCj4gIHN0aWxsLCBJIHdvdWxkIHByZWZl ciBhIHNvbHV0aW9uIHdpdGhvdXQgZG91YmxlLU5BVC4NCg0KPT4gbXkgYW5zd2VyIGlzIHNpbXBs ZToNCiAxLSBpdCBpcyB0ZWNobmljYWxseSBwb3NzaWJsZSBidXQgSU1ITyBzaG91bGQgbm90IGJl IGRlcGxveWVkIGluIHRoZSByZWFsDQogIHdvcmxkLg0KDQpbUWldIEkgZmFpbGVkIHRvIGNhdGNo IHlvdXIgaWRlYS4gSU1ITyB0aGUgTkFUIGluIHRoZSBwb3J0LXJlc3RyaWN0ZWQgQ1BFIHNob3Vs ZCBmaWx0ZXIgdGhlIA0KcGFja2V0cyBvZiB3aGljaCB0aGUgcG9ydCBudW1iZXIgaXMgb3V0IG9m IHRoZSBhc3NpZ25lZCByYW5nZS4gQW5kIHN1Y2ggcGFja2V0cyBpcyBvayB0byANCmJlIGRpc2Nh cmRlZCBieSB0aGUgQ1BFLiBTbyB3aWxsIHlvdSBwbGVhc2UgZ2l2ZSBzb21lIGRlc2NyaXB0aW9u cyBvbiB0aGlzIHBvaW50Pw0KDQogMi0gb25lIGNhbiBhdm9pZCBvbmx5IHRoZSBzZWNvbmQgTkFU IGl0c2VsZiwgbm90IHRoZSBwYWNrZXQgcmVhc3NlbWJseSBmb3INCiAgaW5zdGFuY2UuDQogMy0g dGhlIHNlY29uZCBOQVQgaXMgYSBwcmV0dHkgc2ltcGxlIG9uZSBhbmQgaXMgc3RhdGVsZXNzIChp LmUuLCB5b3UgY2FuIGRyb3ANCiAgdGhlIENHTiBib3ggYW5kIGhvdHBsdWcgYSByZXBsYWNlbWVu dCBib3ggd2l0aCB0aGUgc2FtZSBjb25maWc6IGN1c3RvbWVycw0KICBzaG91bGQgc2VlIG9ubHkg dGhlIHBhY2tldHMgZHJvcHBlZCBkdXJpbmcgdGhlIG9wZXJhdGlvbi4gQlRXIHdlIGhhdmUgYQ0K ICBwbGFuIHRvIHNob3cgdGhpcyBhdCB0aGUgbmV4dCBJRVRGIG1lZXRpbmcpLg0KDQo+ICA+ID0+ IGJ1dCB0aGUgSUNNUC1iYXNlZCBzb2x1dGlvbiBpcyBkZWVwbHkgYnJva2VuIHNvIGlzIGl0IGEg cmVhbA0KPiAgPiBhZHZhbnRhZ2U/DQo+ICA+DQo+ICBbUWlvbmddIEluIGRyYWZ0LWN1aS1zb2Z0 d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUsIHdlIGhhdmUgZGVzY3JpYmVkIHRoZQ0KPiAgIklD TVAgcHJvY2Vzc2luZyIgaW4gc2VjdGlvbiAxMC4gQW5kIHdlIGhhdmUgdmVyaWZpZWQgdGhhdCBp dCB3b3JrcyBmaW5lIGluDQo+ICBhbGwgSUNNUC1iYXNlZCBwcm90b2NvbHMsIGUuZy4gcGluZywg dHJhY2VydCwgZXRjLiBUaGVyZSBpcyBubyBwcm9ibGVtIGhlcmUuDQoNCj0+IG15IGNvbW1lbnQg d2FzIGFib3V0IHRoZSBJQ01QLWJhc2Ugc29sdXRpb24gZm9yIHRoZSBjb25maWd1cmF0aW9uIGlu DQpSZWluYWxkbyBQZW5ubydzIEktRC4gT2YgY291cnNlIEkgaGF2ZSBubyBjb25jZXJuIGFib3V0 IHJhaXNpbmcgYWRtaW4gcHJvaGliDQpJQ01QcyB3aGVuIGEgcG9ydCBvdXQtb2YtcmFuZ2UgcGFj a2V0IGlzIGZpbHRlcmVkIChpbiBmYWN0IGl0IGlzIGEgZ3JlYXQgaWRlYSkuDQpGb3IgdGhlIElD TVAgZWNobyBzZXJ2aWNlIHlvdSBjYW4gbWFwIGl0IHVzaW5nIHRoZSBJRCBhcyB0aGUgKHNvdXJj ZSkgcG9ydCwNCml0IHdvcmtzIHdlbGwgYnV0IGlmIHlvdSdkIGxpa2UgdG8gdXNlIHRoaXMgZnJv bSB0aGUgSW50ZXJuZXQgc2lkZSB5b3UgbmVlZA0KYSBtb2RpZmllZCBwaW5nIHdoZXJlIHlvdSBj YW4gc2V0IHRoZSBJRCB0byB1c2UgKEkgY2FuIHByb3ZpZGUgb25lIGlmIHlvdSB3YW50DQp0byB0 cnk6IElNSE8gaXQgaXMgYmV0dGVyIHRvIGJlIGFibGUgdG8gcGluZyBTRC1DUEVzIGFuZCBub3Qg b25seSB0aGUgU0QtQ0dOKS4NCg0KPiAgPiA+ICAgICAgICAgICBRdWVzdGlvbiA1LTE6IFdoeSAi TVVTVCI/ICBJTUhPLCB0aGlzIGlzIGRlcGxveW1lbnQtc3BlY2lmaWMuDQo+DQo+ICA+ID0+IG5v IHN1Y2ggc3BlY2lmaWM6DQo+ICA+ICAtIGl0IG1ha2VzIHRoZSByZWFzb25hYmxlIGFzc3VtcHRp b24gdGhhbiBJUHY0IGFkZHJlc3NlcyBhcmUgYXNzaWduZWQNCj4gID4gIHVzaW5nIERIQ1B2NA0K PiAgPiAgLSBpdCBzdGF0ZXMgIkRTLUxpdGUiIHNvIHRoZXJlIGlzIG5vIGRpcmVjdCBJUHY0IGF2 YWlsYWJsZQ0KPiAgPiAgLSBzbyBJTUhPIHRoZSBxdWVzdGlvbiBpcyBtb3JlIGFib3V0IHRoZSBE SENQdjQtb3Zlci1JUHY2IGFwcGxpY2F0aW9uDQo+ICA+ICBhbmQgaXMgbW9yZSBmb3IgdGhlIERI QyBXRyAoQlRXIHBsZWFzZSBkb24ndCBib3VuY2UgdGhpcyBpc3N1ZSBiZXR3ZWVuDQo+ICA+ICB0 aGUgdHdvIFdHcywgbXkgaWRlYSBpcyBtb3JlIHRvIG1ha2UgYSBwb2ludCBhYm91dCBESENQdjQt b3Zlci1JUHY2DQo+ICA+ICBpdHNlbGYpDQo+ICA+DQo+ICBbUWlvbmddIEkgc3RpbGwgdGhpbmsg aXQgaXMgZGVwbG95bWVudC1zcGVjaWZpYy4gRm9yIG9wZXJhdG9ycyB3aG8gcGVyZmVyDQo+ICB0 byBkZXBsb3kgUENQIHNvbHV0aW9uLCBpdCBpcyBuYXR1cmUgZm9yIHRoZW0gdG8gYWRvcHQgUENQ LWJhc2Ugb3INCj4gIFBDUC1leHRlbnNpb24gKHBjcC1uYXRjb29yZCkuIEZvciBvcGVyYXRvcnMg d2hvIHdvdWxkIGxpa2UgdG8gZGVwbG95DQo+ICBESENQdjQtb3Zlci1JUHY2LCBwb3J0LXJhbmdl IGNhbiBiZSBhc3NpZ25lZCBpbiB0aGlzIHdheS4NCg0KPT4gSSBtaXN1bmRlcnN0b29kIHlvdXIg Y29uY2VybjogaW4gZmFjdCB5b3UgcHJlZmVyIHNvbWV0aGluZyB3aGljaCBwcm92aWRlcw0KdGhl IHdob2xlIGNvbmZpZywgbm90IG9ubHkgdGhlIElQdjQgYWRkcmVzcy4gU28gdGhlIGlzc3VlIGlz IG5vdCB0aGUgMi4xIGJ1dA0KdGhlIDIuMSBhbmQgMi4yIChpLmUuLCBESENQdjQgb3ZlciBJUHY2 IGZvciB0aGUgZXh0ZXJuYWwgYWRkcmVzcywgYW5kIElDTVANCmZvciB0aGUgcG9ydCByYW5nZSkg dG9nZXRoZXIsIGFuZCB5b3UgYWxyZWFkeSBrbm93IHdoYXQgSSB0aGluayBhYm91dCAyLjIuDQoN CltRaV0gVXNpbmcgSUNNUCBmb3IgdGhlIHBvcnQgcmFuZ2UgaXMgYSBuZXcgaWRlYSBBRkFJSy4g SG93ZXZlciwgaW4gb3JkZXIgdG8gZ2V0IHRoZSBpbmZvIA0Kb2YgdGhlIG1pbiAmIG1heCBwb3J0 IG51bWJlciwgaXQgaXMgbmVlZGVkIHRvIGxvb2sgdXAgdGhlIHBlci1zdWJzY3JpYmVyIG1hcHBp bmcgdGFibGUNCiB3aGljaCBtYXkgYmUgaHVnZS4gSSd2ZSBubyBpZGVhIGlmIGl0J3Mgb2sgZm9y IHRoZSBJQ01QIHByb2Nlc3MgdG8gZG8gdGhhdC4NCkFuZCBJJ20gdGhpbmtpbmcgd2hldGhlciBp dCdzIG5lY2Vzc2FyeSB0byBtYWtlIGl0IGNsZWFyIGFib3V0IGhvdyB0byBnZXQgdGhlIG1pbiAm IG1heA0KIHBvcnQgbnVtYmVyIGluIHRoZSBkcmFmdC4NCg0KDQo+ICBbUWlvbmddIFNpbmNlIGl0 IGlzIGEgc3RhdGVsZXNzIHNvbHV0aW9uLCBJIGFsc28gcHJlZmVyIHRoZSBHTUEgYWxnb3JpdGht DQo+ICB3aGljaCBoYXMgYmVlbiBkaXNjdXNzZXMgd2lkZWx5IGluIHRoZSBXRy4NCg0KPT4geWVz LCBpdCBoYXMgbWFueSBhZHZhbnRhZ2VzLiBCdXQgdG8gY29tZSBiYWNrIHRvIHRoZSBmaXJzdCBw b2ludCwgaXQgaXMNCmZvciB0aGUgc2Vjb25kIE5BVCAoOi0pIQ0KDQpSZWdhcmRzDQoNCkZyYW5j aXMuRHVwb250QGZkdXBvbnQuZnINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart888488822538_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Francis,
     Please see inline, and sorry if they've been= =20 discussed ever :)
 
     Looking forward to ur reply~
 
Best Regards !
 
Qi Sun
 
Date: 2012-03-14 20:44
To: Qiong
CC: Softwires WG; dr= aft-cui-softwire-b4-translated-ds-lite;=20 draft-penno-soft= wire-sdnat@tools.ietf.org
Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.=20 draft-cui-softwire-b4-translated-ds-lite
 In your previous mail you wrote:
 
>  >  In your previous mail&= nbsp;you wrote:
>  >
>  > >      &nb= sp; (*) Question 1: It is not clear&nbs= p;in text if there is a second NAT
>  > >      &nb= sp; in the AFTR or not.  Could you=  please confirm/infirm a second NAT
>  > >      &nb= sp; is present?
>  >
>  > =3D> there is one bu= t:
>  >  - it translates only&n= bsp;port numbers following an algorithm
>  >
>  >  - the NAT is not&= nbsp;strictly required: one can imagine to a= ssign
>  >   directly to a CP= E its port range as it is visible = from the Internet
>  >   (note: 1- it sho= uld be not what we want as it make= s CPEs trivial
>  >    to track, 2-&nb= sp;it doesn't remove the mandatory check on&= nbsp;source ports
>  >    in the from&nbs= p;CPE to the Internet way)
>  >
>  [Qiong] Thanks for clarification. = ;It seems this is not mentioned when to=
>  adopt and how to process the=  second NAT in current version of sd-na= t. But
>  still, I would prefer a solu= tion without double-NAT.
 
=3D> my answer is simple:
 1- it is technically possible but = ;IMHO should not be deployed in the rea= l
  world.
 
[Qi] I failed to catch your idea. IMHO the NAT in the port-restricted= CPE=20 should filter the
packets of which the port number is out of the assigned range. And su= ch=20 packets is ok to
be discarded by the CPE. So will you please give some descriptions on= this=20 point?
 
 2- one can avoid only the second&= nbsp;NAT itself, not the packet reassembly f= or
  instance.
 3- the second NAT is a pretty&nbs= p;simple one and is stateless (i.e., you&nbs= p;can drop
  the CGN box and hotplug a r= eplacement box with the same config: custome= rs
  should see only the packets drop= ped during the operation. BTW we have a=
  plan to show this at the ne= xt IETF meeting).
 
>  > =3D> but the ICMP-based&n= bsp;solution is deeply broken so is it = a real
>  > advantage?
>  >
>  [Qiong] In draft-cui-softwire-b4-translated= -ds-lite, we have described the
>  "ICMP processing" in section 10.&= nbsp;And we have verified that it works = ;fine in
>  all ICMP-based protocols, e.g. pi= ng, tracert, etc. There is no problem h= ere.
 
=3D> my comment was about the ICMP-b= ase solution for the configuration in
Reinaldo Penno's I-D. Of course I have&= nbsp;no concern about raising admin prohib
ICMPs when a port out-of-range packet i= s filtered (in fact it is a great = idea).
For the ICMP echo service you can = map it using the ID as the (source)&nbs= p;port,
it works well but if you'd like to=  use this from the Internet side you&nb= sp;need
a modified ping where you can set = the ID to use (I can provide one i= f you want
to try: IMHO it is better to be&nb= sp;able to ping SD-CPEs and not only th= e SD-CGN).
 
>  > >      &nb= sp;    Question 5-1: Why "MUST"? &= nbsp;IMHO, this is deployment-specific.
>
>  > =3D> no such specific:
>  >  - it makes the re= asonable assumption than IPv4 addresses are = assigned
>  >  using DHCPv4
>  >  - it states "DS-Lite"&= nbsp;so there is no direct IPv4 available
>  >  - so IMHO the que= stion is more about the DHCPv4-over-IPv6 app= lication
>  >  and is more for t= he DHC WG (BTW please don't bounce this=  issue between
>  >  the two WGs, my i= dea is more to make a point about = DHCPv4-over-IPv6
>  >  itself)
>  >
>  [Qiong] I still think it is&= nbsp;deployment-specific. For operators who perfer
>  to deploy PCP solution, it i= s nature for them to adopt PCP-base or<= /DIV>
>  PCP-extension (pcp-natcoord). For oper= ators who would like to deploy
>  DHCPv4-over-IPv6, port-range can be&nb= sp;assigned in this way.
 
=3D> I misunderstood your concern: in&nbs= p;fact you prefer something which provides
the whole config, not only the IPv4&nbs= p;address. So the issue is not the 2.1&= nbsp;but
the 2.1 and 2.2 (i.e., DHCPv4 over = ;IPv6 for the external address, and ICMP
for the port range) together, and you&n= bsp;already know what I think about 2.2.
 
[Qi] Using ICMP for the port range is a new idea AFAIK. However, in o= rder=20 to get the info
of the min & max port number, it is needed to look up the=20 per-subscriber mapping table
 which may be huge. I've no idea if it's ok for the IC= MP=20 process to do that.
And I'm thinking whether it's necessary to make it clear about how to= get=20 the min & max
 port number in the draft.
 
 
>  [Qiong] Since it is a statel= ess solution, I also prefer the GMA alg= orithm
>  which has been discusses widely&n= bsp;in the WG.
 
=3D> yes, it has many advantages. Bu= t to come back to the first point, = ;it is
for the second NAT (:-)!
 
Regards
 
Francis.Dupont@fdupont.fr
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart888488822538_=------ From sunqi.csnet.thu@gmail.com Sun Mar 18 09:24:07 2012 Return-Path: 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 6601F21F8547 for ; Sun, 18 Mar 2012 09:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 ON-a5LRRUuGy for ; Sun, 18 Mar 2012 09:24:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5D21F8535 for ; Sun, 18 Mar 2012 09:24:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so9619832iaz.31 for ; Sun, 18 Mar 2012 09:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=vO3iCA/ySWGn27Eb5nHmzSywq57EczQZbXWoYmYe+JM=; b=JnMQ7Gkows/F/7TPKvC1NI2yybyHRB8TFqBixWZquqTtbEtIIgakUSn/QwHWZutZDk U7mOTN1mPYo49TPnQyaJxKwBd3y8cZUIs7kt7Eq3B5933hPuYfzPvR+vdSv9nbZI3j8k kgO20UusrYf3L9zaPTW7GpQODWHvhxuFAHDk3g3wNzeOZ9YBRBmJsou7VXJKnIjWJEOX Nq0LGnEfDqV+rLo0f0nO2FZsv9uGz8r0MmGbD0oXU4cqyUHYg1EYLcU+XmbS7WDdboE6 dMdXXqxy05h2U0ohLx39DCQRQGiiNkor2GKg2kV/n0ZI2Vn/1V1UWM0gVZgk5Jv0KSOs 8rmw== Received: by 10.50.203.99 with SMTP id kp3mr4091662igc.16.1332087845540; Sun, 18 Mar 2012 09:24:05 -0700 (PDT) Received: from sunqi ([59.64.255.54]) by mx.google.com with ESMTPS id ba4sm6058723igb.14.2012.03.18.09.24.03 (version=SSLv3 cipher=OTHER); Sun, 18 Mar 2012 09:24:04 -0700 (PDT) Date: Mon, 19 Mar 2012 00:24:00 +0800 From: "Qi Sun" To: "Wojciech Dec" References: X-Priority: 3 X-GUID: 44340008-BE17-4784-A05E-AD7A547944D5 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <201203190023599479803@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart816511361427_=----" Cc: softwires WG Subject: Re: [Softwires] New Version Notification for draft-mdt-softwire-map-translation-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 16:24:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart816511361427_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV29qY2llY2gsDQpUaGUgZHJhZnQgZ2l2ZXMgb3V0IGEgZ3JlYXQgc3VwcG9ydCBmb3IgdGhl IE1BUCBtZWNoYW5pc20gYW5kIGlzIG5pY2VseSB3cml0dGVuLiBIZXJlIGFyZSBzb21lIGNvbmZ1 c2lvbnMgd2hpbGUgSaGvbSByZWFkaW5nIHRoZSBkcmFmdC4gUGxlYXNlIGhlbHAgbWUgd2l0aCB1 bmRlcnN0YW5kaW5nIDotKQ0KIA0KMSwgSW4gc2VjdGlvbiA3LjQsIHRoZSA0dGggcGFyYWdyYXBo Og0KT3RoZXJ3aXNlLCB0aGUgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIChJUHY0LXRyYW5zbGF0 ZWFibGUgYWRkcmVzcykgTVVTVCBiZSBkZXJpdmVkIGZyb20NCnRoZSByZWNlaXZlZCBJUHY0IGRl c3RpbmF0aW9uIGFkZHJlc3MgcGVyIERNUi4gIFRoZSBkZXN0aW5hdGlvbiBwb3J0IG51bWJlciBN VVNUIGJlIHVuY2hhbmdlZC4NCiANCkNvbnNpZGVyaW5nIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFk ZHJlc3MgaXMgZGVyaXZlZCBmcm9tIHRoZSByZWNlaXZlZCBJUHY0IGRlc3RpbmF0aW9uIGFkZHJl c3MgcGVyIERNUiwgd2h5IHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYW4gSVB2NC10 cmFuc2xhdGFibGUgYWRkcmVzcywgbm90IElQdjQtY29udmVydGVkIGFkZHJlc3M/DQogDQoyLCBJ biBzZWN0aW9uIDcuNQ0KICAgQXQgdGhlIENFLCB0aGUgSVB2NCBzb3VyY2UgYWRkcmVzcyBNVVNU IGJlIGRlcml2ZWQgZnJvbSB0aGUgSVB2Ng0KICAgc291cmNlIGFkZHJlc3MgKElQdjYtY29udmVy dGVkIGFkZHJlc3MpIGFzIHBlciB0aGUgRE1SLCBvciBhcyBwZXIgdGhlDQogICBGTVIuICBUaGUg c291cmNlIHBvcnQgbnVtYmVyIE1VU1QgYmUgdW5jaGFuZ2VkLg0KIA0KICAgSVB2NCBEZXN0aW5h dGlvbiBBZGRyZXNzIGFuZCBEZXN0aW5hdGlvbiBQb3J0IE51bWJlcjogQXQgdGhlIENFLCB0aGUN CiAgIElQdjQgZGVzdGluYXRpb24gYWRkcmVzcyBNVVNUIGJlIGRlcml2ZWQgZnJvbSB0aGUgSVB2 NiBkZXN0aW5hdGlvbg0KICAgYWRkcmVzcyAoSVB2Ni10cmFuc2xhdGFibGUgYWRkcmVzcykgYXMg cGVyIEJNUi4gIFRoZSBkZXN0aW5hdGlvbiBwb3J0DQogICBudW1iZXIgTVVTVCBiZSB1bmNoYW5n ZWQuDQogDQogDQpXaGF0IGlzIGFuIElQdjYtIGNvbnZlcnRlZCBhZGRyZXNzIGFuZCBJUHY2LXRy YW5zbGF0YWJsZSBhZGRyZXNzPyBJoa9tIGEgbGl0dGxlIGxvc3QgaGVyZaGtDQogDQozLCBJbiBz ZWN0aW9uIDYuMi4xDQpUaGUgSVB2NiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBN VVNUIHRoZW4gYmUgZGVyaXZlZCBhcyBwZXIgU2VjdGlvbiA2IG9mIHRoaXMgZHJhZnQsIGFuZKGt Li4NCiANCklNSE8gdGhlIHN1cGVyIGxpbmsgobBTZWN0aW9uIDahsSBtYXkgYmUgobBTZWN0aW9u IDehsSwgcmVmZXJyaW5nIHRvIHNlY3Rpb24gNi40LjEgYW5kIDYuNC4yLiBEaWQgSSB1bmRlcnN0 YW5kIHJpZ2h0Pw0KIA0KVGhlcmUgYXJlIHRoZSBzYW1lIHN1cGVyIGxpbmsgaW4gc2VjdGlvbiA2 LjIuMi4NCiANCg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBtaXN1bmRlcnN0b29kIGFueXRoaW5n Lg0KIA0KQmVzdCBSZWdhcmRzIQ0KIA0KUWkgU3VuDQpGcm9tOiBXb2pjaWVjaCBEZWMNCkRhdGU6 IDIwMTItMDMtMTAgMDA6MDMNClRvOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFtTb2Z0 d2lyZXNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWR0LXNvZnR3aXJlLW1h cC10cmFuc2xhdGlvbi0wMS50eHQNCkhpIEFsbA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbWR0LXNvZnR3aXJlLW1hcC10cmFuc2xhdGlvbi0wMS50eHQgaGFzIGJlZW4NCnBvc3RlZCB1 bmRlcjoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWR0LXNvZnR3aXJlLW1h cC10cmFuc2xhdGlvbi0wMQ0KDQpGaWxlbmFtZTogIGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtdHJh bnNsYXRpb24NClJldmlzaW9uOiAgMDENClRpdGxlOiAgIE1BUCBUcmFuc2xhdGlvbiAoTUFQLVQp IC0gc3BlY2lmaWNhdGlvbg0KQ3JlYXRpb24gZGF0ZTogIDIwMTItMDMtMDkNCldHIElEOiAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSAmcXVvdDtNYXBwaW5nIG9mIEFkZHJlc3MgYW5k IFBvcnQmcXVvdDsgKE1BUCkNCiAgIGRvdWJsZSBzdGF0ZWxlc3MgdHJhbnNsYXRpb24gYmFzZWQg c29sdXRpb24gKE1BUC1UKSBmb3IgcHJvdmlkaW5nDQogICBJUHY0IGhvc3RzIGNvbm5lY3Rpdml0 eSB0byBhbmQgYWNyb3NzIGFuIElQdjYgZG9tYWluLg0KDQpXZSB3ZWxjb21lIGZ1cnRoZXIgV0cg ZmVlZGJhY2suICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM= ------=_001_NextPart816511361427_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Wojciech,

The draft gives out a great support f= or the MAP=20 mechanism and is nicely written. Here are some confusions while I=A1=AFm r= eading the=20 draft. Please help me with understanding :-)

 

1, In section 7.4, the 4th= =20 paragraph:

Otherwise, the IPv6 destination addre= ss=20 (IPv4-translateable address) MUST be derived=20 from

the received IPv4 destination address= per=20 DMR.  The destination port n= umber=20 MUST be unchanged.

 

Considering the IPv6 destination addr= ess is=20 derived from the received IPv4 destination address per DMR, why the IPv6=20 destination address is an IPv4-translatable address, not IPv4-converted=20 address?

 

2, In section=20 7.5

&nb= sp; =20 At the CE, the IPv4 source address MUST be derived from the=20 IPv6

&nb= sp; =20 source address (IPv6-converted address) as per the DMR, or as per=20 the

&nb= sp; =20 FMR.  The source port= number=20 MUST be unchanged.

 

&nb= sp; =20 IPv4 Destination Address and Destination Port Number: At the CE,=20 the

&nb= sp; =20 IPv4 destination address MUST be derived from the IPv6=20 destination

&nb= sp; =20 address (= IPv6-translatable address) as per BMR.  The destination=20 port

&nb= sp; =20 number MUST be unchanged.

 

 

What is an IPv6- converted address an= d=20 IPv6-translatable address? I=A1=AFm a little lost=20 here=A1=AD

 

3, In section=20 6.2.1

The IPv6 source and destination addre= sses MUST=20 then be derived as per Section 6 of this draft,=20 and=A1=AD..

 

IMHO the super link =A1=B0Section 6= =A1=B1 may be =A1=B0Section=20 7=A1=B1, referring to section 6.4.1 and 6.4.2. Did I understand=20 right?

 

There are the same super link in sect= ion=20 6.2.2.

 

 

Please correct me if I misunderstood=20 anything.

 

Best=20 Regards!

 

Qi Sun

From: Wojciech Dec<= /DIV>
Date: 2012-03-10 00:03
To: softwires@ietf.org
Subject: [Softwires] New Version Notification for=20 draft-mdt-softwire-map-translation-01.txt
Hi All
 
A new version of I-D, draft-mdt-softwire-map= -translation-01.txt has been
posted under:
 
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
 
Filename:  draft-mdt-softwire-map-translation
Revision:  01
Title:   MAP Translation (MAP-T) - = ;specification
Creation date:  2012-03-09
WG ID:   Individual Submission
Number of pages: 22
 
Abstract:
   This document specifies the &am= p;quot;Mapping of Address and Port&quot; (MAP= )
   double stateless translation based&n= bsp;solution (MAP-T) for providing
   IPv4 hosts connectivity to and&= nbsp;across an IPv6 domain.
 
We welcome further WG feedback.   =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;         
 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart816511361427_=------ From xing@cernet.edu.cn Sun Mar 18 15:39:24 2012 Return-Path: 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 D80D621F852B for ; Sun, 18 Mar 2012 15:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_40=-0.185, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 rqHiwqzk3jKI for ; Sun, 18 Mar 2012 15:39:24 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3A21F8522 for ; Sun, 18 Mar 2012 15:39:23 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.40.54]) by centos (Coremail) with SMTP id AQAAf3DbWARTY2ZPmUYSAA--.2196S2; Mon, 19 Mar 2012 06:36:06 +0800 (CST) Message-ID: <4F666409.9050800@cernet.edu.cn> Date: Mon, 19 Mar 2012 06:39:05 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> In-Reply-To: <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> Content-Type: multipart/alternative; boundary="------------010404080905010206070803" X-CM-TRANSID: AQAAf3DbWARTY2ZPmUYSAA--.2196S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAFyktw45Cr4kAr4DurW8Crg_yoW5Xw47pF y3GrsYyFZrGF1Ikrs7uw4xur1rAFWkK3y5Jw1UtwnYyws8Ca4Iqr4YkFyak3y8Xr18Jw1j q3yjkFn8Xan5ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU3F14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwV C2z280aVCY1x0267AKxVWUJVW8JwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E57IF 67AEF4xIwI1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0x vEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0 c2IEe2xFo4CEbIxvr21lc2xSY4AK67AK6Fyl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67 AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIY rxkI7VAKI48JMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DYxBIdaVFxhVjvjDU0xZFpf 9x0JU9Xo7UUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 22:39:25 -0000 This is a multi-part message in MIME format. --------------010404080905010206070803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Remi, 于 2012/3/9 21:39, Rémi Després 写é“: > Hi Xing, > > Le 2012-03-09 à 08:17, Xing Li a écrit : > >> Hi, Remi, >> >> 于 2012/2/10 18:23, Rémi Després 写é“: >>> Hi Xing, >>> Good to have you coming in the (unfinished) technical analysis. >>> >>> I answered to Ole on his remarks, which you support, but not on >>> the following: >>> >>> You propose to have a line on "IPv4 to IPv6 communication (single >>> translation) supported", wit > >>> Let me therefore reiterate the wish to see an ISP use case, with its >>> Mapping rules, and with IPv6 prefixes of CEs that illustrate the >>> problem you see. >> >> The CERNET2 is an IPv6-only core network. We provide stateless >> IPv4/IPv6 translation between CERNET2 and the IPv4 core network >> (CERNET). The users can either use single translation directly, or >> add their own IPv4/IPv6 translor if double translation is required. >> >> Is this answer your question? > > Not quite, since neither example MAP-T Mapping rules nor assigned IPv6 > prefixes are provided, but that may be sufficient so far. > > A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE > node, when it receives no 4rd mapping rule, to exercise single > translation. > Actually, I believe that using for this the BIH of RFC6535 is both > sufficient and recommendable. > Translated IPv4 packets, because they are sent from CE nodes to DNS64 > synthesized addresses, are appropriately routed to their destinations. > (It can be via the NAT64-CGN if needed, or via more direct paths if > possible.) > Anything missed? Sorry, this is a misunderstanding. Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment. Regards, xing > > Regards, > RD > > > > > >> Regards, >> >> xing >> >> >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> Le 2012-02-10 à 04:28, Xing Li a écrit : >>> ...| | | | | >>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | >>>>>> | | packets | | | | | >>>>> suggest you rename to "IPv4 to IPv6 communication (single translation) supported" >>>>> >>>> >>>> (2) More clarification should be added here. I am not sure 4rd-H >>>> can support single translation. >>>> >>>> (a) According to (1), 4rd-H does not perform header translation >>>> defined by RFC6145. >>>> >>>> (b) In the softwire mailing list, it seems that 4rd-H cannot >>>> support single translation. See the thread containing >>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and >>>> other posts. >>>> >>>> (c) If 4rd-H cannot support single translation, then "IPv6 web >>>> caches work for IPv4 packets" requires special configurations, it >>>> cannot do IPv6 web caches for non 4rd-H packets. >>> >>> ... >>> >>>> (5) I would like to see the details of how 4rd-H handles ICMP and >>>> ICMP error messages. In the softwire mailing list there were some >>>> discussions. See the thread containing >>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and >>>> other posts.Please add >>>> >>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>> ... >>> >> > --------------010404080905010206070803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Remi,

于 2012/3/9 21:39, Rémi Després 写é“:
Hi Xing,

Le 2012-03-09 à 08:17, Xing Li a écrit :

Hi, Remi,

于 2012/2/10 18:23, Rémi Després 写é“:
Hi Xing,
Good to have you coming in the (unfinished) technical analysis.

I answered to Ole on his remarks, which you support, but not on the following:

You propose to have a line on "IPv4 to IPv6 communication (single translation) supported", wit 

Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see.

The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 translation between CERNET2 and the IPv4 core network (CERNET). The users can either use single translation directly, or add their own IPv4/IPv6 translor if double translation is required.

Is this answer your question?

Not quite, since neither example MAP-T Mapping rules nor assigned IPv6 prefixes are provided, but that may be sufficient so far.

 A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, to exercise single translation. 
 Actually, I believe that using for this the BIH of RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 à 04:28, Xing Li a écrit :
... | | | | |
  |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |
...





--------------010404080905010206070803-- From fibrib@gmail.com Sun Mar 18 22:19:26 2012 Return-Path: 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 4427E21F85A3 for ; Sun, 18 Mar 2012 22:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 oZISulzgffHo for ; Sun, 18 Mar 2012 22:19:24 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06E7321F8597 for ; Sun, 18 Mar 2012 22:19:23 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1250154qcs.31 for ; Sun, 18 Mar 2012 22:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zWU+tmxXVsiEQjYgTvlTuorOf+WrN71GtAZ5Uidb5Y0=; b=R/+Us1SrtXIoSxfkypyy0+hGjSd6q6JIrjDDwC2dxpccqobz4VybIhMskRnHD58wkC 5UOcMVmpIr5Lv3IttLWdlSQQ2wZ69F2Hp8Zk4DDF19h/v2N2gObziUtrlgq/rig8JdUI 2qNUuP4ILHuEiZLzRuyIEG0WcU2KHGY3BRIVtV3YOjZOTBpjgLOouO5fH3WNdX2IQ/Pv anuCgXHK8tpZCmOltK29PLYS1HOF+r1ihGk1/UHzkHOvu9VEp4PGQs1TZo2PRybF71Tg nz9fRFonrrxmnD2k5fI+/h171z8Vd9Yet10pFoLtPc5t1Nbgwt9UGgsIHYNSbnO09Hdq 7ZqA== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr13980472qab.13.1332134363401; Sun, 18 Mar 2012 22:19:23 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sun, 18 Mar 2012 22:19:23 -0700 (PDT) In-Reply-To: <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> Date: Mon, 19 Mar 2012 05:19:23 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef7860cf504bb91b399 Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 05:19:26 -0000 --20cf30363ef7860cf504bb91b399 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, please see inline. 2012/3/16 R=E9mi Despr=E9s > Maoke, > > First: > - My apologies for having not answered this email before receiving a > reminder (it was by mistake lost in a stack of non-urgent things to do). > - Thanks for the clear and detailed analysis. > > More comments in line. > > Le 2012-03-13 =E0 10:53, Maoke a =E9crit : > > Remi, > > discussion on R-16 of Sec 4.7: > > > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it > > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet > > MUST contain the first 8 octets of the discarded-packet IP > > payload. > > now the ICMPv6 error message contains the payload as the "header-mapped" > IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translate= s > this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies > the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the > RFC6145 does? (for ICMP, the CNP doesn't help) > > if it does, you'd better cite RFC6145 here. if it doesn't, please specify= . > > dear Remi, you didn't respond this. > > > If the CE or BR has a global IPv4 address, this > > address MUST be used as source of this packet. Otherwise, the > > unspecified address 0.0.0.0 SHOULD be used as this source. > > let me draw an example for that: > > A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; > router R2 here)--- B > > 1. consider ICMPv6 error happens at R1 > > original IPv4 packet at A, sent to B: > +---------+----------------------------------------------+ > | IPv4 | payload | > | hdr, H1 | P1 | > +---------+----------------------------------------------+ > > CE translates (precisely speaking, "header-maps") it to: > +------------+----------------------------------------------+ > | IPv6 | payload | > | header, H2 | P1 | > +------------+----------------------------------------------+ > > R1 found a error for this IPv6 packet, it generates an ICMPv6 report: > +------------+--------+-----------+-------------------------+ > | IPv6 | ICMPv6 | IPv6 | payload (truncated to | > | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | > +------------+--------+-----------+-------------------------+ > \_______________ ___________________/ > V > as the ICMPv6 error message body > > this message feedbacked to CE, who will translate it to: > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > \__________ __________/ > V > as the ICMPv4 error message body > > it is clear that 4rd-U address mapping is applied for > > H1 -> H2 -> H4 > > H3 has the source address of R1 while the destination address as the CE. > > then, CE's (or BR's for the case of B --> A) global IPv4 address or > 0.0.0.0 will be used in H5, right? > > > Right. > > first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address > represents either a host not yet having gained an IPv4 address on the LOC= AL > network or an application listening on any addresses of a host. > > > packet with 0.0.0.0 might be dropped by any intermediate routers of > current implementations. > > > This address never appears on any IPv4 link. > Intermediate routers being IPv6, there is no problem. > i doubt there is not a use-case where between A and CE there are some subnet routers. > OK? > > > > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unreachable, No > > route to destination") MUST be translated into ICMPv4 Type =3D 3 > > and Code =3D 0 (Destination unreachable, Net unreachable). > > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit > > exceeded in transit) MUST be translated into ICMPv4 Type =3D 11 > > and Code =3D 0 (Time exceeded, Time to live exceeded in > > transit). > > for C1 -> C2 translation, i have the following comments: > > 1) here 4rd-U uses the CE's global IPv4 address > > > (i think "global" refers to a non-shared one, right?) > > > Global address is used as a synonymous of public address. > If somewhere it seems to mean non-shared address, it must be a mistake. > > > to represent all the error generator inside in the IPv6 domain. this > surely fits a "tunnel" behavior that attempts to treat the delivery from = CE > to BR as a "link", and therefore the error is responded by the link's end > point. > 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit > exceeded and ICMPv6 unreachable node should be translated as ICMPv4 > destination unreachable (Type =3D 3) host unreachable (Code =3D 1), becau= se it > should indicates the link problem of the tunnel. > 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a > typical behavior of path participant rather than a "tunnel". the differen= ce > of the tunnel and the path participant is: the latter consumes the TTL pe= r > physical hop. for example, if we set TTL =3D 32 in H1, tunneling means fr= om A > to B communication may succeed as long as (A---CE) + (BR---B) doesn't > exceed 30 hops and CE---BR is well connected; while current 4rd-U means > from A to B communication may succeed only when total numbers of > intermediate routers doesn't exceed 31. > > this is why typical tunneling solutions initialize the out-header's IPv6 > Hop Limit to 255. when routing loop happens in the IPv6 domain and Hop > Limit is consumed out, the link is considered broken. > > > I don't see any problem with having, at tunnel exit, the TTL decreased by > the number of traversed routers. > you don't see it a problem because you reject the common understanding about "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it has been admitted by your statement that "4rd tunnel is not any tunnel". my understanding here is "4rd tunnel" is ACTUALLY another path section of translation, according to its behavior. if you would say "4rd-U is a translation solution alternative to RFC6145 providing better transparency in double-translation environment with some cost and uncertain risk", i would totally accept without any further argument. > > > > 2. consider ICMPv4 error happens at R2: > > R2 sees original IPv4 packet at A, sent to B: > +---------+----------------------------------------------+ > | IPv4 | payload | > | hdr, H1 | P1 | > +---------+----------------------------------------------+ > > R2 has found some error with that packet, issuing an ICMPv4 message and > sending to A: > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > \__________ __________/ > V > as the ICMPv4 error message body > > 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): > +------------+--------+--------+--------------+ > | IPv6 | ICMPv4 | IPv4 | truncated | > | header, H7 | hdr, C3| hdr, H1| payload, P3 | > +------------+--------+--------+--------------+ > > woops, unfortunately, R1 also found something wrong. R1 generates an > ICMPv6 report, responding back to B: > +------------+--------+------------+--------+--------+--------------+ > | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | > | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | > +------------+--------+------------+--------+--------+--------------+ > > BR sees this and makes translation to: > +---------+--------+---------+--------+--------+------------+ > | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| > +---------+--------+---------+--------+--------+------------+ > |<------- 8 octet ----------->| > \___________________ __________________/ > V > as the ICMPv4 error message body > > here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. her= e > 4rd-U can have two options: > 1) let it be but depends on the IPv4 Internet routers, or host B itself t= o > drop the ICMP of ICMP; > 2) actively check the header in the ICMPv4 message body (H9 above) and > identify if the protocol of the discard-packet is ICMPv4 too; if so, BR > drops the packet. > > i doubt either is good. anyway, no matter which is used, 4rd-U must deal > with this issue. (sorry if i missed some text where it has been done.) > > > The right choice is clearly 2 (RFC792 rightly says: "To avoid the infinit= e > regress of messages about messages etc., no ICMP messages are sent about > ICMP messages.") > sure 2) is better than 1). however, the remained problem is IPv6 carrying ICMPv4. i just summarize my concerns here in order the community can judge the impact: #1. such kind of packet loses the consistency between the destination address in the IPv6 header and the source address of original IPv4 header contained in the ICMP error message. #2. such kind of packet loses IP header integrity mechanism as neither IPv4's header checksum nor the ICMPv6's checksum containing pseudo-header is included. because it is stated that 4rd-U is "ensuring compatibility with IPv6-only middle boxes that perform deep-packet-inspection", i here point out at least #1 checking on ICMP error message being sent to the exact source of original packet, and #2 checking on IP header integrity by calculating the checksum in header or pseudo-header cannot rely on the functionality of the middle boxes in the IPv6-only domain that perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these issues as well. (neither MAP-T nor MAP-E has the similar concern). - maoke > It can be made more explicit in the specification. Thanks. > > > Cheers, > RD > > > > > > cheers, > maoke > > 2012/3/12 R=E9mi Despr=E9s > >> Hello, all, >> >> An updated version of draft-despres-softwire-4rd-u is now available at >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >> >> Differences with -04 include: >> - DHCPv6 options are now specified >> - various errors and typos are corrected >> - some clarifications are added, following received questions and commen= ts >> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs an= d >> within CPEs) >> - An editor's note has been added, following a WG-ML discussion, about a= n >> additional Mapping-rule parameter that might be needed to assign privile= ged >> ports to to some shared-address CEs. >> - Document layout has been adjusted as a result of other modifications. >> - the authors list has been completed. >> >> Questions and comments are most welcome. >> >> Regards, >> RD >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --20cf30363ef7860cf504bb91b399 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,=A0

please see inline.=A0

<= div class=3D"gmail_quote">2012/3/16 R=E9mi Despr=E9s <= despres.remi@= laposte.net>
Maoke,
First:
- My apologies for having not answered t= his email before receiving a reminder (it was by mistake lost in a stack of= non-urgent things to do).
- Thanks for the clear and detailed analysis.

More comments in line.

Le 2012-03-13 =E0 10:53, Ma= oke a =E9crit :

Remi,=A0

discussion on R-16 of Sec 4.7:
<= div>
=A0 > R-16: If a CE or BR receives an ICMPv6 error m= essage [RFC4443], it
=A0 > MUST synthesize an ICMPv4 error pac= ket [RFC0792]. This packet
=A0 > MUST contain the first 8 octets of the discarded-packet IP=
=A0 > payload.

now the ICMPv6 err= or message contains the payload as the "header-mapped" IPv6 PDU o= f the discarded packet. right? so does 4rd-U CE or BR translates this ICMPv= 6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies the checksu= m adjustment algorithm between ICMPv6 and ICMPv4 here, as the RFC6145 does?= (for ICMP, the CNP doesn't help)

if it does, you'd better cite RFC6145 here. if it d= oesn't, please specify.=A0
dear Remi, you didn't respond this.=A0

=A0 > If the CE or BR has a global IPv4 addre= ss, this
=A0 > address MUST be used as source of this packet.= Otherwise, the
=A0 > unspecified address 0.0.0.0 SHOULD be used as this source.=

let me draw an example for that:

A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Intern= et; router R2 here)--- B

1. consider ICMPv6 error happens at R1

original IPv4 packet at A, sent to B:
+---------+-------= ---------------------------------------+
| IPv4 =A0 =A0| payload = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

CE translates (precisel= y speaking, "header-maps") it to:=A0
+------------+----------------------------------------------+
| IPv6 =A0=A0 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| header, H2 | P1 =A0=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0|
+------------+----------------------------------------------+

R1 found a error for this IPv6 packet, it generates an ICM= Pv6 report:
+------------+--------+-----------+-------------= ------------+
| IPv6 =A0=A0 =A0 =A0| ICMPv6 | IPv6 =A0 =A0 =A0| payload (truncated t= o =A0 |
| header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),= P2 |
+------------+--------+-----------+-------------------------= +
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_______________ ___________= ________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv6 error message body

this message feedbacked to CE, who will translate it to:
+---------+--------+--------+--------------+
| IPv4 =A0= =A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H5 | hdr, C= 2| hdr, H4| payload, P3=A0 |
+---------+--------+--------+-------= -------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

it is clear that 4rd-U address mapping is applied for= =A0

=A0 H1 -> H2 -> H4

<= div>H3 has the source address of R1 while the destination address as the CE= .

then, CE's (or BR's for the case of B --> A)= global IPv4 address or 0.0.0.0 will be used in H5, right?

Right.

first of all, the 0.0.0.0 might be a wr= ong choice. Unspecified Address represents either a host not yet having gai= ned an IPv4 address on the LOCAL network or an application listening on any= addresses of a host.

packet with 0.0.= 0.0 might be dropped by any intermediate routers of current implementations= .=A0

This address never appear= s on any IPv4 link.
Intermediate routers being IPv6, there is no problem.

i doubt there is not a use-case where bet= ween A and CE there are some subnet routers.=A0
=A0
OK?


=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Destinati= on unreachable, No
=A0 > route to destination") MUST be = translated into ICMPv4 Type =3D 3
=A0 > and Code =3D 0 (Desti= nation unreachable, Net unreachable).
=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit=
=A0 > exceeded in transit) MUST be translated into ICMPv4 Ty= pe =3D 11
=A0 > and Code =3D 0 (Time exceeded, Time to live e= xceeded in
=A0 > transit).

for C1 -> C2 transla= tion, i have the following comments:

1) here = 4rd-U uses the CE's global IPv4 address

(i think "global" refers to a= non-shared one, right?)

= Global address is used as a synonymous of public address.
If some= where it seems to mean non-shared address, it must be a mistake.


to represent a= ll the error generator inside in the IPv6 domain. this surely fits a "= tunnel" behavior that attempts to treat the delivery from CE to BR as = a "link", and therefore the error is responded by the link's = end point.=A0
2) however, if this is treated as a "tunnel", both ICMPv6 ho= p-limit exceeded and ICMPv6 unreachable node should be translated as ICMPv4= destination unreachable (Type =3D 3) host unreachable (Code =3D 1), becaus= e it should indicates the link problem of the tunnel.
3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a = typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter consumes t= he TTL per physical hop. for example, if we set TTL =3D 32 in H1, tunneling= means from A to B communication may succeed as long as (A---CE) + (BR---B)= doesn't exceed 30 hops and CE---BR is well connected; while current 4r= d-U means from A to B communication may succeed only when total numbers of = intermediate routers doesn't exceed 31.=A0

this is why typical tunneling solutions initializ= e the out-header's IPv6 Hop Limit to 255. when routing loop happens in = the IPv6 domain and Hop Limit is consumed out, the link is considered broke= n.

I don't see any problem wi= th having,=A0at tunnel exit,=A0the TTL decreased by the number of traversed= routers.

you don&#= 39;t see it a problem because you reject the common understanding about &qu= ot;tunnel" as a virtual link, but define the so-called 4rd-tunnel. it = has been admitted by your statement that "4rd tunnel is not any tunnel= ". my understanding here is "4rd tunnel" is ACTUALLY another= path section of translation, according to its behavior. if you would say &= quot;4rd-U is a translation solution alternative to RFC6145 providing bette= r transparency in double-translation environment with some cost and uncerta= in risk", i would totally accept without any further argument.=A0
=A0
=A0


2. consider ICMPv4 error happens at R2:=A0
R2 sees original IPv4 packet at A, sent to B:
+= ---------+----------------------------------------------+
| IPv4 = =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)

The rig= ht choice is clearly 2 (RFC792 rightly says: "To avoid the infinite re= gress of messages about messages etc., no ICMP messages are sent about ICMP= messages.")

sure 2) is better = than 1). however, the remained problem is IPv6 carrying ICMPv4. i just summ= arize my concerns here in order the community can judge the impact:=A0
#1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 header c= ontained in the ICMP error message.
#2. such kind of packet loses= IP header integrity mechanism as neither IPv4's header checksum nor th= e ICMPv6's checksum containing pseudo-header is included.=A0

because it is stated that 4rd-U is "ensuring compa= tibility with IPv6-only middle boxes that perform deep-packet-inspection&qu= ot;, i here point out at least #1 checking on ICMP error message being sent= to the exact source of original packet, and #2 checking on IP header integ= rity by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that perform = deep-packet-inspection. then 4rd-U CE/BR MUST consider these issues as well= .=A0

(neither MAP-T nor MAP-E has the similar concern).=A0

- maoke=A0
=A0
It can be made more= explicit in the specification. Thanks.


Cheers,
RD




cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--20cf30363ef7860cf504bb91b399-- From washam.fan@gmail.com Sun Mar 18 22:58:02 2012 Return-Path: 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 1AEAD11E8083 for ; Sun, 18 Mar 2012 22:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Sf3iHmtaiSrU for ; Sun, 18 Mar 2012 22:58:00 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E88F11E8072 for ; Sun, 18 Mar 2012 22:58:00 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2597883wib.13 for ; Sun, 18 Mar 2012 22:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eekMOx4WeYDJXD+TemUgpMb7WyvDd2MgeBxtT6mO30w=; b=xeMOTypGR59nHXBOKdhlZy9305AYKV/fazkSh7KvS9pgnKTjQRmz2YxJE2hBI9jbaD xBXvG2IRoMh12Nta/RaWqnrpLDE+hCmulrSngPgU59VU1X/CHpMUFkzrgk1szc1MGMdq S8bGb3otVhOWA8p4TeWwpCZg+ciZSMMrip4WyI37Fpj/r3lpQ9t5Zz5Wr/Wtdwkb+tcO QxMjdPVto2IaKAp2Ti/NMCsz0AFqTc+nE9ZjC7gOp8oOje8rXGUtKX7mIt3PkRIz1QBZ etc0bsxLqNdgU/nzvxhDnpT/KXKrqx56SPjpH6iT8uIII0NsggGG7y/knDt8g/sYaa0W 3Zig== MIME-Version: 1.0 Received: by 10.216.150.148 with SMTP id z20mr6616515wej.22.1332136679621; Sun, 18 Mar 2012 22:57:59 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Sun, 18 Mar 2012 22:57:59 -0700 (PDT) In-Reply-To: References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> Date: Mon, 19 Mar 2012 13:57:59 +0800 Message-ID: From: Washam Fan To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 05:58:02 -0000 > you don't see it a problem because you reject the common understanding about > "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it has been > admitted by your statement that "4rd tunnel is not any tunnel". my > understanding here is "4rd tunnel" is ACTUALLY another path section of > translation, according to its behavior. if you would say "4rd-U is a > translation solution alternative to RFC6145 providing better transparency in > double-translation environment with some cost and uncertain risk", i would > totally accept without any further argument. > +1. 4rd-U has been considered as a translation mechanism to me (with better transparency). Thanks, washam From fibrib@gmail.com Mon Mar 19 01:16:04 2012 Return-Path: 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 15D4921F8601 for ; Mon, 19 Mar 2012 01:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 4pqfjeQlaRMF for ; Mon, 19 Mar 2012 01:16:02 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE321F85DB for ; Mon, 19 Mar 2012 01:16:01 -0700 (PDT) Received: by qaea16 with SMTP id a16so660910qae.10 for ; Mon, 19 Mar 2012 01:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C3F6c7PD3BuHFXKTjcUyUmckqsU7P/xKzEBcqqbUEb4=; b=KFkSn30IIfdqjZc7dfGBseF+ytkVRorjc6HzS1edIcxxFga7yDuNOWLxvRjHxdqdBb P0rLFSSkITcFZnkKnR6HRes0yYpLdgywuMUso9xdEz4sirWzSf04tFPwC65KiQxS+fT0 Ve0xkpECiKJiggTBcCDB2cckEZBGtrMJONVlVDPP5p097sA7BoVaooLoiyiXw02TO1Vu rQmUqsiBj+KS+bTozbA+Ea8KaP+Bpp+IZJizZEmIcq+9umoO5CfQnMmiM9+gmOryobxO wPaXMIk5MqNVoUy2prE+ZPNDbWWXCnLcn/tb/+pGaOBbuWhbxlOKCZWcY2nVVhatFyzg VJmA== MIME-Version: 1.0 Received: by 10.229.134.196 with SMTP id k4mr4177378qct.29.1332144961192; Mon, 19 Mar 2012 01:16:01 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 01:16:01 -0700 (PDT) In-Reply-To: <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> Date: Mon, 19 Mar 2012 08:16:01 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c6a86e23382b404bb942b9a Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 08:16:04 -0000 --00248c6a86e23382b404bb942b9a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/16 R=E9mi Despr=E9s > 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 =3D> B (via NAT64+) > A3 <=3D> B (via 4rd BR) > (There is no A1-B connectivity) > A2 is IPv6-only, right? if so, let me go down. > > Anything missed? > > > Other detailed comments follow. > > Le 2012-03-16 =E0 01:59, Maoke a =E9crit : > > > > 2012/3/15 R=E9mi Despr=E9s > >> >> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >> >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>> >>> i understand NAT64 makes translation between arbitrary IPv6 address to >>> arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 >>> address. >>> >>> >>> >>> in other words, we cannot limit NAT64 stateful service only serve those >>> IPv6 addresses with CNP. >>> >>> >>> That's no the case at all(!). >>> A NAT64+ is a *backward compatible* extension of NAT64 (everything that >>> worked before still works completely unchanged). >>> >>> The draft says: >>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support >>> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-addre= ss >>> format." >>> >>> >> >> this phrase is not understood yet. do you mean using 4rd-IPv6-address >> format for stateful translation service? >> >> >> Yes (but, &s said, only for CE nodes that are 4rd capable (with the >> advantage of better IPv4 transparency between CEs and NAT64+ than betwee= n >> RFC6145 and NAT64). >> >> please draw an example of A <---> B communication as i did for >> clarification. >> >> >> Here is an example scenario: >> >> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH uses >> RFC6145) >> A1 | >> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server >> | UDP-lite UDP-lite >> v4Appli-4rdCE --' capable B >> A2 =3D> A-B OK >> >> > yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly > speaking, if the "not support" means passing-it-through without checksum > adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing > with the L4, right? > > > A NAT64 that supports UDP Lite MUST update checksum for hosts that have > native IPv6 addresses. > That's why A1 =3D> B doesn't work unless the NAT64 recognizes which packe= ts > are those of IPv4 applications in DS hosts. > A1 -> B doesn't need stateful NAT64 but stateless service is enough. well, stateful is also ok. it is true NAT64 supporting UDP-Lite must update checksum. > > B --> A is a question mark, if we use the NAT64+ which does nothing with > the L4 checksum, it is also not a problem. > > > > however, if we use, as you mentioned before, an UDP-Lite-aware update of > RFC6146, that may updates the checksum while the BIH doesn't know that. > > > Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to > support more protocols than the two required by the RFC. It is just an > extension which cannot break anything (backward compatible). > confusing. upgrade vs. extension?? > > > > my point here is: what is the use case with the details of addressing? if > and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U > address while NAT64+ has a pool of checksum-neutral IPv6 address to serve= B > for the communications, A1 BIH or A2 CE may do the stateless processing > successfuly. if NAT64+ hasn't such a address pool for B, things will fail > because only one among src and dst is checksum-neutral. > > > Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address reache= s > the NAT64+ at this IPv6 address: > > +-------------------------------+---+---+-------------+------+ > | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | > +-------------------------------+---+---+-------------+------+ > : 64 : 8 : 8 : 32 : 16 : > > In the reverse direction, and for the same IPv4 address, it is the same > IPv6 address that must be synthesized by the NAT64+. > this address is used for A2 or used for B? if you mean B, then may i conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted address having CNP)? if i can, may i further conclude that NAT64+ serves only for the case where A2 has the 4rd-U-style address? if the A2 is configured with any IPv6 address, for example, address with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, right? if so, i do really suggest you call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with any native IPv6 address to connect with an IPv4 peer. your answer below didn't respond my question, sorry. for example (in the use case of NAT64 instead of NAT64-), A2 has native IPv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE might synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' through IPv6; however, when this packet goes through the NAT64+, because only B' is checksum-neutral while A2 is not, NAT64+ passing it without L4 checksum adjustment will make B receive a packet with wrong checksum, for any L4 protocols. the above example works well for TCP and UDP with today's NAT64, without limitations on A2's address. - maoke > This is I suppose implicit, but it can advantageously be made explicit in > the draft. > Thanks. > > > Because 4rd IPv6 addresses of CEs are distinguishable from all other >>> IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONL= Y >>> for addresses that actually are 4rd CE addresses. >>> >>> >> >> we need to make sure if the NAT64s make both src and dst addresses >> checksum-neutral. >> >> Correct, iff the host address has the V octet. >> > > 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE > addresses from others. > > > True, but while testing the V octet is sufficient in 4rd, the NAT64 has i= n > MAP to process mapping rules to find for null subnet IDs whose lengths > depend on which mapping rule applies. > That's IMHO one instance where the V-octet potential is clear. > > > 2. even with the V-octet, do you mean B's IPv4 address also translated (b= y > the NAT64+) to a CNP-and-V-containing IPv6 address? > > > Yes (see above). > > if 2 is true, why you use stateful NAT64+ here for B rather than a > stateless one? > > > Because we consider hosts that are not assigned any public IPv4 address, > even shared. > > if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for > B's communications, and such a case results only A's mapped address is > checksum-neutral, and thus anyway L4 adjustment is needed. > > if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because > NAT64 doesn't have the limitation on the IPv6 address pool in use. > > > Suggestion not retained ;-). > What you call the IPv6 address pool isn't a reserved pool: as explained > above, NAT64+ synthesizes its IPv6 source addresses using its unchanged /= 64 > prefix. > > > 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT > RECOMMENDED [RFC6180]" (but the above technical discussion can omit this > for the time being). > > > Right. > > RD > > > > > > > - maoke > > >> >> i cannot imagine what the use case is. please specify! >> >> >> Hope the picture above helps. >> >> RD >> >> >> >> >> - maoke >> >> >>> >>> >>> RD >>> >>> >>> - maoke >>> >>> 2012/3/15 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>> >>>> > Maoke, >>>> > >>>> > Thanks for this question. >>>> > This subject being new, I take it on a new thread. >>>> > >>>> > 2012-03-15 10:38, Maoke: >>>> > ... >>>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>>> > >>>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels >>>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 paylo= ads. >>>> > Any protocol that this NAT64 supports is then supported e2e for 4rd-= u >>>> CEs >>>> > These CEs need not being dependent on which NAT64 supports which >>>> protocols. >>>> > >>>> > Note that the NAT64 doesn't need to have CNP code. It just happens >>>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and= IPv4 >>>> payloads are the same for all protocols that have ports at the same pl= ace >>>> as TCP/UDP/..., and the same checksum algorithm) >>>> >>>> Oops. >>>> This is only true for the IPv6 host address. To construct an IPv6 >>>> address when transmitting to a 4rd-u CE, the NAT64 should compute a C= NP. >>>> (This is to maintain the property that that middleboxes can treat tunn= el >>>> packets as valid IPv6 packets. Not a big deal, but necessary). >>>> Sorry for having hastily added this sentence. >>>> >>>> RD >>>> >>>> > >>>> > RD >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Softwires mailing list >>>> > Softwires@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >>> >>> >> >> > > --00248c6a86e23382b404bb942b9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Maoke,

Let me try a = more complete picture than before:


= =A0 =A0 A1 -----. =A0 =A0 =A0 =A0 =A0=A0
RFC6145-host|=A0 =A0 =A0= =A0 =A0 =A0.-- 4rd BR --.=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 A2 -----:--(v6net)--: =A0 =A0 =A0 =A0 =A0 =A0:--(v4 = Internet)--- B=A0
=A0 4rd-CE =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0UDP Lite=A0appli=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0
(no IPv4 @) | =A0 =A0 =A0 =A0 =A0=A0&= #39;-- NAT64+ --'=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0
=A0 =A0 A3 ---= --'=A0
=A0 4rd-CE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
(IPv4 @, sha= red=A0or not)


NAT64+ is s= upposed to have a bindings for UDP Lite, either only for 4rd IPv6 addresses= (the minimum), or also for native IPv6 addresses (the complete upgrade, wi= th UDP-Lite checksum adjustment for these addresses)

Connectivities I get are:=A0
=A0A2 =A0=3D>= B (via NAT64+)
=A0A3 <=3D> B (via 4rd BR)
(There= is no A1-B connectivity)

A2 is IPv6-only, right? if so, let me go down.=A0
=A0

Anything missed?


Other detailed comments follow.

Le 2012= -03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s= <despres.remi@laposte.net>

Le 2012-03-15 =E0 14:47, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte= .net>

Le 2012-03-15 =E0 11:45, = Maoke a =E9crit :

i understand NAT6= 4 makes translation between arbitrary IPv6 address to arbitrary IPv4 addres= s. i don't understand how you make CNP in any IPv6 address.


in other words, we = cannot limit NAT64 stateful service only serve those IPv6 addresses with CN= P.

That's no the case at all(!).= =A0
A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t worked before still works completely unchanged).

The draft says:
"NAT64+: =A0An ISP NAT64 of [RFC6146] that = is upgraded to support 4rd=A0tunneling when IPv6 addresses it deals with ha= ve the 4rd-IPv6-address format."
=A0
=A0
this phrase is no= t understood yet. do you mean using 4rd-IPv6-address format for stateful tr= anslation service?

Yes (but, = &s said, only for CE nodes that are 4rd capable (with the advantage of = better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NA= T64).

ple= ase draw an example of A <---> B communication as i did for clarifica= tion.

Here is an example= scenario:

v4appli-BIH ----. =3D> A>B NOK (because, accordin= g to RFC6535, BIH uses RFC6145)=A0
=A0 =A0 =A0A1 =A0 =A0 =A0 =A0 = |=A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :----(v6net)----- NA= T64+ ---(IPv4 Internet)--- Server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-l= ite =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-lite
v4Appli-4= rdCE --' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0capable=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B
=A0 =A0 =A0A2 =A0 =A0 =A0 =A0 = =A0=3D> A-B OK


yes, BIH uses = RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, i= f the "not support" means passing-it-through without checksum adj= ustment, A --> B is fine because neither BIH nor NAT64+ does nothing wit= h the L4, right?

A NAT64 that supports UDP Lite= MUST update checksum for hosts that have native IPv6 addresses.
= That's why A1 =3D> B doesn't work unless the NAT64 recognizes wh= ich packets are those of IPv4 applications in DS hosts.

A1 -> B doesn't n= eed stateful NAT64 but stateless service is enough. well, stateful is also = ok. it is true NAT64 supporting UDP-Lite must update checksum.=A0
=A0

B --> A is a question mark, if we use the NAT64+ which does nothin= g with the L4 checksum, it is also not a problem.
=


however, if we use, as you mentioned before, an UDP-Lite-aware update of RF= C6146, that may updates the checksum while the BIH doesn't know that.= =A0

Note that an upgrade of RF= C6146 isn't needed for A NAT64 (and NAT64+) to support more protocols t= han the two required by the RFC. It is just an extension which cannot break= anything (backward compatible).

confusing. upgrade vs. extensi= on??=A0
=A0



my point here is: what is the use case with the details= of addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 add= ress to serve B for the communications, A1 BIH or A2 CE may do the stateles= s processing successfuly. if NAT64+ hasn't such a address pool for B, t= hings will fail because only one among src and dst is checksum-neutral.=A0<= /div>

Sec 4.4 (8) says that a CE tha= t targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 addres= s:

+-------------------------------+---+---+-= ------------+------+
| =A0 =A0 =A0NAT64+ IPv6 prefix =A0 =A0 =A0 |"u"| 0 |DST IPv= 4 add.| =A0CNP |
+-------------------------------+---+---+-------= ------+------+
: =A0 =A0 =A0 =A0 =A0 =A0 =A0 64 =A0 =A0 =A0 =A0 = =A0 =A0 =A0: 8 : 8 : =A0 =A0 =A032 =A0 =A0 : =A016 =A0:

In the reverse direction, and=A0for the same IPv4= address,=A0it is the same IPv6 address that must be synthesized by the NAT= 64+.

this address i= s used for A2 or used for B? if you mean B, then may i conclude that NAT64+= is serving between A2 (native IPv6 address with 4rd-U CNP) and B (synthesi= zed by NAT64+ into another IPv6-converted address having CNP)? if i can, ma= y i further conclude that NAT64+ serves only for the case where A2 has the = 4rd-U-style address?=A0

if the A2 is configured with any IPv6 address, for exam= ple, address with the autoconfigured EUI64 IID, it is out of the scope of t= he NAT64+, right?=A0

if so, i do really suggest yo= u call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with = any native IPv6 address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry= . for example (in the use case of NAT64 instead of NAT64-), A2 has native I= Pv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. = the CE might synthesize an IPv6 address for B, with the NAT64+ prefix and t= he 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' = through IPv6; however, when this packet goes through the NAT64+, because on= ly B' is checksum-neutral while A2 is not, NAT64+ passing it without L4= checksum adjustment will make B receive a packet with wrong checksum, for = any L4 protocols.=A0

the above example works well for TCP and UDP with today= 's NAT64, without limitations on A2's address.=A0

- maoke
=A0
This is I suppose implic= it, but it can advantageously be made explicit in the draft.
Than= ks.


Because 4rd IPv6 addresses of CEs are distinguishable from all other I= Pv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for= addresses that actually are 4rd CE addresses.
=A0
=A0
we need to make sure if the NAT64s make bot= h src and dst addresses checksum-neutral.
Correct, iff the host address has = the V octet.

1. without the V-o= ctet, CE and NAT64 can also distinguish the 4rd-CE addresses from others.= =A0

True, but while testing the V = octet is sufficient in 4rd, the NAT64 has in MAP to process mapping rules t= o find for null subnet IDs whose lengths depend on which mapping rule appli= es.
That's IMHO one instance where the V-octet potential is clear.


2. even with the V-octet, do you mean B's IPv4 address also transl= ated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=A0
=

Yes (see above).

if 2 is true,= why you use stateful NAT64+ here for B rather than a stateless one?
=

Because we consider hosts that are = not assigned any public IPv4 address, even shared.

if 2 is not true, then the NAT64 can use any arbitrary IPv6 addre= ss for B's communications, and such a case results only A's mapped = address is checksum-neutral, and thus anyway L4 adjustment is needed.=A0

if 2 is true, i do suggest you naming NAT64+ as NAT64- = instead, because NAT64 doesn't have the limitation on the IPv6 address = pool in use.=A0

Suggestio= n not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as expl= ained above, NAT64+ synthesizes its IPv6 source addresses using its unchang= ed /64 prefix.=A0


3. RFC6535 states, explicitly, "Use of= BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the abov= e technical discussion can omit this for the time being).=A0

Right.

RD


=




- maoke=A0
=A0

i cannot imagine what the use case is. ple= ase specify!

Hope the pic= ture above helps.

RD



=A0
- maoke
=A0
=A0

RD=A0


- maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires








--00248c6a86e23382b404bb942b9a-- From despres.remi@laposte.net Mon Mar 19 01:48:29 2012 Return-Path: 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 3265A21F85F6 for ; Mon, 19 Mar 2012 01:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.084, 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 U8fn6v4ZwGFq for ; Mon, 19 Mar 2012 01:48:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1D21F85F3 for ; Mon, 19 Mar 2012 01:48:25 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id nLoP1i00137Y3f403LoPeB; Mon, 19 Mar 2012 09:48:23 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-145--495099420 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 09:48:22 +0100 Message-Id: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF 9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 08:48:29 -0000 --Apple-Mail-145--495099420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 09:16, Maoke a =E9crit : >=20 >=20 > 2012/3/16 R=E9mi Despr=E9s > Maoke, >=20 > Let me try a more complete picture than before: >=20 >=20 > A1 -----. =20 > RFC6145-host| .-- 4rd BR --.=20 > | | | > A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 > 4rd-CE | | | UDP Lite appli = =20 > (no IPv4 @) | '-- NAT64+ --'=20 > | =20 > A3 -----'=20 > 4rd-CE =20 > (IPv4 @, shared or not) >=20 >=20 > 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) >=20 > Connectivities I get are:=20 > A2 =3D> B (via NAT64+) > A3 <=3D> B (via 4rd BR) > (There is no A1-B connectivity) >=20 > A2 is IPv6-only, right? There seems to be a misunderstanding on what is IPv6-only. a) A2 is dual stack. Being a CE node, it supports IPv4 applications, and = typically includes a NAT44.=20 b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has = no assigned public IPv4 address (even shared). c) Because it has received a NAT64+ mapping rule, it knows it can tunnel = IPv4 packets to the NAT64+. > if so, let me go down.=20 Not so =3D> doesn't apply.=20 (Yet some further comments below) RD > =20 >=20 > Anything missed? >=20 >=20 > Other detailed comments follow. >=20 > Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/15 R=E9mi Despr=E9s >>=20 >> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>>=20 >>>> i understand NAT64 makes translation between arbitrary IPv6 address = to arbitrary IPv4 address. i don't understand how you make CNP in any = IPv6 address. >>>=20 >>>=20 >>>> in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. >>>=20 >>> That's no the case at all(!).=20 >>> A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely unchanged). >>>=20 >>> The draft says: >>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd = tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address = format." >>> =20 >>> =20 >>> this phrase is not understood yet. do you mean using = 4rd-IPv6-address format for stateful translation service? >>=20 >> Yes (but, &s said, only for CE nodes that are 4rd capable (with the = advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). >>=20 >>> please draw an example of A <---> B communication as i did for = clarification. >>=20 >> Here is an example scenario: >>=20 >> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH = uses RFC6145)=20 >> A1 | =20 >> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server >> | UDP-lite = UDP-lite >> v4Appli-4rdCE --' capable B >> A2 =3D> A-B OK >>=20 >>=20 >> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but = exactly speaking, if the "not support" means passing-it-through without = checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right? >=20 > A NAT64 that supports UDP Lite MUST update checksum for hosts that = have native IPv6 addresses. > That's why A1 =3D> B doesn't work unless the NAT64 recognizes which = packets are those of IPv4 applications in DS hosts. >=20 > A1 -> B doesn't need stateful NAT64 but stateless service is enough. = well, stateful is also ok. it is true NAT64 supporting UDP-Lite must = update checksum.=20 > =20 >=20 >> B --> A is a question mark, if we use the NAT64+ which does nothing = with the L4 checksum, it is also not a problem. >=20 >=20 >> however, if we use, as you mentioned before, an UDP-Lite-aware update = of RFC6146, that may updates the checksum while the BIH doesn't know = that.=20 >=20 > Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) = to support more protocols than the two required by the RFC. It is just = an extension which cannot break anything (backward compatible). >=20 > confusing. upgrade vs. extension??=20 > =20 >=20 >=20 >>=20 >> my point here is: what is the use case with the details of = addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 = address to serve B for the communications, A1 BIH or A2 CE may do the = stateless processing successfuly. if NAT64+ hasn't such a address pool = for B, things will fail because only one among src and dst is = checksum-neutral.=20 >=20 > Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address = reaches the NAT64+ at this IPv6 address: >=20 > +-------------------------------+---+---+-------------+------+ > | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | > +-------------------------------+---+---+-------------+------+ > : 64 : 8 : 8 : 32 : 16 : >=20 > In the reverse direction, and for the same IPv4 address, it is the = same IPv6 address that must be synthesized by the NAT64+. >=20 > this address is used for A2 or used for B? if you mean B, then may i = conclude that NAT64+ is serving between A2 (native IPv6 address with = 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted = address having CNP)? if i can, may i further conclude that NAT64+ serves = only for the case where A2 has the 4rd-U-style address?=20 Let me repeat that: - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. - The only difference is that NAT64+ has a plus for addresses that are = those of 4RD-u CEs (better IPv4 transparency). > if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right?=20 >=20 > if so, i do really suggest you call it NAT64- instead of NAT64+ = because NAT64 can also serve hosts with any native IPv6 address to = connect with an IPv4 peer. >=20 > your answer below didn't respond my question, sorry. for example (in = the use case of NAT64 instead of NAT64-), A2 has native IPv6 address = 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE = might synthesize an IPv6 address for B, with the NAT64+ prefix and the = 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' through = IPv6; however, when this packet goes through the NAT64+, > because only B' is checksum-neutral while A2 is not, If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, = per Fig 6, 2001:db8:1234:5678:3000::=20 It IS checksum neutral. > NAT64+ passing it without L4 checksum adjustment will make B receive a = packet with wrong checksum, for any L4 protocols.=20 >=20 > the above example works well for TCP and UDP with today's NAT64, = without limitations on A2's address.=20 >=20 > - maoke > =20 > This is I suppose implicit, but it can advantageously be made explicit = in the draft. > Thanks. >=20 >=20 >>> Because 4rd IPv6 addresses of CEs are distinguishable from all other = IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY = for addresses that actually are 4rd CE addresses. >>> =20 >>> =20 >>> we need to make sure if the NAT64s make both src and dst addresses = checksum-neutral. >>=20 >> Correct, iff the host address has the V octet. >>=20 >> 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE = addresses from others.=20 >=20 > True, but while testing the V octet is sufficient in 4rd, the NAT64 = has in MAP to process mapping rules to find for null subnet IDs whose = lengths depend on which mapping rule applies. > That's IMHO one instance where the V-octet potential is clear. >=20 >=20 >> 2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=20 >=20 > Yes (see above). >=20 >> if 2 is true, why you use stateful NAT64+ here for B rather than a = stateless one? >=20 > Because we consider hosts that are not assigned any public IPv4 = address, even shared. >=20 >> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address = for B's communications, and such a case results only A's mapped address = is checksum-neutral, and thus anyway L4 adjustment is needed.=20 >>=20 >> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, = because NAT64 doesn't have the limitation on the IPv6 address pool in = use.=20 >=20 > Suggestion not retained ;-). > What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix.=20 >=20 >=20 >> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is = NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit = this for the time being).=20 >=20 > Right. >=20 > RD >=20 >=20 >=20 >=20 >=20 >>=20 >> - maoke=20 >> =20 >>=20 >>> i cannot imagine what the use case is. please specify! >>=20 >> Hope the picture above helps. >>=20 >> RD >>=20 >>=20 >>=20 >>> =20 >>> - maoke >>> =20 >>> =20 >>>=20 >>> RD=20 >>>=20 >>>=20 >>>> - maoke=20 >>>>=20 >>>> 2012/3/15 R=E9mi Despr=E9s >>>>=20 >>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>>=20 >>>> > Maoke, >>>> > >>>> > Thanks for this question. >>>> > This subject being new, I take it on a new thread. >>>> > >>>> > 2012-03-15 10:38, Maoke: >>>> > ... >>>> >> i didn't understand the how the stateful NAT64 benefits from = CNP. >>>> > >>>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >>>> > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs >>>> > These CEs need not being dependent on which NAT64 supports which = protocols. >>>> > >>>> > Note that the NAT64 doesn't need to have CNP code. It just = happens that host IPv6 addresses it sees are checksum neutral. (Thus, = IPv6 and IPv4 payloads are the same for all protocols that have ports at = the same place as TCP/UDP/..., and the same checksum algorithm) >>>>=20 >>>> Oops. >>>> This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >>>> Sorry for having hastily added this sentence. >>>>=20 >>>> RD >>>>=20 >>>> > >>>> > RD >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Softwires mailing list >>>> > Softwires@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-145--495099420 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
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 =  =3D> B (via NAT64+)
 A3 <=3D> B (via 4rd = BR)
(There is no A1-B = connectivity)

A2 = is IPv6-only, right?

There = seems to be a misunderstanding on what is IPv6-only.
a) A2 is = dual stack. Being a CE node, it supports IPv4 applications, = and typically includes a NAT44. 
b) Its IPv6 prefix = matches neither a CE nor the BR mapping rule, it has no assigned public = IPv4 address (even shared).
c) Because it has received a = NAT64+ mapping rule, it knows it can tunnel IPv4 packets to the = NAT64+.


if so, let me go = down. 

Not so =3D> = doesn't apply. 
(Yet some further comments = below)

RD


 

Anything = missed?


Other detailed comments follow.

Le = 2012-03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 14:47, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 11:45, Maoke a =E9crit :

i = understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address.


in other words, = we cannot limit NAT64 stateful service only serve those IPv6 addresses = with CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
 
 
this = phrase is not understood yet. do you mean using 4rd-IPv6-address format = for stateful translation service? =

Yes (but, &s said, = only for CE nodes that are 4rd capable (with the advantage of better = IPv4 transparency between CEs and NAT64+ than between RFC6145 and = NAT64).

please draw an example of A <---> B = communication as i did for clarification. =

Here is an example = scenario:

v4appli-BIH ----. =3D> A>B NOK (because, = according to RFC6535, BIH uses RFC6145) 
    =  A1         |    =  
                = :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
                |   =              UDP-lite     =                 =  UDP-lite
v4Appli-4rdCE --'         =         capable        =                 =  B
     A2         =  =3D> A-B OK


yes, BIH = uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly = speaking, if the "not support" means passing-it-through without checksum = adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right?

A NAT64 that supports UDP = Lite MUST update checksum for hosts that have native IPv6 = addresses.
That's why A1 =3D> B doesn't work unless the = NAT64 recognizes which packets are those of IPv4 applications in DS = hosts.

A1 -> B doesn't = need stateful NAT64 but stateless service is enough. well, stateful is = also ok. it is true NAT64 supporting UDP-Lite must update = checksum. 
 

B --> A is a question mark, if we use the NAT64+ which does = nothing with the L4 checksum, it is also not a problem. =


however, if we use, as you mentioned before, an UDP-Lite-aware update of = RFC6146, that may updates the checksum while the BIH doesn't know = that. 

Note that an = upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to support more = protocols than the two required by the RFC. It is just an extension = which cannot break anything (backward compatible).

confusing. upgrade vs. = extension?? 
 



my point here is: what is the use case with the = details of addressing? if and only if A1 or A2 is configured with an = RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of = checksum-neutral IPv6 address to serve B for the communications, A1 BIH = or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't = such a address pool for B, things will fail because only one among src = and dst is checksum-neutral. 

Sec 4.4 (8) says that a CE = that targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 = address:

+-------------------------------+--= -+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| = 0 |DST IPv4 add.|  CNP = |
+-------------------------------+---+---+-------------+------+=
:               64   =            : 8 : 8 :     =  32     :  16  :

In the reverse direction, and for the = same IPv4 address, it is the same IPv6 address that must be = synthesized by the = NAT64+.

this = address is used for A2 or used for B? if you mean B, then may i conclude = that NAT64+ is serving between A2 (native IPv6 address with 4rd-U CNP) = and B (synthesized by NAT64+ into another IPv6-converted address having = CNP)? if i can, may i further conclude that NAT64+ serves only for the = case where A2 has the 4rd-U-style = address? 

Let me repeat = that:
- NAT64+ works as a NAT64 for addresses that aren't = 4rd-u style.
- The only difference is that NAT64+ has a plus = for addresses that are those of 4RD-u CEs (better IPv4 = transparency).


if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right? 

if so, i do really suggest you = call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with = any native IPv6 address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry. = for example (in the use case of NAT64 instead of NAT64-), A2 has native = IPv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is = 192.32.77.50. the CE might synthesize an IPv6 address for B, with the = NAT64+ prefix and the 0xc0204d32 and a CNP embedded, say B', and let A2 = connect to B' through IPv6; however, when this packet goes through the = NAT64+,

because only B' is checksum-neutral while A2 = is not,

If the /64 of A2 = is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, per = Fig 6, 2001:db8:1234:5678:3000::<CNP> 
It IS = checksum neutral.

NAT64+ passing it without L4 checksum = adjustment will make B receive a packet with wrong checksum, for any L4 = protocols. 

the above example works well for TCP and UDP with = today's NAT64, without limitations on A2's = address. 

- = maoke
 
This is I suppose = implicit, but it can advantageously be made explicit in the = draft.
Thanks.


Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE = addresses.
 
 
we need to make sure if the NAT64s = make both src and dst addresses = checksum-neutral.
Correct, iff the host address = has the V octet.

1. without = the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from = others. 

True, but while testing the = V octet is sufficient in 4rd, the NAT64 has in MAP to process mapping = rules to find for null subnet IDs whose lengths depend on which mapping = rule applies.
That's IMHO one instance where the V-octet potential is = clear.


2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 = address? 

Yes (see = above).

if 2 is = true, why you use stateful NAT64+ here for B rather than a stateless = one?

Because we consider = hosts that are not assigned any public IPv4 address, even shared.

if 2 is not true, then the NAT64 can use any = arbitrary IPv6 address for B's communications, and such a case results = only A's mapped address is checksum-neutral, and thus anyway L4 = adjustment is needed. 

if 2 is true, i do suggest you naming NAT64+ as = NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 = address pool in = use. 

Suggestion = not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix. 


3. RFC6535 states, explicitly, "Use of = BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above = technical discussion can omit this for the time = being). 

Right.

RD




<= br>

- maoke 
 

i cannot imagine what the use case is. = please specify!

Hope = the picture above helps.

RD



 
- = maoke
 
 

RD 


- maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires









= --Apple-Mail-145--495099420-- From fibrib@gmail.com Mon Mar 19 02:21:12 2012 Return-Path: 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 3195521F85EA for ; Mon, 19 Mar 2012 02:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 81o5Np3NIdza for ; Mon, 19 Mar 2012 02:21:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84821F8550 for ; Mon, 19 Mar 2012 02:21:09 -0700 (PDT) Received: by qaea16 with SMTP id a16so680576qae.10 for ; Mon, 19 Mar 2012 02:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rl7gFHeR5JSAxwJpzxgiIY1Az39/yMW8OdAYO50b9xY=; b=winBFWIZIeB9xK1hdiJ+UD9+2li1Yxh4Dy1DTnkiH5rlgfxZkAtvuabmlQZXDswEYH RhJZ4j1u2ooUeOAofHPuj2SUzLC892Xm9bvIon8MOsCGnqhWCP2lDVDIWB7CeKpl/Abn 38ucwy7RP5Afke4ZG0vIuhn3JznQI8Lk6Z44GIqvcmJ3I602Eaeubll9aAtbAZuxGu1q SY2NBbBYvTuJ1dztbrjTpFG9tUtvcTMS/Z0C6rDU8JgRqJhSrijGdFsXd7zysWmRPgDN 0BDO+4vODQoQx+ixCLG1KUZwnIImOWCQs0EHnee7tok4FLaFQQDBNOIBItIqhP0bsAgB gyLQ== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr14546514qab.39.1332148869475; Mon, 19 Mar 2012 02:21:09 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 02:21:09 -0700 (PDT) In-Reply-To: References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> Date: Mon, 19 Mar 2012 09:21:09 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47e272e0c04bb9514f8 Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 09:21:12 -0000 --20cf3074b47e272e0c04bb9514f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/19 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 09:16, Maoke a =E9crit : > > > > 2012/3/16 R=E9mi Despr=E9s > >> 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 =3D> B (via NAT64+) >> A3 <=3D> B (via 4rd BR) >> (There is no A1-B connectivity) >> > > A2 is IPv6-only, right? > > > There seems to be a misunderstanding on what is IPv6-only. > a) A2 is dual stack. Being a CE node, it supports IPv4 applications, and > typically includes a NAT44. > b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has n= o > assigned public IPv4 address (even shared). > c) Because it has received a NAT64+ mapping rule, it knows it can tunnel > IPv4 packets to the NAT64+. > > > if so, let me go down. > > > Not so =3D> doesn't apply. > (Yet some further comments below) > > RD > > > > >> >> Anything missed? >> >> >> Other detailed comments follow. >> >> Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >> >> >> >> 2012/3/15 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >>> >>> >>> >>> 2012/3/15 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>>> >>>> i understand NAT64 makes translation between arbitrary IPv6 address to >>>> arbitrary IPv4 address. i don't understand how you make CNP in any IPv= 6 >>>> address. >>>> >>>> >>>> >>>> in other words, we cannot limit NAT64 stateful service only serve thos= e >>>> IPv6 addresses with CNP. >>>> >>>> >>>> That's no the case at all(!). >>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t >>>> worked before still works completely unchanged). >>>> >>>> The draft says: >>>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support >>>> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-addr= ess >>>> format." >>>> >>>> >>> >>> this phrase is not understood yet. do you mean using 4rd-IPv6-address >>> format for stateful translation service? >>> >>> >>> Yes (but, &s said, only for CE nodes that are 4rd capable (with the >>> advantage of better IPv4 transparency between CEs and NAT64+ than betwe= en >>> RFC6145 and NAT64). >>> >>> please draw an example of A <---> B communication as i did for >>> clarification. >>> >>> >>> Here is an example scenario: >>> >>> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH uses >>> RFC6145) >>> A1 | >>> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server >>> | UDP-lite UDP-lite >>> v4Appli-4rdCE --' capable B >>> A2 =3D> A-B OK >>> >>> >> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactl= y >> speaking, if the "not support" means passing-it-through without checksum >> adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing >> with the L4, right? >> >> >> A NAT64 that supports UDP Lite MUST update checksum for hosts that have >> native IPv6 addresses. >> That's why A1 =3D> B doesn't work unless the NAT64 recognizes which pack= ets >> are those of IPv4 applications in DS hosts. >> > > A1 -> B doesn't need stateful NAT64 but stateless service is enough. well= , > stateful is also ok. it is true NAT64 supporting UDP-Lite must update > checksum. > > >> >> B --> A is a question mark, if we use the NAT64+ which does nothing wit= h >> the L4 checksum, it is also not a problem. >> >> >> >> however, if we use, as you mentioned before, an UDP-Lite-aware update of >> RFC6146, that may updates the checksum while the BIH doesn't know that. >> >> >> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to >> support more protocols than the two required by the RFC. It is just an >> extension which cannot break anything (backward compatible). >> > > confusing. upgrade vs. extension?? > > >> >> >> >> my point here is: what is the use case with the details of addressing? i= f >> and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U >> address while NAT64+ has a pool of checksum-neutral IPv6 address to serv= e B >> for the communications, A1 BIH or A2 CE may do the stateless processing >> successfuly. if NAT64+ hasn't such a address pool for B, things will fai= l >> because only one among src and dst is checksum-neutral. >> >> >> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address >> reaches the NAT64+ at this IPv6 address: >> >> +-------------------------------+---+---+-------------+------+ >> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >> +-------------------------------+---+---+-------------+------+ >> : 64 : 8 : 8 : 32 : 16 : >> >> In the reverse direction, and for the same IPv4 address, it is the same >> IPv6 address that must be synthesized by the NAT64+. >> > > this address is used for A2 or used for B? if you mean B, then may i > conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd-= U > CNP) and B (synthesized by NAT64+ into another IPv6-converted address > having CNP)? if i can, may i further conclude that NAT64+ serves only for > the case where A2 has the 4rd-U-style address? > > > Let me repeat that: > - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. > - The only difference is that NAT64+ has a plus for addresses that are > those of 4RD-u CEs (better IPv4 transparency). > accepted. but i have pointed out the "better transparency" has some cost and uncertaity up to now (see another thread). > > > if the A2 is configured with any IPv6 address, for example, address with > the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, right= ? > > if so, i do really suggest you call it NAT64- instead of NAT64+ because > NAT64 can also serve hosts with any native IPv6 address to connect with a= n > IPv4 peer. > > your answer below didn't respond my question, sorry. for example (in the > use case of NAT64 instead of NAT64-), A2 has native IPv6 address > 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE mig= ht > synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204d= 32 > and a CNP embedded, say B', and let A2 connect to B' through IPv6; howeve= r, > when this packet goes through the NAT64+, > > > because only B' is checksum-neutral while A2 is not, > > > If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, per > Fig 6, 2001:db8:1234:5678:3000:: > It IS checksum neutral. > well, it is saying A2 must have the 4rd address in order to get the benefit of NAT64-, right? i have typed "for example (in the use case of NAT64 instead of NAT64-), ..." as the prerequisite of the above discussion. 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. 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. 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. i think we are common that a. is true, right? do you mean c. instead of b. = ? thanks, maoke > > NAT64+ passing it without L4 checksum adjustment will make B receive a > packet with wrong checksum, for any L4 protocols. > > the above example works well for TCP and UDP with today's NAT64, without > limitations on A2's address. > > - maoke > > >> This is I suppose implicit, but it can advantageously be made explicit i= n >> the draft. >> Thanks. >> >> >> Because 4rd IPv6 addresses of CEs are distinguishable from all other >>>> IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ON= LY >>>> for addresses that actually are 4rd CE addresses. >>>> >>>> >>> >>> we need to make sure if the NAT64s make both src and dst addresses >>> checksum-neutral. >>> >>> Correct, iff the host address has the V octet. >>> >> >> 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE >> addresses from others. >> >> >> True, but while testing the V octet is sufficient in 4rd, the NAT64 has >> in MAP to process mapping rules to find for null subnet IDs whose length= s >> depend on which mapping rule applies. >> That's IMHO one instance where the V-octet potential is clear. >> >> >> 2. even with the V-octet, do you mean B's IPv4 address also translated >> (by the NAT64+) to a CNP-and-V-containing IPv6 address? >> >> >> Yes (see above). >> >> if 2 is true, why you use stateful NAT64+ here for B rather than a >> stateless one? >> >> >> Because we consider hosts that are not assigned any public IPv4 address, >> even shared. >> >> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for >> B's communications, and such a case results only A's mapped address is >> checksum-neutral, and thus anyway L4 adjustment is needed. >> >> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because >> NAT64 doesn't have the limitation on the IPv6 address pool in use. >> >> >> Suggestion not retained ;-). >> What you call the IPv6 address pool isn't a reserved pool: as explained >> above, NAT64+ synthesizes its IPv6 source addresses using its unchanged = /64 >> prefix. >> >> >> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT >> RECOMMENDED [RFC6180]" (but the above technical discussion can omit this >> for the time being). >> >> >> Right. >> >> RD >> >> >> >> >> >> >> - maoke >> >> >>> >>> i cannot imagine what the use case is. please specify! >>> >>> >>> Hope the picture above helps. >>> >>> RD >>> >>> >>> >>> >>> - maoke >>> >>> >>>> >>>> >>>> RD >>>> >>>> >>>> - maoke >>>> >>>> 2012/3/15 R=E9mi Despr=E9s >>>> >>>>> >>>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>>> >>>>> > Maoke, >>>>> > >>>>> > Thanks for this question. >>>>> > This subject being new, I take it on a new thread. >>>>> > >>>>> > 2012-03-15 10:38, Maoke: >>>>> > ... >>>>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>>>> > >>>>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels >>>>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payl= oads. >>>>> > Any protocol that this NAT64 supports is then supported e2e for >>>>> 4rd-u CEs >>>>> > These CEs need not being dependent on which NAT64 supports which >>>>> protocols. >>>>> > >>>>> > Note that the NAT64 doesn't need to have CNP code. It just happens >>>>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 an= d IPv4 >>>>> payloads are the same for all protocols that have ports at the same p= lace >>>>> as TCP/UDP/..., and the same checksum algorithm) >>>>> >>>>> Oops. >>>>> This is only true for the IPv6 host address. To construct an IPv6 >>>>> address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. >>>>> (This is to maintain the property that that middleboxes can treat tun= nel >>>>> packets as valid IPv6 packets. Not a big deal, but necessary). >>>>> Sorry for having hastily added this sentence. >>>>> >>>>> RD >>>>> >>>>> > >>>>> > RD >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Softwires mailing list >>>>> > Softwires@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > --20cf3074b47e272e0c04bb9514f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 09:16, = Maoke a =E9crit :


=
2012/3/16 R=E9mi Despr=E9s <despres.= remi@laposte.net>
Maoke,

Let me try a = more complete picture than before:


= =A0 =A0 A1 -----. =A0 =A0 =A0 =A0 =A0=A0
RFC6145-host|=A0 =A0 =A0= =A0 =A0 =A0.-- 4rd BR --.=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 A2 -----:--(v6net)--: =A0 =A0 =A0 =A0 =A0 =A0:--(v4 = Internet)--- B=A0
=A0 4rd-CE =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0UDP Lite=A0appli=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0
(no IPv4 @) | =A0 =A0 =A0 =A0 =A0=A0&= #39;-- NAT64+ --'=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0
=A0 =A0 A3 ---= --'=A0
=A0 4rd-CE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
(IPv4 @, sha= red=A0or not)


NAT64+ is s= upposed to have a bindings for UDP Lite, either only for 4rd IPv6 addresses= (the minimum), or also for native IPv6 addresses (the complete upgrade, wi= th UDP-Lite checksum adjustment for these addresses)

Connectivities I get are:=A0
=A0A2 =A0=3D>= B (via NAT64+)
=A0A3 <=3D> B (via 4rd BR)
(There= is no A1-B connectivity)

A2 is IPv6-only, right?

T= here seems to be a misunderstanding on what is IPv6-only.
a) A2 i= s dual stack.=A0Being a CE node, it=A0supports IPv4 applications, and typic= ally includes a NAT44.=A0
b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it ha= s no assigned public IPv4 address (even shared).
c) Because it ha= s received a NAT64+ mapping rule, it knows it can tunnel IPv4 packets to th= e NAT64+.


if so, let me go down.=A0

Not so =3D> doesn't apply.=A0
(Yet some= further comments below)

RD


=
=A0

Anything missed?


Other detailed comments follow.

Le 2012= -03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-15 =E0 14:47, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte= .net>

Le 2012-03-15 =E0 11:45, = Maoke a =E9crit :

i understand NAT6= 4 makes translation between arbitrary IPv6 address to arbitrary IPv4 addres= s. i don't understand how you make CNP in any IPv6 address.


in other words, we = cannot limit NAT64 stateful service only serve those IPv6 addresses with CN= P.

That's no the case at all(!).= =A0
A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t worked before still works completely unchanged).

The draft says:
"NAT64+: =A0An ISP NAT64 of [RFC6146] that = is upgraded to support 4rd=A0tunneling when IPv6 addresses it deals with ha= ve the 4rd-IPv6-address format."
=A0
=A0
this phrase is no= t understood yet. do you mean using 4rd-IPv6-address format for stateful tr= anslation service?

Yes (but, = &s said, only for CE nodes that are 4rd capable (with the advantage of = better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NA= T64).

ple= ase draw an example of A <---> B communication as i did for clarifica= tion.

Here is an example= scenario:

v4appli-BIH ----. =3D> A>B NOK (because, accordin= g to RFC6535, BIH uses RFC6145)=A0
=A0 =A0 =A0A1 =A0 =A0 =A0 =A0 = |=A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :----(v6net)----- NA= T64+ ---(IPv4 Internet)--- Server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-l= ite =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-lite
v4Appli-4= rdCE --' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0capable=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B
=A0 =A0 =A0A2 =A0 =A0 =A0 =A0 = =A0=3D> A-B OK


yes, BIH uses = RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, i= f the "not support" means passing-it-through without checksum adj= ustment, A --> B is fine because neither BIH nor NAT64+ does nothing wit= h the L4, right?

A NAT64 that supports UDP Lite= MUST update checksum for hosts that have native IPv6 addresses.
= That's why A1 =3D> B doesn't work unless the NAT64 recognizes wh= ich packets are those of IPv4 applications in DS hosts.

A1 -> B doesn't n= eed stateful NAT64 but stateless service is enough. well, stateful is also = ok. it is true NAT64 supporting UDP-Lite must update checksum.=A0
=A0

B --> A is a question mark, if we use the NAT64+ which does nothin= g with the L4 checksum, it is also not a problem.
=


however, if we use, as you mentioned before, an UDP-Lite-aware update of RF= C6146, that may updates the checksum while the BIH doesn't know that.= =A0

Note that an upgrade of RF= C6146 isn't needed for A NAT64 (and NAT64+) to support more protocols t= han the two required by the RFC. It is just an extension which cannot break= anything (backward compatible).

confusing. upgrade vs. extensi= on??=A0
=A0



my point here is: what is the use case with the details= of addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 add= ress to serve B for the communications, A1 BIH or A2 CE may do the stateles= s processing successfuly. if NAT64+ hasn't such a address pool for B, t= hings will fail because only one among src and dst is checksum-neutral.=A0<= /div>

Sec 4.4 (8) says that a CE tha= t targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 addres= s:

+-------------------------------+---+---+-= ------------+------+
| =A0 =A0 =A0NAT64+ IPv6 prefix =A0 =A0 =A0 |"u"| 0 |DST IPv= 4 add.| =A0CNP |
+-------------------------------+---+---+-------= ------+------+
: =A0 =A0 =A0 =A0 =A0 =A0 =A0 64 =A0 =A0 =A0 =A0 = =A0 =A0 =A0: 8 : 8 : =A0 =A0 =A032 =A0 =A0 : =A016 =A0:

In the reverse direction, and=A0for the same IPv4= address,=A0it is the same IPv6 address that must be synthesized by the NAT= 64+.

this address i= s used for A2 or used for B? if you mean B, then may i conclude that NAT64+= is serving between A2 (native IPv6 address with 4rd-U CNP) and B (synthesi= zed by NAT64+ into another IPv6-converted address having CNP)? if i can, ma= y i further conclude that NAT64+ serves only for the case where A2 has the = 4rd-U-style address?=A0

Let me repeat that:
- NAT64+ works as a NAT64 for addresses that aren't 4rd-u style.<= /div>
- The only difference is that NAT64+ has a plus for addresses tha= t are those of 4RD-u CEs (better IPv4 transparency).

accepted. but i have pointed o= ut the "better transparency" has some cost and uncertaity up to n= ow (see another thread).=A0
=A0

<= br>
if the A2 is configured with any IPv6 address, for example, address wi= th the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, righ= t?=A0

if so, i do really suggest you call it NAT64= - instead of NAT64+ because NAT64 can also serve hosts with any native IPv6= address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry= . for example (in the use case of NAT64 instead of NAT64-), A2 has native I= Pv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. = the CE might synthesize an IPv6 address for B, with the NAT64+ prefix and t= he 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' = through IPv6; however, when this packet goes through the NAT64+,

because only B' is checksum-neutral while A2 is not,
<= /blockquote>

If the /64 of A2 is=A02001:db8:1234:5= 678::/64, its=A04rd IPv6 address is,=A0per Fig 6,=A02001:db8:1234:5678:3000= ::<CNP>=A0
It IS checksum neutral.

<= div>well, it is saying A2 must have the 4rd address in order to get the ben= efit of NAT64-, right? i have typed "for example (in the use case of N= AT64 instead of NAT64-), ..." as the prerequisite of the above discuss= ion. let me have the following propositions:=A0

a. NAT64 suitable for any case no matter A2 is assigned= with any kind of address, but currently only works for TCP and UDP.=A0
b. NAT64+ works for the cases where A2 is assigned with a special ty= pe of IPv6 address with the CNP, without need to update checksum for any L4= protocols.=A0
c. NAT64+ works like:=A0
=A0 =A0if A2 has a V-CNP-address, t= hen it doesn't update the checksum for any L4 protocols;=A0
= =A0 =A0if A2 has any other kind of native IPv6 address, then NAT64+ works j= ust like NAT64, updating the checksum but also currently only works for TCP= and UDP.=A0

i think we are common that a. is true, right? do you me= an c. instead of b. ?

thanks,
maoke

=A0

NAT64+ passing it witho= ut L4 checksum adjustment will make B receive a packet with wrong checksum,= for any L4 protocols.=A0

the above example works well for TCP and UDP with today= 's NAT64, without limitations on A2's address.=A0

- maoke
=A0
This is I suppose implic= it, but it can advantageously be made explicit in the draft.
Than= ks.


Because 4rd IPv6 addresses of CEs are distinguishable from all other I= Pv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for= addresses that actually are 4rd CE addresses.
=A0
=A0
we need to make sure if the NAT64s make bot= h src and dst addresses checksum-neutral.
Correct, iff the host address has = the V octet.

1. without the V-o= ctet, CE and NAT64 can also distinguish the 4rd-CE addresses from others.= =A0

True, but while testing the V = octet is sufficient in 4rd, the NAT64 has in MAP to process mapping rules t= o find for null subnet IDs whose lengths depend on which mapping rule appli= es.
That's IMHO one instance where the V-octet potential is clear.


2. even with the V-octet, do you mean B's IPv4 address also transl= ated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=A0
=

Yes (see above).

if 2 is true,= why you use stateful NAT64+ here for B rather than a stateless one?
=

Because we consider hosts that are = not assigned any public IPv4 address, even shared.

if = 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B'= s communications, and such a case results only A's mapped address is ch= ecksum-neutral, and thus anyway L4 adjustment is needed.=A0

if 2 is true, i do suggest you naming NAT64+ as NAT64- = instead, because NAT64 doesn't have the limitation on the IPv6 address = pool in use.=A0

Suggestio= n not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as expl= ained above, NAT64+ synthesizes its IPv6 source addresses using its unchang= ed /64 prefix.=A0


3. RFC6535 states, explicitly, "Use of= BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the abov= e technical discussion can omit this for the time being).=A0

Right.

RD






- maoke=A0
=A0

i cannot imagine what the use case is. ple= ase specify!

Hope the pic= ture above helps.

RD



=A0
- maoke
=A0
=A0

RD=A0


- maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires










--20cf3074b47e272e0c04bb9514f8-- From despres.remi@laposte.net Mon Mar 19 03:05:02 2012 Return-Path: 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 BA91C21F85B5 for ; Mon, 19 Mar 2012 03:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.082, 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 7sm3CW7D3rYi for ; Mon, 19 Mar 2012 03:05:01 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2138621F8589 for ; Mon, 19 Mar 2012 03:04:59 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id nN4x1i00C37Y3f403N4xpu; Mon, 19 Mar 2012 11:04:58 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-146--490504582 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 11:04:57 +0100 Message-Id: <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 10:05:02 -0000 --Apple-Mail-146--490504582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 06:19, Maoke a =E9crit : > Remi,=20 >=20 > please see inline.=20 >=20 > 2012/3/16 R=E9mi Despr=E9s > Maoke, >=20 > First: > - My apologies for having not answered this email before receiving a = reminder (it was by mistake lost in a stack of non-urgent things to do). > - Thanks for the clear and detailed analysis. >=20 > More comments in line. >=20 > Le 2012-03-13 =E0 10:53, Maoke a =E9crit : >=20 >> Remi,=20 >>=20 >> discussion on R-16 of Sec 4.7: >>=20 >> > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], = it >> > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet >> > MUST contain the first 8 octets of the discarded-packet IP >> > payload. >>=20 >> now the ICMPv6 error message contains the payload as the = "header-mapped" IPv6 PDU of the discarded packet. right? so does 4rd-U = CE or BR translates this ICMPv6 payload to ICMPv4 payload as RFC6145 = does? does 4rd-U applies the checksum adjustment algorithm between = ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP doesn't = help) >>=20 >> if it does, you'd better cite RFC6145 here. if it doesn't, please = specify.=20 >=20 > dear Remi, you didn't respond this.=20 AFAIK, I did, but somewhere else (see ** below).=20 >> > If the CE or BR has a global IPv4 address, this >> > address MUST be used as source of this packet. Otherwise, the >> > unspecified address 0.0.0.0 SHOULD be used as this source. >>=20 >> let me draw an example for that: >>=20 >> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; = router R2 here)--- B >>=20 >> 1. consider ICMPv6 error happens at R1 >>=20 >> original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >>=20 >> CE translates (precisely speaking, "header-maps") it to:=20 >> +------------+----------------------------------------------+ >> | IPv6 | payload | >> | header, H2 | P1 | >> +------------+----------------------------------------------+ >>=20 >> R1 found a error for this IPv6 packet, it generates an ICMPv6 report: >> +------------+--------+-----------+-------------------------+ >> | IPv6 | ICMPv6 | IPv6 | payload (truncated to | >> | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | >> +------------+--------+-----------+-------------------------+ >> \_______________ ___________________/ >> V >> as the ICMPv6 error message body >>=20 >> this message feedbacked to CE, who will translate it to: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >>=20 >> it is clear that 4rd-U address mapping is applied for=20 >>=20 >> H1 -> H2 -> H4 >>=20 >> H3 has the source address of R1 while the destination address as the = CE. >>=20 >> then, CE's (or BR's for the case of B --> A) global IPv4 address or = 0.0.0.0 will be used in H5, right? >=20 > Right. >=20 >> first of all, the 0.0.0.0 might be a wrong choice. Unspecified = Address represents either a host not yet having gained an IPv4 address = on the LOCAL network or an application listening on any addresses of a = host. >=20 >> packet with 0.0.0.0 might be dropped by any intermediate routers of = current implementations.=20 >=20 > This address never appears on any IPv4 link. > Intermediate routers being IPv6, there is no problem. >=20 > i doubt there is not a use-case where between A and CE there are some = subnet routers.=20 > =20 > OK? 4rd-u isn't concerned with what happens between A and CE. There, internal hosts have RFC1918 addresses and external hosts public = IPv4 addresses. Anything missing? >> > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unreachable, No >> > route to destination") MUST be translated into ICMPv4 Type =3D 3 >> > and Code =3D 0 (Destination unreachable, Net unreachable). >> > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit >> > exceeded in transit) MUST be translated into ICMPv4 Type =3D 11 >> > and Code =3D 0 (Time exceeded, Time to live exceeded in >> > transit). >>=20 >> for C1 -> C2 translation, i have the following comments: >>=20 >> 1) here 4rd-U uses the CE's global IPv4 address >=20 >> (i think "global" refers to a non-shared one, right?) >=20 > Global address is used as a synonymous of public address. > If somewhere it seems to mean non-shared address, it must be a = mistake. >=20 >=20 >> to represent all the error generator inside in the IPv6 domain. this = surely fits a "tunnel" behavior that attempts to treat the delivery from = CE to BR as a "link", and therefore the error is responded by the link's = end point.=20 >> 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit = exceeded and ICMPv6 unreachable node should be translated as ICMPv4 = destination unreachable (Type =3D 3) host unreachable (Code =3D 1), = because it should indicates the link problem of the tunnel. >> 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a = typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter = consumes the TTL per physical hop. for example, if we set TTL =3D 32 in = H1, tunneling means from A to B communication may succeed as long as = (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well = connected; while current 4rd-U means from A to B communication may = succeed only when total numbers of intermediate routers doesn't exceed = 31.=20 >>=20 >> this is why typical tunneling solutions initialize the out-header's = IPv6 Hop Limit to 255. when routing loop happens in the IPv6 domain and = Hop Limit is consumed out, the link is considered broken. >=20 > I don't see any problem with having, at tunnel exit, the TTL decreased = by the number of traversed routers. >=20 > you don't see it a problem because you reject the common understanding = about "tunnel" as a virtual link, but define the so-called 4rd-tunnel. = it has been admitted by your statement that "4rd tunnel is not any = tunnel". Come on! This sentence, which isn't in the draft, cannot be understood off = context. The draft is clear about what a 4rd tunnel is, and the point is that, = hosts *cannot distinguish* between packets that are natively routed e2e, = and those that are tunneled on their way, any number of times and with = any tunnel types. > my understanding here is "4rd tunnel" is ACTUALLY another path section = of translation, according to its behavior. if you would say "4rd-U is a = translation solution alternative to RFC6145 providing better = transparency in double-translation environment with some cost and = uncertain risk", i would totally accept without any further argument. Both of us know that double translation in general looses some = information. What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique. Hope you can accept this as sufficient, so that we can keep this work on = real and substantial problems. >> 2. consider ICMPv4 error happens at R2:=20 >>=20 >> R2 sees original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >>=20 >> R2 has found some error with that packet, issuing an ICMPv4 message = and sending to A: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >>=20 >> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >> +------------+--------+--------+--------------+ >> | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+--------+--------------+ >>=20 >> woops, unfortunately, R1 also found something wrong. R1 generates an = ICMPv6 report, responding back to B:=20 >> +------------+--------+------------+--------+--------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+------------+--------+--------+--------------+ >>=20 >> BR sees this and makes translation to:=20 >> +---------+--------+---------+--------+--------+------------+ >> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >> +---------+--------+---------+--------+--------+------------+ >> |<------- 8 octet ----------->| >> \___________________ __________________/ >> V >> as the ICMPv4 error message body >>=20 >> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. = here 4rd-U can have two options: >> 1) let it be but depends on the IPv4 Internet routers, or host B = itself to drop the ICMP of ICMP;=20 >> 2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet.=20 >>=20 >> i doubt either is good. anyway, no matter which is used, 4rd-U must = deal with this issue. (sorry if i missed some text where it has been = done.) (**) > The right choice is clearly 2 (RFC792 rightly says: "To avoid the = infinite regress of messages about messages etc., no ICMP messages are = sent about ICMP messages.") > sure 2) is better than 1). however, the remained problem is IPv6 = carrying ICMPv4. i just summarize my concerns here in order the = community can judge the impact:=20 > #1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 = header contained in the ICMP error message. That's getting tricky. Will you be in Paris so that we can discuss with a piece of paper = details of what you have in mind? (In the following 3 days, I will be = busy otherwise, and will have little or no access to email.) > #2. such kind of packet loses IP header integrity mechanism as neither = IPv4's header checksum nor the ICMPv6's checksum containing = pseudo-header is included.=20 Packets discussed here will never be delivered anyway (ICMP about ICMP). I don't see how any practical concern would appear here.=20 > because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well.=20 >=20 > (neither MAP-T nor MAP-E has the similar concern). For MAP-E, of course (compatibility with IPv6-only middle boxes is off = scope). For MAP-T, see above. > =20 >=20 > - maoke=20 (**) > It can be made more explicit in the specification. In R-16, after "If a CE or BR receives an ICMPv6 error message = [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we = could add "(unless the message concerns a ICMP message, as required by = [RFC0792] to avoid ICMP about ICMP)". Thanks, RD > Thanks. >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >>=20 >> cheers, >> maoke >>=20 >> 2012/3/12 R=E9mi Despr=E9s >> Hello, all, >>=20 >> An updated version of draft-despres-softwire-4rd-u is now available = at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>=20 >> Differences with -04 include: >> - DHCPv6 options are now specified >> - various errors and typos are corrected >> - some clarifications are added, following received questions and = comments >> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs) >> - An editor's note has been added, following a WG-ML discussion, = about an additional Mapping-rule parameter that might be needed to = assign privileged ports to to some shared-address CEs. >> - Document layout has been adjusted as a result of other = modifications. >> - the authors list has been completed. >>=20 >> Questions and comments are most welcome. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-146--490504582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Remi, 

please see = inline. 

2012/3/16 R=E9mi = Despr=E9s <despres.remi@laposte.net>
Maoke,

First:
= - My apologies for having not answered this email before receiving a = reminder (it was by mistake lost in a stack of non-urgent things to = do).
- Thanks for the clear and detailed = analysis.

More comments in = line.

Le 2012-03-13 =E0 10:53, Maoke a =E9crit = :

Remi, 

discussion on R-16 of Sec = 4.7:

  > R-16: If a CE or BR receives = an ICMPv6 error message [RFC4443], it
  > MUST = synthesize an ICMPv4 error packet [RFC0792]. This packet
  > MUST contain the first 8 octets of the = discarded-packet IP
  > payload. =

now the ICMPv6 error message contains the = payload as the "header-mapped" IPv6 PDU of the discarded packet. right? = so does 4rd-U CE or BR translates this ICMPv6 payload to ICMPv4 payload = as RFC6145 does? does 4rd-U applies the checksum adjustment algorithm = between ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP = doesn't help)

if it does, you'd better cite RFC6145 here. if it = doesn't, please = specify. 
dear Remi, you didn't respond = this. 

AFAIK, I did, = but somewhere else (see ** = below). 


  > If the CE or BR has a global IPv4 = address, this
  > address MUST be used as source of = this packet. Otherwise, the
  > unspecified address 0.0.0.0 SHOULD be used as this = source.

let me draw an example for = that:

A --- CE ----(IPv6 domain; router R1 = here)---- BR ----(IPv4 Internet; router R2 here)--- B

1. consider ICMPv6 error happens at = R1

original IPv4 packet at A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

CE translates (precisely speaking, = "header-maps") it to: 
=
+------------+----------------------------------------------+
| IPv6       | payload       =                     =            |
| header, H2 | P1 =                    =                     =    |
=
+------------+----------------------------------------------+

R1 found a error for this IPv6 packet, it generates an = ICMPv6 = report:
+------------+--------+-----------+----------------= ---------+
| IPv6       | ICMPv6 | IPv6     =  | payload (truncated to   |
| header, H3 | hdr, C1| = header, H2| fit in min IPv6 MTU),P2 = |
+------------+--------+-----------+-------------------------+<= /div>
                    =    \_______________ = ___________________/
        =                     =            V
    =                     =  as the ICMPv6 error message body

this = message feedbacked to CE, who will translate it to:
+---------+--------+--------+--------------+
| IPv4 =    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H5 | hdr, C2| hdr, H4| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

it is clear that 4rd-U address mapping is applied = for 

  H1 -> H2 -> = H4

H3 has the source address of R1 while the = destination address as the CE.

then, CE's (or BR's for the case of B --> A) = global IPv4 address or 0.0.0.0 will be used in H5, = right?

Right.

first of all, the 0.0.0.0 might be a = wrong choice. Unspecified Address represents either a host not yet = having gained an IPv4 address on the LOCAL network or an application = listening on any addresses of a host.

packet with = 0.0.0.0 might be dropped by any intermediate routers of current = implementations. 

This = address never appears on any IPv4 link.
Intermediate routers being IPv6, there is no = problem.

i doubt there = is not a use-case where between A and CE there are some subnet = routers. 
 
OK?

4rd-u isn't concerned with = what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 = addresses.
Anything = missing?


  > ICMPv6 Type =3D 1 and Code =3D 0 = (Destination unreachable, No
  > route to = destination") MUST be translated into ICMPv4 Type =3D 3
  = > and Code =3D 0 (Destination unreachable, Net unreachable).
  > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop = limit
  > exceeded in transit) MUST be translated = into ICMPv4 Type =3D 11
  > and Code =3D 0 (Time = exceeded, Time to live exceeded in
  > transit).

for C1 -> C2 = translation, i have the following = comments:

1) here 4rd-U uses the CE's = global IPv4 address

(i think "global" refers to a = non-shared one, = right?)

Global address = is used as a synonymous of public address.
If somewhere it = seems to mean non-shared address, it must be a mistake.


to = represent all the error generator inside in the IPv6 domain. this surely = fits a "tunnel" behavior that attempts to treat the delivery from CE to = BR as a "link", and therefore the error is responded by the link's end = point. 
2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit = exceeded and ICMPv6 unreachable node should be translated as ICMPv4 = destination unreachable (Type =3D 3) host unreachable (Code =3D 1), = because it should indicates the link problem of the tunnel.
3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is = a typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter = consumes the TTL per physical hop. for example, if we set TTL =3D 32 in = H1, tunneling means from A to B communication may succeed as long as = (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well = connected; while current 4rd-U means from A to B communication may = succeed only when total numbers of intermediate routers doesn't exceed = 31. 

this is why typical tunneling solutions = initialize the out-header's IPv6 Hop Limit to 255. when routing loop = happens in the IPv6 domain and Hop Limit is consumed out, the link is = considered broken.

I don't see any problem = with having, at tunnel exit, the TTL decreased by the number = of traversed = routers.

you = don't see it a problem because you reject the common understanding about = "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it has = been admitted by your statement that "4rd tunnel is not any = tunnel".

Come = on!
This sentence, which isn't in the draft, cannot be = understood off context.

The draft is clear = about what a 4rd tunnel is, and the point is that, hosts *cannot = distinguish* between packets that are natively routed e2e, and those = that are tunneled on their way, any number of times and with any tunnel = types.




my understanding here is = "4rd tunnel" is ACTUALLY another path section of translation, according = to its behavior. if you would say "4rd-U is a translation solution = alternative to RFC6145 providing better transparency in = double-translation environment with some cost and uncertain risk", i = would totally accept without any further = argument.

Both of us know = that double translation in general looses some = information.
What I wouldn't object to is to rename the = Reversible-header-mapping technique as Reversible-header-translation = technique.
Hope you can accept this as sufficient, so that we = can keep this work on real and substantial = problems.


2. consider ICMPv4 error happens at = R2: 

R2 sees original IPv4 packet at = A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

R2 has found some error with that packet, = issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H6 | hdr, C3| hdr, H1| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as = payload of = IPv6):
+------------+--------+--------+--------------+
| IPv6       | ICMPv4 | IPv4   | = truncated    |
| header, H7 | hdr, C3| hdr, H1| payload, P3  = |
+------------+--------+--------+--------------+

=
woops, unfortunately, R1 also found something wrong. R1 = generates an ICMPv6 report, responding back to B: 
=
+------------+--------+------------+--------+--------+----------= ----+
| IPv6       | ICMPv6 | IPv6 =       | ICMPv4 | IPv4   | truncated   =  |
| header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| = payload, P3  |
=
+------------+--------+------------+--------+--------+--------------+=

BR sees this and = makes translation = to: 
+---------+--------+----= -----+--------+--------+------------+
| IPv4    | ICMPv4 | IPv4    | ICMPv4 | = IPv4   | truncated  |
| hdr, H10| hdr, C5| hdr, = H9 | hdr, C3| hdr, H1| payload, = P4|
+---------+--------+---------+--------+--------+------------= +
        =                     =  |<------- 8 octet  = ----------->|
        =             \___________________ = __________________/
        =                     =             V
                  =        as the ICMPv4 error message = body

here an "ICMP of ICMP", which is not = allowed in ICMPv4, is generated. here 4rd-U can have two = options:
1) let it be but depends on the IPv4 Internet = routers, or host B itself to drop the ICMP of ICMP; 
2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet. 

i doubt either is = good. anyway, no matter which is used, 4rd-U must deal with this issue. = (sorry if i missed some text where it has been = done.)
<= /blockquote>

(**)
The right choice is = clearly 2 (RFC792 rightly says: "To avoid the infinite regress of = messages about messages etc., no ICMP messages are sent about ICMP = messages.")
<= br>
sure 2) = is better than 1). however, the remained problem is IPv6 carrying = ICMPv4. i just summarize my concerns here in order the community can = judge the impact: 
#1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error = message.

That's getting = tricky.
Will you be in Paris so that we can discuss with a = piece of paper details of what you have in mind? (In the following = 3 days, I will be busy otherwise, and will have little or no access to = email.)

#2. such kind of packet loses IP header = integrity mechanism as neither IPv4's header checksum nor the ICMPv6's = checksum containing pseudo-header is = included. 

Packets = discussed here will never be delivered anyway (ICMP about = ICMP).
I don't see how any practical concern would appear = here. 

=
because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well. 

(neither MAP-T nor MAP-E has the similar = concern).

For MAP-E, of = course (compatibility with IPv6-only middle boxes is off = scope).
For MAP-T, see above.

 

- = maoke 

(**)
It can be made = more explicit in the specification. =

In R-16, after  "If a CE or BR receives an ICMPv6 = error message [RFC4443], it  MUST synthesize an ICMPv4 error packet = [RFC0792]" we could add "(unless the message concerns a ICMP message, as = required by [RFC0792] to avoid ICMP about = ICMP)".

Thanks,
RD

=



Thanks.


Cheers,
RD



=

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 05

Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and = comments
- the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other = modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-146--490504582-- From despres.remi@laposte.net Mon Mar 19 03:22:59 2012 Return-Path: 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 6AF4A21F8669 for ; Mon, 19 Mar 2012 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.081, 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 z+Q14zXE0uTy for ; Mon, 19 Mar 2012 03:22:57 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8321F866A for ; Mon, 19 Mar 2012 03:22:56 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id nNNq1i00F37Y3f403NNq1f; Mon, 19 Mar 2012 11:22:54 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-147--489432496 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 11:22:49 +0100 Message-Id: <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF 9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 10:22:59 -0000 --Apple-Mail-147--489432496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 10:21, Maoke a =E9crit : >=20 >=20 > 2012/3/19 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 09:16, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/16 R=E9mi Despr=E9s >> Maoke, >>=20 >> Let me try a more complete picture than before: >>=20 >>=20 >> A1 -----. =20 >> RFC6145-host| .-- 4rd BR --.=20 >> | | | >> A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 >> 4rd-CE | | | UDP Lite appli = =20 >> (no IPv4 @) | '-- NAT64+ --'=20 >> | =20 >> A3 -----'=20 >> 4rd-CE =20 >> (IPv4 @, shared or not) >>=20 >>=20 >> 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) >>=20 >> Connectivities I get are:=20 >> A2 =3D> B (via NAT64+) >> A3 <=3D> B (via 4rd BR) >> (There is no A1-B connectivity) >>=20 >> A2 is IPv6-only, right? >=20 > There seems to be a misunderstanding on what is IPv6-only. > a) A2 is dual stack. Being a CE node, it supports IPv4 applications, = and typically includes a NAT44.=20 > b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it = has no assigned public IPv4 address (even shared). > c) Because it has received a NAT64+ mapping rule, it knows it can = tunnel IPv4 packets to the NAT64+. >=20 >=20 >> if so, let me go down.=20 >=20 > Not so =3D> doesn't apply.=20 > (Yet some further comments below) >=20 > RD >=20 >=20 >> =20 >>=20 >> Anything missed? >>=20 >>=20 >> Other detailed comments follow. >>=20 >> Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/15 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/15 R=E9mi Despr=E9s >>>>=20 >>>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>>>=20 >>>>> i understand NAT64 makes translation between arbitrary IPv6 = address to arbitrary IPv4 address. i don't understand how you make CNP = in any IPv6 address. >>>>=20 >>>>=20 >>>>> in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. >>>>=20 >>>> That's no the case at all(!).=20 >>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely unchanged). >>>>=20 >>>> The draft says: >>>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd = tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address = format." >>>> =20 >>>> =20 >>>> this phrase is not understood yet. do you mean using = 4rd-IPv6-address format for stateful translation service? >>>=20 >>> Yes (but, &s said, only for CE nodes that are 4rd capable (with the = advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). >>>=20 >>>> please draw an example of A <---> B communication as i did for = clarification. >>>=20 >>> Here is an example scenario: >>>=20 >>> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH = uses RFC6145)=20 >>> A1 | =20 >>> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- = Server >>> | UDP-lite = UDP-lite >>> v4Appli-4rdCE --' capable B >>> A2 =3D> A-B OK >>>=20 >>>=20 >>> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but = exactly speaking, if the "not support" means passing-it-through without = checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right? >>=20 >> A NAT64 that supports UDP Lite MUST update checksum for hosts that = have native IPv6 addresses. >> That's why A1 =3D> B doesn't work unless the NAT64 recognizes which = packets are those of IPv4 applications in DS hosts. >>=20 >> A1 -> B doesn't need stateful NAT64 but stateless service is enough. = well, stateful is also ok. it is true NAT64 supporting UDP-Lite must = update checksum.=20 >> =20 >>=20 >>> B --> A is a question mark, if we use the NAT64+ which does nothing = with the L4 checksum, it is also not a problem. >>=20 >>=20 >>> however, if we use, as you mentioned before, an UDP-Lite-aware = update of RFC6146, that may updates the checksum while the BIH doesn't = know that.=20 >>=20 >> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) = to support more protocols than the two required by the RFC. It is just = an extension which cannot break anything (backward compatible). >>=20 >> confusing. upgrade vs. extension??=20 >> =20 >>=20 >>=20 >>>=20 >>> my point here is: what is the use case with the details of = addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 = address to serve B for the communications, A1 BIH or A2 CE may do the = stateless processing successfuly. if NAT64+ hasn't such a address pool = for B, things will fail because only one among src and dst is = checksum-neutral.=20 >>=20 >> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address = reaches the NAT64+ at this IPv6 address: >>=20 >> +-------------------------------+---+---+-------------+------+ >> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >> +-------------------------------+---+---+-------------+------+ >> : 64 : 8 : 8 : 32 : 16 : >>=20 >> In the reverse direction, and for the same IPv4 address, it is the = same IPv6 address that must be synthesized by the NAT64+. >>=20 >> this address is used for A2 or used for B? if you mean B, then may i = conclude that NAT64+ is serving between A2 (native IPv6 address with = 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted = address having CNP)? if i can, may i further conclude that NAT64+ serves = only for the case where A2 has the 4rd-U-style address?=20 >=20 > Let me repeat that: > - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. > - The only difference is that NAT64+ has a plus for addresses that are = those of 4RD-u CEs (better IPv4 transparency). >=20 > accepted. but i have pointed out the "better transparency" has some = cost and uncertaity up to now (see another thread).=20 > =20 >=20 >=20 >> if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right?=20 >>=20 >> if so, i do really suggest you call it NAT64- instead of NAT64+ = because NAT64 can also serve hosts with any native IPv6 address to = connect with an IPv4 peer. >>=20 >> your answer below didn't respond my question, sorry. for example (in = the use case of NAT64 instead of NAT64-), A2 has native IPv6 address = 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE = might synthesize an IPv6 address for B, with the NAT64+ prefix and the = 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' through = IPv6; however, when this packet goes through the NAT64+, >=20 >> because only B' is checksum-neutral while A2 is not, >=20 > If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, = per Fig 6, 2001:db8:1234:5678:3000::=20 > It IS checksum neutral. >=20 > well, it is saying A2 must have the 4rd address in order to get the = benefit of NAT64-, right? (*) For native IPv6, it has whatever address applies (that of your = example is OK). Its CE is reached with all destination addresses starting with the site = /64 followed by with the V octet. =20 > i have typed "for example (in the use case of NAT64 instead of = NAT64-), ..." as the prerequisite of the above discussion. let me have = the following propositions:=20 >=20 > a. NAT64 suitable for any case no matter A2 is assigned with any kind = of address, but currently only works for TCP and UDP.=20 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.=20 > c. NAT64+ works like:=20 > if A2 has a V-CNP-address, then it doesn't update the checksum for = any L4 protocols;=20 > 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.=20 >=20 > 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.=20 That's IMHO clear enough, especially with the (*) above which clarifies = AFAIK which native and 4rd IPv6 addresses are used by CEs. Cheers, RD >=20 > thanks, > maoke >=20 > =20 >=20 >> NAT64+ passing it without L4 checksum adjustment will make B receive = a packet with wrong checksum, for any L4 protocols.=20 >>=20 >> the above example works well for TCP and UDP with today's NAT64, = without limitations on A2's address.=20 >>=20 >> - maoke >> =20 >> This is I suppose implicit, but it can advantageously be made = explicit in the draft. >> Thanks. >>=20 >>=20 >>>> Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE addresses. >>>> =20 >>>> =20 >>>> we need to make sure if the NAT64s make both src and dst addresses = checksum-neutral. >>>=20 >>> Correct, iff the host address has the V octet. >>>=20 >>> 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE = addresses from others.=20 >>=20 >> True, but while testing the V octet is sufficient in 4rd, the NAT64 = has in MAP to process mapping rules to find for null subnet IDs whose = lengths depend on which mapping rule applies. >> That's IMHO one instance where the V-octet potential is clear. >>=20 >>=20 >>> 2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=20 >>=20 >> Yes (see above). >>=20 >>> if 2 is true, why you use stateful NAT64+ here for B rather than a = stateless one? >>=20 >> Because we consider hosts that are not assigned any public IPv4 = address, even shared. >>=20 >>> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address = for B's communications, and such a case results only A's mapped address = is checksum-neutral, and thus anyway L4 adjustment is needed.=20 >>>=20 >>> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, = because NAT64 doesn't have the limitation on the IPv6 address pool in = use.=20 >>=20 >> Suggestion not retained ;-). >> What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix.=20 >>=20 >>=20 >>> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is = NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit = this for the time being).=20 >>=20 >> Right. >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> - maoke=20 >>> =20 >>>=20 >>>> i cannot imagine what the use case is. please specify! >>>=20 >>> Hope the picture above helps. >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>> =20 >>>> - maoke >>>> =20 >>>> =20 >>>>=20 >>>> RD=20 >>>>=20 >>>>=20 >>>>> - maoke=20 >>>>>=20 >>>>> 2012/3/15 R=E9mi Despr=E9s >>>>>=20 >>>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>>>=20 >>>>> > Maoke, >>>>> > >>>>> > Thanks for this question. >>>>> > This subject being new, I take it on a new thread. >>>>> > >>>>> > 2012-03-15 10:38, Maoke: >>>>> > ... >>>>> >> i didn't understand the how the stateful NAT64 benefits from = CNP. >>>>> > >>>>> > The point is that if a NAT64 is upgraded to support 4rd-u = tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >>>>> > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs >>>>> > These CEs need not being dependent on which NAT64 supports which = protocols. >>>>> > >>>>> > Note that the NAT64 doesn't need to have CNP code. It just = happens that host IPv6 addresses it sees are checksum neutral. (Thus, = IPv6 and IPv4 payloads are the same for all protocols that have ports at = the same place as TCP/UDP/..., and the same checksum algorithm) >>>>>=20 >>>>> Oops. >>>>> This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >>>>> Sorry for having hastily added this sentence. >>>>>=20 >>>>> RD >>>>>=20 >>>>> > >>>>> > RD >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Softwires mailing list >>>>> > Softwires@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-147--489432496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 09:16, Maoke a =E9crit :



2012/3/16 R=E9mi = Despr=E9s <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 =  =3D> B (via NAT64+)
 A3 <=3D> B (via 4rd = BR)
(There is no A1-B = connectivity)

A2 is IPv6-only, = right?

There seems to = be a misunderstanding on what is IPv6-only.
a) A2 is dual = stack. Being a CE node, it supports IPv4 applications, and = typically includes a NAT44. 
b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it = has no assigned public IPv4 address (even shared).
c) Because = it has received a NAT64+ mapping rule, it knows it can tunnel IPv4 = packets to the NAT64+.


if so, let me go = down. 

Not so =3D> = doesn't apply. 
(Yet some further comments below)

RD


 

Anything = missed?


Other detailed comments follow.

Le = 2012-03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 14:47, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 11:45, Maoke a =E9crit :

i = understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address.


in other words, = we cannot limit NAT64 stateful service only serve those IPv6 addresses = with CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
 
 
this = phrase is not understood yet. do you mean using 4rd-IPv6-address format = for stateful translation service? =

Yes (but, &s said, = only for CE nodes that are 4rd capable (with the advantage of better = IPv4 transparency between CEs and NAT64+ than between RFC6145 and = NAT64).

please draw an example of A <---> B = communication as i did for clarification. =

Here is an example = scenario:

v4appli-BIH ----. =3D> A>B NOK (because, = according to RFC6535, BIH uses RFC6145) 
    =  A1         |    =  
                = :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
                |   =              UDP-lite     =                 =  UDP-lite
v4Appli-4rdCE --'         =         capable        =                 =  B
     A2         =  =3D> A-B OK


yes, BIH = uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly = speaking, if the "not support" means passing-it-through without checksum = adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right?

A NAT64 that supports UDP = Lite MUST update checksum for hosts that have native IPv6 = addresses.
That's why A1 =3D> B doesn't work unless the = NAT64 recognizes which packets are those of IPv4 applications in DS = hosts.

A1 -> B doesn't = need stateful NAT64 but stateless service is enough. well, stateful is = also ok. it is true NAT64 supporting UDP-Lite must update = checksum. 
 

B --> A is a question mark, if we use the NAT64+ which does = nothing with the L4 checksum, it is also not a problem. =


however, if we use, as you mentioned before, an UDP-Lite-aware update of = RFC6146, that may updates the checksum while the BIH doesn't know = that. 

Note that an = upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to support more = protocols than the two required by the RFC. It is just an extension = which cannot break anything (backward compatible).

confusing. upgrade vs. = extension?? 
 



my point here is: what is the use case with the = details of addressing? if and only if A1 or A2 is configured with an = RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of = checksum-neutral IPv6 address to serve B for the communications, A1 BIH = or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't = such a address pool for B, things will fail because only one among src = and dst is checksum-neutral. 

Sec 4.4 (8) says that a CE = that targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 = address:

+-------------------------------+--= -+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| = 0 |DST IPv4 add.|  CNP = |
+-------------------------------+---+---+-------------+------+=
:               64   =            : 8 : 8 :     =  32     :  16  :

In the reverse direction, and for the = same IPv4 address, it is the same IPv6 address that must be = synthesized by the = NAT64+.

this = address is used for A2 or used for B? if you mean B, then may i conclude = that NAT64+ is serving between A2 (native IPv6 address with 4rd-U CNP) = and B (synthesized by NAT64+ into another IPv6-converted address having = CNP)? if i can, may i further conclude that NAT64+ serves only for the = case where A2 has the 4rd-U-style address? 

Let me repeat = that:
- NAT64+ works as a NAT64 for addresses that aren't = 4rd-u style.
- The only difference is that NAT64+ has a plus = for addresses that are those of 4RD-u CEs (better IPv4 = transparency).

accepted. but i have = pointed out the "better transparency" has some cost and uncertaity up to = now (see another thread). 
 


if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right? 

if so, i do really suggest you = call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with = any native IPv6 address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry. = for example (in the use case of NAT64 instead of NAT64-), A2 has native = IPv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is = 192.32.77.50. the CE might synthesize an IPv6 address for B, with the = NAT64+ prefix and the 0xc0204d32 and a CNP embedded, say B', and let A2 = connect to B' through IPv6; however, when this packet goes through the = NAT64+,

because only B' is checksum-neutral while A2 = is not,

If the /64 of = A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address = is, per Fig = 6, 2001:db8:1234:5678:3000::<CNP> 
It IS checksum = neutral.

well, it is = saying A2 must have the 4rd address in order to get the benefit of = NAT64-, right?

(*) For = native IPv6, it has whatever address applies (that of your example is = OK).
Its CE is reached with all destination addresses starting = with the site /64 followed by with the V octet. =  


i have typed "for example (in the use case = of NAT64 instead of NAT64-), ..." as the prerequisite of the above = discussion. 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. 
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. 

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. 

That's IMHO clear enough, especially = with the (*) above which clarifies AFAIK which native and 4rd IPv6 = addresses are used by = CEs.


Cheers,
RD





thanks,
maoke

 

NAT64+ passing it without L4 checksum = adjustment will make B receive a packet with wrong checksum, for any L4 = protocols. 

the above example works well for TCP and UDP with = today's NAT64, without limitations on A2's = address. 

- = maoke
 
This is I suppose = implicit, but it can advantageously be made explicit in the = draft.
Thanks.


Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE = addresses.
 
 
we need to make sure if the NAT64s = make both src and dst addresses = checksum-neutral.
Correct, iff the host address = has the V octet.

1. without = the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from = others. 

True, but while testing the = V octet is sufficient in 4rd, the NAT64 has in MAP to process mapping = rules to find for null subnet IDs whose lengths depend on which mapping = rule applies.
That's IMHO one instance where the V-octet potential is = clear.


2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 = address? 

Yes (see = above).

if 2 is = true, why you use stateful NAT64+ here for B rather than a stateless = one?

Because we consider = hosts that are not assigned any public IPv4 address, even shared.

if= 2 is not true, then the NAT64 can use any arbitrary IPv6 address for = B's communications, and such a case results only A's mapped address is = checksum-neutral, and thus anyway L4 adjustment is needed. 

if 2 is true, i do suggest you naming NAT64+ as = NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 = address pool in = use. 

Suggestion = not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix. 


3. RFC6535 states, explicitly, "Use of = BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above = technical discussion can omit this for the time = being). 

Right.

RD






- maoke 
 

i cannot imagine what the use case is. = please specify!

Hope = the picture above helps.

RD



 
- = maoke
 
 

RD 


- maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires











= --Apple-Mail-147--489432496-- From fibrib@gmail.com Mon Mar 19 03:38:23 2012 Return-Path: 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 AFED021F867E for ; Mon, 19 Mar 2012 03:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Q-u3LIN+DO5m for ; Mon, 19 Mar 2012 03:38:21 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67AB121F864D for ; Mon, 19 Mar 2012 03:38:21 -0700 (PDT) Received: by ggmi1 with SMTP id i1so5987267ggm.31 for ; Mon, 19 Mar 2012 03:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gmMpmgFRSsqyGYdXhjw5/AdBSi0uJHVv9az5QfY92TU=; b=bHaGPE9JdO+9jFbKBUtunw6pR1BlY1VmairxwAPbfISRfa5SRjG1bvAWCqPzw7/TQg l3+1PO+NRtz4K/u5IlqyTUBnEHvb18iuSx59Y8tku4e3SxG1fclO15/Nvnc36nHK1wHa SOzLAKNSdYabYgzfZGHfETWLsQX51ZupxVnxL+ffEMmdM4kmMDFTNXo/pQLp1Asu7rrq 3Zhs2e9ueC7UdCe6tblZeRpgzEtLxqbzyWE37O2qZiavHUShrF/JNzWcVT1IoFIEIYkw yu4PZ+usxSLkkP1RnTjfAecJEiPitgCYtGUaFruliM4GnzX+GKHV6tI7sth7zgs1nQVV EsKg== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr14777498qab.39.1332153500905; Mon, 19 Mar 2012 03:38:20 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 03:38:20 -0700 (PDT) In-Reply-To: <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> Date: Mon, 19 Mar 2012 10:38:20 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47e35300404bb9628bb Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 10:38:23 -0000 --20cf3074b47e35300404bb9628bb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/19 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 06:19, Maoke a =E9crit : > > Remi, > > please see inline. > > 2012/3/16 R=E9mi Despr=E9s > >> Maoke, >> >> First: >> - My apologies for having not answered this email before receiving a >> reminder (it was by mistake lost in a stack of non-urgent things to do). >> - Thanks for the clear and detailed analysis. >> >> More comments in line. >> >> Le 2012-03-13 =E0 10:53, Maoke a =E9crit : >> >> Remi, >> >> discussion on R-16 of Sec 4.7: >> >> > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it >> > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet >> > MUST contain the first 8 octets of the discarded-packet IP >> > payload. >> >> now the ICMPv6 error message contains the payload as the "header-mapped" >> IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translat= es >> this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applie= s >> the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the >> RFC6145 does? (for ICMP, the CNP doesn't help) >> >> if it does, you'd better cite RFC6145 here. if it doesn't, please >> specify. >> >> dear Remi, you didn't respond this. > > > AFAIK, I did, but somewhere else (see ** below). > > > > If the CE or BR has a global IPv4 address, this >> > address MUST be used as source of this packet. Otherwise, the >> > unspecified address 0.0.0.0 SHOULD be used as this source. >> >> let me draw an example for that: >> >> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >> router R2 here)--- B >> >> 1. consider ICMPv6 error happens at R1 >> >> original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> CE translates (precisely speaking, "header-maps") it to: >> +------------+----------------------------------------------+ >> | IPv6 | payload | >> | header, H2 | P1 | >> +------------+----------------------------------------------+ >> >> R1 found a error for this IPv6 packet, it generates an ICMPv6 report: >> +------------+--------+-----------+-------------------------+ >> | IPv6 | ICMPv6 | IPv6 | payload (truncated to | >> | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | >> +------------+--------+-----------+-------------------------+ >> \_______________ ___________________/ >> V >> as the ICMPv6 error message body >> >> this message feedbacked to CE, who will translate it to: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> it is clear that 4rd-U address mapping is applied for >> >> H1 -> H2 -> H4 >> >> H3 has the source address of R1 while the destination address as the CE. >> >> then, CE's (or BR's for the case of B --> A) global IPv4 address or >> 0.0.0.0 will be used in H5, right? >> >> >> Right. >> >> first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address >> represents either a host not yet having gained an IPv4 address on the LO= CAL >> network or an application listening on any addresses of a host. >> >> >> packet with 0.0.0.0 might be dropped by any intermediate routers of >> current implementations. >> >> >> This address never appears on any IPv4 link. >> Intermediate routers being IPv6, there is no problem. >> > > i doubt there is not a use-case where between A and CE there are some > subnet routers. > > >> OK? >> > > 4rd-u isn't concerned with what happens between A and CE. > There, internal hosts have RFC1918 addresses and external hosts public > IPv4 addresses. > no problem here for 4rd-u, but RFC6145/6146 work also in the case the translator is not located next to the end hosts. then i understand 4rd-u is less flexible. > Anything missing? > > > > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unreachable, No >> > route to destination") MUST be translated into ICMPv4 Type =3D 3 >> > and Code =3D 0 (Destination unreachable, Net unreachable). >> > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit >> > exceeded in transit) MUST be translated into ICMPv4 Type =3D 11 >> > and Code =3D 0 (Time exceeded, Time to live exceeded in >> > transit). >> >> for C1 -> C2 translation, i have the following comments: >> >> 1) here 4rd-U uses the CE's global IPv4 address >> >> >> (i think "global" refers to a non-shared one, right?) >> >> >> Global address is used as a synonymous of public address. >> If somewhere it seems to mean non-shared address, it must be a mistake. >> >> >> to represent all the error generator inside in the IPv6 domain. this >> surely fits a "tunnel" behavior that attempts to treat the delivery from= CE >> to BR as a "link", and therefore the error is responded by the link's en= d >> point. >> 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit >> exceeded and ICMPv6 unreachable node should be translated as ICMPv4 >> destination unreachable (Type =3D 3) host unreachable (Code =3D 1), beca= use it >> should indicates the link problem of the tunnel. >> 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a >> typical behavior of path participant rather than a "tunnel". the differe= nce >> of the tunnel and the path participant is: the latter consumes the TTL p= er >> physical hop. for example, if we set TTL =3D 32 in H1, tunneling means f= rom A >> to B communication may succeed as long as (A---CE) + (BR---B) doesn't >> exceed 30 hops and CE---BR is well connected; while current 4rd-U means >> from A to B communication may succeed only when total numbers of >> intermediate routers doesn't exceed 31. >> >> this is why typical tunneling solutions initialize the out-header's IPv6 >> Hop Limit to 255. when routing loop happens in the IPv6 domain and Hop >> Limit is consumed out, the link is considered broken. >> >> >> I don't see any problem with having, at tunnel exit, the TTL decreased b= y >> the number of traversed routers. >> > > you don't see it a problem because you reject the common understanding > about "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it > has been admitted by your statement that "4rd tunnel is not any tunnel". > > > Come on! > This sentence, which isn't in the draft, cannot be understood off context= . > > The draft is clear about what a 4rd tunnel is, and the point is that, > hosts *cannot distinguish* between packets that are natively routed e2e, > and those that are tunneled on their way, any number of times and with an= y > tunnel types. > > > > > my understanding here is "4rd tunnel" is ACTUALLY another path section of > translation, according to its behavior. if you would say "4rd-U is a > translation solution alternative to RFC6145 providing better transparency > in double-translation environment with some cost and uncertain risk", i > would totally accept without any further argument. > > > Both of us know that double translation in general looses some informatio= n. > to me, behavior is more important than the acceptable level of information loss. on the other hand, we cannot state 4rd-U doesn't lose any information. > What I wouldn't object to is to rename the Reversible-header-mapping > technique as Reversible-header-translation technique. > Hope you can accept this as sufficient, so that we can keep this work on > real and substantial problems. > real substantial problem includes the need of "tunnel as virtual link" building block in the Internet architecture. > > > 2. consider ICMPv4 error happens at R2: >> >> R2 sees original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> R2 has found some error with that packet, issuing an ICMPv4 message and >> sending to A: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >> +------------+--------+--------+--------------+ >> | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+--------+--------------+ >> >> woops, unfortunately, R1 also found something wrong. R1 generates an >> ICMPv6 report, responding back to B: >> +------------+--------+------------+--------+--------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+------------+--------+--------+--------------+ >> >> BR sees this and makes translation to: >> +---------+--------+---------+--------+--------+------------+ >> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >> +---------+--------+---------+--------+--------+------------+ >> |<------- 8 octet ----------->| >> \___________________ __________________/ >> V >> as the ICMPv4 error message body >> >> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. >> here 4rd-U can have two options: >> 1) let it be but depends on the IPv4 Internet routers, or host B itself >> to drop the ICMP of ICMP; >> 2) actively check the header in the ICMPv4 message body (H9 above) and >> identify if the protocol of the discard-packet is ICMPv4 too; if so, BR >> drops the packet. >> >> i doubt either is good. anyway, no matter which is used, 4rd-U must deal >> with this issue. (sorry if i missed some text where it has been done.) >> >> > (**) > > The right choice is clearly 2 (RFC792 rightly says: "To avoid the infinit= e >> regress of messages about messages etc., no ICMP messages are sent about >> ICMP messages.") >> > > > sure 2) is better than 1). however, the remained problem is IPv6 carrying > ICMPv4. i just summarize my concerns here in order the community can judg= e > the impact: > #1. such kind of packet loses the consistency between the destination > address in the IPv6 header and the source address of original IPv4 header > contained in the ICMP error message. > > > That's getting tricky. > yes. but i don't think people keeping part of original packets in ICMP message body is trivial. > Will you be in Paris so that we can discuss with a piece of paper details > of what you have in mind? (In the following 3 days, I will be busy > otherwise, and will have little or no access to email.) > > sorry but i couldn't go to Paris due to the company's arrangement. > #2. such kind of packet loses IP header integrity mechanism as neither > IPv4's header checksum nor the ICMPv6's checksum containing pseudo-header > is included. > > > Packets discussed here will never be delivered anyway (ICMP about ICMP). > I don't see how any practical concern would appear here. > #2 is not about ICMP about ICMP but about no checksum for IP addresses in IP neither in ICMP. i don't think people keeping checksum here or there is trivial. > > because it is stated that 4rd-U is "ensuring compatibility with IPv6-only > middle boxes that perform deep-packet-inspection", i here point out at > least #1 checking on ICMP error message being sent to the exact source of > original packet, and #2 checking on IP header integrity by calculating th= e > checksum in header or pseudo-header cannot rely on the functionality of t= he > middle boxes in the IPv6-only domain that perform deep-packet-inspection. > then 4rd-U CE/BR MUST consider these issues as well. > > (neither MAP-T nor MAP-E has the similar concern). > > > For MAP-E, of course (compatibility with IPv6-only middle boxes is off > scope). > For MAP-T, see above. > IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. no further concern. - maoke > > > > - maoke > > > (**) > > It can be made more explicit in the specification. >> > > In R-16, after "If a CE or BR receives an ICMPv6 error message [RFC4443]= , > it MUST synthesize an ICMPv4 error packet [RFC0792]" we could add "(unle= ss > the message concerns a ICMP message, as required by [RFC0792] to avoid IC= MP > about ICMP)". > > Thanks, > RD > > > > > Thanks. >> > >> >> Cheers, >> RD >> >> >> >> >> >> cheers, >> maoke >> >> 2012/3/12 R=E9mi Despr=E9s >> >>> Hello, all, >>> >>> An updated version of draft-despres-softwire-4rd-u is now available at >>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>> >>> Differences with -04 include: >>> - DHCPv6 options are now specified >>> - various errors and typos are corrected >>> - some clarifications are added, following received questions and >>> comments >>> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs >>> and within CPEs) >>> - An editor's note has been added, following a WG-ML discussion, about >>> an additional Mapping-rule parameter that might be needed to assign >>> privileged ports to to some shared-address CEs. >>> - Document layout has been adjusted as a result of other modifications. >>> - the authors list has been completed. >>> >>> Questions and comments are most welcome. >>> >>> Regards, >>> RD >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> > > --20cf3074b47e35300404bb9628bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 06:19, = Maoke a =E9crit :

Remi,=A0

please see inline.=A0

2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte.net>=
Maoke,
First:
- My apologies for having not answered t= his email before receiving a reminder (it was by mistake lost in a stack of= non-urgent things to do).
- Thanks for the clear and detailed analysis.

More comments in line.

Le 2012-03-13 =E0 10:53, Ma= oke a =E9crit :

Remi,=A0

discussion on R-16 of Sec 4.7:
<= div>
=A0 > R-16: If a CE or BR receives an ICMPv6 error m= essage [RFC4443], it
=A0 > MUST synthesize an ICMPv4 error pac= ket [RFC0792]. This packet
=A0 > MUST contain the first 8 octets of the discarded-packet IP=
=A0 > payload.

now the ICMPv6 err= or message contains the payload as the "header-mapped" IPv6 PDU o= f the discarded packet. right? so does 4rd-U CE or BR translates this ICMPv= 6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies the checksu= m adjustment algorithm between ICMPv6 and ICMPv4 here, as the RFC6145 does?= (for ICMP, the CNP doesn't help)

if it does, you'd better cite RFC6145 here. if it d= oesn't, please specify.=A0
dear Remi, you didn't respond this.=A0

AFAIK, I did, but somewhere else (se= e ** below).=A0


<= blockquote type=3D"cite">
=A0 > If the CE or BR has a global IPv4 address, this
=A0= > address MUST be used as source of this packet. Otherwise, th= e
=A0 > unspecified address 0.0.0.0 SHOULD be used as this source.=

let me draw an example for that:

A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Intern= et; router R2 here)--- B

1. consider ICMPv6 error happens at R1

original IPv4 packet at A, sent to B:
+---------+-------= ---------------------------------------+
| IPv4 =A0 =A0| payload = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

CE translates (precisel= y speaking, "header-maps") it to:=A0
+------------+----------------------------------------------+
| IPv6 =A0=A0 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| header, H2 | P1 =A0=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0|
+------------+----------------------------------------------+

R1 found a error for this IPv6 packet, it generates an ICM= Pv6 report:
+------------+--------+-----------+-------------= ------------+
| IPv6 =A0=A0 =A0 =A0| ICMPv6 | IPv6 =A0 =A0 =A0| payload (truncated t= o =A0 |
| header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),= P2 |
+------------+--------+-----------+-------------------------= +
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_______________ ___________= ________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv6 error message body

this message feedbacked to CE, who will translate it to:
+---------+--------+--------+--------------+
| IPv4 =A0= =A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H5 | hdr, C= 2| hdr, H4| payload, P3=A0 |
+---------+--------+--------+-------= -------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

it is clear that 4rd-U address mapping is applied for= =A0

=A0 H1 -> H2 -> H4

<= div>H3 has the source address of R1 while the destination address as the CE= .

then, CE's (or BR's for the case of B --> A)= global IPv4 address or 0.0.0.0 will be used in H5, right?

Right.

first of all, the 0.0.0.0 might be a wr= ong choice. Unspecified Address represents either a host not yet having gai= ned an IPv4 address on the LOCAL network or an application listening on any= addresses of a host.

packet with 0.0.= 0.0 might be dropped by any intermediate routers of current implementations= .=A0

This address never appear= s on any IPv4 link.
Intermediate routers being IPv6, there is no problem.

i doubt there is not a use-case where bet= ween A and CE there are some subnet routers.=A0
=A0
OK?

4rd-u isn'= t concerned with what happens between A and CE.
There, internal h= osts have RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for 4rd-= u, but RFC6145/6146 work also in the case the translator is not located nex= t to the end hosts. then i understand 4rd-u is less flexible.=A0
=A0
Anything missing?


=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Destination unrea= chable, No
=A0 > route to destination") MUST be translat= ed into ICMPv4 Type =3D 3
=A0 > and Code =3D 0 (Destination unreachable, Net unreachable).=
=A0 > ICMPv6 Type =3D 1 and Code =3D 0 (Time exceeded, Hop limit=
=A0 > exceeded in transit) MUST be translated into ICMPv4 Ty= pe =3D 11
=A0 > and Code =3D 0 (Time exceeded, Time to live e= xceeded in
=A0 > transit).

for C1 -> C2 transla= tion, i have the following comments:

1) here = 4rd-U uses the CE's global IPv4 address

(i think "global" refers to a= non-shared one, right?)

= Global address is used as a synonymous of public address.
If some= where it seems to mean non-shared address, it must be a mistake.


to represent a= ll the error generator inside in the IPv6 domain. this surely fits a "= tunnel" behavior that attempts to treat the delivery from CE to BR as = a "link", and therefore the error is responded by the link's = end point.=A0
2) however, if this is treated as a "tunnel", both ICMPv6 ho= p-limit exceeded and ICMPv6 unreachable node should be translated as ICMPv4= destination unreachable (Type =3D 3) host unreachable (Code =3D 1), becaus= e it should indicates the link problem of the tunnel.
3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a = typical behavior of path participant rather than a "tunnel". the = difference of the tunnel and the path participant is: the latter consumes t= he TTL per physical hop. for example, if we set TTL =3D 32 in H1, tunneling= means from A to B communication may succeed as long as (A---CE) + (BR---B)= doesn't exceed 30 hops and CE---BR is well connected; while current 4r= d-U means from A to B communication may succeed only when total numbers of = intermediate routers doesn't exceed 31.=A0

this is why typical tunneling solutions initializ= e the out-header's IPv6 Hop Limit to 255. when routing loop happens in = the IPv6 domain and Hop Limit is consumed out, the link is considered broke= n.

I don't see any problem wi= th having,=A0at tunnel exit,=A0the TTL decreased by the number of traversed= routers.

you don&#= 39;t see it a problem because you reject the common understanding about &qu= ot;tunnel" as a virtual link, but define the so-called 4rd-tunnel. it = has been admitted by your statement that "4rd tunnel is not any tunnel= ".

Come on!
This senten= ce, which isn't in the draft, cannot be understood off context.

The draft is clear about what a 4rd tunnel is, and the po= int is that, hosts *cannot distinguish* between packets that are natively r= outed e2e, and those that are tunneled on their way, any number of times an= d with any tunnel types.




my understanding here is= "4rd tunnel" is ACTUALLY another path section of translation, ac= cording to its behavior. if you would say "4rd-U is a translation solu= tion alternative to RFC6145 providing better transparency in double-transla= tion environment with some cost and uncertain risk", i would totally a= ccept without any further argument.

Both of us know that double tr= anslation in general looses some information.

to me, behavior is more important than the acceptable = level of information loss. on the other hand, we cannot state 4rd-U doesn&#= 39;t lose any information.=A0
=A0
What I wouldn't object to is to rename the Reversible-h= eader-mapping technique as Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems.

real substantial problem includes the need of "tunnel as virt= ual link" building block in the Internet architecture.=A0
=A0


2. consider ICMPv4 = error happens at R2:=A0

R2 sees original IPv4= packet at A, sent to B:
+---------+-----------------------------= -----------------+
| IPv4 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)
<= /div>

(**)

The right choice is= clearly 2 (RFC792 rightly says: "To avoid the infinite regress of mes= sages about messages etc., no ICMP messages are sent about ICMP messages.&q= uot;)


sure 2) is better than 1). h= owever, the remained problem is IPv6 carrying ICMPv4. i just summarize my c= oncerns here in order the community can judge the impact:=A0
#1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 header c= ontained in the ICMP error message.

That's getting tricky.

yes. but i don't think people keeping part of original packets in ICM= P message body is trivial.
=A0
Will you be in Paris so that we ca= n discuss with a piece of paper details of what you have in mind?=A0(In the= following 3 days, I will be busy otherwise, and will have little or no acc= ess to email.)


sorry but i couldn't go to Paris due to the company's arrangemen= t.=A0
=A0
#2. such kind of packet loses IP = header integrity mechanism as neither IPv4's header checksum nor the IC= MPv6's checksum containing pseudo-header is included.=A0

Packets discussed here will ne= ver be delivered anyway (ICMP about ICMP).
I don't see how an= y practical concern would appear here.=A0

#2 is not about ICMP about ICMP but about no checksum for IP= addresses in IP neither in ICMP. i don't think people keeping checksum= here or there is trivial.=A0
=A0

because it is stated that 4rd-U is "ensuring compatibility with I= Pv6-only middle boxes that perform deep-packet-inspection", i here poi= nt out at least #1 checking on ICMP error message being sent to the exact s= ource of original packet, and #2 checking on IP header integrity by calcula= ting the checksum in header or pseudo-header cannot rely on the functionali= ty of the middle boxes in the IPv6-only domain that perform deep-packet-ins= pection. then 4rd-U CE/BR MUST consider these issues as well.=A0

(neither MAP-T nor MAP-E has the similar concern).

For MAP-E, of course (compati= bility with IPv6-only middle boxes is off scope).
For MAP-T, see = above.

IPv6 carrying ICMPv6 is able t= o be deeply inspected by any IPv6 nodes. no further concern.=A0
<= br>
- maoke
=A0

=A0

- maoke=A0

(**)

It can be made more= explicit in the specification.
=

In=A0R-16, after =A0"If a= CE or BR receives an ICMPv6 error message [RFC4443], it=A0 MUST synthesize= an ICMPv4 error packet [RFC0792]" we could add "(unless the mess= age concerns a ICMP message, as required by [RFC0792] to avoid ICMP about I= CMP)".

Thanks,
RD




Thanks.
=


Cheers,
RD




cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires





--20cf3074b47e35300404bb9628bb-- From fibrib@gmail.com Mon Mar 19 03:45:00 2012 Return-Path: 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 6664A21F85F8 for ; Mon, 19 Mar 2012 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 aIqCVI65L-45 for ; Mon, 19 Mar 2012 03:44:58 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16221F85F6 for ; Mon, 19 Mar 2012 03:44:57 -0700 (PDT) Received: by qadc14 with SMTP id c14so705509qad.10 for ; Mon, 19 Mar 2012 03:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/qMp23kpt6KkYW6xMd39cng0lq6vb8HS+zh3HJRefXo=; b=JXL7Du0zQ5SL9dsdKtGoa/RDNVrq4u+Tob2kbcLuZJfrsRC/XA9w6KVn9sMCxN9RSy ERN7fwzZSh73taFFQ8tDISb+Fl3WEfPgskOoYFNKKQctrntdDfCfA4bULfF8o/jFcEAj daW4xJQ6ArzVi991eZFfax31vYSqSyu7ZC4cVb0Y7AoDnPI0v0RuUefjSlxLUVQjSHwX uQdmWUXH6qU+Sxx7pCdd5zG72OgHwxL8NBFBctM/V84F7oh5rk4E2ZxQDp1w13IeqYS8 zgmetm8Rtu+pFj08KrodRPYBKAxiFQ8FG2MVlru3SVN+b8/HHfL6aQWWLFmvcbVCzHZn vemA== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr14814930qab.13.1332153897090; Mon, 19 Mar 2012 03:44:57 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 03:44:57 -0700 (PDT) In-Reply-To: <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> Date: Mon, 19 Mar 2012 10:44:57 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef7d27d5604bb963f95 Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 10:45:00 -0000 --20cf30363ef7d27d5604bb963f95 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/19 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 10:21, Maoke a =E9crit : > > > > 2012/3/19 R=E9mi Despr=E9s > >> >> Le 2012-03-19 =E0 09:16, Maoke a =E9crit : >> >> >> >> 2012/3/16 R=E9mi Despr=E9s >> >>> 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 =3D> B (via NAT64+) >>> A3 <=3D> B (via 4rd BR) >>> (There is no A1-B connectivity) >>> >> >> A2 is IPv6-only, right? >> >> >> There seems to be a misunderstanding on what is IPv6-only. >> a) A2 is dual stack. Being a CE node, it supports IPv4 applications, and >> typically includes a NAT44. >> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has >> no assigned public IPv4 address (even shared). >> c) Because it has received a NAT64+ mapping rule, it knows it can tunnel >> IPv4 packets to the NAT64+. >> >> >> if so, let me go down. >> >> >> Not so =3D> doesn't apply. >> (Yet some further comments below) >> >> RD >> >> >> >> >>> >>> Anything missed? >>> >>> >>> Other detailed comments follow. >>> >>> Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >>> >>> >>> >>> 2012/3/15 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >>>> >>>> >>>> >>>> 2012/3/15 R=E9mi Despr=E9s >>>> >>>>> >>>>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>>>> >>>>> i understand NAT64 makes translation between arbitrary IPv6 address t= o >>>>> arbitrary IPv4 address. i don't understand how you make CNP in any IP= v6 >>>>> address. >>>>> >>>>> >>>>> >>>>> in other words, we cannot limit NAT64 stateful service only serve >>>>> those IPv6 addresses with CNP. >>>>> >>>>> >>>>> That's no the case at all(!). >>>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything >>>>> that worked before still works completely unchanged). >>>>> >>>>> The draft says: >>>>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support >>>>> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-add= ress >>>>> format." >>>>> >>>>> >>>> >>>> this phrase is not understood yet. do you mean using 4rd-IPv6-address >>>> format for stateful translation service? >>>> >>>> >>>> Yes (but, &s said, only for CE nodes that are 4rd capable (with the >>>> advantage of better IPv4 transparency between CEs and NAT64+ than betw= een >>>> RFC6145 and NAT64). >>>> >>>> please draw an example of A <---> B communication as i did for >>>> clarification. >>>> >>>> >>>> Here is an example scenario: >>>> >>>> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH use= s >>>> RFC6145) >>>> A1 | >>>> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server >>>> | UDP-lite UDP-lit= e >>>> v4Appli-4rdCE --' capable B >>>> A2 =3D> A-B OK >>>> >>>> >>> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but >>> exactly speaking, if the "not support" means passing-it-through without >>> checksum adjustment, A --> B is fine because neither BIH nor NAT64+ doe= s >>> nothing with the L4, right? >>> >>> >>> A NAT64 that supports UDP Lite MUST update checksum for hosts that have >>> native IPv6 addresses. >>> That's why A1 =3D> B doesn't work unless the NAT64 recognizes which >>> packets are those of IPv4 applications in DS hosts. >>> >> >> A1 -> B doesn't need stateful NAT64 but stateless service is enough. >> well, stateful is also ok. it is true NAT64 supporting UDP-Lite must upd= ate >> checksum. >> >> >>> >>> B --> A is a question mark, if we use the NAT64+ which does nothing >>> with the L4 checksum, it is also not a problem. >>> >>> >>> >>> however, if we use, as you mentioned before, an UDP-Lite-aware update o= f >>> RFC6146, that may updates the checksum while the BIH doesn't know that. >>> >>> >>> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) t= o >>> support more protocols than the two required by the RFC. It is just an >>> extension which cannot break anything (backward compatible). >>> >> >> confusing. upgrade vs. extension?? >> >> >>> >>> >>> >>> my point here is: what is the use case with the details of addressing? >>> if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd= -U >>> address while NAT64+ has a pool of checksum-neutral IPv6 address to ser= ve B >>> for the communications, A1 BIH or A2 CE may do the stateless processing >>> successfuly. if NAT64+ hasn't such a address pool for B, things will fa= il >>> because only one among src and dst is checksum-neutral. >>> >>> >>> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address >>> reaches the NAT64+ at this IPv6 address: >>> >>> +-------------------------------+---+---+-------------+------+ >>> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >>> +-------------------------------+---+---+-------------+------+ >>> : 64 : 8 : 8 : 32 : 16 : >>> >>> In the reverse direction, and for the same IPv4 address, it is the same >>> IPv6 address that must be synthesized by the NAT64+. >>> >> >> this address is used for A2 or used for B? if you mean B, then may i >> conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd= -U >> CNP) and B (synthesized by NAT64+ into another IPv6-converted address >> having CNP)? if i can, may i further conclude that NAT64+ serves only fo= r >> the case where A2 has the 4rd-U-style address? >> >> >> Let me repeat that: >> - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. >> - The only difference is that NAT64+ has a plus for addresses that are >> those of 4RD-u CEs (better IPv4 transparency). >> > > accepted. but i have pointed out the "better transparency" has some cost > and uncertaity up to now (see another thread). > > >> >> >> if the A2 is configured with any IPv6 address, for example, address with >> the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, righ= t? >> >> if so, i do really suggest you call it NAT64- instead of NAT64+ because >> NAT64 can also serve hosts with any native IPv6 address to connect with = an >> IPv4 peer. >> >> your answer below didn't respond my question, sorry. for example (in the >> use case of NAT64 instead of NAT64-), A2 has native IPv6 address >> 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE mi= ght >> synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204= d32 >> and a CNP embedded, say B', and let A2 connect to B' through IPv6; howev= er, >> when this packet goes through the NAT64+, >> >> >> because only B' is checksum-neutral while A2 is not, >> >> >> If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, pe= r >> Fig 6, 2001:db8:1234:5678:3000:: >> It IS checksum neutral. >> > > well, it is saying A2 must have the 4rd address in order to get the > benefit of NAT64-, right? > > > (*) For native IPv6, it has whatever address applies (that of your exampl= e > is OK). > Its CE is reached with all destination addresses starting with the site > /64 followed by with the V octet. > > > i have typed "for example (in the use case of NAT64 instead of NAT64-), > ..." as the prerequisite of the above discussion. let me have the followi= ng > 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. > 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 jus= t > like NAT64, updating the checksum but also currently only works for TCP a= nd > UDP. > > 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? is the NAT64+ mapping rule stateless or stateful? what the behavior of NAT64+ in the case of "except"? is there "and" or "or" between the "received ..." and the "have IPv6 prefixes..." clauses? please answer directly: do you mean c. instead of b.? (or, if either is not applied, and you may have d.) thanks, maoke > > That's IMHO clear enough, especially with the (*) above which clarifies > AFAIK which native and 4rd IPv6 addresses are used by CEs. > > > Cheers, > RD > > > > > > thanks, > maoke > > > >> >> NAT64+ passing it without L4 checksum adjustment will make B receive a >> packet with wrong checksum, for any L4 protocols. >> >> the above example works well for TCP and UDP with today's NAT64, without >> limitations on A2's address. >> >> - maoke >> >> >>> This is I suppose implicit, but it can advantageously be made explicit >>> in the draft. >>> Thanks. >>> >>> >>> Because 4rd IPv6 addresses of CEs are distinguishable from all other >>>>> IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs O= NLY >>>>> for addresses that actually are 4rd CE addresses. >>>>> >>>>> >>>> >>>> we need to make sure if the NAT64s make both src and dst addresses >>>> checksum-neutral. >>>> >>>> Correct, iff the host address has the V octet. >>>> >>> >>> 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE >>> addresses from others. >>> >>> >>> True, but while testing the V octet is sufficient in 4rd, the NAT64 has >>> in MAP to process mapping rules to find for null subnet IDs whose lengt= hs >>> depend on which mapping rule applies. >>> That's IMHO one instance where the V-octet potential is clear. >>> >>> >>> 2. even with the V-octet, do you mean B's IPv4 address also translated >>> (by the NAT64+) to a CNP-and-V-containing IPv6 address? >>> >>> >>> Yes (see above). >>> >>> if 2 is true, why you use stateful NAT64+ here for B rather than a >>> stateless one? >>> >>> >>> Because we consider hosts that are not assigned any public IPv4 address= , >>> even shared. >>> >>> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for >>> B's communications, and such a case results only A's mapped address is >>> checksum-neutral, and thus anyway L4 adjustment is needed. >>> >>> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because >>> NAT64 doesn't have the limitation on the IPv6 address pool in use. >>> >>> >>> Suggestion not retained ;-). >>> What you call the IPv6 address pool isn't a reserved pool: as explained >>> above, NAT64+ synthesizes its IPv6 source addresses using its unchanged= /64 >>> prefix. >>> >>> >>> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT >>> RECOMMENDED [RFC6180]" (but the above technical discussion can omit thi= s >>> for the time being). >>> >>> >>> Right. >>> >>> RD >>> >>> >>> >>> >>> >>> >>> - maoke >>> >>> >>>> >>>> i cannot imagine what the use case is. please specify! >>>> >>>> >>>> Hope the picture above helps. >>>> >>>> RD >>>> >>>> >>>> >>>> >>>> - maoke >>>> >>>> >>>>> >>>>> >>>>> RD >>>>> >>>>> >>>>> - maoke >>>>> >>>>> 2012/3/15 R=E9mi Despr=E9s >>>>> >>>>>> >>>>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>>>> >>>>>> > Maoke, >>>>>> > >>>>>> > Thanks for this question. >>>>>> > This subject being new, I take it on a new thread. >>>>>> > >>>>>> > 2012-03-15 10:38, Maoke: >>>>>> > ... >>>>>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>>>>> > >>>>>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels >>>>>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 pay= loads. >>>>>> > Any protocol that this NAT64 supports is then supported e2e for >>>>>> 4rd-u CEs >>>>>> > These CEs need not being dependent on which NAT64 supports which >>>>>> protocols. >>>>>> > >>>>>> > Note that the NAT64 doesn't need to have CNP code. It just happens >>>>>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 a= nd IPv4 >>>>>> payloads are the same for all protocols that have ports at the same = place >>>>>> as TCP/UDP/..., and the same checksum algorithm) >>>>>> >>>>>> Oops. >>>>>> This is only true for the IPv6 host address. To construct an IPv6 >>>>>> address when transmitting to a 4rd-u CE, the NAT64 should compute a= CNP. >>>>>> (This is to maintain the property that that middleboxes can treat tu= nnel >>>>>> packets as valid IPv6 packets. Not a big deal, but necessary). >>>>>> Sorry for having hastily added this sentence. >>>>>> >>>>>> RD >>>>>> >>>>>> > >>>>>> > RD >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Softwires mailing list >>>>>> > Softwires@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > --20cf30363ef7d27d5604bb963f95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 10:21, = Maoke a =E9crit :



2012/3/19 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-19 =E0 09:16, = Maoke a =E9crit :



2012/3/16 R=E9mi Despr=E9s <despres.remi@laposte= .net>
Maoke,

Let me try a = more complete picture than before:


= =A0 =A0 A1 -----. =A0 =A0 =A0 =A0 =A0=A0
RFC6145-host|=A0 =A0 =A0= =A0 =A0 =A0.-- 4rd BR --.=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 A2 -----:--(v6net)--: =A0 =A0 =A0 =A0 =A0 =A0:--(v4 = Internet)--- B=A0
=A0 4rd-CE =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0UDP Lite=A0appli=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0
(no IPv4 @) | =A0 =A0 =A0 =A0 =A0=A0&= #39;-- NAT64+ --'=A0
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0
=A0 =A0 A3 ---= --'=A0
=A0 4rd-CE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
(IPv4 @, sha= red=A0or not)


NAT64+ is s= upposed to have a bindings for UDP Lite, either only for 4rd IPv6 addresses= (the minimum), or also for native IPv6 addresses (the complete upgrade, wi= th UDP-Lite checksum adjustment for these addresses)

Connectivities I get are:=A0
=A0A2 =A0=3D>= B (via NAT64+)
=A0A3 <=3D> B (via 4rd BR)
(There= is no A1-B connectivity)

A2 is IPv6-only, right?

T= here seems to be a misunderstanding on what is IPv6-only.
a) A2 i= s dual stack.=A0Being a CE node, it=A0supports IPv4 applications, and typic= ally includes a NAT44.=A0
b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it ha= s no assigned public IPv4 address (even shared).
c) Because it ha= s received a NAT64+ mapping rule, it knows it can tunnel IPv4 packets to th= e NAT64+.


if so, let me go down.=A0

Not so =3D> doesn't apply.=A0
(Yet some further commen= ts below)

RD


=A0

Anything missed?


Other detailed comments follow.

Le 2012= -03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-03-15 =E0 14:47, = Maoke a =E9crit :



2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte= .net>

Le 2012-03-15 =E0 11:45, = Maoke a =E9crit :

i understand NAT6= 4 makes translation between arbitrary IPv6 address to arbitrary IPv4 addres= s. i don't understand how you make CNP in any IPv6 address.


in other words, we = cannot limit NAT64 stateful service only serve those IPv6 addresses with CN= P.

That's no the case at all(!).= =A0
A NAT64+ is a *backward compatible* extension of NAT64 (everything tha= t worked before still works completely unchanged).

The draft says:
"NAT64+: =A0An ISP NAT64 of [RFC6146] that = is upgraded to support 4rd=A0tunneling when IPv6 addresses it deals with ha= ve the 4rd-IPv6-address format."
=A0
=A0
this phrase is no= t understood yet. do you mean using 4rd-IPv6-address format for stateful tr= anslation service?

Yes (but, = &s said, only for CE nodes that are 4rd capable (with the advantage of = better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NA= T64).

ple= ase draw an example of A <---> B communication as i did for clarifica= tion.

Here is an example= scenario:

v4appli-BIH ----. =3D> A>B NOK (because, accordin= g to RFC6535, BIH uses RFC6145)=A0
=A0 =A0 =A0A1 =A0 =A0 =A0 =A0 = |=A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :----(v6net)----- NA= T64+ ---(IPv4 Internet)--- Server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-l= ite =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UDP-lite
v4Appli-4= rdCE --' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0capable=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B
=A0 =A0 =A0A2 =A0 =A0 =A0 =A0 = =A0=3D> A-B OK


yes, BIH uses = RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, i= f the "not support" means passing-it-through without checksum adj= ustment, A --> B is fine because neither BIH nor NAT64+ does nothing wit= h the L4, right?

A NAT64 that supports UDP Lite= MUST update checksum for hosts that have native IPv6 addresses.
= That's why A1 =3D> B doesn't work unless the NAT64 recognizes wh= ich packets are those of IPv4 applications in DS hosts.

A1 -> B doesn't n= eed stateful NAT64 but stateless service is enough. well, stateful is also = ok. it is true NAT64 supporting UDP-Lite must update checksum.=A0
=A0

B --> A is a question mark, if we use the NAT64+ which does nothin= g with the L4 checksum, it is also not a problem.
=


however, if we use, as you mentioned before, an UDP-Lite-aware update of RF= C6146, that may updates the checksum while the BIH doesn't know that.= =A0

Note that an upgrade of RF= C6146 isn't needed for A NAT64 (and NAT64+) to support more protocols t= han the two required by the RFC. It is just an extension which cannot break= anything (backward compatible).

confusing. upgrade vs. extensi= on??=A0
=A0



my point here is: what is the use case with the details= of addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 add= ress to serve B for the communications, A1 BIH or A2 CE may do the stateles= s processing successfuly. if NAT64+ hasn't such a address pool for B, t= hings will fail because only one among src and dst is checksum-neutral.=A0<= /div>

Sec 4.4 (8) says that a CE tha= t targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 addres= s:

+-------------------------------+---+---+-= ------------+------+
| =A0 =A0 =A0NAT64+ IPv6 prefix =A0 =A0 =A0 |"u"| 0 |DST IPv= 4 add.| =A0CNP |
+-------------------------------+---+---+-------= ------+------+
: =A0 =A0 =A0 =A0 =A0 =A0 =A0 64 =A0 =A0 =A0 =A0 = =A0 =A0 =A0: 8 : 8 : =A0 =A0 =A032 =A0 =A0 : =A016 =A0:

In the reverse direction, and=A0for the same IPv4= address,=A0it is the same IPv6 address that must be synthesized by the NAT= 64+.

this address i= s used for A2 or used for B? if you mean B, then may i conclude that NAT64+= is serving between A2 (native IPv6 address with 4rd-U CNP) and B (synthesi= zed by NAT64+ into another IPv6-converted address having CNP)? if i can, ma= y i further conclude that NAT64+ serves only for the case where A2 has the = 4rd-U-style address?=A0

Let me repeat that:
- NAT64+ works as a NAT64 for addresses that aren't 4rd-u style.<= /div>
- The only difference is that NAT64+ has a plus for addresses tha= t are those of 4RD-u CEs (better IPv4 transparency).

accepted. but i have pointed o= ut the "better transparency" has some cost and uncertaity up to n= ow (see another thread).=A0
=A0


if the A2 is configured with any IPv6 address, for example, address wi= th the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, righ= t?=A0

if so, i do really suggest you call it NAT64= - instead of NAT64+ because NAT64 can also serve hosts with any native IPv6= address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry= . for example (in the use case of NAT64 instead of NAT64-), A2 has native I= Pv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. = the CE might synthesize an IPv6 address for B, with the NAT64+ prefix and t= he 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' = through IPv6; however, when this packet goes through the NAT64+,

because only B' is checksum-neutral while A2 is not,
<= /blockquote>

If the /64 of A2 is=A02001:db8:1234:5= 678::/64, its=A04rd IPv6 address is,=A0per Fig 6,=A02001:db8:1234:5678:3000= ::<CNP>=A0
It IS checksum neutral.

<= div>well, it is saying A2 must have the 4rd address in order to get the ben= efit of NAT64-, right?

(*)=A0For native IPv6, it has whatever address applies (that of your e= xample is OK).
Its CE is reached with all destination addresses s= tarting with the site /64 followed by with the V octet. =A0


i have typed "for example (in the use case of NAT64 instead of NAT6= 4-), ..." as the prerequisite of the above discussion. let me have the= following propositions:=A0

a. NAT64 suitable for any case no matter A2 is assigned= with any kind of address, but currently only works for TCP and UDP.=A0

Yes (but with the DF bit tra= nsparency 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 p= rotocols.=A0
c. NAT64+ works like:=A0
=A0 =A0if A2 has a V-CNP-address, t= hen it doesn't update the checksum for any L4 protocols;=A0
= =A0 =A0if A2 has any other kind of native IPv6 address, then NAT64+ works j= ust like NAT64, updating the checksum but also currently only works for TCP= and UDP.=A0

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:<= /div>
- received a NAT64+ mapping rule
- have IPv6 prefixes f= rom which no IPv4 address can be derived.
For them, better transparency is achieved by replacing double RFC6145 = translation by a Reversible header mapping.=A0

not yet cleared. "receives a NAT64+ mapping rule= " for what? is the NAT64+ mapping rule stateless or stateful? what the= behavior of NAT64+ in the case of "except"? is there "and&q= uot; or "or" between the "received ..." and the "h= ave IPv6 prefixes..." clauses?

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

<= div>thanks,=A0
maoke
=A0

That's IMHO cle= ar enough, especially with the (*) above which clarifies AFAIK which native= and 4rd IPv6 addresses are used by CEs.


Cheers,
RD

<= br>



thanks,
maoke

=
=A0

NAT64+ passing it without L4 checksu= m adjustment will make B receive a packet with wrong checksum, for any L4 p= rotocols.=A0

the above example works well for TCP and UDP with today= 's NAT64, without limitations on A2's address.=A0

- maoke
=A0
This is I suppose implic= it, but it can advantageously be made explicit in the draft.
Than= ks.


Because 4rd IPv6 addresses of CEs are distinguishable from all other I= Pv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for= addresses that actually are 4rd CE addresses.
=A0
=A0
we need to make sure if the NAT64s make bot= h src and dst addresses checksum-neutral.
Correct, iff the host address has = the V octet.

1. without the V-o= ctet, CE and NAT64 can also distinguish the 4rd-CE addresses from others.= =A0

True, but while testing the V = octet is sufficient in 4rd, the NAT64 has in MAP to process mapping rules t= o find for null subnet IDs whose lengths depend on which mapping rule appli= es.
That's IMHO one instance where the V-octet potential is clear.


2. even with the V-octet, do you mean B's IPv4 address also transl= ated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=A0
=

Yes (see above).

if 2 is true,= why you use stateful NAT64+ here for B rather than a stateless one?
=

Because we consider hosts that are = not assigned any public IPv4 address, even shared.

if = 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B'= s communications, and such a case results only A's mapped address is ch= ecksum-neutral, and thus anyway L4 adjustment is needed.=A0

if 2 is true, i do suggest you naming NAT64+ as NAT64- = instead, because NAT64 doesn't have the limitation on the IPv6 address = pool in use.=A0

Suggestio= n not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as expl= ained above, NAT64+ synthesizes its IPv6 source addresses using its unchang= ed /64 prefix.=A0


3. RFC6535 states, explicitly, "Use of= BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the abov= e technical discussion can omit this for the time being).=A0

Right.

RD






- maoke=A0
=A0

i cannot imagine what the use case is. ple= ase specify!

Hope the pic= ture above helps.

RD



=A0
- maoke
=A0
=A0

RD=A0


- maoke=A0

2012/3/15 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from C= NP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thu= s becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads.
> Any protocol that this NAT64 supports is then supported e2e for 4rd-u = CEs
> These CEs need not being dependent on which NAT64 supports which proto= cols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens= that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv= 4 payloads are the same for all protocols that have ports at the same place= as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 address w= hen transmitting to =A0a 4rd-u CE, the NAT64 should compute a CNP. (This is= to maintain the property that that middleboxes can treat tunnel packets as= valid IPv6 packets. Not a big deal, but necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires












--20cf30363ef7d27d5604bb963f95-- From despres.remi@laposte.net Mon Mar 19 06:22:34 2012 Return-Path: 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 7A31F21F8597 for ; Mon, 19 Mar 2012 06:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 p3CUUbcAohy0 for ; Mon, 19 Mar 2012 06:22:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 031A221F8582 for ; Mon, 19 Mar 2012 06:22:30 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DF4BE940011; Mon, 19 Mar 2012 14:22:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-149--478665330 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F666409.9050800@cernet.edu.cn> Date: Mon, 19 Mar 2012 14:22:16 +0100 Message-Id: <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:22:34 -0000 --Apple-Mail-149--478665330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Xing, I look forward to face to face discussions in Paris if we don't clarify = everything before that (I will be busy on something else in the next 3 = days). Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : ... >>=20 >> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE = node, when it receives no 4rd mapping rule, to exercise single = translation.=20 >> Actually, I believe that using for this the BIH of RFC6535 is both = sufficient and recommendable. >> Translated IPv4 packets, because they are sent from CE nodes to = DNS64 synthesized addresses, are appropriately routed to their = destinations. (It can be via the NAT64-CGN if needed, or via more direct = paths if possible.) >> Anything missed? >=20 > Sorry, this is a misunderstanding.=20 > Hint: Single translation and double translation are based on the same = mapping rule in the CERNET2 deployment. I am well aware of this, but this doesn't explain why 4rd mapping rules = similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 = communication (single translation) supported". As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via manual configuration or stateful autoconfiguration via DHCPv6". Hosts can therefore be assigned Interface IDs that have the 4rd-u format = (with V octet and CNP). Now, when both addresses happen to be checksum neutral, RFC6145 = translation doesn't modify L4 data, so that it doesn't matter whether = the DS node has used 4rd-u header mapping or single translation.=20 Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd = CE nodes.=20 Regards, RD > Regards, >=20 > xing >=20 >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>> Regards, >>>=20 >>> xing >>>=20 >>>=20 >>>>=20 >>>> Regards, >>>> RD >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >>>> ... | | | | | >>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y = | N | >>>>>>> | | packets | | | = | | >>>>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>>>=20 >>>>>=20 >>>>> (2) More clarification should be added here. I am not sure 4rd-H = can support single translation. >>>>>=20 >>>>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>>>=20 >>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot = support single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. >>>>>=20 >>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>>>=20 >>>> ... >>>>=20 >>>>> (5) I would like to see the details of how 4rd-H handles ICMP and = ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>>>=20 >>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>> ... >>>>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail-149--478665330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Xing,

I look forward to face to face discussions in = Paris if we don't clarify everything before that (I will be busy on = something else in the next 3 = days).


Le 2012-03-18 =C3=A0 = 23:39, Xing Li a =C3=A9crit :
...

 A key point is that 4rd doesn't prevent = a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, = to exercise single translation. 
 Actually, I believe that using for this the BIH of = RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from = CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 = deployment.

I am well aware of = this, but this doesn't explain why 4rd mapping rules similar to = those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 = communication (single translation) supported".
As said in RFC6219, CERNET hosts have their IPv6 = addresses configured "via manual configuration or stateful = autoconfiguration via DHCPv6".
Hosts can = therefore be assigned Interface IDs that have the 4rd-u format = (with V octet and CNP).

Now, when = both addresses happen to be checksum neutral, RFC6145 translation = doesn't modify L4 data, so that it doesn't matter whether the DS node = has used 4rd-u header mapping or single = translation. 
Thus, IPv6-only = hosts can exchange packets with IPv4 applications of 4rd = CE nodes. 

Regards,
RD






=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit = :
... | | | | |
  |  5 | IPv6 web caches work =
for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to =
IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single = translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...






= --Apple-Mail-149--478665330-- From despres.remi@laposte.net Mon Mar 19 07:16:10 2012 Return-Path: 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 97DCD21F8690 for ; Mon, 19 Mar 2012 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.079, 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 nL+zDy4Ber67 for ; Mon, 19 Mar 2012 07:16:09 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id CEFCA21F865C for ; Mon, 19 Mar 2012 07:16:07 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id nSG41i00Y37Y3f403SG4Fj; Mon, 19 Mar 2012 15:16:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-150--475437570 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 15:16:04 +0100 Message-Id: References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:16:10 -0000 --Apple-Mail-150--475437570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 11:38, Maoke a =E9crit : ... >>>=20 >>> let me draw an example for that: >>>=20 >>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 = Internet; router R2 here)--- B ... > 4rd-u isn't concerned with what happens between A and CE. > There, internal hosts have RFC1918 addresses and external hosts public = IPv4 addresses. >=20 > no problem here for 4rd-u, but RFC6145/6146 work also in the case the = translator is not located next to the end hosts. then i understand 4rd-u = is less flexible.=20 I don't see the configuration you have in mind. > =20 > Anything missing? ... > Both of us know that double translation in general looses some = information. >=20 > to me, behavior is more important than the acceptable level of = information loss. Not understood. > on the other hand, we cannot state 4rd-U doesn't lose any information.=20= 4rd options aren't supported (like in MAP-T) What else do you see as lost e2e? > =20 > What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique. > Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems. >=20 > real substantial problem includes the need of "tunnel as virtual link" = building block in the Internet architecture.=20 Keeping it simple, without depending on complex and fussy concepts, = remains IMHO preferable. =20 >>> 2. consider ICMPv4 error happens at R2:=20 >>>=20 >>> R2 sees original IPv4 packet at A, sent to B: >>> +---------+----------------------------------------------+ >>> | IPv4 | payload | >>> | hdr, H1 | P1 | >>> +---------+----------------------------------------------+ >>>=20 >>> R2 has found some error with that packet, issuing an ICMPv4 message = and sending to A: >>> +---------+--------+--------+--------------+ >>> | IPv4 | ICMPv4 | IPv4 | truncated | >>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>> +---------+--------+--------+--------------+ >>> |<- 8 octet ->| >>> \__________ __________/ >>> V >>> as the ICMPv4 error message body >>>=20 >>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of = IPv6): >>> +------------+--------+--------+--------------+ >>> | IPv6 | ICMPv4 | IPv4 | truncated | >>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>> +------------+--------+--------+--------------+ >>>=20 >>> woops, unfortunately, R1 also found something wrong. R1 generates an = ICMPv6 report, responding back to B:=20 >>> = +------------+--------+------------+--------+--------+--------------+ >>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated = | >>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 = | >>> = +------------+--------+------------+--------+--------+--------------+ >>>=20 >>> BR sees this and makes translation to:=20 >>> +---------+--------+---------+--------+--------+------------+ >>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>> +---------+--------+---------+--------+--------+------------+ >>> |<------- 8 octet ----------->| >>> \___________________ __________________/ >>> V >>> as the ICMPv4 error message body >>>=20 >>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is = generated. here 4rd-U can have two options: >>> 1) let it be but depends on the IPv4 Internet routers, or host B = itself to drop the ICMP of ICMP;=20 >>> 2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet.=20 >>>=20 >>> i doubt either is good. anyway, no matter which is used, 4rd-U must = deal with this issue. (sorry if i missed some text where it has been = done.) >=20 > (**) >=20 >> The right choice is clearly 2 (RFC792 rightly says: "To avoid the = infinite regress of messages about messages etc., no ICMP messages are = sent about ICMP messages.") >=20 >=20 >> sure 2) is better than 1). however, the remained problem is IPv6 = carrying ICMPv4. i just summarize my concerns here in order the = community can judge the impact:=20 >> #1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 = header contained in the ICMP error message. >=20 > That's getting tricky. >=20 > yes. but i don't think people keeping part of original packets in ICMP = message body is trivial. If not "trivial" at least quite simple: +------------+--------+------------+--------------+ | IPv6 | ICMPv6 | IPv6 | truncated | | header, H2 | hdr, C1| header, H1 | payload, P1 | +------------+--------+------------+--------------+ || \/ +---------+--------+--------+--------------+ | IPv4 | ICMPv4 | IPv4 | truncated | | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | +---------+--------+--------+--------------+ =20 |<- 8 octet ->| SRC of H2 is a constant DST of H2 and H3, and SRC of H2, are copied from fields in H1 The ICMPv4 checksum is computed from scratch. > Will you be in Paris so that we can discuss with a piece of paper = details of what you have in mind? (In the following 3 days, I will be = busy otherwise, and will have little or no access to email.) >=20 >=20 > sorry but i couldn't go to Paris due to the company's arrangement.=20 Your presence will be missed. Sorry to learn that. >> #2. such kind of packet loses IP header integrity mechanism as = neither IPv4's header checksum nor the ICMPv6's checksum containing = pseudo-header is included.=20 >=20 > Packets discussed here will never be delivered anyway (ICMP about = ICMP). > I don't see how any practical concern would appear here.=20 >=20 > #2 is not about ICMP about ICMP but about no checksum for IP addresses = in IP neither in ICMP. i don't think people keeping checksum here or = there is trivial.=20 Not sure to see the issue. When an ICMPv4 error message is synthesized, its ICMP checksum can = easily be computed, as explained above. (Always keeping only 8 octets of the original payload, as specified, = strictly limits the computation.) >> because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well.=20 >>=20 >> (neither MAP-T nor MAP-E has the similar concern). >=20 > For MAP-E, of course (compatibility with IPv6-only middle boxes is off = scope). > For MAP-T, see above. >=20 > IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. Sure. Now, if an ICMPv6 error packet is returned whose partially returned = payload is that of an ICMPv4 message, i.e. with an unknown protocol in = IPv6, this packet can be indifferently discarded or forwarded after DPI = without any negative effect.=20 (If not discarded here, it will be discarded at 4rd tunnel exit.) > no further concern. Cheers, RD > =20 >=20 > - maoke > =20 >=20 >> =20 >>=20 >> - maoke=20 >=20 > (**) >=20 >> It can be made more explicit in the specification. >=20 > In R-16, after "If a CE or BR receives an ICMPv6 error message = [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we = could add "(unless the message concerns a ICMP message, as required by = [RFC0792] to avoid ICMP about ICMP)". >=20 > Thanks, > RD >=20 >=20 >=20 >=20 >> Thanks. >>=20 >>=20 >> Cheers, >> RD >>=20 >>=20 >>=20 >>=20 >>>=20 >>> cheers, >>> maoke >>>=20 >>> 2012/3/12 R=E9mi Despr=E9s >>> Hello, all, >>>=20 >>> An updated version of draft-despres-softwire-4rd-u is now available = at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>=20 >>> Differences with -04 include: >>> - DHCPv6 options are now specified >>> - various errors and typos are corrected >>> - some clarifications are added, following received questions and = comments >>> - the CE-behind-CPE use case has been revised (mix of CEs behind = CPEs and within CPEs) >>> - An editor's note has been added, following a WG-ML discussion, = about an additional Mapping-rule parameter that might be needed to = assign privileged ports to to some shared-address CEs. >>> - Document layout has been adjusted as a result of other = modifications. >>> - the authors list has been completed. >>>=20 >>> Questions and comments are most welcome. >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-150--475437570 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

let me draw an example for = that:

A --- CE ----(IPv6 domain; router R1 = here)---- BR ----(IPv4 Internet; router R2 here)--- = B
...
4rd-u isn't concerned with = what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for = 4rd-u, but RFC6145/6146 work also in the case the translator is not = located next to the end hosts. then i understand 4rd-u is less = flexible. 

I don't see = the configuration you have in mind.

 
Anything = missing?
...

Both of us know that double = translation in general looses some = information.

to me, = behavior is more important than the acceptable level of information = loss.

Not = understood.

on the other hand, we cannot state 4rd-U = doesn't lose any = information. 

4rd = options aren't supported (like in MAP-T)
What else do you see = as lost e2e?

 
What I wouldn't object to is to = rename the Reversible-header-mapping technique as = Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this = work on real and substantial = problems.

real = substantial problem includes the need of "tunnel as virtual link" = building block in the Internet = architecture. 

Keeping = it simple, without depending on complex and fussy concepts, remains IMHO = preferable.
  

2. consider = ICMPv4 error happens at R2: 

R2 sees = original IPv4 packet at A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

R2 has found some error with that packet, = issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H6 | hdr, C3| hdr, H1| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as = payload of = IPv6):
+------------+--------+--------+--------------+
| IPv6       | ICMPv4 | IPv4   | = truncated    |
| header, H7 | hdr, C3| hdr, H1| payload, P3  = |
+------------+--------+--------+--------------+

=
woops, unfortunately, R1 also found something wrong. R1 = generates an ICMPv6 report, responding back to B: 
=
+------------+--------+------------+--------+--------+----------= ----+
| IPv6       | ICMPv6 | IPv6 =       | ICMPv4 | IPv4   | truncated   =  |
| header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| = payload, P3  |
=
+------------+--------+------------+--------+--------+--------------+=

BR sees this and = makes translation = to: 
+---------+--------+----= -----+--------+--------+------------+
| IPv4    | ICMPv4 | IPv4    | ICMPv4 | = IPv4   | truncated  |
| hdr, H10| hdr, C5| hdr, = H9 | hdr, C3| hdr, H1| payload, = P4|
+---------+--------+---------+--------+--------+------------= +
        =                     =  |<------- 8 octet  = ----------->|
        =             \___________________ = __________________/
        =                     =             V
                  =        as the ICMPv4 error message = body

here an "ICMP of ICMP", which is not = allowed in ICMPv4, is generated. here 4rd-U can have two = options:
1) let it be but depends on the IPv4 Internet = routers, or host B itself to drop the ICMP of ICMP; 
2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet. 

i doubt either is = good. anyway, no matter which is used, 4rd-U must deal with this issue. = (sorry if i missed some text where it has been done.)
=
=

(**)

The right choice = is clearly 2 (RFC792 rightly says: "To avoid the infinite regress of = messages about messages etc., no ICMP messages are sent about ICMP = messages.")
=


sure 2) is better than = 1). however, the remained problem is IPv6 carrying ICMPv4. i just = summarize my concerns here in order the community can judge the = impact: 
#1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error = message.

That's getting = tricky.

yes. but i don't = think people keeping part of original packets in ICMP message body is = trivial.

If not "trivial" at = least quite = simple:

+------------+--------+------------+-----= ---------+
| IPv6       | ICMPv6 | IPv6   =     | truncated    |
| header, H2 | hdr, = C1| header, H1 | payload, P1 =  |
+------------+--------+------------+--------------+
                  =   ||
              =       = \/
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H2 | hdr, C1| hdr, H3| payload, P2 =  |
+---------+--------+--------+--------------+   =             
    =                     =     |<- 8 octet  ->|
SRC of H2 is a = constant
DST of H2 and H3, and SRC of H2, are copied from = fields in H1
The ICMPv4 checksum is computed from = scratch.


Will you be in Paris so that we = can discuss with a piece of paper details of what you have in = mind? (In the following 3 days, I will be busy otherwise, and will = have little or no access to email.)


sorry = but i couldn't go to Paris due to the company's = arrangement. 


Y= our presence will be missed. Sorry to learn = that.


#2. such kind of packet = loses IP header integrity mechanism as neither IPv4's header checksum = nor the ICMPv6's checksum containing pseudo-header is = included. 

Packets discussed here will = never be delivered anyway (ICMP about ICMP).
I don't see how = any practical concern would appear = here. 

#2 is not about ICMP about ICMP but about no checksum for = IP addresses in IP neither in ICMP. i don't think people keeping = checksum here or there is = trivial. 

Not sure to = see the issue.
When an ICMPv4 error message is synthesized, = its ICMP checksum can easily be computed, as explained = above.
(Always keeping only 8 octets of the original payload, = as specified, strictly limits the = computation.)


because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well. 

(neither MAP-T nor MAP-E has the similar = concern).

For MAP-E, = of course (compatibility with IPv6-only middle boxes is off = scope).
For MAP-T, see above.

IPv6 carrying ICMPv6 is = able to be deeply inspected by any IPv6 nodes. =

Sure.
Now, = if an ICMPv6 error packet is returned whose partially returned payload = is that of an ICMPv4 message, i.e. with an unknown protocol in IPv6, = this packet can be indifferently discarded or forwarded after DPI = without any negative effect. 
(If not discarded here, it = will be discarded at 4rd tunnel = exit.)


no further = concern.


= Cheers,
RD



 

- = maoke
 

 

- = maoke 

(**)

It can be made = more explicit in the specification. =

In R-16, after  "If a CE or BR receives an = ICMPv6 error message [RFC4443], it  MUST synthesize an ICMPv4 error = packet [RFC0792]" we could add "(unless the message concerns a ICMP = message, as required by [RFC0792] to avoid ICMP about ICMP)".

Thanks,
RD




Thanks.


Cheers,
RD



=

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 05

Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and = comments
- the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other = modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires






= --Apple-Mail-150--475437570-- From rajiva@cisco.com Mon Mar 19 07:16:18 2012 Return-Path: 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 8EA5E21F86EB for ; Mon, 19 Mar 2012 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 4ffXOB6QB97Q for ; Mon, 19 Mar 2012 07:16:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A61AA21F86EA for ; Mon, 19 Mar 2012 07:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5880; q=dns/txt; s=iport; t=1332166577; x=1333376177; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iZiGBdPYjG2YYd1vvgq9LooYsQ7ye0/NtTxjZrxGlLk=; b=N3qe2h1qGS9ORpduLP3GmsYax76WqOFa4tSHRjojRLYtRrKAn18bHmVQ mY8IcGmBx+fyP216hwPLNYOl5NkJuP9KNNUZRigaFmfhx6AI71+vtsC84 PL1VA+xVXAov7u+I6o7sKIuspMy+zHjONPpW+LREhiL0EVbVLOT25RF4Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAE/Z0+tJXG8/2dsb2JhbABCDoUwsAiBBIEHggkBAQEDARIBEA0EOgQHBQcEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEEARIIARmHYwULmyuNBJFbgS+JGoUdM2MEiFabUoFogi9VgT4 X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208";a="67579589" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 19 Mar 2012 14:16:17 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2JEGHmE026125; Mon, 19 Mar 2012 14:16:17 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 09:16:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 19 Mar 2012 09:16:15 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07A8D42B@XMB-RCD-111.cisco.com> In-Reply-To: <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] MAP and 4rd - Relationship with Single translation Thread-Index: Ac0F02H6AIKO2OeGQOu9v3uxdbJwZQABYCrw References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net><96214733-7D45-436E-81C2-6E6701542C79@employees.org><4F348EEB.4050908@cernet.edu.cn><86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net><4F59AE74.4090204@cernet.edu.cn><5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net><4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> From: "Rajiv Asati (rajiva)" To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= , "Xing Li" X-OriginalArrivalTime: 19 Mar 2012 14:16:17.0137 (UTC) FILETIME=[D95CF610:01CD05DA] Cc: Softwires WG , Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:16:18 -0000 DQo+IEkgYW0gd2VsbCBhd2FyZSBvZiB0aGlzLCBidXQgdGhpcyBkb2Vzbid0IGV4cGxhaW4gd2h5 IDRyZCBtYXBwaW5nIHJ1bGVzIHNpbWlsYXINCj4gdG8gdGhvc2Ugb2YgQ0VSTkVUMiB3b3VsZG4n dCBoYXZlLCBsaWtlIE1BUC1ULCAiSVB2NCB0byBJUHY2IGNvbW11bmljYXRpb24NCj4gKHNpbmds ZSB0cmFuc2xhdGlvbikgc3VwcG9ydGVkIi4NCj4gDQo+IA0KPiBBcyBzYWlkIGluIFJGQzYyMTks IENFUk5FVCBob3N0cyBoYXZlIHRoZWlyIElQdjYgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgInZpYQ0K PiBtYW51YWwgY29uZmlndXJhdGlvbiBvciBzdGF0ZWZ1bCBhdXRvY29uZmlndXJhdGlvbiB2aWEg REhDUHY2Ii4NCj4gSG9zdHMgY2FuIHRoZXJlZm9yZSBiZSBhc3NpZ25lZCBJbnRlcmZhY2UgSURz IHRoYXQgaGF2ZSB0aGUgNHJkLXUgZm9ybWF0ICh3aXRoDQo+IFYgb2N0ZXQgYW5kIENOUCkuDQoN Ckkgc2VlIGEgdHJlbWVuZG91cyB2YWx1ZSAmIGFkdmFudGFnZSBpbiBzdGFuZGFyZGl6aW5nIGEg bWVjaGFuaXNtIChzdWNoIGFzIE1BUC1UIChha2EgZElWSSkpIHRoYXQgaGFzIGJlZW4gaW4gcHJv ZHVjdGlvbiBuZXR3b3JrcyBmb3IgfjJ5cnMuIA0KDQpDaGVlcnMsDQpSYWppdg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBSw6lt aSBEZXNwcsOpcw0KPiBTZW50OiBNb25kYXksIE1hcmNoIDE5LCAyMDEyIDk6MjIgQU0NCj4gVG86 IFhpbmcgTGkNCj4gQ2M6IFNvZnR3aXJlcyBXRzsgWW9uZyBDdWk7IFJhbHBoIERyb21zIChyZHJv bXMpDQo+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBNQVAgYW5kIDRyZCAtIFJlbGF0aW9uc2hp cCB3aXRoIFNpbmdsZSB0cmFuc2xhdGlvbg0KPiANCj4gSGksIFhpbmcsDQo+IA0KPiBJIGxvb2sg Zm9yd2FyZCB0byBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbnMgaW4gUGFyaXMgaWYgd2UgZG9uJ3Qg Y2xhcmlmeSBldmVyeXRoaW5nDQo+IGJlZm9yZSB0aGF0IChJIHdpbGwgYmUgYnVzeSBvbiBzb21l dGhpbmcgZWxzZSBpbiB0aGUgbmV4dCAzIGRheXMpLg0KPiANCj4gDQo+IExlIDIwMTItMDMtMTgg w6AgMjM6MzksIFhpbmcgTGkgYSDDqWNyaXQgOg0KPiAuLi4NCj4gDQo+IA0KPiANCj4gCQkgQSBr ZXkgcG9pbnQgaXMgdGhhdCA0cmQgZG9lc24ndCBwcmV2ZW50IGEgNHJkLWNhcGFibGUgZHVhbC0N Cj4gc3RhY2sgQ0Ugbm9kZSwgd2hlbiBpdCByZWNlaXZlcyBubyA0cmQgbWFwcGluZyBydWxlLCB0 byBleGVyY2lzZSBzaW5nbGUNCj4gdHJhbnNsYXRpb24uDQo+IAkJIEFjdHVhbGx5LCBJIGJlbGll dmUgdGhhdCB1c2luZyBmb3IgdGhpcyB0aGUgQklIIG9mIFJGQzY1MzUgaXMNCj4gYm90aCBzdWZm aWNpZW50IGFuZCByZWNvbW1lbmRhYmxlLg0KPiAJCSBUcmFuc2xhdGVkIElQdjQgcGFja2V0cywg YmVjYXVzZSB0aGV5IGFyZSBzZW50IGZyb20gQ0Ugbm9kZXMNCj4gdG8gRE5TNjQgc3ludGhlc2l6 ZWQgYWRkcmVzc2VzLCBhcmUgYXBwcm9wcmlhdGVseSByb3V0ZWQgdG8gdGhlaXIgZGVzdGluYXRp b25zLg0KPiAoSXQgY2FuIGJlIHZpYSB0aGUgTkFUNjQtQ0dOIGlmIG5lZWRlZCwgb3IgdmlhIG1v cmUgZGlyZWN0IHBhdGhzIGlmIHBvc3NpYmxlLikNCj4gCQlBbnl0aGluZyBtaXNzZWQ/DQo+IA0K PiANCj4gCVNvcnJ5LCB0aGlzIGlzIGEgbWlzdW5kZXJzdGFuZGluZy4NCj4gCUhpbnQ6IFNpbmds ZSB0cmFuc2xhdGlvbiBhbmQgZG91YmxlIHRyYW5zbGF0aW9uIGFyZSBiYXNlZCBvbiB0aGUgc2Ft ZQ0KPiBtYXBwaW5nIHJ1bGUgaW4gdGhlIENFUk5FVDIgZGVwbG95bWVudC4NCj4gDQo+IA0KPiAN Cj4gSSBhbSB3ZWxsIGF3YXJlIG9mIHRoaXMsIGJ1dCB0aGlzIGRvZXNuJ3QgZXhwbGFpbiB3aHkg NHJkIG1hcHBpbmcgcnVsZXMgc2ltaWxhcg0KPiB0byB0aG9zZSBvZiBDRVJORVQyIHdvdWxkbid0 IGhhdmUsIGxpa2UgTUFQLVQsICJJUHY0IHRvIElQdjYgY29tbXVuaWNhdGlvbg0KPiAoc2luZ2xl IHRyYW5zbGF0aW9uKSBzdXBwb3J0ZWQiLg0KPiANCj4gDQo+IEFzIHNhaWQgaW4gUkZDNjIxOSwg Q0VSTkVUIGhvc3RzIGhhdmUgdGhlaXIgSVB2NiBhZGRyZXNzZXMgY29uZmlndXJlZCAidmlhDQo+ IG1hbnVhbCBjb25maWd1cmF0aW9uIG9yIHN0YXRlZnVsIGF1dG9jb25maWd1cmF0aW9uIHZpYSBE SENQdjYiLg0KPiBIb3N0cyBjYW4gdGhlcmVmb3JlIGJlIGFzc2lnbmVkIEludGVyZmFjZSBJRHMg dGhhdCBoYXZlIHRoZSA0cmQtdSBmb3JtYXQgKHdpdGgNCj4gViBvY3RldCBhbmQgQ05QKS4NCj4g DQo+IA0KPiBOb3csIHdoZW4gYm90aCBhZGRyZXNzZXMgaGFwcGVuIHRvIGJlIGNoZWNrc3VtIG5l dXRyYWwsIFJGQzYxNDUNCj4gdHJhbnNsYXRpb24gZG9lc24ndCBtb2RpZnkgTDQgZGF0YSwgc28g dGhhdCBpdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSBEUw0KPiBub2RlIGhhcyB1c2VkIDRy ZC11IGhlYWRlciBtYXBwaW5nIG9yIHNpbmdsZSB0cmFuc2xhdGlvbi4NCj4gVGh1cywgSVB2Ni1v bmx5IGhvc3RzIGNhbiBleGNoYW5nZSBwYWNrZXRzIHdpdGggSVB2NCBhcHBsaWNhdGlvbnMgb2Yg NHJkIENFDQo+IG5vZGVzLg0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IFJEDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IAlSZWdhcmRz LA0KPiANCj4gCXhpbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAJCVJlZ2FyZHMsDQo+IAkJUkQN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gCQkJUmVnYXJkcywNCj4gDQo+IAkJCXhpbmcNCj4g DQo+IA0KPiANCj4gDQo+IA0KPiAJCQkJUmVnYXJkcywNCj4gCQkJCVJEDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gCQkJCUxlIDIwMTItMDItMTAgw6AgMDQ6MjgsIFhpbmcgTGkgYSDDqWNyaXQgOg0K PiAJCQkJLi4uIHwgfCB8IHwgfA0KPiANCj4gCQkJCQkJCSAgfCAgNSB8IElQdjYgd2ViDQo+IGNh Y2hlcyB3b3JrIGZvciBJUHY0ICAgICAgICB8ICBZICB8ICBOICB8ICBZICB8ICBOICB8DQo+IAkJ CQkJCQkgIHwgICAgfCBwYWNrZXRzDQo+IHwgICAgIHwgICAgIHwgICAgIHwgICAgIHwNCj4gDQo+ IAkJCQkJCXN1Z2dlc3QgeW91IHJlbmFtZSB0byAiSVB2NA0KPiB0byBJUHY2IGNvbW11bmljYXRp b24gKHNpbmdsZSB0cmFuc2xhdGlvbikgc3VwcG9ydGVkIg0KPiANCj4gDQo+IA0KPiAJCQkJCSgy KSBNb3JlIGNsYXJpZmljYXRpb24gc2hvdWxkIGJlIGFkZGVkDQo+IGhlcmUuIEkgYW0gbm90IHN1 cmUgNHJkLUggY2FuIHN1cHBvcnQgc2luZ2xlIHRyYW5zbGF0aW9uLg0KPiANCj4gCQkJCQkoYSkg QWNjb3JkaW5nIHRvICgxKSwgNHJkLUggZG9lcyBub3QNCj4gcGVyZm9ybSBoZWFkZXIgdHJhbnNs YXRpb24gZGVmaW5lZCBieSBSRkM2MTQ1Lg0KPiANCj4gCQkJCQkoYikgSW4gdGhlIHNvZnR3aXJl IG1haWxpbmcgbGlzdCwgaXQgc2VlbXMNCj4gdGhhdCA0cmQtSCBjYW5ub3Qgc3VwcG9ydCBzaW5n bGUgdHJhbnNsYXRpb24uICBTZWUgdGhlIHRocmVhZCBjb250YWluaW5nDQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zb2Z0d2lyZXMvY3VycmVudC9tc2cwMzMyNC5odG1s IGFuZA0KPiBvdGhlciBwb3N0cy4NCj4gDQo+IAkJCQkJKGMpIElmIDRyZC1IIGNhbm5vdCBzdXBw b3J0IHNpbmdsZQ0KPiB0cmFuc2xhdGlvbiwgdGhlbiAiSVB2NiB3ZWIgY2FjaGVzIHdvcmsgZm9y IElQdjQgcGFja2V0cyIgcmVxdWlyZXMgc3BlY2lhbA0KPiBjb25maWd1cmF0aW9ucywgaXQgY2Fu bm90IGRvIElQdjYgd2ViIGNhY2hlcyBmb3Igbm9uIDRyZC1IIHBhY2tldHMuDQo+IA0KPiANCj4g DQo+IAkJCQkuLi4NCj4gDQo+IA0KPiAJCQkJCSg1KSBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBk ZXRhaWxzIG9mDQo+IGhvdyA0cmQtSCBoYW5kbGVzIElDTVAgYW5kIElDTVAgZXJyb3IgbWVzc2Fn ZXMuIEluIHRoZSBzb2Z0d2lyZSBtYWlsaW5nIGxpc3QNCj4gdGhlcmUgd2VyZSBzb21lIGRpc2N1 c3Npb25zLiBTZWUgdGhlIHRocmVhZCBjb250YWluaW5nDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zb2Z0d2lyZXMvY3VycmVudC9tc2cwMzMyNC5odG1sIGFuZA0KPiBv dGhlciBwb3N0cy4gUGxlYXNlIGFkZA0KPiANCj4gDQo+IAkJCQkJfCAxNyB8IEhhbmRsZSBJQ01Q IChSRkM2MTQ1KSB8IFkgfA0KPiBuL2EgfCA/IHwgPyB8DQo+IA0KPiAJCQkJLi4uDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQoNCg== From fibrib@gmail.com Mon Mar 19 07:30:21 2012 Return-Path: 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 9B17B21F87D7 for ; Mon, 19 Mar 2012 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 XT-W-7v20Zsw for ; Mon, 19 Mar 2012 07:30:19 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2205121F87D6 for ; Mon, 19 Mar 2012 07:30:03 -0700 (PDT) Received: by yenm5 with SMTP id m5so6212556yen.31 for ; Mon, 19 Mar 2012 07:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wf6IHGOrfeZPg4oKzpBASPVQH+oitCYnt93jcB2RNBA=; b=KDGTgbecmjw1R+FklsUduxDs3rpBtsG0gXV1EVMAbHuTyhNxh7fJeZ6YJlix9H4MbO jf2lZNXNw6YHuNDFRsNupv9n8CYbPABVaw7rRQvE6MKf/yly7+B2D+jjK166h76olL/5 LANoOKQviPg6qEqAi/kzNv/+cpGzWJnxyP1O0M1y2NiNyBcEHXFK9tn+BPnVDG/yUiMJ iH+BemtJDCnEljavY8xiPTbqpTRmPdcIJsuQa2026EsnEJcckIVPNty6du6mmOKF1GoK WkqEBB+Wlozfo1lgX7h5ret3SGg4nkHyjKSC1UBASx4jOp3ctvdClHNujt/R7SkTttXm Fz5w== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr15760851qab.39.1332167402661; Mon, 19 Mar 2012 07:30:02 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 07:30:02 -0700 (PDT) In-Reply-To: References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> Date: Mon, 19 Mar 2012 23:30:02 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b47ed125db04bb996485 Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:30:21 -0000 --20cf3074b47ed125db04bb996485 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/19 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 11:38, Maoke a =E9crit : > ... > > >>> let me draw an example for that: >>> >>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>> router R2 here)--- B >>> >>> ... > > 4rd-u isn't concerned with what happens between A and CE. >> There, internal hosts have RFC1918 addresses and external hosts public >> IPv4 addresses. >> > > no problem here for 4rd-u, but RFC6145/6146 work also in the case the > translator is not located next to the end hosts. then i understand 4rd-u = is > less flexible. > > > I don't see the configuration you have in mind. > > people often insert a router between the home CE and their computers ;-) sometimes, e.g., because the CE has limited number of ports for connection or less funtioning. > > > > >> Anything missing? >> > ... > > Both of us know that double translation in general looses some informatio= n. >> > > to me, behavior is more important than the acceptable level of informatio= n > loss. > > > Not understood. > > then let's keep our own point for next face-to-face discussion. > > > on the other hand, we cannot state 4rd-U doesn't lose any information. > > > 4rd options aren't supported (like in MAP-T) > What else do you see as lost e2e? > > not else end-to-end except the original TTL across the IPv6 cloud. (therefore i said any information. :) > > > > >> What I wouldn't object to is to rename the Reversible-header-mapping >> technique as Reversible-header-translation technique. >> Hope you can accept this as sufficient, so that we can keep this work on >> real and substantial problems. >> > > real substantial problem includes the need of "tunnel as virtual link" > building block in the Internet architecture. > > > Keeping it simple, without depending on complex and fussy concepts, > remains IMHO preferable. > > > 2. consider ICMPv4 error happens at R2: >>> >>> R2 sees original IPv4 packet at A, sent to B: >>> +---------+----------------------------------------------+ >>> | IPv4 | payload | >>> | hdr, H1 | P1 | >>> +---------+----------------------------------------------+ >>> >>> R2 has found some error with that packet, issuing an ICMPv4 message and >>> sending to A: >>> +---------+--------+--------+--------------+ >>> | IPv4 | ICMPv4 | IPv4 | truncated | >>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>> +---------+--------+--------+--------------+ >>> |<- 8 octet ->| >>> \__________ __________/ >>> V >>> as the ICMPv4 error message body >>> >>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >>> +------------+--------+--------+--------------+ >>> | IPv6 | ICMPv4 | IPv4 | truncated | >>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>> +------------+--------+--------+--------------+ >>> >>> woops, unfortunately, R1 also found something wrong. R1 generates an >>> ICMPv6 report, responding back to B: >>> +------------+--------+------------+--------+--------+--------------+ >>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >>> +------------+--------+------------+--------+--------+--------------+ >>> >>> BR sees this and makes translation to: >>> +---------+--------+---------+--------+--------+------------+ >>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>> +---------+--------+---------+--------+--------+------------+ >>> |<------- 8 octet ----------->| >>> \___________________ __________________/ >>> V >>> as the ICMPv4 error message body >>> >>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. >>> here 4rd-U can have two options: >>> 1) let it be but depends on the IPv4 Internet routers, or host B itself >>> to drop the ICMP of ICMP; >>> 2) actively check the header in the ICMPv4 message body (H9 above) and >>> identify if the protocol of the discard-packet is ICMPv4 too; if so, BR >>> drops the packet. >>> >>> i doubt either is good. anyway, no matter which is used, 4rd-U must dea= l >>> with this issue. (sorry if i missed some text where it has been done.) >>> >>> >> (**) >> >> The right choice is clearly 2 (RFC792 rightly says: "To avoid the >>> infinite regress of messages about messages etc., no ICMP messages are = sent >>> about ICMP messages.") >>> >> >> >> sure 2) is better than 1). however, the remained problem is IPv6 carryin= g >> ICMPv4. i just summarize my concerns here in order the community can jud= ge >> the impact: >> #1. such kind of packet loses the consistency between the destination >> address in the IPv6 header and the source address of original IPv4 heade= r >> contained in the ICMP error message. >> >> >> That's getting tricky. >> > > yes. but i don't think people keeping part of original packets in ICMP > message body is trivial. > > > If not "trivial" at least quite simple: > > +------------+--------+------------+--------------+ > | IPv6 | ICMPv6 | IPv6 | truncated | > | header, H2 | hdr, C1| header, H1 | payload, P1 | > +------------+--------+------------+--------------+ > || > \/ > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > SRC of H2 is a constant > DST of H2 and H3, and SRC of H2, are copied from fields in H1 > The ICMPv4 checksum is computed from scratch. > > well, not this case. but the IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original packet). > > > > Will you be in Paris so that we can discuss with a piece of paper details >> of what you have in mind? (In the following 3 days, I will be busy >> otherwise, and will have little or no access to email.) >> >> > sorry but i couldn't go to Paris due to the company's arrangement. > > > > Your presence will be missed. Sorry to learn that. > > thanks! it is pity that i cannot discuss with you face-to-face this time. > > > > #2. such kind of packet loses IP header integrity mechanism as neither >> IPv4's header checksum nor the ICMPv6's checksum containing pseudo-heade= r >> is included. >> >> >> Packets discussed here will never be delivered anyway (ICMP about ICMP). >> I don't see how any practical concern would appear here. >> > > #2 is not about ICMP about ICMP but about no checksum for IP addresses in > IP neither in ICMP. i don't think people keeping checksum here or there i= s > trivial. > > > Not sure to see the issue. > When an ICMPv4 error message is synthesized, its ICMP checksum can easily > be computed, as explained above. > (Always keeping only 8 octets of the original payload, as > specified, strictly limits the computation.) > > not the ICMP data checksum, but about the integrity of IP header. in IPv4, IP header has checksum; in IPv6, ICMPv6 checksum includes the pseudo-header. regards, maoke > > > > because it is stated that 4rd-U is "ensuring compatibility with IPv6-only >> middle boxes that perform deep-packet-inspection", i here point out at >> least #1 checking on ICMP error message being sent to the exact source o= f >> original packet, and #2 checking on IP header integrity by calculating t= he >> checksum in header or pseudo-header cannot rely on the functionality of = the >> middle boxes in the IPv6-only domain that perform deep-packet-inspection= . >> then 4rd-U CE/BR MUST consider these issues as well. >> >> (neither MAP-T nor MAP-E has the similar concern). >> >> >> For MAP-E, of course (compatibility with IPv6-only middle boxes is off >> scope). >> For MAP-T, see above. >> > > IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. > > > Sure. > Now, if an ICMPv6 error packet is returned whose partially returned > payload is that of an ICMPv4 message, i.e. with an unknown protocol in > IPv6, this packet can be indifferently discarded or forwarded after DPI > without any negative effect. > (If not discarded here, it will be discarded at 4rd tunnel exit.) > > > no further concern. > > > > Cheers, > RD > > > > > > - maoke > > >> >> >> >> - maoke >> >> >> (**) >> >> It can be made more explicit in the specification. >>> >> >> In R-16, after "If a CE or BR receives an ICMPv6 error message >> [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we coul= d >> add "(unless the message concerns a ICMP message, as required by [RFC079= 2] >> to avoid ICMP about ICMP)". >> >> Thanks, >> RD >> >> >> >> >> Thanks. >>> >> >>> >>> Cheers, >>> RD >>> >>> >>> >>> >>> >>> cheers, >>> maoke >>> >>> 2012/3/12 R=E9mi Despr=E9s >>> >>>> Hello, all, >>>> >>>> An updated version of draft-despres-softwire-4rd-u is now available at >>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>> >>>> Differences with -04 include: >>>> - DHCPv6 options are now specified >>>> - various errors and typos are corrected >>>> - some clarifications are added, following received questions and >>>> comments >>>> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs >>>> and within CPEs) >>>> - An editor's note has been added, following a WG-ML discussion, about >>>> an additional Mapping-rule parameter that might be needed to assign >>>> privileged ports to to some shared-address CEs. >>>> - Document layout has been adjusted as a result of other modifications= . >>>> - the authors list has been completed. >>>> >>>> Questions and comments are most welcome. >>>> >>>> Regards, >>>> RD >>>> >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> >>> >> >> > > --20cf3074b47ed125db04bb996485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 11:38, = Maoke a =E9crit :
...

<= div class=3D"gmail_quote">

let me draw an ex= ample for that:

A --- CE ----(IPv6 domain; router = R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
=
...

4rd-u isn't concerne= d with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for 4rd-= u, but RFC6145/6146 work also in the case the translator is not located nex= t to the end hosts. then i understand 4rd-u is less flexible.=A0

I don't see the configuration yo= u have in mind.
=A0
=A0
<= div>people often insert a router between the home CE and their computers ;-= ) sometimes, e.g., because the CE has limited number of ports for connectio= n or less funtioning.
=A0
=A0

= =A0
Anything missing?
<= /div>
...

Both of us know that double t= ranslation in general looses some information.

to me, behavior is more important than the acceptable= level of information loss.

Not understood.
=A0<= /div>
=A0
then let's keep our ow= n point for next face-to-face discussion.
=A0
=A0
on the other ha= nd, we cannot state 4rd-U doesn't lose any information.=A0
<= /blockquote>

4rd options aren't supported (like in MAP-T)<= /div>
What else do you see as lost e2e?
=A0
=
=A0
not else end-to-end except the original TTL= across the IPv6 cloud. (therefore i said any information. :)
=A0
=A0

=A0
What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems.

real substantial problem includes the need of "tunnel as virt= ual link" building block in the Internet architecture.=A0

Keeping it simple, without dep= ending on complex and fussy concepts, remains IMHO preferable.
=A0=A0

<= div class=3D"gmail_quote">
2. consider ICMPv4 = error happens at R2:=A0

R2 sees original IPv4= packet at A, sent to B:
+---------+-----------------------------= -----------------+
| IPv4 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)
<= /div>

(**)

The right choice is= clearly 2 (RFC792 rightly says: "To avoid the infinite regress of mes= sages about messages etc., no ICMP messages are sent about ICMP messages.&q= uot;)


sure 2) is better than 1). h= owever, the remained problem is IPv6 carrying ICMPv4. i just summarize my c= oncerns here in order the community can judge the impact:=A0
#1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 header c= ontained in the ICMP error message.

That's getting tricky.

yes. but i don't think people keeping part of original packets in ICM= P message body is trivial.

If not "trivial" at least quite simple:

=
+------------+--------+------------+--------------+
| = IPv6 =A0 =A0 =A0 | ICMPv6 | IPv6 =A0 =A0 =A0 | truncated =A0 =A0|
| header, H2 | hdr, C1| header, H1 | payload, P1 =A0|
+------------+--------+------------+--------------+
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ||
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \/
+---------+--------+--------+---= -----------+
| IPv4 =A0 =A0| ICMPv4 | IPv4 =A0 | truncated =A0 = =A0|
| hdr, H2 | hdr, C1| hdr, H3| payload, P2 =A0|
+---------+--------+--------+--------------+ =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |<- 8 octet =A0->|
SRC of H2 is a constant
DST of H2 and H3, and SRC of H2, are copied from fields in H1
The ICMPv4 checksum is computed from scratch.
=A0
=A0
well, not this case. but the IPv6Header= -ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original packet).
=A0
=A0


<= div class=3D"gmail_quote">
Will you be in Paris so that we ca= n discuss with a piece of paper details of what you have in mind?=A0(In the= following 3 days, I will be busy otherwise, and will have little or no acc= ess to email.)


sorry but = i couldn't go to Paris due to the company's arrangement.=A0


Your presence will be = missed. Sorry to learn that.
=A0
=A0
thanks! it is pity that= i cannot discuss with you face-to-face this time.
=A0
=A0

#2. such kind of packet loses IP header integr= ity mechanism as neither IPv4's header checksum nor the ICMPv6's ch= ecksum containing pseudo-header is included.=A0

Packets discussed here will ne= ver be delivered anyway (ICMP about ICMP).
I don't see how an= y practical concern would appear here.=A0

#2 is not about ICMP about ICMP but about no checksum for IP= addresses in IP neither in ICMP. i don't think people keeping checksum= here or there is trivial.=A0

Not sure to see the issue.
When an ICMPv4 error message is s= ynthesized, its ICMP checksum can easily be computed, as explained above.
(Always keeping only 8 octets of the original payload, as specifie= d,=A0strictly limits the computation.)
=A0
=A0
not the ICMP data= checksum, but about the integrity of IP header. in IPv4, IP header has che= cksum; in IPv6, ICMPv6 checksum includes the pseudo-header.
=A0<= /div>
regards,
maoke
=A0
=A0


because it is stated that 4rd-U is "ensuring compatibility with I= Pv6-only middle boxes that perform deep-packet-inspection", i here poi= nt out at least #1 checking on ICMP error message being sent to the exact s= ource of original packet, and #2 checking on IP header integrity by calcula= ting the checksum in header or pseudo-header cannot rely on the functionali= ty of the middle boxes in the IPv6-only domain that perform deep-packet-ins= pection. then 4rd-U CE/BR MUST consider these issues as well.=A0

(neither MAP-T nor MAP-E has the similar concern).

For MAP-E, of course (compati= bility with IPv6-only middle boxes is off scope).
For MAP-T, see = above.

IPv6 carrying ICMPv6 is able t= o be deeply inspected by any IPv6 nodes.

=
Sure.
Now, if an ICMPv6 error packet is ret= urned whose partially returned payload is that of an ICMPv4 message, i.e. w= ith an unknown protocol in IPv6, this packet can be indifferently discarded= or forwarded after DPI without any negative effect.=A0
(If not discarded here, it will be discarded at 4rd tunnel exit.)


no further concern.

<= div>
Cheers,
RD
=



=A0

- maoke
=A0

=A0

- maoke=A0

(**)

It can be made more= explicit in the specification.
=

In=A0R-16, after =A0"If a= CE or BR receives an ICMPv6 error message [RFC4443], it=A0 MUST synthesize= an ICMPv4 error packet [RFC0792]" we could add "(unless the mess= age concerns a ICMP message, as required by [RFC0792] to avoid ICMP about I= CMP)".

Thanks,
RD


=


Thanks.
=


Cheers,
RD




cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires







--20cf3074b47ed125db04bb996485-- From despres.remi@laposte.net Mon Mar 19 07:37:40 2012 Return-Path: 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 8309B21F8814 for ; Mon, 19 Mar 2012 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 fm12QgKF+vHe for ; Mon, 19 Mar 2012 07:37:39 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 5891721F87E0 for ; Mon, 19 Mar 2012 07:37:32 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id nSdR1i00F37Y3f403SdR2E; Mon, 19 Mar 2012 15:37:31 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C07A8D42B@XMB-RCD-111.cisco.com> Date: Mon, 19 Mar 2012 15:37:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net><96214733-7D45-436E-81C2-6E6701542C79@employees.org><4F348EEB.4050908@cernet.edu.cn><86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net><4F59AE74.4090204@cernet.edu.cn><5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net><4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> <067E6CE33034954AAC05C9EC85E2577C07A8D42B@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:37:40 -0000 Hi, Rajiv, Le 2012-03-19 =E0 15:16, Rajiv Asati (rajiva) a =E9crit : >=20 >> I am well aware of this, but this doesn't explain why 4rd mapping = rules similar >> to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 = communication >> (single translation) supported". >>=20 >>=20 >> As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via >> manual configuration or stateful autoconfiguration via DHCPv6". >> Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with >> V octet and CNP). >=20 > I see a tremendous value & advantage in standardizing a mechanism = (such as MAP-T (aka dIVI)) that has been in production networks for = ~2yrs. 4rd-u is very close to both 4rd-T and 4rd-E (built AFAIK in due = knowledge of what they achieve). Its purpose is to makes possible a unified standard that supports not = only use cases a la dIVI, but also those of MAP-E (or the reverse = depending on one comes from). The real questions is then: - is one standard better than 2? - and if yes, which one is a best IETF choice: MAP-T only, MAP-E only, = or 4rd-U only. Is seems you would prefer MAP-T only, but that's for the WG to find a = consensus once informed about possible choices. =20 See you next week, RD >=20 > Cheers, > Rajiv >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On >> Behalf Of R=E9mi Despr=E9s >> Sent: Monday, March 19, 2012 9:22 AM >> To: Xing Li >> Cc: Softwires WG; Yong Cui; Ralph Droms (rdroms) >> Subject: Re: [Softwires] MAP and 4rd - Relationship with Single = translation >>=20 >> Hi, Xing, >>=20 >> I look forward to face to face discussions in Paris if we don't = clarify everything >> before that (I will be busy on something else in the next 3 days). >>=20 >>=20 >> Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : >> ... >>=20 >>=20 >>=20 >> A key point is that 4rd doesn't prevent a 4rd-capable = dual- >> stack CE node, when it receives no 4rd mapping rule, to exercise = single >> translation. >> Actually, I believe that using for this the BIH of = RFC6535 is >> both sufficient and recommendable. >> Translated IPv4 packets, because they are sent from CE = nodes >> to DNS64 synthesized addresses, are appropriately routed to their = destinations. >> (It can be via the NAT64-CGN if needed, or via more direct paths if = possible.) >> Anything missed? >>=20 >>=20 >> Sorry, this is a misunderstanding. >> Hint: Single translation and double translation are based on the = same >> mapping rule in the CERNET2 deployment. >>=20 >>=20 >>=20 >> I am well aware of this, but this doesn't explain why 4rd mapping = rules similar >> to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 = communication >> (single translation) supported". >>=20 >>=20 >> As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via >> manual configuration or stateful autoconfiguration via DHCPv6". >> Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with >> V octet and CNP). >>=20 >>=20 >> Now, when both addresses happen to be checksum neutral, RFC6145 >> translation doesn't modify L4 data, so that it doesn't matter whether = the DS >> node has used 4rd-u header mapping or single translation. >> Thus, IPv6-only hosts can exchange packets with IPv4 applications of = 4rd CE >> nodes. >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> xing >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> xing >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit= : >> ... | | | | | >>=20 >> | 5 | IPv6 = web >> caches work for IPv4 | Y | N | Y | N | >> | | packets >> | | | | | >>=20 >> suggest you rename to = "IPv4 >> to IPv6 communication (single translation) supported" >>=20 >>=20 >>=20 >> (2) More clarification should be = added >> here. I am not sure 4rd-H can support single translation. >>=20 >> (a) According to (1), 4rd-H does = not >> perform header translation defined by RFC6145. >>=20 >> (b) In the softwire mailing = list, it seems >> that 4rd-H cannot support single translation. See the thread = containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html = and >> other posts. >>=20 >> (c) If 4rd-H cannot support = single >> translation, then "IPv6 web caches work for IPv4 packets" requires = special >> configurations, it cannot do IPv6 web caches for non 4rd-H packets. >>=20 >>=20 >>=20 >> ... >>=20 >>=20 >> (5) I would like to see the = details of >> how 4rd-H handles ICMP and ICMP error messages. In the softwire = mailing list >> there were some discussions. See the thread containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html = and >> other posts. Please add >>=20 >>=20 >> | 17 | Handle ICMP (RFC6145) | Y = | >> n/a | ? | ? | >>=20 >> ... >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From despres.remi@laposte.net Mon Mar 19 08:03:16 2012 Return-Path: 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 E8CFE21F86F8 for ; Mon, 19 Mar 2012 08:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.076, 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 tB3SQOrpJblZ for ; Mon, 19 Mar 2012 08:03:13 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B721F87A0 for ; Mon, 19 Mar 2012 08:03:10 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id nT371i00A37Y3f403T37yw; Mon, 19 Mar 2012 16:03:08 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-151--472614933 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 16:03:06 +0100 Message-Id: <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:03:16 -0000 --Apple-Mail-151--472614933 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 15:30, Maoke a =E9crit : >=20 >=20 > 2012/3/19 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 11:38, Maoke a =E9crit : > ... >=20 >>>>=20 >>>> let me draw an example for that: >>>>=20 >>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 = Internet; router R2 here)--- B > ... >=20 >> 4rd-u isn't concerned with what happens between A and CE. >> There, internal hosts have RFC1918 addresses and external hosts = public IPv4 addresses. >>=20 >> no problem here for 4rd-u, but RFC6145/6146 work also in the case the = translator is not located next to the end hosts. then i understand 4rd-u = is less flexible.=20 >=20 > I don't see the configuration you have in mind. > =20 > =20 > people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning. I still don't see the problem with a NAT44 in the CE. If the CE itself, is behind a transparent CPE, I don't see more what the = problem would be. >> =20 >> Anything missing? > ... >=20 >> Both of us know that double translation in general looses some = information. >>=20 >> to me, behavior is more important than the acceptable level of = information loss. >=20 > Not understood. > =20 > =20 > then let's keep our own point for next face-to-face discussion. > =20 > =20 >=20 >> on the other hand, we cannot state 4rd-U doesn't lose any = information.=20 >=20 > 4rd options aren't supported (like in MAP-T) > What else do you see as lost e2e? > =20 > =20 > not else end-to-end except the original TTL across the IPv6 cloud. = (therefore i said any information. :) > =20 > =20 >=20 >> =20 >> What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique. >> Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems. >>=20 >> real substantial problem includes the need of "tunnel as virtual = link" building block in the Internet architecture.=20 >=20 > Keeping it simple, without depending on complex and fussy concepts, = remains IMHO preferable. > =20 >=20 >>>> 2. consider ICMPv4 error happens at R2:=20 >>>>=20 >>>> R2 sees original IPv4 packet at A, sent to B: >>>> +---------+----------------------------------------------+ >>>> | IPv4 | payload | >>>> | hdr, H1 | P1 | >>>> +---------+----------------------------------------------+ >>>>=20 >>>> R2 has found some error with that packet, issuing an ICMPv4 message = and sending to A: >>>> +---------+--------+--------+--------------+ >>>> | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>>> +---------+--------+--------+--------------+ >>>> |<- 8 octet ->| >>>> \__________ __________/ >>>> V >>>> as the ICMPv4 error message body >>>>=20 >>>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of = IPv6): >>>> +------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv4 | IPv4 | truncated | >>>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>> +------------+--------+--------+--------------+ >>>>=20 >>>> woops, unfortunately, R1 also found something wrong. R1 generates = an ICMPv6 report, responding back to B:=20 >>>> = +------------+--------+------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated = | >>>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 = | >>>> = +------------+--------+------------+--------+--------+--------------+ >>>>=20 >>>> BR sees this and makes translation to:=20 >>>> +---------+--------+---------+--------+--------+------------+ >>>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>>> +---------+--------+---------+--------+--------+------------+ >>>> |<------- 8 octet ----------->| >>>> \___________________ __________________/ >>>> V >>>> as the ICMPv4 error message body >>>>=20 >>>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is = generated. here 4rd-U can have two options: >>>> 1) let it be but depends on the IPv4 Internet routers, or host B = itself to drop the ICMP of ICMP;=20 >>>> 2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet.=20 >>>>=20 >>>> i doubt either is good. anyway, no matter which is used, 4rd-U must = deal with this issue. (sorry if i missed some text where it has been = done.) >>=20 >> (**) >>=20 >>> The right choice is clearly 2 (RFC792 rightly says: "To avoid the = infinite regress of messages about messages etc., no ICMP messages are = sent about ICMP messages.") >>=20 >>=20 >>> sure 2) is better than 1). however, the remained problem is IPv6 = carrying ICMPv4. i just summarize my concerns here in order the = community can judge the impact:=20 >>> #1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error message. >>=20 >> That's getting tricky. >>=20 >> yes. but i don't think people keeping part of original packets in = ICMP message body is trivial. >=20 > If not "trivial" at least quite simple: >=20 > +------------+--------+------------+--------------+ > | IPv6 | ICMPv6 | IPv6 | truncated | > | header, H2 | hdr, C1| header, H1 | payload, P1 | > +------------+--------+------------+--------------+ > || > \/ > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | > +---------+--------+--------+--------------+ =20 > |<- 8 octet ->| > SRC of H2 is a constant > DST of H2 and H3, and SRC of H2, are copied from fields in H1 > The ICMPv4 checksum is computed from scratch. > =20 > =20 > well, not this case. but the = IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original = packet). OK. In a 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 = payloads. There is no doubt AFAIK that they can be configured to let go one more = protocol (ICMPv4 in this instance). >> Will you be in Paris so that we can discuss with a piece of paper = details of what you have in mind? (In the following 3 days, I will be = busy otherwise, and will have little or no access to email.) >>=20 >>=20 >> sorry but i couldn't go to Paris due to the company's arrangement.=20 >=20 >=20 > Your presence will be missed. Sorry to learn that. > =20 > =20 > thanks! it is pity that i cannot discuss with you face-to-face this = time. > =20 > =20 >=20 >=20 >>> #2. such kind of packet loses IP header integrity mechanism as = neither IPv4's header checksum nor the ICMPv6's checksum containing = pseudo-header is included.=20 >>=20 >> Packets discussed here will never be delivered anyway (ICMP about = ICMP). >> I don't see how any practical concern would appear here.=20 >>=20 >> #2 is not about ICMP about ICMP but about no checksum for IP = addresses in IP neither in ICMP. i don't think people keeping checksum = here or there is trivial.=20 >=20 > Not sure to see the issue. > When an ICMPv4 error message is synthesized, its ICMP checksum can = easily be computed, as explained above. > (Always keeping only 8 octets of the original payload, as specified, = strictly limits the computation.) > =20 > =20 > not the ICMP data checksum, but about the integrity of IP header. in = IPv4, IP header has checksum; in IPv6, ICMPv6 checksum includes the = pseudo-header. Since the ICMPv4 that is synthesized when an ICMPv6 error message is = received is built from scratch (with 8 octets of IPv4 payload copied, = but with newly computed checksums), I can't see where there could be a = problem. (If you still see one, more details would be needed.) Regards, RD > =20 > regards, > maoke > =20 > =20 >=20 >=20 >>> because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well.=20 >>>=20 >>> (neither MAP-T nor MAP-E has the similar concern). >>=20 >> For MAP-E, of course (compatibility with IPv6-only middle boxes is = off scope). >> For MAP-T, see above. >>=20 >> IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 = nodes. >=20 > Sure. > Now, if an ICMPv6 error packet is returned whose partially returned = payload is that of an ICMPv4 message, i.e. with an unknown protocol in = IPv6, this packet can be indifferently discarded or forwarded after DPI = without any negative effect.=20 > (If not discarded here, it will be discarded at 4rd tunnel exit.) >=20 >=20 >> no further concern. >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >> =20 >>=20 >> - maoke >> =20 >>=20 >>> =20 >>>=20 >>> - maoke=20 >>=20 >> (**) >>=20 >>> It can be made more explicit in the specification. >>=20 >> In R-16, after "If a CE or BR receives an ICMPv6 error message = [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we = could add "(unless the message concerns a ICMP message, as required by = [RFC0792] to avoid ICMP about ICMP)". >>=20 >> Thanks, >> RD >>=20 >>=20 >>=20 >>=20 >>> Thanks. >>>=20 >>>=20 >>> Cheers, >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> cheers, >>>> maoke >>>>=20 >>>> 2012/3/12 R=E9mi Despr=E9s >>>> Hello, all, >>>>=20 >>>> An updated version of draft-despres-softwire-4rd-u is now available = at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>>=20 >>>> Differences with -04 include: >>>> - DHCPv6 options are now specified >>>> - various errors and typos are corrected >>>> - some clarifications are added, following received questions and = comments >>>> - the CE-behind-CPE use case has been revised (mix of CEs behind = CPEs and within CPEs) >>>> - An editor's note has been added, following a WG-ML discussion, = about an additional Mapping-rule parameter that might be needed to = assign privileged ports to to some shared-address CEs. >>>> - Document layout has been adjusted as a result of other = modifications. >>>> - the authors list has been completed. >>>>=20 >>>> Questions and comments are most welcome. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-151--472614933 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 11:38, Maoke a =E9crit :
...


let me = draw an example for that:

A --- CE ----(IPv6 = domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- = B
=
...

4rd-u isn't concerned = with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for = 4rd-u, but RFC6145/6146 work also in the case the translator is not = located next to the end hosts. then i understand 4rd-u is less = flexible. 

I don't see the configuration you = have in = mind.
 
 
people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning. =


I still don't see = the problem with a NAT44 in the CE.
If the CE itself, is = behind a transparent CPE, I don't see more what the problem would = be.


 
Anything = missing?
...

Both of us know that = double translation in general looses some = information.

to me, = behavior is more important than the acceptable level of information = loss.

Not = understood.
 
 
then let's keep our own point for next face-to-face discussion. =
 
 

on the other hand, we cannot state 4rd-U = doesn't lose any information. 

4rd options aren't supported (like in = MAP-T)
What else do you see as lost = e2e?
 
 
= not else end-to-end except the original TTL across the IPv6 cloud. = (therefore i said any information. :)
 
 

 
What I wouldn't object to is to = rename the Reversible-header-mapping technique as = Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this = work on real and substantial = problems.

real = substantial problem includes the need of "tunnel as virtual link" = building block in the Internet architecture. 

Keeping it simple, without = depending on complex and fussy concepts, remains IMHO = preferable.
  

2. consider = ICMPv4 error happens at R2: 

R2 sees = original IPv4 packet at A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

R2 has found some error with that packet, = issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H6 | hdr, C3| hdr, H1| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as = payload of = IPv6):
+------------+--------+--------+--------------+
| IPv6       | ICMPv4 | IPv4   | = truncated    |
| header, H7 | hdr, C3| hdr, H1| payload, P3  = |
+------------+--------+--------+--------------+

=
woops, unfortunately, R1 also found something wrong. R1 = generates an ICMPv6 report, responding back to B: 
=
+------------+--------+------------+--------+--------+----------= ----+
| IPv6       | ICMPv6 | IPv6 =       | ICMPv4 | IPv4   | truncated   =  |
| header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| = payload, P3  |
=
+------------+--------+------------+--------+--------+--------------+=

BR sees this and = makes translation = to: 
+---------+--------+----= -----+--------+--------+------------+
| IPv4    | ICMPv4 | IPv4    | ICMPv4 | = IPv4   | truncated  |
| hdr, H10| hdr, C5| hdr, = H9 | hdr, C3| hdr, H1| payload, = P4|
+---------+--------+---------+--------+--------+------------= +
        =                     =  |<------- 8 octet  = ----------->|
        =             \___________________ = __________________/
        =                     =             V
                  =        as the ICMPv4 error message = body

here an "ICMP of ICMP", which is not = allowed in ICMPv4, is generated. here 4rd-U can have two = options:
1) let it be but depends on the IPv4 Internet = routers, or host B itself to drop the ICMP of ICMP; 
2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet. 

i doubt either is = good. anyway, no matter which is used, 4rd-U must deal with this issue. = (sorry if i missed some text where it has been done.)
=
=

(**)

The right choice = is clearly 2 (RFC792 rightly says: "To avoid the infinite regress of = messages about messages etc., no ICMP messages are sent about ICMP = messages.")
=


sure 2) is better than = 1). however, the remained problem is IPv6 carrying ICMPv4. i just = summarize my concerns here in order the community can judge the = impact: 
#1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error = message.

That's getting = tricky.

yes. but i don't = think people keeping part of original packets in ICMP message body is = trivial.

If not "trivial" at least quite = simple:

+------------+--------+------------+-----= ---------+
| IPv6       | ICMPv6 | IPv6   =     | truncated    |
| header, H2 | hdr, = C1| header, H1 | payload, P1  |
=
+------------+--------+------------+--------------+
  =                   = ||
                =     \/
+---------+--------+--------+--------------+
|= IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H2 | hdr, C1| hdr, H3| payload, P2  |
+---------+--------+--------+--------------+   =             
    =                     =     |<- 8 octet  ->|
SRC of H2 is a = constant
DST of H2 and H3, and SRC of H2, are copied from fields in = H1
The ICMPv4 checksum is computed from = scratch.
 
 
<= div>well, not this case. but the = IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original = packet).

OK.
In a = 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 = payloads.
There is no doubt AFAIK that they can be configured = to let go one more protocol (ICMPv4 in this = instance).



Will you be in Paris so that we = can discuss with a piece of paper details of what you have in = mind? (In the following 3 days, I will be busy otherwise, and will = have little or no access to email.)


sorry = but i couldn't go to Paris due to the company's = arrangement. 


=
Your presence will be missed. Sorry to learn that.
 
 
thanks! it is = pity that i cannot discuss with you face-to-face this time. =
 
 


#2. such kind of packet = loses IP header integrity mechanism as neither IPv4's header checksum = nor the ICMPv6's checksum containing pseudo-header is = included. 

Packets discussed here will = never be delivered anyway (ICMP about ICMP).
I don't see how = any practical concern would appear = here. 

#2 is not about ICMP about ICMP but about no checksum for = IP addresses in IP neither in ICMP. i don't think people keeping = checksum here or there is = trivial. 

Not sure to see the issue.
When an ICMPv4 error message = is synthesized, its ICMP checksum can easily be computed, as explained = above.
(Always keeping only 8 octets of the original payload, = as specified, strictly limits the computation.)
 
 
not the = ICMP data checksum, but about the integrity of IP header. in IPv4, IP = header has checksum; in IPv6, ICMPv6 checksum includes the = pseudo-header.

Since the = ICMPv4 that is synthesized when an ICMPv6 error message is received is = built from scratch (with 8 octets of IPv4 payload copied, but with newly = computed checksums), I can't see where there could be a = problem.
(If you still see one, more details would be = needed.)

Regards,
RD



 
regards,
maoke
 
 


because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well. 

(neither MAP-T nor MAP-E has the similar = concern).

For MAP-E, = of course (compatibility with IPv6-only middle boxes is off = scope).
For MAP-T, see above.

IPv6 carrying ICMPv6 is = able to be deeply inspected by any IPv6 nodes. =

Sure.
No= w, if an ICMPv6 error packet is returned whose partially returned = payload is that of an ICMPv4 message, i.e. with an unknown protocol in = IPv6, this packet can be indifferently discarded or forwarded after DPI = without any negative effect. 
(If not discarded here, it will be discarded at 4rd tunnel = exit.)


no further = concern.


Cheers,
RD



 

- = maoke
 

 

- = maoke 

(**)

It can be made = more explicit in the specification. =

In R-16, after  "If a CE or BR receives an = ICMPv6 error message [RFC4443], it  MUST synthesize an ICMPv4 error = packet [RFC0792]" we could add "(unless the message concerns a ICMP = message, as required by [RFC0792] to avoid ICMP about ICMP)".
=

Thanks,
RD



Thanks.


Cheers,
RD



=

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 05

Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and = comments
- the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other = modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires








= --Apple-Mail-151--472614933-- From fibrib@gmail.com Mon Mar 19 08:09:01 2012 Return-Path: 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 F342521F8747 for ; Mon, 19 Mar 2012 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 sTt-qK5vGYDC for ; Mon, 19 Mar 2012 08:08:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7AFE21F8732 for ; Mon, 19 Mar 2012 08:08:58 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6268736ghb.31 for ; Mon, 19 Mar 2012 08:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vc1/bi0fznCKAk/5W05hv/qpIvBYTCYfUKs4qNlBAOI=; b=l3U6fmKqaUV8GS+CT9o4KQXiz7i/kLiuznZGScWyRKkj7drKAVc9kifv9K5000Gvs/ euuggoAfcqdTvnp/gYM7f0weyfkEhRRy9TmubLK3Bs7s0uwDRNkaYNC/ZXakhNd2zsc1 9mBSEcMdct95xGY+Vk9NrXRYnwtKwcXqSEXEC58T2oR3rxx3uitUzSVjI9DYQR1p728B zx0k58sZXqhkdY42gFVqsYD2kaQHrCJYH5EF+hq/Ke+FKHm12t4hsbH0a6mmarF3oyHw NvVZZNXZ0Aq0mObs/WBFYbvDgpgHbCDY/Q7ztsz1BEb4nFQ4OD1oMaVaGMvN34oYjguo omLw== MIME-Version: 1.0 Received: by 10.224.181.210 with SMTP id bz18mr15968683qab.13.1332169737687; Mon, 19 Mar 2012 08:08:57 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 08:08:57 -0700 (PDT) In-Reply-To: <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> Date: Tue, 20 Mar 2012 00:08:57 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30363ef7fed0ed04bb99ef7f Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:09:01 -0000 --20cf30363ef7fed0ed04bb99ef7f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/20 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 15:30, Maoke a =E9crit : > > > > 2012/3/19 R=E9mi Despr=E9s > >> >> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >> ... >> >> >>>> let me draw an example for that: >>>> >>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>> router R2 here)--- B >>>> >>>> ... >> >> 4rd-u isn't concerned with what happens between A and CE. >>> There, internal hosts have RFC1918 addresses and external hosts public >>> IPv4 addresses. >>> >> >> no problem here for 4rd-u, but RFC6145/6146 work also in the case the >> translator is not located next to the end hosts. then i understand 4rd-u= is >> less flexible. >> >> >> I don't see the configuration you have in mind. >> >> > > people often insert a router between the home CE and their computers ;-) > sometimes, e.g., because the CE has limited number of ports for connectio= n > or less funtioning. > > > > I still don't see the problem with a NAT44 in the CE. > If the CE itself, is behind a transparent CPE, I don't see more what the > problem would be. > > > >> >>> Anything missing? >>> >> ... >> >> Both of us know that double translation in general looses some >>> information. >>> >> >> to me, behavior is more important than the acceptable level of >> information loss. >> >> >> Not understood. >> >> > > then let's keep our own point for next face-to-face discussion. > > >> >> >> on the other hand, we cannot state 4rd-U doesn't lose any information. >> >> >> 4rd options aren't supported (like in MAP-T) >> What else do you see as lost e2e? >> >> > > not else end-to-end except the original TTL across the IPv6 cloud. > (therefore i said any information. :) > > >> >> >> >> >>> What I wouldn't object to is to rename the Reversible-header-mapping >>> technique as Reversible-header-translation technique. >>> Hope you can accept this as sufficient, so that we can keep this work o= n >>> real and substantial problems. >>> >> >> real substantial problem includes the need of "tunnel as virtual link" >> building block in the Internet architecture. >> >> >> Keeping it simple, without depending on complex and fussy concepts, >> remains IMHO preferable. >> >> >> 2. consider ICMPv4 error happens at R2: >>>> >>>> R2 sees original IPv4 packet at A, sent to B: >>>> +---------+----------------------------------------------+ >>>> | IPv4 | payload | >>>> | hdr, H1 | P1 | >>>> +---------+----------------------------------------------+ >>>> >>>> R2 has found some error with that packet, issuing an ICMPv4 message an= d >>>> sending to A: >>>> +---------+--------+--------+--------------+ >>>> | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>>> +---------+--------+--------+--------------+ >>>> |<- 8 octet ->| >>>> \__________ __________/ >>>> V >>>> as the ICMPv4 error message body >>>> >>>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >>>> +------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv4 | IPv4 | truncated | >>>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>> +------------+--------+--------+--------------+ >>>> >>>> woops, unfortunately, R1 also found something wrong. R1 generates an >>>> ICMPv6 report, responding back to B: >>>> +------------+--------+------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >>>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>> +------------+--------+------------+--------+--------+--------------+ >>>> >>>> BR sees this and makes translation to: >>>> +---------+--------+---------+--------+--------+------------+ >>>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>>> +---------+--------+---------+--------+--------+------------+ >>>> |<------- 8 octet ----------->| >>>> \___________________ __________________/ >>>> V >>>> as the ICMPv4 error message body >>>> >>>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. >>>> here 4rd-U can have two options: >>>> 1) let it be but depends on the IPv4 Internet routers, or host B itsel= f >>>> to drop the ICMP of ICMP; >>>> 2) actively check the header in the ICMPv4 message body (H9 above) and >>>> identify if the protocol of the discard-packet is ICMPv4 too; if so, B= R >>>> drops the packet. >>>> >>>> i doubt either is good. anyway, no matter which is used, 4rd-U must >>>> deal with this issue. (sorry if i missed some text where it has been d= one.) >>>> >>>> >>> (**) >>> >>> The right choice is clearly 2 (RFC792 rightly says: "To avoid the >>>> infinite regress of messages about messages etc., no ICMP messages are= sent >>>> about ICMP messages.") >>>> >>> >>> >>> sure 2) is better than 1). however, the remained problem is IPv6 >>> carrying ICMPv4. i just summarize my concerns here in order the communi= ty >>> can judge the impact: >>> #1. such kind of packet loses the consistency between the destination >>> address in the IPv6 header and the source address of original IPv4 head= er >>> contained in the ICMP error message. >>> >>> >>> That's getting tricky. >>> >> >> yes. but i don't think people keeping part of original packets in ICMP >> message body is trivial. >> >> >> If not "trivial" at least quite simple: >> >> +------------+--------+------------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | truncated | >> | header, H2 | hdr, C1| header, H1 | payload, P1 | >> +------------+--------+------------+--------------+ >> || >> \/ >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> SRC of H2 is a constant >> DST of H2 and H3, and SRC of H2, are copied from fields in H1 >> The ICMPv4 checksum is computed from scratch. >> >> > > well, not this case. but the > IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original > packet). > > > OK. > In a 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 > payloads. > There is no doubt AFAIK that they can be configured to let go one more > protocol (ICMPv4 in this instance). > > > > Will you be in Paris so that we can discuss with a piece of paper >>> details of what you have in mind? (In the following 3 days, I will be b= usy >>> otherwise, and will have little or no access to email.) >>> >>> >> sorry but i couldn't go to Paris due to the company's arrangement. >> >> >> >> Your presence will be missed. Sorry to learn that. >> >> > > thanks! it is pity that i cannot discuss with you face-to-face this time. > > >> >> >> >> #2. such kind of packet loses IP header integrity mechanism as neither >>> IPv4's header checksum nor the ICMPv6's checksum containing pseudo-head= er >>> is included. >>> >>> >>> Packets discussed here will never be delivered anyway (ICMP about ICMP)= . >>> I don't see how any practical concern would appear here. >>> >> >> #2 is not about ICMP about ICMP but about no checksum for IP addresses i= n >> IP neither in ICMP. i don't think people keeping checksum here or there = is >> trivial. >> >> >> Not sure to see the issue. >> When an ICMPv4 error message is synthesized, its ICMP checksum can easil= y >> be computed, as explained above. >> (Always keeping only 8 octets of the original payload, as >> specified, strictly limits the computation.) >> >> > > not the ICMP data checksum, but about the integrity of IP header. in IPv4= , > IP header has checksum; in IPv6, ICMPv6 checksum includes the > pseudo-header. > > > Since the ICMPv4 that is synthesized when an ICMPv6 error message is > received is built from scratch (with 8 octets of IPv4 payload copied, but > with newly computed checksums), I can't see where there could be a proble= m. > (If you still see one, more details would be needed.) > > well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, integrity of IP addresses has no checksum to protect. because IPv6 header has no checksum and ICMPv4 checksum doesn't cover pseudo-header at all. - maoke > > > Regards, > RD > > > > > regards, > maoke > > >> >> >> >> because it is stated that 4rd-U is "ensuring compatibility with >>> IPv6-only middle boxes that perform deep-packet-inspection", i here poi= nt >>> out at least #1 checking on ICMP error message being sent to the exact >>> source of original packet, and #2 checking on IP header integrity by >>> calculating the checksum in header or pseudo-header cannot rely on the >>> functionality of the middle boxes in the IPv6-only domain that perform >>> deep-packet-inspection. then 4rd-U CE/BR MUST consider these issues as >>> well. >>> >>> (neither MAP-T nor MAP-E has the similar concern). >>> >>> >>> For MAP-E, of course (compatibility with IPv6-only middle boxes is off >>> scope). >>> For MAP-T, see above. >>> >> >> IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. >> >> >> Sure. >> Now, if an ICMPv6 error packet is returned whose partially returned >> payload is that of an ICMPv4 message, i.e. with an unknown protocol in >> IPv6, this packet can be indifferently discarded or forwarded after DPI >> without any negative effect. >> (If not discarded here, it will be discarded at 4rd tunnel exit.) >> >> >> no further concern. >> >> >> >> Cheers, >> RD >> >> >> >> >> >> - maoke >> >> >>> >>> >>> >>> - maoke >>> >>> >>> (**) >>> >>> It can be made more explicit in the specification. >>>> >>> >>> In R-16, after "If a CE or BR receives an ICMPv6 error message >>> [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we cou= ld >>> add "(unless the message concerns a ICMP message, as required by [RFC07= 92] >>> to avoid ICMP about ICMP)". >>> >>> Thanks, >>> RD >>> >>> >>> >>> >>> Thanks. >>>> >>> >>>> >>>> Cheers, >>>> RD >>>> >>>> >>>> >>>> >>>> >>>> cheers, >>>> maoke >>>> >>>> 2012/3/12 R=E9mi Despr=E9s >>>> >>>>> Hello, all, >>>>> >>>>> An updated version of draft-despres-softwire-4rd-u is now available a= t >>>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>>> >>>>> Differences with -04 include: >>>>> - DHCPv6 options are now specified >>>>> - various errors and typos are corrected >>>>> - some clarifications are added, following received questions and >>>>> comments >>>>> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs >>>>> and within CPEs) >>>>> - An editor's note has been added, following a WG-ML discussion, abou= t >>>>> an additional Mapping-rule parameter that might be needed to assign >>>>> privileged ports to to some shared-address CEs. >>>>> - Document layout has been adjusted as a result of other modification= s. >>>>> - the authors list has been completed. >>>>> >>>>> Questions and comments are most welcome. >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>>> >>>> >>> >>> >> >> > > --20cf30363ef7fed0ed04bb99ef7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 15:30, = Maoke a =E9crit :


=
2012/3/19 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-19 =E0 11:38, = Maoke a =E9crit :
...


let me draw an ex= ample for that:

A --- CE ----(IPv6 domain; router = R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
=
...

<= blockquote type=3D"cite">
4rd-u isn't concerne= d with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for 4rd-= u, but RFC6145/6146 work also in the case the translator is not located nex= t to the end hosts. then i understand 4rd-u is less flexible.=A0

I don't see the configuration yo= u have in mind.
=A0
=A0
<= div>people often insert a router between the home CE and their computers ;-= ) sometimes, e.g., because the CE has limited number of ports for connectio= n or less funtioning.


I still don't se= e the problem with a NAT44 in the CE.
If the CE itself, is behind= a transparent CPE, I don't see more what the problem would be.


=A0
Anything missing?
<= /div>
...
Both of us know that double t= ranslation in general looses some information.

to me, behavior is more important than the acceptable= level of information loss.

Not understood.
=A0<= /div>
=A0
then let's keep our ow= n point for next face-to-face discussion.
=A0
=A0

on the other hand, we cannot= state 4rd-U doesn't lose any information.=A0

4rd options aren't supported (like in MAP-T)<= /div>
What else do you see as lost e2e?
=A0
=
=A0
not else end-to-end except the original TTL= across the IPv6 cloud. (therefore i said any information. :)
=A0
=A0

=A0
What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems.

real substantial problem includes the need of "tunnel as virt= ual link" building block in the Internet architecture.=A0

Keeping it simple, without dep= ending on complex and fussy concepts, remains IMHO preferable.
=A0=A0

2. consider ICMPv4 = error happens at R2:=A0

R2 sees original IPv4= packet at A, sent to B:
+---------+-----------------------------= -----------------+
| IPv4 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)
<= /div>

(**)

The right choice is= clearly 2 (RFC792 rightly says: "To avoid the infinite regress of mes= sages about messages etc., no ICMP messages are sent about ICMP messages.&q= uot;)


sure 2) is better than 1). h= owever, the remained problem is IPv6 carrying ICMPv4. i just summarize my c= oncerns here in order the community can judge the impact:=A0
#1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 header c= ontained in the ICMP error message.

That's getting tricky.

yes. but i don't think people keeping part of original packets in ICM= P message body is trivial.

If not "trivial" at least quite simple:

=
+------------+--------+------------+--------------+
| = IPv6 =A0 =A0 =A0 | ICMPv6 | IPv6 =A0 =A0 =A0 | truncated =A0 =A0|
| header, H2 | hdr, C1| header, H1 | payload, P1 =A0|
+------------+--------+------------+--------------+
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ||
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \/
+---------+--------+--------+--------------+<= /div>
| IPv4 =A0 =A0| ICMPv4 | IPv4 =A0 | truncated =A0 =A0|
| hdr, H2 | hdr, C1| hdr, H3| payload, P2 =A0|
+-= --------+--------+--------+--------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8 o= ctet =A0->|
SRC of H2 is a constant
DST of H2 and H3, and SRC of H2, are copied from fields in H1
The ICMPv4 checksum is computed from scratch.
=A0
=A0
well, not this case. but the IPv6Header= -ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original packet).

OK.
In a 4rd-u= domain, middle boxes shouldn't discard packets having ICMPv4 payloads.=
There is no doubt AFAIK that they can be configured to let go on= e more protocol (ICMPv4 in this instance).



Will you be in Paris so that we ca= n discuss with a piece of paper details of what you have in mind?=A0(In the= following 3 days, I will be busy otherwise, and will have little or no acc= ess to email.)


sorry but = i couldn't go to Paris due to the company's arrangement.=A0


Your presence will be = missed. Sorry to learn that.
=A0
=A0
thanks! it is pity that= i cannot discuss with you face-to-face this time.
=A0
=A0


#2. such kind of packet loses IP header integr= ity mechanism as neither IPv4's header checksum nor the ICMPv6's ch= ecksum containing pseudo-header is included.=A0

Packets discussed here will ne= ver be delivered anyway (ICMP about ICMP).
I don't see how an= y practical concern would appear here.=A0

#2 is not about ICMP about ICMP but about no checksum for IP= addresses in IP neither in ICMP. i don't think people keeping checksum= here or there is trivial.=A0

Not sure to see the issue.
When an ICMPv4 error message is s= ynthesized, its ICMP checksum can easily be computed, as explained above.
(Always keeping only 8 octets of the original payload, as specifie= d,=A0strictly limits the computation.)
=A0
=A0
not the ICMP data= checksum, but about the integrity of IP header. in IPv4, IP header has che= cksum; in IPv6, ICMPv6 checksum includes the pseudo-header.

Since the ICMPv4 that is synthesized when an ICMP= v6 error message is received is built from scratch (with 8 octets of IPv4 p= ayload copied, but with newly computed checksums), I can't see where=A0= there could be a problem.
(If you still see one, more details would be needed.)
=A0
=A0
well. i mean in the case of = 4rd-U=A0IPv6 carrying ICMPv4, integrity of IP addresses has no checksum to = protect. because IPv6 header has no checksum and ICMPv4 checksum doesn'= t cover pseudo-header at all. - maoke
=A0
=A0

Regards,
RD



=A0
regards,
maoke
=A0
=A0


because it is stated that 4rd-U is "ensuring compatibility with I= Pv6-only middle boxes that perform deep-packet-inspection", i here poi= nt out at least #1 checking on ICMP error message being sent to the exact s= ource of original packet, and #2 checking on IP header integrity by calcula= ting the checksum in header or pseudo-header cannot rely on the functionali= ty of the middle boxes in the IPv6-only domain that perform deep-packet-ins= pection. then 4rd-U CE/BR MUST consider these issues as well.=A0

(neither MAP-T nor MAP-E has the similar concern).

For MAP-E, of course (compati= bility with IPv6-only middle boxes is off scope).
For MAP-T, see = above.

IPv6 carrying ICMPv6 is able t= o be deeply inspected by any IPv6 nodes.

=
Sure.
Now, if an ICMPv6 error packet is ret= urned whose partially returned payload is that of an ICMPv4 message, i.e. w= ith an unknown protocol in IPv6, this packet can be indifferently discarded= or forwarded after DPI without any negative effect.=A0
(If not discarded here, it will be discarded at 4rd tunnel exit.)


no further concern.


Cheers,
RD



=A0

- maoke
=A0

=A0

- maoke=A0

(**)

It can be made more= explicit in the specification.
=

In=A0R-16, after =A0"If a= CE or BR receives an ICMPv6 error message [RFC4443], it=A0 MUST synthesize= an ICMPv4 error packet [RFC0792]" we could add "(unless the mess= age concerns a ICMP message, as required by [RFC0792] to avoid ICMP about I= CMP)".

Thanks,
RD


=


Thanks.
=


Cheers,
RD




cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires









--20cf30363ef7fed0ed04bb99ef7f-- From fibrib@gmail.com Mon Mar 19 08:12:42 2012 Return-Path: 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 4EF3421F87EA for ; Mon, 19 Mar 2012 08:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 AI6VW5dL+lM9 for ; Mon, 19 Mar 2012 08:12:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F35A421F87E5 for ; Mon, 19 Mar 2012 08:12:39 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6273292ghb.31 for ; Mon, 19 Mar 2012 08:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TR9pqg1CJ1nfG3su8UTYViEMLwHomHRswUYsaRu/cb4=; b=FlYaEA3ZhkMzrJffwM0EtNw1V8yuZ98dMnE1NslPNZAxku3U4Ia3mOEu+e+iWyB57r htswEy0noHw90TbC1vvqUK9dQ/A7M5ZtEbWyeX+aQLpnHZfufBycy7vwR5ek1ZeclzlS IRbNlz4ib+f4+0j129KyhAQzzHXM5dHn8/seL0BbEN4a05sKJKrgj8WE0STtIISQj1FA KtjpYdyYccfKbrv+5mJR/NF7Ylz+5jsr/8YAxZNTTPa2GX2HRvDOjp+nuajG+EXSEtnA lt01hWITldL2OFIhViDTszA2WGZIMayp9myfK+an2ASIZ/+TsZGcSfUgBCQVZ3u8KE3z ed9g== MIME-Version: 1.0 Received: by 10.224.101.130 with SMTP id c2mr15766844qao.47.1332169959494; Mon, 19 Mar 2012 08:12:39 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 19 Mar 2012 08:12:39 -0700 (PDT) In-Reply-To: <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> Date: Tue, 20 Mar 2012 00:12:39 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b7943752b804bb99fde5 Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:12:42 -0000 --20cf3074b7943752b804bb99fde5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/20 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 15:30, Maoke a =E9crit : > > > > 2012/3/19 R=E9mi Despr=E9s > >> >> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >> ... >> >> >>>> let me draw an example for that: >>>> >>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>> router R2 here)--- B >>>> >>>> ... >> >> 4rd-u isn't concerned with what happens between A and CE. >>> There, internal hosts have RFC1918 addresses and external hosts public >>> IPv4 addresses. >>> >> >> no problem here for 4rd-u, but RFC6145/6146 work also in the case the >> translator is not located next to the end hosts. then i understand 4rd-u= is >> less flexible. >> >> >> I don't see the configuration you have in mind. >> >> > > people often insert a router between the home CE and their computers ;-) > sometimes, e.g., because the CE has limited number of ports for connectio= n > or less funtioning. > > > > I still don't see the problem with a NAT44 in the CE. > > the topic is about 0.0.0.0 as the source address for the ICMPv6-translated ICMPv4 message's IP header. if there is a router between the CE and the host, the packet with 0.0.0.0 will be discarded rather than being forwarded, according to the common definition of the "unspecified address". > > If the CE itself, is behind a transparent CPE, I don't see more what the > problem would be. > > > >> >>> Anything missing? >>> >> ... >> >> Both of us know that double translation in general looses some >>> information. >>> >> >> to me, behavior is more important than the acceptable level of >> information loss. >> >> >> Not understood. >> >> > > then let's keep our own point for next face-to-face discussion. > > >> >> >> on the other hand, we cannot state 4rd-U doesn't lose any information. >> >> >> 4rd options aren't supported (like in MAP-T) >> What else do you see as lost e2e? >> >> > > not else end-to-end except the original TTL across the IPv6 cloud. > (therefore i said any information. :) > > >> >> >> >> >>> What I wouldn't object to is to rename the Reversible-header-mapping >>> technique as Reversible-header-translation technique. >>> Hope you can accept this as sufficient, so that we can keep this work o= n >>> real and substantial problems. >>> >> >> real substantial problem includes the need of "tunnel as virtual link" >> building block in the Internet architecture. >> >> >> Keeping it simple, without depending on complex and fussy concepts, >> remains IMHO preferable. >> >> >> 2. consider ICMPv4 error happens at R2: >>>> >>>> R2 sees original IPv4 packet at A, sent to B: >>>> +---------+----------------------------------------------+ >>>> | IPv4 | payload | >>>> | hdr, H1 | P1 | >>>> +---------+----------------------------------------------+ >>>> >>>> R2 has found some error with that packet, issuing an ICMPv4 message an= d >>>> sending to A: >>>> +---------+--------+--------+--------------+ >>>> | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>>> +---------+--------+--------+--------------+ >>>> |<- 8 octet ->| >>>> \__________ __________/ >>>> V >>>> as the ICMPv4 error message body >>>> >>>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >>>> +------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv4 | IPv4 | truncated | >>>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>> +------------+--------+--------+--------------+ >>>> >>>> woops, unfortunately, R1 also found something wrong. R1 generates an >>>> ICMPv6 report, responding back to B: >>>> +------------+--------+------------+--------+--------+--------------+ >>>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >>>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>> +------------+--------+------------+--------+--------+--------------+ >>>> >>>> BR sees this and makes translation to: >>>> +---------+--------+---------+--------+--------+------------+ >>>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>>> +---------+--------+---------+--------+--------+------------+ >>>> |<------- 8 octet ----------->| >>>> \___________________ __________________/ >>>> V >>>> as the ICMPv4 error message body >>>> >>>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. >>>> here 4rd-U can have two options: >>>> 1) let it be but depends on the IPv4 Internet routers, or host B itsel= f >>>> to drop the ICMP of ICMP; >>>> 2) actively check the header in the ICMPv4 message body (H9 above) and >>>> identify if the protocol of the discard-packet is ICMPv4 too; if so, B= R >>>> drops the packet. >>>> >>>> i doubt either is good. anyway, no matter which is used, 4rd-U must >>>> deal with this issue. (sorry if i missed some text where it has been d= one.) >>>> >>>> >>> (**) >>> >>> The right choice is clearly 2 (RFC792 rightly says: "To avoid the >>>> infinite regress of messages about messages etc., no ICMP messages are= sent >>>> about ICMP messages.") >>>> >>> >>> >>> sure 2) is better than 1). however, the remained problem is IPv6 >>> carrying ICMPv4. i just summarize my concerns here in order the communi= ty >>> can judge the impact: >>> #1. such kind of packet loses the consistency between the destination >>> address in the IPv6 header and the source address of original IPv4 head= er >>> contained in the ICMP error message. >>> >>> >>> That's getting tricky. >>> >> >> yes. but i don't think people keeping part of original packets in ICMP >> message body is trivial. >> >> >> If not "trivial" at least quite simple: >> >> +------------+--------+------------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | truncated | >> | header, H2 | hdr, C1| header, H1 | payload, P1 | >> +------------+--------+------------+--------------+ >> || >> \/ >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> SRC of H2 is a constant >> DST of H2 and H3, and SRC of H2, are copied from fields in H1 >> The ICMPv4 checksum is computed from scratch. >> >> > > well, not this case. but the > IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original > packet). > > > OK. > In a 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 > payloads. > There is no doubt AFAIK that they can be configured to let go one more > protocol (ICMPv4 in this instance). > > > > Will you be in Paris so that we can discuss with a piece of paper >>> details of what you have in mind? (In the following 3 days, I will be b= usy >>> otherwise, and will have little or no access to email.) >>> >>> >> sorry but i couldn't go to Paris due to the company's arrangement. >> >> >> >> Your presence will be missed. Sorry to learn that. >> >> > > thanks! it is pity that i cannot discuss with you face-to-face this time. > > >> >> >> >> #2. such kind of packet loses IP header integrity mechanism as neither >>> IPv4's header checksum nor the ICMPv6's checksum containing pseudo-head= er >>> is included. >>> >>> >>> Packets discussed here will never be delivered anyway (ICMP about ICMP)= . >>> I don't see how any practical concern would appear here. >>> >> >> #2 is not about ICMP about ICMP but about no checksum for IP addresses i= n >> IP neither in ICMP. i don't think people keeping checksum here or there = is >> trivial. >> >> >> Not sure to see the issue. >> When an ICMPv4 error message is synthesized, its ICMP checksum can easil= y >> be computed, as explained above. >> (Always keeping only 8 octets of the original payload, as >> specified, strictly limits the computation.) >> >> > > not the ICMP data checksum, but about the integrity of IP header. in IPv4= , > IP header has checksum; in IPv6, ICMPv6 checksum includes the > pseudo-header. > > > Since the ICMPv4 that is synthesized when an ICMPv6 error message is > received is built from scratch (with 8 octets of IPv4 payload copied, but > with newly computed checksums), I can't see where there could be a proble= m. > (If you still see one, more details would be needed.) > > Regards, > RD > > > > > regards, > maoke > > >> >> >> >> because it is stated that 4rd-U is "ensuring compatibility with >>> IPv6-only middle boxes that perform deep-packet-inspection", i here poi= nt >>> out at least #1 checking on ICMP error message being sent to the exact >>> source of original packet, and #2 checking on IP header integrity by >>> calculating the checksum in header or pseudo-header cannot rely on the >>> functionality of the middle boxes in the IPv6-only domain that perform >>> deep-packet-inspection. then 4rd-U CE/BR MUST consider these issues as >>> well. >>> >>> (neither MAP-T nor MAP-E has the similar concern). >>> >>> >>> For MAP-E, of course (compatibility with IPv6-only middle boxes is off >>> scope). >>> For MAP-T, see above. >>> >> >> IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. >> >> >> Sure. >> Now, if an ICMPv6 error packet is returned whose partially returned >> payload is that of an ICMPv4 message, i.e. with an unknown protocol in >> IPv6, this packet can be indifferently discarded or forwarded after DPI >> without any negative effect. >> (If not discarded here, it will be discarded at 4rd tunnel exit.) >> >> >> no further concern. >> >> >> >> Cheers, >> RD >> >> >> >> >> >> - maoke >> >> >>> >>> >>> >>> - maoke >>> >>> >>> (**) >>> >>> It can be made more explicit in the specification. >>>> >>> >>> In R-16, after "If a CE or BR receives an ICMPv6 error message >>> [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we cou= ld >>> add "(unless the message concerns a ICMP message, as required by [RFC07= 92] >>> to avoid ICMP about ICMP)". >>> >>> Thanks, >>> RD >>> >>> >>> >>> >>> Thanks. >>>> >>> >>>> >>>> Cheers, >>>> RD >>>> >>>> >>>> >>>> >>>> >>>> cheers, >>>> maoke >>>> >>>> 2012/3/12 R=E9mi Despr=E9s >>>> >>>>> Hello, all, >>>>> >>>>> An updated version of draft-despres-softwire-4rd-u is now available a= t >>>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>>> >>>>> Differences with -04 include: >>>>> - DHCPv6 options are now specified >>>>> - various errors and typos are corrected >>>>> - some clarifications are added, following received questions and >>>>> comments >>>>> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs >>>>> and within CPEs) >>>>> - An editor's note has been added, following a WG-ML discussion, abou= t >>>>> an additional Mapping-rule parameter that might be needed to assign >>>>> privileged ports to to some shared-address CEs. >>>>> - Document layout has been adjusted as a result of other modification= s. >>>>> - the authors list has been completed. >>>>> >>>>> Questions and comments are most welcome. >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>>> >>>> >>> >>> >> >> > > --20cf3074b7943752b804bb99fde5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 15:30, = Maoke a =E9crit :


=
2012/3/19 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-19 =E0 11:38, = Maoke a =E9crit :
...


let me draw an ex= ample for that:

A --- CE ----(IPv6 domain; router = R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
=
...

<= blockquote type=3D"cite">
4rd-u isn't concerne= d with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for 4rd-= u, but RFC6145/6146 work also in the case the translator is not located nex= t to the end hosts. then i understand 4rd-u is less flexible.=A0

I don't see the configuration yo= u have in mind.
=A0
=A0
<= div>people often insert a router between the home CE and their computers ;-= ) sometimes, e.g., because the CE has limited number of ports for connectio= n or less funtioning.


I still don't se= e the problem with a NAT44 in the CE.
=A0
=A0
the topic is about 0.0.0.0 as the source address for th= e ICMPv6-translated ICMPv4 message's IP header. if there is a router be= tween the CE and the host, the packet with 0.0.0.0 will be discarded rather= than being forwarded, according to the common definition of the "unsp= ecified address".
=A0
=A0=
If the CE itself, is behind a transparent CPE, I don't see more wh= at the problem would be.


=A0
Anything missing?
<= /div>
...
Both of us know that double t= ranslation in general looses some information.

to me, behavior is more important than the acceptable= level of information loss.

Not understood.
=A0<= /div>
=A0
then let's keep our ow= n point for next face-to-face discussion.
=A0
=A0

on the other hand, we cannot= state 4rd-U doesn't lose any information.=A0

4rd options aren't supported (like in MAP-T)<= /div>
What else do you see as lost e2e?
=A0
=
=A0
not else end-to-end except the original TTL= across the IPv6 cloud. (therefore i said any information. :)
=A0
=A0

=A0
What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this work = on real and substantial problems.

real substantial problem includes the need of "tunnel as virt= ual link" building block in the Internet architecture.=A0

Keeping it simple, without dep= ending on complex and fussy concepts, remains IMHO preferable.
=A0=A0

2. consider ICMPv4 = error happens at R2:=A0

R2 sees original IPv4= packet at A, sent to B:
+---------+-----------------------------= -----------------+
| IPv4 =A0 =A0| payload =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| hdr, H1 | P1 =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+---------+---------------------= -------------------------+

R2 has found some error= with that packet, issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| IPv= 4 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0|
| hdr, H6 | h= dr, C3| hdr, H1| payload, P3=A0 |
+---------+--------+--------+--= ------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8= octet=A0 ->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \__________ __________/
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 V
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as pay= load of IPv6):
+------------+--------+--------+-------------= -+
| IPv6 =A0=A0 =A0=A0 | ICMPv4 | IPv4=A0 =A0| truncated =A0 =A0= |
| header, H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+-= -------+--------+--------------+

woops, unfortunat= ely, R1 also found something wrong. R1 generates an ICMPv6 report, respondi= ng back to B:=A0
+------------+--------+------------+--------+--------+-----------= ---+
| IPv6=A0 =A0 =A0 =A0| ICMPv6 | IPv6 =A0=A0 =A0=A0 | ICMPv4 = | IPv4=A0 =A0| truncated =A0 =A0|
| header, H8 | hdr, C4| header,= H7 | hdr, C3| hdr, H1| payload, P3=A0 |
+------------+--------+------------+--------+--------+--------------+<= /div>

BR sees this and mak= es translation to:=A0
+---------+--= ------+---------+--------+--------+------------+
| IPv4 =A0 =A0| ICMPv4 | IPv4=A0 =A0 | ICMPv4 | IPv4=A0 =A0| truncated= =A0|
| hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P= 4|
+---------+--------+---------+--------+--------+------------+<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0|<------- 8 octet=A0 ----------->|
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \___________________= __________________/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as the ICMPv4 error= message body

here an "ICMP of ICMP", wh= ich is not allowed in ICMPv4, is generated. here 4rd-U can have two options= :
1) let it be but depends on the IPv4 Internet routers, or host = B itself to drop the ICMP of ICMP;=A0
2) actively check the header in the ICMPv4 message body (H9 above) and= identify if the protocol of the discard-packet is ICMPv4 too; if so, BR dr= ops the packet.=A0

i doubt either is good. anyway,= no matter which is used, 4rd-U must deal with this issue. (sorry if i miss= ed some text where it has been done.)
<= /div>

(**)

The right choice is= clearly 2 (RFC792 rightly says: "To avoid the infinite regress of mes= sages about messages etc., no ICMP messages are sent about ICMP messages.&q= uot;)


sure 2) is better than 1). h= owever, the remained problem is IPv6 carrying ICMPv4. i just summarize my c= oncerns here in order the community can judge the impact:=A0
#1. such kind of packet loses the consistency between the destination = address in the IPv6 header and the source address of original IPv4 header c= ontained in the ICMP error message.

That's getting tricky.

yes. but i don't think people keeping part of original packets in ICM= P message body is trivial.

If not "trivial" at least quite simple:

=
+------------+--------+------------+--------------+
| = IPv6 =A0 =A0 =A0 | ICMPv6 | IPv6 =A0 =A0 =A0 | truncated =A0 =A0|
| header, H2 | hdr, C1| header, H1 | payload, P1 =A0|
+------------+--------+------------+--------------+
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ||
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \/
+---------+--------+--------+--------------+<= /div>
| IPv4 =A0 =A0| ICMPv4 | IPv4 =A0 | truncated =A0 =A0|
| hdr, H2 | hdr, C1| hdr, H3| payload, P2 =A0|
+-= --------+--------+--------+--------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<- 8 o= ctet =A0->|
SRC of H2 is a constant
DST of H2 and H3, and SRC of H2, are copied from fields in H1
The ICMPv4 checksum is computed from scratch.
=A0
=A0
well, not this case. but the IPv6Header= -ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original packet).

OK.
In a 4rd-u= domain, middle boxes shouldn't discard packets having ICMPv4 payloads.=
There is no doubt AFAIK that they can be configured to let go on= e more protocol (ICMPv4 in this instance).



Will you be in Paris so that we ca= n discuss with a piece of paper details of what you have in mind?=A0(In the= following 3 days, I will be busy otherwise, and will have little or no acc= ess to email.)


sorry but = i couldn't go to Paris due to the company's arrangement.=A0


Your presence will be = missed. Sorry to learn that.
=A0
=A0
thanks! it is pity that= i cannot discuss with you face-to-face this time.
=A0
=A0


#2. such kind of packet loses IP header integr= ity mechanism as neither IPv4's header checksum nor the ICMPv6's ch= ecksum containing pseudo-header is included.=A0

Packets discussed here will ne= ver be delivered anyway (ICMP about ICMP).
I don't see how an= y practical concern would appear here.=A0

#2 is not about ICMP about ICMP but about no checksum for IP= addresses in IP neither in ICMP. i don't think people keeping checksum= here or there is trivial.=A0

Not sure to see the issue.
When an ICMPv4 error message is s= ynthesized, its ICMP checksum can easily be computed, as explained above.
(Always keeping only 8 octets of the original payload, as specifie= d,=A0strictly limits the computation.)
=A0
=A0
not the ICMP data= checksum, but about the integrity of IP header. in IPv4, IP header has che= cksum; in IPv6, ICMPv6 checksum includes the pseudo-header.

Since the ICMPv4 that is synthesized when an ICMP= v6 error message is received is built from scratch (with 8 octets of IPv4 p= ayload copied, but with newly computed checksums), I can't see where=A0= there could be a problem.
(If you still see one, more details would be needed.)

Regards,
RD
=


=A0
regards,
maoke
=A0
=A0


because it is stated that 4rd-U is "ensuring compatibility with I= Pv6-only middle boxes that perform deep-packet-inspection", i here poi= nt out at least #1 checking on ICMP error message being sent to the exact s= ource of original packet, and #2 checking on IP header integrity by calcula= ting the checksum in header or pseudo-header cannot rely on the functionali= ty of the middle boxes in the IPv6-only domain that perform deep-packet-ins= pection. then 4rd-U CE/BR MUST consider these issues as well.=A0

(neither MAP-T nor MAP-E has the similar concern).

For MAP-E, of course (compati= bility with IPv6-only middle boxes is off scope).
For MAP-T, see = above.

IPv6 carrying ICMPv6 is able t= o be deeply inspected by any IPv6 nodes.

=
Sure.
Now, if an ICMPv6 error packet is ret= urned whose partially returned payload is that of an ICMPv4 message, i.e. w= ith an unknown protocol in IPv6, this packet can be indifferently discarded= or forwarded after DPI without any negative effect.=A0
(If not discarded here, it will be discarded at 4rd tunnel exit.)


no further concern.


Cheers,
RD



=A0

- maoke
=A0

=A0

- maoke=A0

(**)

It can be made more= explicit in the specification.
=

In=A0R-16, after =A0"If a= CE or BR receives an ICMPv6 error message [RFC4443], it=A0 MUST synthesize= an ICMPv4 error packet [RFC0792]" we could add "(unless the mess= age concerns a ICMP message, as required by [RFC0792] to avoid ICMP about I= CMP)".

Thanks,
RD


=


Thanks.
=


Cheers,
RD




cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05<= br>
Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and comments<= br> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and w= ithin CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign privile= ged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires









--20cf3074b7943752b804bb99fde5-- From despres.remi@laposte.net Mon Mar 19 08:46:05 2012 Return-Path: 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 E2E9421F8770 for ; Mon, 19 Mar 2012 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 Zn9FRcS9XNpy for ; Mon, 19 Mar 2012 08:46:04 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1ED21F8731 for ; Mon, 19 Mar 2012 08:46:01 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8A563940167; Mon, 19 Mar 2012 16:45:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-152--470049711 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 16:45:52 +0100 Message-Id: <6B38A213-4325-40B0-836C-DC991788AC8A@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:46:06 -0000 --Apple-Mail-152--470049711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 16:08, Maoke a =E9crit : >=20 >=20 > 2012/3/20 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 15:30, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/19 R=E9mi Despr=E9s >>=20 >> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >> ... >>=20 >>>>>=20 >>>>> let me draw an example for that: >>>>>=20 >>>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 = Internet; router R2 here)--- B >> ... >>=20 >>> 4rd-u isn't concerned with what happens between A and CE. >>> There, internal hosts have RFC1918 addresses and external hosts = public IPv4 addresses. >>>=20 >>> no problem here for 4rd-u, but RFC6145/6146 work also in the case = the translator is not located next to the end hosts. then i understand = 4rd-u is less flexible.=20 >>=20 >> I don't see the configuration you have in mind. >> =20 >> =20 >> people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning. >=20 >=20 > I still don't see the problem with a NAT44 in the CE. > If the CE itself, is behind a transparent CPE, I don't see more what = the problem would be. >=20 >=20 >>> =20 >>> Anything missing? >> ... >>=20 >>> Both of us know that double translation in general looses some = information. >>>=20 >>> to me, behavior is more important than the acceptable level of = information loss. >>=20 >> Not understood. >> =20 >> =20 >> then let's keep our own point for next face-to-face discussion. >> =20 >> =20 >>=20 >>> on the other hand, we cannot state 4rd-U doesn't lose any = information.=20 >>=20 >> 4rd options aren't supported (like in MAP-T) >> What else do you see as lost e2e? >> =20 >> =20 >> not else end-to-end except the original TTL across the IPv6 cloud. = (therefore i said any information. :) >> =20 >> =20 >>=20 >>> =20 >>> What I wouldn't object to is to rename the Reversible-header-mapping = technique as Reversible-header-translation technique. >>> Hope you can accept this as sufficient, so that we can keep this = work on real and substantial problems. >>>=20 >>> real substantial problem includes the need of "tunnel as virtual = link" building block in the Internet architecture.=20 >>=20 >> Keeping it simple, without depending on complex and fussy concepts, = remains IMHO preferable. >> =20 >>=20 >>>>> 2. consider ICMPv4 error happens at R2:=20 >>>>>=20 >>>>> R2 sees original IPv4 packet at A, sent to B: >>>>> +---------+----------------------------------------------+ >>>>> | IPv4 | payload | >>>>> | hdr, H1 | P1 | >>>>> +---------+----------------------------------------------+ >>>>>=20 >>>>> R2 has found some error with that packet, issuing an ICMPv4 = message and sending to A: >>>>> +---------+--------+--------+--------------+ >>>>> | IPv4 | ICMPv4 | IPv4 | truncated | >>>>> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >>>>> +---------+--------+--------+--------------+ >>>>> |<- 8 octet ->| >>>>> \__________ __________/ >>>>> V >>>>> as the ICMPv4 error message body >>>>>=20 >>>>> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of = IPv6): >>>>> +------------+--------+--------+--------------+ >>>>> | IPv6 | ICMPv4 | IPv4 | truncated | >>>>> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >>>>> +------------+--------+--------+--------------+ >>>>>=20 >>>>> woops, unfortunately, R1 also found something wrong. R1 generates = an ICMPv6 report, responding back to B:=20 >>>>> = +------------+--------+------------+--------+--------+--------------+ >>>>> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated = | >>>>> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 = | >>>>> = +------------+--------+------------+--------+--------+--------------+ >>>>>=20 >>>>> BR sees this and makes translation to:=20 >>>>> +---------+--------+---------+--------+--------+------------+ >>>>> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >>>>> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >>>>> +---------+--------+---------+--------+--------+------------+ >>>>> |<------- 8 octet ----------->| >>>>> \___________________ __________________/ >>>>> V >>>>> as the ICMPv4 error message body >>>>>=20 >>>>> here an "ICMP of ICMP", which is not allowed in ICMPv4, is = generated. here 4rd-U can have two options: >>>>> 1) let it be but depends on the IPv4 Internet routers, or host B = itself to drop the ICMP of ICMP;=20 >>>>> 2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet.=20 >>>>>=20 >>>>> i doubt either is good. anyway, no matter which is used, 4rd-U = must deal with this issue. (sorry if i missed some text where it has = been done.) >>>=20 >>> (**) >>>=20 >>>> The right choice is clearly 2 (RFC792 rightly says: "To avoid the = infinite regress of messages about messages etc., no ICMP messages are = sent about ICMP messages.") >>>=20 >>>=20 >>>> sure 2) is better than 1). however, the remained problem is IPv6 = carrying ICMPv4. i just summarize my concerns here in order the = community can judge the impact:=20 >>>> #1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error message. >>>=20 >>> That's getting tricky. >>>=20 >>> yes. but i don't think people keeping part of original packets in = ICMP message body is trivial. >>=20 >> If not "trivial" at least quite simple: >>=20 >> +------------+--------+------------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | truncated | >> | header, H2 | hdr, C1| header, H1 | payload, P1 | >> +------------+--------+------------+--------------+ >> || >> \/ >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | >> +---------+--------+--------+--------------+ =20 >> |<- 8 octet ->| >> SRC of H2 is a constant >> DST of H2 and H3, and SRC of H2, are copied from fields in H1 >> The ICMPv4 checksum is computed from scratch. >> =20 >> =20 >> well, not this case. but the = IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original = packet). >=20 > OK. > In a 4rd-u domain, middle boxes shouldn't discard packets having = ICMPv4 payloads. > There is no doubt AFAIK that they can be configured to let go one more = protocol (ICMPv4 in this instance). >=20 >=20 >=20 >>> Will you be in Paris so that we can discuss with a piece of paper = details of what you have in mind? (In the following 3 days, I will be = busy otherwise, and will have little or no access to email.) >>>=20 >>>=20 >>> sorry but i couldn't go to Paris due to the company's arrangement.=20= >>=20 >>=20 >> Your presence will be missed. Sorry to learn that. >> =20 >> =20 >> thanks! it is pity that i cannot discuss with you face-to-face this = time. >> =20 >> =20 >>=20 >>=20 >>>> #2. such kind of packet loses IP header integrity mechanism as = neither IPv4's header checksum nor the ICMPv6's checksum containing = pseudo-header is included.=20 >>>=20 >>> Packets discussed here will never be delivered anyway (ICMP about = ICMP). >>> I don't see how any practical concern would appear here.=20 >>>=20 >>> #2 is not about ICMP about ICMP but about no checksum for IP = addresses in IP neither in ICMP. i don't think people keeping checksum = here or there is trivial.=20 >>=20 >> Not sure to see the issue. >> When an ICMPv4 error message is synthesized, its ICMP checksum can = easily be computed, as explained above. >> (Always keeping only 8 octets of the original payload, as specified, = strictly limits the computation.) >> =20 >> =20 >> not the ICMP data checksum, but about the integrity of IP header. in = IPv4, IP header has checksum; in IPv6, ICMPv6 checksum includes the = pseudo-header. >=20 > Since the ICMPv4 that is synthesized when an ICMPv6 error message is = received is built from scratch (with 8 octets of IPv4 payload copied, = but with newly computed checksums), I can't see where there could be a = problem. > (If you still see one, more details would be needed.) > =20 > =20 > well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, integrity of = IP addresses has no checksum to protect. because IPv6 header has no = checksum and ICMPv4 checksum doesn't cover pseudo-header at all. - maoke well, I think the risk of corrupted IPv6 header H1 within the domain can = be ignored because L2 checks should be sufficient in this case. Note that, in case of RFC6145 translation, checking validity of IPv6 = addresses implies checksum computation of the complete ICMPv6 message, = which can be long. Do you know BTW if this is actually done in existing implementations? Since the source of the original IPv4 packet is present in both DST(H2) = and SRC(H1), a consistency check can easily be performed for this = address. A note about this could be added to the draft. Thanks, RD=20 =20 > =20 > =20 >=20 > Regards, > RD >=20 >=20 >=20 >> =20 >> regards, >> maoke >> =20 >> =20 >>=20 >>=20 >>>> because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well.=20 >>>>=20 >>>> (neither MAP-T nor MAP-E has the similar concern). >>>=20 >>> For MAP-E, of course (compatibility with IPv6-only middle boxes is = off scope). >>> For MAP-T, see above. >>>=20 >>> IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 = nodes. >>=20 >> Sure. >> Now, if an ICMPv6 error packet is returned whose partially returned = payload is that of an ICMPv4 message, i.e. with an unknown protocol in = IPv6, this packet can be indifferently discarded or forwarded after DPI = without any negative effect.=20 >> (If not discarded here, it will be discarded at 4rd tunnel exit.) >>=20 >>=20 >>> no further concern. >>=20 >>=20 >> Cheers, >> RD >>=20 >>=20 >>=20 >>> =20 >>>=20 >>> - maoke >>> =20 >>>=20 >>>> =20 >>>>=20 >>>> - maoke=20 >>>=20 >>> (**) >>>=20 >>>> It can be made more explicit in the specification. >>>=20 >>> In R-16, after "If a CE or BR receives an ICMPv6 error message = [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we = could add "(unless the message concerns a ICMP message, as required by = [RFC0792] to avoid ICMP about ICMP)". >>>=20 >>> Thanks, >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>> Thanks. >>>>=20 >>>>=20 >>>> Cheers, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> cheers, >>>>> maoke >>>>>=20 >>>>> 2012/3/12 R=E9mi Despr=E9s >>>>> Hello, all, >>>>>=20 >>>>> An updated version of draft-despres-softwire-4rd-u is now = available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >>>>>=20 >>>>> Differences with -04 include: >>>>> - DHCPv6 options are now specified >>>>> - various errors and typos are corrected >>>>> - some clarifications are added, following received questions and = comments >>>>> - the CE-behind-CPE use case has been revised (mix of CEs behind = CPEs and within CPEs) >>>>> - An editor's note has been added, following a WG-ML discussion, = about an additional Mapping-rule parameter that might be needed to = assign privileged ports to to some shared-address CEs. >>>>> - Document layout has been adjusted as a result of other = modifications. >>>>> - the authors list has been completed. >>>>>=20 >>>>> Questions and comments are most welcome. >>>>>=20 >>>>> Regards, >>>>> RD >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-152--470049711 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 15:30, Maoke a =E9crit :



2012/3/19 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-19 =E0 = 11:38, Maoke a =E9crit :
...


let me = draw an example for that:

A --- CE ----(IPv6 = domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- = B
=
...
4rd-u isn't concerned = with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for = 4rd-u, but RFC6145/6146 work also in the case the translator is not = located next to the end hosts. then i understand 4rd-u is less = flexible. 

I don't see the configuration you = have in = mind.
 
 
people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning.


I still don't see = the problem with a NAT44 in the CE.
If the CE itself, is = behind a transparent CPE, I don't see more what the problem would = be.


 
Anything = missing?
...

Both of us know that = double translation in general looses some = information.

to me, = behavior is more important than the acceptable level of information = loss.

Not = understood.
 
 
then let's keep our own point for next face-to-face discussion. =
 
 

on the other hand, we = cannot state 4rd-U doesn't lose any = information. 

4rd options aren't supported (like in = MAP-T)
What else do you see as lost = e2e?
 
 
= not else end-to-end except the original TTL across the IPv6 cloud. = (therefore i said any information. :)
 
 

 
What I wouldn't object to is to = rename the Reversible-header-mapping technique as = Reversible-header-translation technique.
Hope you can accept this as sufficient, so that we can keep this = work on real and substantial = problems.

real = substantial problem includes the need of "tunnel as virtual link" = building block in the Internet architecture. 

Keeping it simple, without = depending on complex and fussy concepts, remains IMHO = preferable.
  

2. consider = ICMPv4 error happens at R2: 

R2 sees = original IPv4 packet at A, sent to = B:
+---------+----------------------------------------------+
| IPv4    | payload           =                     =        |
| hdr, H1 | P1              =                     =         =  |
+---------+---------------------------------------------= -+

R2 has found some error with that packet, = issuing an ICMPv4 message and sending to A:
+---------+--------+--------+--------------+
| = IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H6 | hdr, C3| hdr, H1| payload, P3  = |
+---------+--------+--------+--------------+
                =             |<- 8 octet  = ->|
          =           \__________ = __________/
          =                   =    V
            =      as the ICMPv4 error message body

4rd-U BR translates that to IPv6 version (ICMPv4 as = payload of = IPv6):
+------------+--------+--------+--------------+
| IPv6       | ICMPv4 | IPv4   | = truncated    |
| header, H7 | hdr, C3| hdr, H1| payload, P3  = |
+------------+--------+--------+--------------+

=
woops, unfortunately, R1 also found something wrong. R1 = generates an ICMPv6 report, responding back to B: 
=
+------------+--------+------------+--------+--------+----------= ----+
| IPv6       | ICMPv6 | IPv6 =       | ICMPv4 | IPv4   | truncated   =  |
| header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| = payload, P3  |
=
+------------+--------+------------+--------+--------+--------------+=

BR sees this and = makes translation = to: 
+---------+--------+----= -----+--------+--------+------------+
| IPv4    | ICMPv4 | IPv4    | ICMPv4 | = IPv4   | truncated  |
| hdr, H10| hdr, C5| hdr, = H9 | hdr, C3| hdr, H1| payload, = P4|
+---------+--------+---------+--------+--------+------------= +
        =                     =  |<------- 8 octet  = ----------->|
        =             \___________________ = __________________/
        =                     =             V
                  =        as the ICMPv4 error message = body

here an "ICMP of ICMP", which is not = allowed in ICMPv4, is generated. here 4rd-U can have two = options:
1) let it be but depends on the IPv4 Internet = routers, or host B itself to drop the ICMP of ICMP; 
2) actively check the header in the ICMPv4 message body (H9 above) = and identify if the protocol of the discard-packet is ICMPv4 too; if so, = BR drops the packet. 

i doubt either is = good. anyway, no matter which is used, 4rd-U must deal with this issue. = (sorry if i missed some text where it has been done.)
=
=

(**)

The right choice = is clearly 2 (RFC792 rightly says: "To avoid the infinite regress of = messages about messages etc., no ICMP messages are sent about ICMP = messages.")
=


sure 2) is better than = 1). however, the remained problem is IPv6 carrying ICMPv4. i just = summarize my concerns here in order the community can judge the = impact: 
#1. such kind of packet loses the consistency between the = destination address in the IPv6 header and the source address of = original IPv4 header contained in the ICMP error = message.

That's getting = tricky.

yes. but i don't = think people keeping part of original packets in ICMP message body is = trivial.

If not "trivial" at least quite = simple:

+------------+--------+------------+-----= ---------+
| IPv6       | ICMPv6 | IPv6   =     | truncated    |
| header, H2 | hdr, = C1| header, H1 | payload, P1  |
=
+------------+--------+------------+--------------+
  =                   = ||
                =     = \/
+---------+--------+--------+--------------+
|= IPv4    | ICMPv4 | IPv4   | truncated   =  |
| hdr, H2 | hdr, C1| hdr, H3| payload, P2 =  |
+---------+--------+--------+--------------+ =               
  =                     =       |<- 8 octet  ->|
SRC of = H2 is a constant
DST of H2 and H3, and SRC of H2, are copied from fields in = H1
The ICMPv4 checksum is computed from = scratch.
 
 
<= div>well, not this case. but the = IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original = packet).

OK.
In a = 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 = payloads.
There is no doubt AFAIK that they can be configured = to let go one more protocol (ICMPv4 in this instance).



Will you be in Paris so that we = can discuss with a piece of paper details of what you have in = mind? (In the following 3 days, I will be busy otherwise, and will = have little or no access to email.)


sorry = but i couldn't go to Paris due to the company's = arrangement. 


=
Your presence will be missed. Sorry to learn that.
 
 
thanks! it is = pity that i cannot discuss with you face-to-face this time. =
 
 


#2. such kind of packet = loses IP header integrity mechanism as neither IPv4's header checksum = nor the ICMPv6's checksum containing pseudo-header is = included. 

Packets discussed here will = never be delivered anyway (ICMP about ICMP).
I don't see how = any practical concern would appear = here. 

#2 is not about ICMP about ICMP but about no checksum for = IP addresses in IP neither in ICMP. i don't think people keeping = checksum here or there is = trivial. 

Not sure to see the issue.
When an ICMPv4 error message = is synthesized, its ICMP checksum can easily be computed, as explained = above.
(Always keeping only 8 octets of the original payload, = as specified, strictly limits the computation.)
 
 
not the = ICMP data checksum, but about the integrity of IP header. in IPv4, IP = header has checksum; in IPv6, ICMPv6 checksum includes the = pseudo-header.

Since the ICMPv4 that is synthesized when an = ICMPv6 error message is received is built from scratch (with 8 octets of = IPv4 payload copied, but with newly computed checksums), I can't see = where there could be a problem.
(If you still see one, more details would be = needed.)
 
 
<= div>well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, = integrity of IP addresses has no checksum to protect. because IPv6 = header has no checksum and ICMPv4 checksum doesn't cover pseudo-header = at all. - maoke

well, I = think the risk of corrupted IPv6 header H1 within the domain can be = ignored because L2 checks should be sufficient in this = case.

Note that, in case of RFC6145 = translation, checking validity of IPv6 addresses implies checksum = computation of the complete ICMPv6 message, which can be = long.
Do you know BTW if this is actually done in existing = implementations?

Since the source of the = original IPv4 packet is present in both DST(H2) and SRC(H1), a = consistency check can easily be performed for this address. A note = about this could be added to the = draft.

Thanks,
RD 
 = ;



 
 

Regards,
RD



 
regards,
maoke
 
 


because it is stated that 4rd-U is "ensuring compatibility with = IPv6-only middle boxes that perform deep-packet-inspection", i here = point out at least #1 checking on ICMP error message being sent to the = exact source of original packet, and #2 checking on IP header integrity = by calculating the checksum in header or pseudo-header cannot rely on = the functionality of the middle boxes in the IPv6-only domain that = perform deep-packet-inspection. then 4rd-U CE/BR MUST consider these = issues as well. 

(neither MAP-T nor MAP-E has the similar = concern).

For MAP-E, = of course (compatibility with IPv6-only middle boxes is off = scope).
For MAP-T, see above.

IPv6 carrying ICMPv6 is = able to be deeply inspected by any IPv6 nodes. =

Sure.
No= w, if an ICMPv6 error packet is returned whose partially returned = payload is that of an ICMPv4 message, i.e. with an unknown protocol in = IPv6, this packet can be indifferently discarded or forwarded after DPI = without any negative effect. 
(If not discarded here, it will be discarded at 4rd tunnel = exit.)


no further = concern.

=
Cheers,
RD



 

- = maoke
 

 

- = maoke 

(**)

It can be made = more explicit in the specification. =

In R-16, after  "If a CE or BR receives an = ICMPv6 error message [RFC4443], it  MUST synthesize an ICMPv4 error = packet [RFC0792]" we could add "(unless the message concerns a ICMP = message, as required by [RFC0792] to avoid ICMP about ICMP)".
=

Thanks,
RD



Thanks.


Cheers,
RD



=

cheers,
maoke

2012/3/12 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello, all,

An updated version of draft-despres-softwire-4rd-u is now available at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 05

Differences with -04 include:
- DHCPv6 options are now specified
- various errors and typos are corrected
- some clarifications are added, following received questions and = comments
- the CE-behind-CPE use case has been revised (mix of CEs behind CPEs = and within CPEs)
- An editor's note has been added, following a WG-ML discussion, about = an additional Mapping-rule parameter that might be needed to assign = privileged ports to to some shared-address CEs.
- Document layout has been adjusted as a result of other = modifications.
- the authors list has been completed.

Questions and comments are most welcome.

Regards,
RD



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires










= --Apple-Mail-152--470049711-- From despres.remi@laposte.net Mon Mar 19 08:49:47 2012 Return-Path: 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 7960321F87E1 for ; Mon, 19 Mar 2012 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.075, 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 J6+KylVlo9Yx for ; Mon, 19 Mar 2012 08:49:46 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD2E21F87D1 for ; Mon, 19 Mar 2012 08:49:45 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id nTpj1i00Q37Y3f403TpjTK; Mon, 19 Mar 2012 16:49:44 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-153--469818769 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 19 Mar 2012 16:49:42 +0100 Message-Id: <16124E27-9D5C-45DE-9EC1-6BC5CC41E909@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:49:47 -0000 --Apple-Mail-153--469818769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 16:12, Maoke a =E9crit : >=20 >=20 > 2012/3/20 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 15:30, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/19 R=E9mi Despr=E9s >>=20 >> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >> ... >>=20 >>>>>=20 >>>>> let me draw an example for that: >>>>>=20 >>>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 = Internet; router R2 here)--- B >> ... >>=20 >>> 4rd-u isn't concerned with what happens between A and CE. >>> There, internal hosts have RFC1918 addresses and external hosts = public IPv4 addresses. >>>=20 >>> no problem here for 4rd-u, but RFC6145/6146 work also in the case = the translator is not located next to the end hosts. then i understand = 4rd-u is less flexible.=20 >>=20 >> I don't see the configuration you have in mind. >> =20 >> =20 >> people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning. >=20 >=20 > I still don't see the problem with a NAT44 in the CE. > =20 > =20 > the topic is about 0.0.0.0 as the source address for the = ICMPv6-translated ICMPv4 message's IP header. if there is a router = between the CE and the host, the packet with 0.0.0.0 will be discarded = rather than being forwarded, according to the common definition of the = "unspecified address". As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, = of course, nor in IPv4 where the only in-site IPv4 addresses are = RFC1918. Anything missed? RD --Apple-Mail-153--469818769 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 15:30, Maoke a =E9crit :



2012/3/19 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-19 =E0 = 11:38, Maoke a =E9crit :
...


let me = draw an example for that:

A --- CE ----(IPv6 = domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- = B
=
...
4rd-u isn't concerned = with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for = 4rd-u, but RFC6145/6146 work also in the case the translator is not = located next to the end hosts. then i understand 4rd-u is less = flexible. 

I don't see the configuration you = have in = mind.
 
 
people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning.


I still don't see = the problem with a NAT44 in the = CE.
 
 
the = topic is about 0.0.0.0 as the source address for the ICMPv6-translated = ICMPv4 message's IP header. if there is a router between the CE and the = host, the packet with 0.0.0.0 will be discarded rather than being = forwarded, according to the common definition of the "unspecified = address".

As I already = said, 0.0.0.0 never appears on any wire: neither in IPv6, of course, nor = in IPv4 where the only in-site IPv4 addresses are = RFC1918.
Anything = missed?

RD


= --Apple-Mail-153--469818769-- From adurand@juniper.net Mon Mar 19 16:38:54 2012 Return-Path: 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 BBB4621F8758 for ; Mon, 19 Mar 2012 16:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 iO+9-y+U8HeC for ; Mon, 19 Mar 2012 16:38:54 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 993E121F8755 for ; Mon, 19 Mar 2012 16:38:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT2fDhhYj5Q2tFi1a6uCmX7gVfBIyFi4v@postini.com; Mon, 19 Mar 2012 16:38:50 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 19 Mar 2012 16:38:43 -0700 From: Alain Durand To: Softwires WG Date: Mon, 19 Mar 2012 16:38:42 -0700 Thread-Topic: =?Windows-1252?Q?Path_to_move_forward_with_4rd=85?= Thread-Index: Ac0GKWtjiwfJTLnPSeG4n7AZAdsQIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yong Cui , Ralph Droms Subject: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 23:38:54 -0000 Dear wg, After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T & U ac= tually solve the stateless problem we started with. There are differences, but it is unclear if those differences are reall= y significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Ex= perimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U). Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to? If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track = document? If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational. If the answer is NO, we are left with E & T (U then might be abandoned or p= ublished as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)? If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E & T= as Experimental. In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other. Alain & Yong, wg co-chairs.= From washam.fan@gmail.com Mon Mar 19 23:06:05 2012 Return-Path: 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 0D58121F850B for ; Mon, 19 Mar 2012 23:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 IcO+UYrb82Pq for ; Mon, 19 Mar 2012 23:06:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4521F84FF for ; Mon, 19 Mar 2012 23:06:03 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so3725645wib.13 for ; Mon, 19 Mar 2012 23:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KQ0ZKIDBk7+8vUcaVQACCNl/tznc6LNeO1ik0zlOGOc=; b=CUtZ962w9Kh08ZmHGkPtaqxzgNX4pEnGSKPNQUQkRV7mm0gSm4789XwiVtSKSQ8CLr iUrAGb1e4G8M6Pn5+cPsqC+EfJHJAK66/oieCfam7Fq0GEX3imSTXZfcVc+heXUtvDKQ cBujtd+/ORLtLIPgOv6kU3HB8Ksessa5sLcANnttEyDzroauufX+mXuIrgsSX0j3k8Ww DSUHgt1Va6I1wLc2hfZY65tpCkC3Q41GgsldLCXhOKDXPRIPRQT1z0YJHx4Xu+Q1XzeX /dk7IzaC0TbscuyJtWkiQHcquhbAnArV2o2zmm42UWqEWfGoX91mPgEpVTIPgrGmf9Cq XZ6A== MIME-Version: 1.0 Received: by 10.180.81.37 with SMTP id w5mr25748705wix.16.1332223563039; Mon, 19 Mar 2012 23:06:03 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Mon, 19 Mar 2012 23:06:03 -0700 (PDT) In-Reply-To: References: <20120309160005.22225.51929.idtracker@ietfa.amsl.com> Date: Tue, 20 Mar 2012 14:06:03 +0800 Message-ID: From: Washam Fan To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] New Version Notification for draft-mdt-softwire-map-translation-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 06:06:05 -0000 Hi Authors, In section 7.6, it states how to do ICMP/ICMPv6 query messages translation. But it omits how to do ICMP/ICMPv6 error messages translation. I think it should be expounded in this section. Thanks, washam 2012/3/10 Wojciech Dec : > Hi All > > A new version of I-D, draft-mdt-softwire-map-translation-01.txt has been > posted under: > > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 > > Filename: =A0draft-mdt-softwire-map-translation > Revision: =A001 > Title: =A0 MAP Translation (MAP-T) - specification > Creation date: =A02012-03-09 > WG ID: =A0 Individual Submission > Number of pages: 22 > > Abstract: > =A0 This document specifies the "Mapping of Address and Port" (= MAP) > =A0 double stateless translation based solution (MAP-T) for providing > =A0 IPv4 hosts connectivity to and across an IPv6 domain. > > We welcome further WG feedback. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From adurand@juniper.net Tue Mar 20 06:06:52 2012 Return-Path: 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 C544A21F8675 for ; Tue, 20 Mar 2012 06:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ErahszVLBxME for ; Tue, 20 Mar 2012 06:06:52 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6221F866C for ; Tue, 20 Mar 2012 06:06:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT2iA4WfAco3rbY4aEQ3fjHMMHy/XiR2L@postini.com; Tue, 20 Mar 2012 06:06:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 20 Mar 2012 06:06:27 -0700 From: Alain Durand To: Qi Sun Date: Tue, 20 Mar 2012 06:06:26 -0700 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: Ac0GmkJsQVZOhcRaQ16Ghc3qdUDnjQ== Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:06:52 -0000 On Mar 17, 2012, at 12:44 PM, Qi Sun wrote: > Hi Med, >=20 > I've read through the draft-penno-* and IMHO it is reasonable in th= e view of deployment. By configuring the profile (i.e. the per-subscriber = mapping table) in the AFTRs, the SPs can achieve an explicit binding betwee= n the IPv4 address + port-set and the customer. This can mean the customer = pay for the ownership of the IPv4 address + port-set. It is easy to associa= te address(port-set) assignment with authentication. >=20 > Best Regards! >=20 > Qi Sun Thank you for your comment. Indeed, it is both simple and necessary to know= on the AFTR which ports belong to which subscriber. It is simple because this can be configured out-of-band (think netconf) fro= m a centralized repository. Note, that, using a centralized repository for subscriber <--> IPv4 address & port mapping, = the service provider has the flexibility to allocate different numbers of ports according to the subscriber profile. Mo= re, because the association subscriber <--> IPv4 address and port is known, there is no need for logging of any so= rt on the AFTR. It is necessary because the AFTR is the only place where we can enforce IPv= 4 ingress filtering, ie put ACLs to check that the incoming tunneled traffic from any given customer is using a legit= imate IPv4 address and source port. When the incoming traffic does not match those ingress filtering rules, an = ICMP error message must be returned. The idea in SD-NAT is to use this ICMP message to carry the information abo= ut the correct port range to use. Alain. From cuiyong@tsinghua.edu.cn Tue Mar 20 06:49:57 2012 Return-Path: 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 91E1321F870F for ; Tue, 20 Mar 2012 06:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495] 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 7TgstcM+PS-n for ; Tue, 20 Mar 2012 06:49:57 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id D313C21F8700 for ; Tue, 20 Mar 2012 06:49:56 -0700 (PDT) Received: from [219.143.128.111] (helo=[192.168.0.155]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1S9zRf-0003tj-IV; Tue, 20 Mar 2012 21:49:51 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Tue, 20 Mar 2012 21:49:33 +0800 From: Yong Cui To: Softwires WG Message-ID: Thread-Topic: IETF 83 Sotfwire Agenda Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ralph Droms Subject: [Softwires] IETF 83 Sotfwire Agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:49:57 -0000 Hi folks, The WG chairs have discussed the agenda based on the presentation requests and main tasks in our wg. Because we received a lot of requests and only have limited time for presentation, some of the requests cannot be scheduled this time. The agenda has been published at ietf 83 site: http://www.ietf.org/proceedings/83/agenda/agenda-83-softwire.htm Please send your slides to Alain and me by this Saturday. Yong & Alain From yiu_lee@cable.comcast.com Tue Mar 20 08:39:48 2012 Return-Path: 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 3ACAB21F85A3 for ; Tue, 20 Mar 2012 08:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.296 X-Spam-Level: X-Spam-Status: No, score=-101.296 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] 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 DWP2lqKfQFth for ; Tue, 20 Mar 2012 08:39:47 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2FA21F85A0 for ; Tue, 20 Mar 2012 08:39:47 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.10108678; Tue, 20 Mar 2012 09:27:43 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 11:39:29 -0400 From: "Lee, Yiu" To: Alain Durand , Qi Sun Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: AQHNBq+jQqwVXTk0mkaJj1rTkfr4yw== Date: Tue, 20 Mar 2012 15:39:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415088367_353913" MIME-Version: 1.0 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:39:48 -0000 --B_3415088367_353913 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. On 3/20/12 9:06 AM, "Alain Durand" wrote: >It is necessary because the AFTR is the only place where we can enforce >IPv4 ingress filtering, ie put ACLs to check >that the incoming tunneled traffic from any given customer is using a >legitimate IPv4 address and source port. >When the incoming traffic does not match those ingress filtering rules, >an ICMP error message must be returned. >The idea in SD-NAT is to use this ICMP message to carry the information >about the correct port range to use. --B_3415088367_353913 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRdJVmO BI9aBVYyWqRqa4k4ipHT2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjAxNTM5MjZaMA0GCSqGSIb3DQEBAQUABIIBABqzy/1wOlHhsEF8IQgxgMra SrcOr0dq/davW1lv/eD+H5xCUkrA4WAN3/b2v56kFVyjv4c0EHOMZH7v7pQkM7OTvRC61lBQ HXZdbMS7nxB5zDIB7rfsly+iMSwq9ked62y5mBE3NcnBeVHneBOwUJxJx6pBdIi+eOHY3xTw Z+fz9rsMCHWRk6H/E9MQkNbmUz6Autag7NhM10SkVCR3iydXeSgI7xldddk4dxFbQe3C4JQJ 3pfHGBrEfJA2QH4xIUXGl5JB5hbmB6MUF2/4KIPl4ppyZDOAIjILd7KlWy8GvVxvBohofGA3 MIjX/SE8NI9sQRBMWsVuaLYYBz9LVEY= --B_3415088367_353913-- From mohamed.boucadair@orange.com Tue Mar 20 09:05:44 2012 Return-Path: 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 07A0921F85E6 for ; Tue, 20 Mar 2012 09:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 ONmK+DTzpxsA for ; Tue, 20 Mar 2012 09:05:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB721F85E0 for ; Tue, 20 Mar 2012 09:05:43 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 607362DC21D; Tue, 20 Mar 2012 17:05:42 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 41DEB4C066; Tue, 20 Mar 2012 17:05:42 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 20 Mar 2012 17:05:42 +0100 From: To: "Lee, Yiu" , Alain Durand , Qi Sun Date: Tue, 20 Mar 2012 17:05:41 +0100 Thread-Topic: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Thread-Index: AQHNBq+jQqwVXTk0mkaJj1rTkfr4y5ZzU2mA Message-ID: <94C682931C08B048B7A8645303FDC9F36E285583EB@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.20.152415 Cc: Softwires WG , draft-cui-softwire-b4-translated-ds-lite , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:05:44 -0000 Hi Yiu, Sending back an ICMP message when receiving a port out of range should be c= onfigurable IMHO.=20 When receiving a port out of range, the behaviour of REQ#12 (A, B and C) of= http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3= can be followed by the AFTR. No need to define a new ICMP message for this; ICMP message Type 3 Code 13 = is fine for this. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Lee, Yiu >Envoy=E9 : mardi 20 mars 2012 16:39 >=C0 : Alain Durand; Qi Sun >Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite;=20 >draft-penno-softwire-sdnat@tools.ietf.org >Objet : Re: [Softwires] draft-penno-softwire-sdnat vs.=20 >draft-cui-softwire-b4-translated-ds-lite > >Today, if a user generates a packet using an illegal IPv4=20 >source address, >what would we do? We could drop the packet silently by doing >source-verify. So, tomorrow if a user use illegal port, IMHO=20 >AFTR should >drop the packet silently. > > >On 3/20/12 9:06 AM, "Alain Durand" wrote: > >>It is necessary because the AFTR is the only place where we=20 >can enforce >>IPv4 ingress filtering, ie put ACLs to check >>that the incoming tunneled traffic from any given customer is using a >>legitimate IPv4 address and source port. >>When the incoming traffic does not match those ingress=20 >filtering rules, >>an ICMP error message must be returned. >>The idea in SD-NAT is to use this ICMP message to carry the=20 >information >>about the correct port range to use. >= From stig@venaas.com Tue Mar 20 13:45:15 2012 Return-Path: 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 0A54D21F860F; Tue, 20 Mar 2012 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9uPkHPNj+Zou; Tue, 20 Mar 2012 13:45:14 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id DF65221F85B8; Tue, 20 Mar 2012 13:45:13 -0700 (PDT) Received: from [10.33.12.81] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id BE7CC7FE4; Tue, 20 Mar 2012 21:45:11 +0100 (CET) Message-ID: <4F68EC55.2060005@venaas.com> Date: Tue, 20 Mar 2012 13:45:09 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sarikaya@ieee.org References: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires-wg , MBONED WG , Softwire Chairs , Behcet Sarikaya Subject: Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 20:45:15 -0000 On 3/9/2012 9:30 AM, Behcet Sarikaya wrote: > +1 I may be against adoption. This DHCPv6 option is needed, but it has nothing to do with ds-lite, and I'm not sure if this is the appropriate working group. This option has larger applicability than just encapsulation. If it is done here, it need to at least be reviewed and discussed in mboned. The options here are really based on draft-ietf-mboned-64-multicast-address-format-01.txt so mboned might be a better home. Copying mboned wg. Stig > > Behcet > > On Mon, Feb 6, 2012 at 10:30 PM, Qiong wrote: >> +1 support >> >> >> On Mon, Feb 6, 2012 at 5:33 PM, wrote: >>> >>> Hi, >>> >>> I support the adoption of this draft as a softwire WG document. >>> >>> Cheers, >>> >>> Christian. >>> >>> >>> -----Message d'origine----- >>> De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la >>> part de Yong Cui >>> Envoyé : lundi 6 février 2012 01:57 >>> À : Softwires WG >>> Cc : Yong Cui >>> Objet : [Softwires] ask for adoption of >>> draft-qin-softwire-multicast-prefix-option >>> >>> Dear Softwires wg, >>> >>> >>> As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in >>> Taipei meeting, the chairs would like to ask for WG adoption on the mailing >>> list. Please review this document and send your comments (especially your >>> opinion on the adoption with your reasons) to the mailing list by two weeks, >>> i.e. Feb. 20. >>> >>> FYI: >>> >>> http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option/ >>> >>> >>> Yong& Alain >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> _________________________________________________________________________________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorization. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange shall not be liable if >>> this message was modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From stig@venaas.com Tue Mar 20 13:47:22 2012 Return-Path: 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 CF12321F860F for ; Tue, 20 Mar 2012 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] 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 zNJM1jN32JKI for ; Tue, 20 Mar 2012 13:47:22 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6585321F85B8 for ; Tue, 20 Mar 2012 13:47:22 -0700 (PDT) Received: from [10.33.12.81] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 4C3437FE4 for ; Tue, 20 Mar 2012 21:47:21 +0100 (CET) Message-ID: <4F68ECD7.6030207@venaas.com> Date: Tue, 20 Mar 2012 13:47:19 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 CC: softwires@ietf.org References: <20111031192909.23485.52653.idtracker@ietfa.amsl.com> In-Reply-To: <20111031192909.23485.52653.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 20:47:22 -0000 I'm a little bit puzzled by how this document talks about DS-Lite. Isn't this an entirely generic solution for tunneling IPv4 multicast through an IPv6-only network? Stig From Tina.Tsou.Zouting@huawei.com Tue Mar 20 14:40:23 2012 Return-Path: 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 2165121E8029 for ; Tue, 20 Mar 2012 14:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HyU1VgdblMVO for ; Tue, 20 Mar 2012 14:40:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1143321E8015 for ; Tue, 20 Mar 2012 14:40:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEO15273; Tue, 20 Mar 2012 17:40:21 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Mar 2012 14:39:23 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Mar 2012 14:39:13 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.172]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Wed, 21 Mar 2012 05:39:21 +0800 From: Tina TSOU To: Yong Cui Thread-Topic: [Softwires] IETF 83 Sotfwire Agenda Thread-Index: AQHNBuHpWgFZVF1fpk243IJbkYQGvA== Date: Tue, 20 Mar 2012 21:39:21 +0000 Message-ID: <6A1E7EE6-717F-4E80-BECD-D4E011918CB2@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Ralph Droms Subject: Re: [Softwires] IETF 83 Sotfwire Agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:40:23 -0000 Dear Chairs, The authors have asked a slot for=20 http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-ana= lysis/ before. It has been referenceed a lot in the heated discussion. Sent from my iPad On Mar 20, 2012, at 6:50 AM, "Yong Cui" wrote: > Hi folks, >=20 > The WG chairs have discussed the agenda based on the presentation request= s > and main tasks in our wg. Because we received a lot of requests and only > have limited time for presentation, some of the requests cannot be > scheduled this time. >=20 > The agenda has been published at ietf 83 site: > http://www.ietf.org/proceedings/83/agenda/agenda-83-softwire.htm >=20 > Please send your slides to Alain and me by this Saturday. >=20 >=20 > Yong & Alain >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From matsuhira@jp.fujitsu.com Tue Mar 20 17:27:57 2012 Return-Path: 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 5043521E803A for ; Tue, 20 Mar 2012 17:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.418 X-Spam-Level: X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Mh+GIY8ZJkQT for ; Tue, 20 Mar 2012 17:27:56 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 726FA21E800C for ; Tue, 20 Mar 2012 17:27:49 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 59CD83EE0B6 for ; Wed, 21 Mar 2012 09:27:48 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 43B4945DE59 for ; Wed, 21 Mar 2012 09:27:48 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2E53F45DE54 for ; Wed, 21 Mar 2012 09:27:48 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1EE551DB8052 for ; Wed, 21 Mar 2012 09:27:48 +0900 (JST) Received: from m005.s.css.fujitsu.com (m005.s.css.fujitsu.com [10.23.4.35]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id D31FA1DB8048 for ; Wed, 21 Mar 2012 09:27:47 +0900 (JST) Received: from m005.css.fujitsu.com (m005 [127.0.0.1]) by m005.s.css.fujitsu.com (Postfix) with ESMTP id 3144C2E05A9; Wed, 21 Mar 2012 09:27:47 +0900 (JST) Received: from [127.0.0.1] (kurokawa-san.ntp.net.fujitsu.co.jp [10.17.194.166]) by m005.s.css.fujitsu.com (Postfix) with ESMTP id D43E02E05FE; Wed, 21 Mar 2012 09:27:43 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4F6920F7.4070100@jp.fujitsu.com> Date: Wed, 21 Mar 2012 09:29:43 +0900 From: Naoki Matsuhira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Naoki Matsuhira References: <1331010845386415.matsuhira@jp.fujitsu.com> <4F595132.8020201@jp.fujitsu.com> In-Reply-To: <4F595132.8020201@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ryo Nakamura , Yong Cui , Softwires WG , Fred Baker Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 00:27:57 -0000 Dear Chairs, I would like to ask a presentation slot for "SA46T interoperability test report" again. I understand the agenda of softwire wg already full, so I ask add this report to the last of the agenda, and If the agenda finished early, please give the chance for presentation. This test was done at WIDE camp spring 2012 on this march 5 - 8, and SA46T also serve IPv4 connectivity in IPv6-only network experiments which will be present at v6ops wg in this IETF meeting. This test results are useful for this wg, and interoperability test report also helpful and very very timely and hot topics, I believe. Regards, Naoki Matsuhra (2012/03/09 9:39), Naoki Matsuhira wrote: > Hi, Alain and Yong, > > I would like to update the title of our presentation request. > > Naoki Matsuhira, Ryo Nakamura "SA46T interoperability test report" (5min) > > Best Regards, > Naoki Matsuhira > > > (2012/03/06 14:14), Naoki Matsuhira wrote: >> Hi, Alain and Yong, >> >> I would like to present SA46T interoperability test results. >> >> 5min is enough. >> >> Naoki Matsuhira >> >> >> >> On Wed, 29 Feb 2012 07:16:38 -0800 >> Alain Durand wrote: >> >>> If you intend to present in Paris, please send Yong and I a request >>> by 3/7. >>> >>> - Alain. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > > > From pengwu.thu@gmail.com Tue Mar 20 21:05:44 2012 Return-Path: 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 0DC4421E803D for ; Tue, 20 Mar 2012 21:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 J9EZc1fsaEhb for ; Tue, 20 Mar 2012 21:05:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF3321E8019 for ; Tue, 20 Mar 2012 21:05:43 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so545380pbb.31 for ; Tue, 20 Mar 2012 21:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Tw8I1oG9F1MJ8OwMNVlJcKnIzP1uxyw0RLqlgInUjzw=; b=WaQgo80cPOEPpgj6T0DicwoZiQ0Mdc7Fp9kEjPXKU/H+3bfOEt6OKCjQl+XLJ2mu/a wmS0YCMtSoTBHzNnO7BDPZS/R/1/67R/DSCA2A3isd2dkDvyxrZl548+55BqY6iy5vDV LO7icWmj5pE77Sw/5kZ0UKH/+ZXT0I+WGYfcM9xkB1dx7GAMHI7/YVMOWLoBiNPiSQfY gs0jRnBzk7n6vyChfWBGLCZFvoHiM0DqHR8t4DBGtpxqU9OtRpAQ3x8Wj2UpTfcHXGgB lWuXHiVXwCJc2TmLTEvzjbjRzgN++0IQ4Awk3QAY5uDHQtnJVxfZLOPFyV4e2BhCwL4E AxnA== MIME-Version: 1.0 Received: by 10.68.73.225 with SMTP id o1mr7101008pbv.77.1332302743259; Tue, 20 Mar 2012 21:05:43 -0700 (PDT) Received: by 10.68.237.42 with HTTP; Tue, 20 Mar 2012 21:05:43 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E281DB353@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 21 Mar 2012 12:05:43 +0800 Message-ID: From: Peng Wu To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 04:05:44 -0000 Hi Alain, I get what you are saying, but I still have one question: so this repository, is it dynamic is some way? For example, what happens if some user whose IPv6 address is not profiled requires enters, or some user is profiled leaves? Or we are supposing that the ISP knows all the user IPv6 prefixes and configures all the address mappings in some initial phase, so no matter what happens in the user side, the address mapping always remains? This can help us to understand the SD-NAT draft more precisely. Thx~ 2012/3/20 Alain Durand : > > On Mar 17, 2012, at 12:44 PM, Qi Sun wrote: > >> Hi Med, >> >> =A0 =A0 =A0 I've read through the draft-penno-* and IMHO it is reasonabl= e in the view of deployment. =A0By configuring the profile (i.e. the per-su= bscriber mapping table) in the AFTRs, the SPs can achieve an explicit bindi= ng between the IPv4 address + port-set and the customer. This can mean the = customer pay for the ownership of the IPv4 address + port-set. It is easy t= o associate address(port-set) assignment with authentication. >> >> Best Regards! >> >> Qi Sun > > Thank you for your comment. Indeed, it is both simple and necessary to kn= ow on the AFTR which ports belong to which subscriber. > > It is simple because this can be configured out-of-band (think netconf) f= rom a centralized repository. Note, that, using > a centralized repository for subscriber <--> =A0IPv4 address & port mappi= ng, the service provider has the flexibility to > allocate different numbers of ports according to the subscriber profile. = More, because the association subscriber > <--> IPv4 address and port is known, there is no need for logging of any = sort on the AFTR. > > It is necessary because the AFTR is the only place where we can enforce I= Pv4 ingress filtering, ie put ACLs to check > that the incoming tunneled traffic from any given customer is using a leg= itimate IPv4 address and source port. > When the incoming traffic does not match those ingress filtering rules, a= n ICMP error message must be returned. > The idea in SD-NAT is to use this ICMP message to carry the information a= bout the correct port range to use. > > Alain. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From washam.fan@gmail.com Tue Mar 20 23:25:14 2012 Return-Path: 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 4243B21F8574 for ; Tue, 20 Mar 2012 23:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ruK5JdFdlJx3 for ; Tue, 20 Mar 2012 23:25:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1898C21F8501 for ; Tue, 20 Mar 2012 23:25:12 -0700 (PDT) Received: by werb10 with SMTP id b10so767531wer.31 for ; Tue, 20 Mar 2012 23:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qds3AgNb77/Sfn2aj19WedyesBddcpY4w0PVDlZXXFs=; b=jH4c4jflIVB+gty5/VlNYCl/F09WOPkJg/WNl6V5yKNUsHSq5offNtPje4p7rQXLD9 Ntr46kE58QCGUliHj8tKhYjGwnFtbVVNMr74AM3HhUN0KkawuZuuLbQ/yDO4wXPdq5uf gTWBVsEyPapGHPkpluWIb5SXO8YljdWdGESKCafbEOdL4i2Cvn1/cMYEv+7FswG/Xnfx wdwchdUCqJPbIRqDq91MfWP0NXpUyAMprxbqY/9YRtGVPfkezasEzKnFE0FVTN3lGdGp TliBr4tF9EaY0rfTA5o9QJ/WzUcDz4sQBnxxBxL03LNqBYmYbnrWCTvLR1bu6+fstDcd VLPg== MIME-Version: 1.0 Received: by 10.180.81.135 with SMTP id a7mr35399015wiy.16.1332311112126; Tue, 20 Mar 2012 23:25:12 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Tue, 20 Mar 2012 23:25:12 -0700 (PDT) Date: Wed, 21 Mar 2012 14:25:12 +0800 Message-ID: From: Washam Fan To: Softwires Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 06:25:14 -0000 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam From mohamed.boucadair@orange.com Wed Mar 21 00:23:04 2012 Return-Path: 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 B852921E8041; Wed, 21 Mar 2012 00:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 d48aM1jYrXAC; Wed, 21 Mar 2012 00:23:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E382721E8040; Wed, 21 Mar 2012 00:23:03 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F05F93B445F; Wed, 21 Mar 2012 08:23:01 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D328927C046; Wed, 21 Mar 2012 08:23:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 21 Mar 2012 08:23:01 +0100 From: To: Stig Venaas , "sarikaya@ieee.org" Date: Wed, 21 Mar 2012 08:23:00 +0100 Thread-Topic: [MBONED] [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option Thread-Index: Ac0G2lzibn63OtcWT5y6dsU3jJyMuAAWHWZg Message-ID: <94C682931C08B048B7A8645303FDC9F36E285584AB@PUEXCB1B.nanterre.francetelecom.fr> References: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> <4F68EC55.2060005@venaas.com> In-Reply-To: <4F68EC55.2060005@venaas.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Cc: Softwires-wg , MBONED WG , Softwire Chairs , Behcet Sarikaya Subject: Re: [Softwires] [MBONED] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 07:23:04 -0000 Dear Stig, For sure mboned will had the opportunity to review it. No matter where the = document is specified if a piece of work is needed. This is the kind of cross-WG documents that would require some flexibility = form the IETF to make progress. Cheers, Med=20 >-----Message d'origine----- >De : mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org]=20 >De la part de Stig Venaas >Envoy=E9 : mardi 20 mars 2012 21:45 >=C0 : sarikaya@ieee.org >Cc : Softwires-wg; MBONED WG; Softwire Chairs; Behcet Sarikaya >Objet : Re: [MBONED] [Softwires] ask for adoption of=20 >draft-qin-softwire-multicast-prefix-option > >On 3/9/2012 9:30 AM, Behcet Sarikaya wrote: >> +1 > >I may be against adoption. This DHCPv6 option is needed, but it has >nothing to do with ds-lite, and I'm not sure if this is the appropriate >working group. This option has larger applicability than just >encapsulation. If it is done here, it need to at least be reviewed and >discussed in mboned. > >The options here are really based on >draft-ietf-mboned-64-multicast-address-format-01.txt >so mboned might be a better home. > >Copying mboned wg. > >Stig > >> >> Behcet >> >> On Mon, Feb 6, 2012 at 10:30 PM, Qiong wrote: >>> +1 support >>> >>> >>> On Mon, Feb 6, 2012 at 5:33=20 >PM, wrote: >>>> >>>> Hi, >>>> >>>> I support the adoption of this draft as a softwire WG document. >>>> >>>> Cheers, >>>> >>>> Christian. >>>> >>>> >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la >>>> part de Yong Cui >>>> Envoy=E9 : lundi 6 f=E9vrier 2012 01:57 >>>> =C0 : Softwires WG >>>> Cc : Yong Cui >>>> Objet : [Softwires] ask for adoption of >>>> draft-qin-softwire-multicast-prefix-option >>>> >>>> Dear Softwires wg, >>>> >>>> >>>> As our WG discussed on DHCPv6 Options for IPv6 DS-Lite=20 >Multicast Prefix in >>>> Taipei meeting, the chairs would like to ask for WG=20 >adoption on the mailing >>>> list. Please review this document and send your comments=20 >(especially your >>>> opinion on the adoption with your reasons) to the mailing=20 >list by two weeks, >>>> i.e. Feb. 20. >>>> >>>> FYI: >>>> >>>>=20 >http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-pr >efix-option/ >>>> >>>> >>>> Yong& Alain >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >>>>=20 >_______________________________________________________________ >__________________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation.=20 >Si vous avez >>>> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces=20 >jointes. Les messages >>>> electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce=20 >message a ete >>>> altere, deforme ou falsifie. Merci >>>> >>>> This message and its attachments may contain confidential=20 >or privileged >>>> information that may be protected by law; >>>> they should not be distributed, used or copied without=20 >authorization. >>>> If you have received this email in error, please notify=20 >the sender and >>>> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange shall=20 >not be liable if >>>> this message was modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >MBONED mailing list >MBONED@ietf.org >https://www.ietf.org/mailman/listinfo/mboned >= From mohamed.boucadair@orange.com Wed Mar 21 03:24:51 2012 Return-Path: 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 11CB221F85F3 for ; Wed, 21 Mar 2012 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 sQbwjJ2Cqc4e for ; Wed, 21 Mar 2012 03:24:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 644D821F84D8 for ; Wed, 21 Mar 2012 03:24:50 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C366422C9F9; Wed, 21 Mar 2012 11:24:49 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A9E324C063; Wed, 21 Mar 2012 11:24:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 21 Mar 2012 11:24:49 +0100 From: To: Washam Fan , Softwires Date: Wed, 21 Mar 2012 11:24:48 +0100 Thread-Topic: [Softwires] Fragmentation in sdnat-02 Thread-Index: Ac0HK2LaMsgh4LpGSx6nMBJtyII6TwAH3cMA Message-ID: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415 Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 10:24:51 -0000 Dear Washam, This is an issue common to all stateless solutions, including deterministic= NAT with (anaycast) IPv4 address pool.=20 FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-sta= teless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-rel= ated function in one single node: any received fragment is redirected to a = dedicated node which will be responsible for reassembly or forward the frag= ment to the appropriate CPE. This node must dedicate resources to handle ou= t of order fragments. Saying that, I can not quantify the severity of this issue in all operation= al networks.=20 Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Washam Fan >Envoy=E9 : mercredi 21 mars 2012 07:25 >=C0 : Softwires >Objet : [Softwires] Fragmentation in sdnat-02 > >Hi Authors, > >In section 3.2, it states IPv4 address pool should be anycasted. This >introduces a risk where different incoming fragments go to different >AFTRs. Because one IPv4 address is shared between multiple >subscribers, reassemly is needed on AFTRs when receiving fragments. If >different fragments go thru different AFTRs, the reassmely process >would fail and incur DoS. > >Thanks, >washam >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From rdroms.ietf@gmail.com Wed Mar 21 05:32:27 2012 Return-Path: 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 7189E21F86EA for ; Wed, 21 Mar 2012 05:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 4NKdl4YGNhSg for ; Wed, 21 Mar 2012 05:32:27 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D439E21F86EB for ; Wed, 21 Mar 2012 05:32:26 -0700 (PDT) Received: by qadc14 with SMTP id c14so1714455qad.10 for ; Wed, 21 Mar 2012 05:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to:x-mailer; bh=Rg+rhNWvESMwluanYOXb8t8z3DytbX5AbmwW1H7u+xI=; b=Zur00NQuyCSjb2sYzNsJ7PLxlKF+Hyuag5FwWKq81aL0usITxMY5H6PtXP4Ig26fdo SIVesBqmUgg6m+e1uv/i8DVDk+eGNCa1b7BmcJTlygKVWRM47fO8LrQrCKp/DXEulY1N CylLU3CxN7U1yAE6oKZfiCpCxXOuayg2o35One108WULahKjS+LN+1OmxVUbCNHGGvtX XJRQjWcx1E4jgkIWvAXXoSD+ulpjvpdPe0g+vmhTVxKJvtpGIGtXZM0FQY2wZnFDP3Ko CGh3cj7rKioHb2/aYPigaRmbaFaAP6TOabrKryttAFUP0FLbDbKhaqwvwbfdnnIiGE0I xwJQ== Received: by 10.229.77.5 with SMTP id e5mr1327776qck.99.1332333146314; Wed, 21 Mar 2012 05:32:26 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id fq1sm2638185qab.10.2012.03.21.05.32.24 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 05:32:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Ralph Droms Date: Wed, 21 Mar 2012 08:32:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: To: Softwires WG X-Mailer: Apple Mail (2.1251.1) Cc: int-ads@tools.ietf.org Subject: [Softwires] Independent Submission RFC publication of draft-tsou-softwire-gwinit-6rd-06 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:32:27 -0000 The Independent Stream Editor has received a request to publish = draft-tsou-softwire-gwinit-6rd-06 as an Independent Submission = Informational RFC. Before the document is published, the IESG needs to = determine the relationship of this document to work in any IETF working = groups, as described in section 3 of RFC 5742. If you have a concern that draft-tsou-softwire-gwinit-6rd-06 might in = some way "disrupt the IETF work done in WG softwire," (quoted from = section 3 of RFC 5742) please let me know. Note that the IESG is explicitly not responsible for the technical = contents of draft-tsou-softwire-gwinit-6rd-06. If you have any comments = or input on the contents of draft-tsou-softwire-gwinit-6rd-06, please = contact the authors at tsou-softwire-gwinit-6rd@tools.ietf.org with a = copy to Nevil Brownlee, the Independent Submissions Editor, at = rfc-ise@rfc-editor.org. - Ralph Droms Internet Area Director From xing@cernet.edu.cn Wed Mar 21 06:39:39 2012 Return-Path: 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 27DF221F8649 for ; Wed, 21 Mar 2012 06:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 Dcja0CKVPcHt for ; Wed, 21 Mar 2012 06:39:37 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id D596E21F8601 for ; Wed, 21 Mar 2012 06:39:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.46.185]) by centos (Coremail) with SMTP id AQAAf3DbWARC2WlPAc8SAA--.3513S2; Wed, 21 Mar 2012 21:36:11 +0800 (CST) Message-ID: <4F69D9FB.9060105@cernet.edu.cn> Date: Wed, 21 Mar 2012 21:39:07 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alain Durand References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030900010109040205040209" X-CM-TRANSID: AQAAf3DbWARC2WlPAc8SAA--.3513S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWFy7WF1fWrW8ZF4ktryfXrb_yoWrtFyUpF 4rGr48Ga1DJFs3C34kAw4xtF1Fyw4fKa1Uuwn3trWxA3s8try8Kryrt3WY9F9rCrn5CF1j vr4akrn8Za1vvFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkG14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjc xK6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28E F7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4 xG67k08I80eVWUJVW8JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8 JwAqx4xG6xAIxVCFxsxG0wAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kI c2xKxwCYjI0SjxkI62AI1cAE67vIY487MxkF7I0En4kS14v26r1q6r43MxkF7I0Ew4C26c xK6c8Ij28IcwCY02Avz4vE14v_Xr4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWU GVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7V AKI48JMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r4j6F4U MIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUsvtAUUU UU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:39:39 -0000 This is a multi-part message in MIME format. --------------030900010109040205040209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing ? 2012/3/20 7:38, Alain Durand ??: > Dear wg, > > After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. > > 1) There is an observation that all the solutions on the table E, T& U actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation > proposals, U is an hybrid unifying solution. > > 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. > > We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T& U). > Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. > > Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask > and their sequence. > > Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? > > If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. > If the answer is YES, we move to the next question. > > > Q2: Do you believe that the WG should publish U as the one Standards Track document? > > If the answer is YES, the process stop, we put U on the Standard Track and publish E& T as Informational. > If the answer is NO, we are left with E& T (U then might be abandoned or published as Historical/Informational) > > > Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? > > If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both E& T as Experimental. > > In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. > > Alain& Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------030900010109040205040209 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, Alain, Yong and Ralph,

The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now.

4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic).

Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data.

Regards,

xing

 



于 2012/3/20 7:38, Alain Durand 写道: 
Dear wg,

After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T & U actually solve the stateless  problem we started with.
    There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation
    proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those
    documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation.

Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards Track document?

If the answer is YES, the process stop, we put U on the Standard Track and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)?

If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other.

  Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--------------030900010109040205040209-- From phdgang@gmail.com Thu Mar 22 00:33:22 2012 Return-Path: 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 A1D7421F85DB for ; Thu, 22 Mar 2012 00:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 x6OSaMFX8ZAn for ; Thu, 22 Mar 2012 00:33:21 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD3221F85D8 for ; Thu, 22 Mar 2012 00:33:21 -0700 (PDT) Received: by werb10 with SMTP id b10so1856817wer.31 for ; Thu, 22 Mar 2012 00:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VrCdAbm6rlThX6QS+KnlzxZC06n9Jo4iawXyVaVHhx8=; b=cANkryVRWl8uwT4vuK7DLQS/Py0gzWYmmyaXUkwQ5V7yMP3bwkTa/bJMcayA01lW1q Gqd2mYJROnxYJ8cUregNprL1ksSOSzioVpSVVVJP+h4gNb+6o5JxdhvJBHQiaDTSOTQR 1Aw4E31/Pe2Bh/2fOtn2rvse4KKzWMvrDfwuKqaZqYn11GdSGE8a7JUxYzFLHWyYQZBU GNuPJ4CJtiGtbnafEqR5WuvsDHaxR6HlcgsyHje/ZspsNKgMI8hRTiGwfwHvuGQcvppt hDCVEzBB9QwY9dLiryhVoWE5Tg5xwRlYQ9NxiqJIZ1iuCgUGb053imm95mTtWekgJ9KV SX7w== MIME-Version: 1.0 Received: by 10.216.133.9 with SMTP id p9mr4135959wei.9.1332401595152; Thu, 22 Mar 2012 00:33:15 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Thu, 22 Mar 2012 00:33:15 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 22 Mar 2012 15:33:15 +0800 Message-ID: From: GangChen To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:33:23 -0000 2012/3/21, mohamed.boucadair@orange.com : > Dear Washam, > > This is an issue common to all stateless solutions, including determinist= ic > NAT with (anaycast) IPv4 address pool. > > FWIW, we recorded this issue here: > http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. > > As a solution to this issue, we proposed to implement the > fragmentation-related function in one single node: any received fragment = is > redirected to a dedicated node which will be responsible for reassembly o= r > forward the fragment to the appropriate CPE. This node must dedicate > resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#section-4.5.2. BRs Gang > Saying that, I can not quantify the severity of this issue in all > operational networks. > > Cheers, > Med > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>Envoy=E9 : mercredi 21 mars 2012 07:25 >>=C0 : Softwires >>Objet : [Softwires] Fragmentation in sdnat-02 >> >>Hi Authors, >> >>In section 3.2, it states IPv4 address pool should be anycasted. This >>introduces a risk where different incoming fragments go to different >>AFTRs. Because one IPv4 address is shared between multiple >>subscribers, reassemly is needed on AFTRs when receiving fragments. If >>different fragments go thru different AFTRs, the reassmely process >>would fail and incur DoS. >> >>Thanks, >>washam >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From mohamed.boucadair@orange.com Thu Mar 22 00:52:02 2012 Return-Path: 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 ED9FC21F8601 for ; Thu, 22 Mar 2012 00:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 SAKBBv90zeUh for ; Thu, 22 Mar 2012 00:52:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7A21F85FB for ; Thu, 22 Mar 2012 00:52:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C5C84324580; Thu, 22 Mar 2012 08:52:00 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A8C7B27C046; Thu, 22 Mar 2012 08:52:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 22 Mar 2012 08:52:00 +0100 From: To: GangChen Date: Thu, 22 Mar 2012 08:51:59 +0100 Thread-Topic: [Softwires] Fragmentation in sdnat-02 Thread-Index: Ac0H/gt7h31+UXxNR32r7FrG2wzKDwAAhkdg Message-ID: <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.22.65414 Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:52:03 -0000 Dear Gang, Thanks, but I failed to find the text describing how to handle two fragment= s received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med >-----Message d'origine----- >De : GangChen [mailto:phdgang@gmail.com]=20 >Envoy=E9 : jeudi 22 mars 2012 08:33 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Washam Fan; Softwires >Objet : Re: [Softwires] Fragmentation in sdnat-02 > >2012/3/21, mohamed.boucadair@orange.com : >> Dear Washam, >> >> This is an issue common to all stateless solutions,=20 >including deterministic >> NAT with (anaycast) IPv4 address pool. >> >> FWIW, we recorded this issue here: >> http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >> >> As a solution to this issue, we proposed to implement the >> fragmentation-related function in one single node: any=20 >received fragment is >> redirected to a dedicated node which will be responsible for=20 >reassembly or >> forward the fragment to the appropriate CPE. This node must dedicate >> resources to handle out of order fragments. > >FYI, I see another approach doing that with a entry table + >redirection action, similarly like >http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >ion-4.5.2. > >BRs > >Gang > >> Saying that, I can not quantify the severity of this issue in all >> operational networks. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : softwires-bounces@ietf.org >>>[mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>Envoy=E9 : mercredi 21 mars 2012 07:25 >>>=C0 : Softwires >>>Objet : [Softwires] Fragmentation in sdnat-02 >>> >>>Hi Authors, >>> >>>In section 3.2, it states IPv4 address pool should be anycasted. This >>>introduces a risk where different incoming fragments go to different >>>AFTRs. Because one IPv4 address is shared between multiple >>>subscribers, reassemly is needed on AFTRs when receiving=20 >fragments. If >>>different fragments go thru different AFTRs, the reassmely process >>>would fail and incur DoS. >>> >>>Thanks, >>>washam >>>_______________________________________________ >>>Softwires mailing list >>>Softwires@ietf.org >>>https://www.ietf.org/mailman/listinfo/softwires >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >= From phdgang@gmail.com Thu Mar 22 02:53:02 2012 Return-Path: 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 23B7321F865A for ; Thu, 22 Mar 2012 02:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WxVcnnNfF8HX for ; Thu, 22 Mar 2012 02:53:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0521F8646 for ; Thu, 22 Mar 2012 02:53:01 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2214062vcb.31 for ; Thu, 22 Mar 2012 02:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hLynH47qd3L1b8PoX0N5/zZujdRj5dsGh0IkfCkiRZM=; b=NndSqGoPto9s58CES/8mDo2FVV9XRddgbBAtqJMbnXEZKH5wRouMfFiZCDnThrSHlE OZsJpxXjI+HRD+072yfi5Q8Oe6utEGKzJhiKVr+S7LdOwoQpqggnPlPTTebFwNYcLjAS II+KFiDEBQ4CQJUuGbXcvuYtAlUq0gROOXjmnbsfyqRY998dyYuBntgBye+m/WBXUilt b13Zxba/q01m+GhwGTDH3fDekcaN5mzOVbKMhAit5Qm1vg5q+Jzhv9XcmXEXKWWQyT5E l6l1EAkGXfbNLIqBsaHPQCVd9Y0/sElmBShF6YUWlVqCA12QVre+Pr4uOe5iepcwIhP+ dH2g== MIME-Version: 1.0 Received: by 10.52.19.196 with SMTP id h4mr2902366vde.91.1332409980733; Thu, 22 Mar 2012 02:53:00 -0700 (PDT) Received: by 10.220.45.136 with HTTP; Thu, 22 Mar 2012 02:53:00 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 22 Mar 2012 17:53:00 +0800 Message-ID: From: GangChen To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:53:02 -0000 Dear Med, Yes. There are no texts targeting to this topics. I mean we could leverage the consideration in 4rd-U to build a entry table. One more REDIRECTION action obviously should be added to the row of "RESULTING ACTIONS". Any received fragment looking for conditions and execute a proper action(forwarding or redirection) BRs Gang 2012/3/22, mohamed.boucadair@orange.com : > Dear Gang, > > Thanks, but I failed to find the text describing how to handle two fragme= nts > received by two distinct BRs. > > Could you please point me to that text in case I miss it? > > Cheers, > Med > >>-----Message d'origine----- >>De : GangChen [mailto:phdgang@gmail.com] >>Envoy=E9 : jeudi 22 mars 2012 08:33 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Washam Fan; Softwires >>Objet : Re: [Softwires] Fragmentation in sdnat-02 >> >>2012/3/21, mohamed.boucadair@orange.com : >>> Dear Washam, >>> >>> This is an issue common to all stateless solutions, >>including deterministic >>> NAT with (anaycast) IPv4 address pool. >>> >>> FWIW, we recorded this issue here: >>> http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>> >>> As a solution to this issue, we proposed to implement the >>> fragmentation-related function in one single node: any >>received fragment is >>> redirected to a dedicated node which will be responsible for >>reassembly or >>> forward the fragment to the appropriate CPE. This node must dedicate >>> resources to handle out of order fragments. >> >>FYI, I see another approach doing that with a entry table + >>redirection action, similarly like >>http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >>ion-4.5.2. >> >>BRs >> >>Gang >> >>> Saying that, I can not quantify the severity of this issue in all >>> operational networks. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : softwires-bounces@ietf.org >>>>[mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>>Envoy=E9 : mercredi 21 mars 2012 07:25 >>>>=C0 : Softwires >>>>Objet : [Softwires] Fragmentation in sdnat-02 >>>> >>>>Hi Authors, >>>> >>>>In section 3.2, it states IPv4 address pool should be anycasted. This >>>>introduces a risk where different incoming fragments go to different >>>>AFTRs. Because one IPv4 address is shared between multiple >>>>subscribers, reassemly is needed on AFTRs when receiving >>fragments. If >>>>different fragments go thru different AFTRs, the reassmely process >>>>would fail and incur DoS. >>>> >>>>Thanks, >>>>washam >>>>_______________________________________________ >>>>Softwires mailing list >>>>Softwires@ietf.org >>>>https://www.ietf.org/mailman/listinfo/softwires >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> From yu.guanghui@gmail.com Thu Mar 22 05:26:44 2012 Return-Path: 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 BBE5821F8698 for ; Thu, 22 Mar 2012 05:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 vnqIVsu0mpzx for ; Thu, 22 Mar 2012 05:26:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9421F867C for ; Thu, 22 Mar 2012 05:26:41 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1950779bku.31 for ; Thu, 22 Mar 2012 05:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ww7Zr1MMLqx4fJ3iVBOLXDXlABQORkehWVlMtkLSyFI=; b=vhNcBtdDFI15yJVXYjNzmPNzNUwMSSKeTcfDIio97O/fZkFqRrlYUq1XqAJjjK2pCy G37M2hotcqbD7AntFGaPBfkpG8iTcY7Fyb33uVhqg87KKNPN6lR/aS3r/tcLicqP8ov7 iUc+foqy1rI1X2fs4B+KZy2VLo9inTRNNRj6vvTUrEHi+9F3Sg/DYudxMtm+2JrRvCWF NVp/KCYngt2z6FrKwz8qS3cO9z4wRIfzslkbAT3WmaT1Ib3wCXMmQ/NRXcD1Gaxw6lz9 kgU3/xl5P8qKsb314/P2iCTBR0kIZRGGeqWxlvj7VMGAoDCECBkQGpp/s7If2myvPxJ2 wp2w== MIME-Version: 1.0 Received: by 10.204.151.86 with SMTP id b22mr3013633bkw.81.1332419200249; Thu, 22 Mar 2012 05:26:40 -0700 (PDT) Received: by 10.204.184.145 with HTTP; Thu, 22 Mar 2012 05:26:40 -0700 (PDT) Date: Thu, 22 Mar 2012 20:26:40 +0800 Message-ID: From: Guanghui Yu To: Softwires WG Content-Type: multipart/alternative; boundary=0015175cd64c1f70f604bbd4055c Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:27:48 -0000 --0015175cd64c1f70f604bbd4055c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all This mail raises a very important issue. MAP-T and MAP-E are not competing technologies. They have different user scenarios. I read 4rd-u draft and found it is flawed. I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation. In summary, 4rd-U is not in the same level of MAP series and it should not be considered for adoption in coming Paris IETF meeting. PS: I'am sorry if this mail sends more than one time, the mail system of our university may have problems with this mail list today. Yu Guanghui Network and Information Center Dalian University of Technology, China Tel: +86 411 84708117 =D4=DA 2012-3-21=A3=AC=CF=C2=CE=E79:39=A3=AC Xing Li =D0=B4=B5=C0=A3=BA Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that =A1=B0multiple address and port mapping technologies could a= nd should converge=A1=B1 and you formally announced =A1=B0the creation of the = MAP (Mapping of Addresses and Ports) design team=A1=B1, a design team which =A1= =B0is tasked to formulate a unified format to be used either in an encapsulation or double translation mode=A1=B1 ( http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now= . 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don=A1=AFt think we have any reason to change the procedure an= d in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing =D3=DA 2012/3/20 7:38, Alain Durand =D0=B4=B5=C0: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T & U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T & U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E & T as Informational. If the answer is NO, we are left with E & T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E & T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain & Yong, wg co-chairs. _______________________________________________ Softwires mailing listSoftwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --0015175cd64c1f70f604bbd4055c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi all =
 =   This mail raises a very important issue. = MAP-T and MAP-E are not competing technologies. They have different user sc= enarios. I read 4rd-u draft and found it is flawed. I will not support the = adoption of 4rd-u, since there is no running code and there is no experimen= tal evaluation. In summary, 4rd-U is not in the same level of MAP series an= d it should not be considered for adoption in coming Paris IETF meeting.

PS: I'am sorry if this mail sends more than one ti= me, the mail system of our university may have problems with this mail list= today.

Yu Guanghui <ygh at dlut.edu.cn>
Network = and Information Center
Dalian University of Technology, China
Tel: +86 411 84708117

=D4=DA 20= 12-3-21=A3=AC=CF=C2=CE=E79:39=A3=AC Xing Li =D0=B4=B5=C0=A3=BA

Hi, Alain, Yong and Ralph,

The newl= y posted agenda does not match the consensus as you mentioned on 6 Oct 2011= , that “multiple address and port mapping technologies could and shou= ld converge” and you formally announced “the creation of the MA= P (Mapping of Addresses and Ports) design team”, a design team which = “is tasked to formulate a unified format to be used either in an enca= psulation or double translation mode” (http://www.ietf.org/= mail-archive/web/softwires/current/msg03024.html). For the past few mon= ths, the design team has produced a series of MAP documents, including MAP,= MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive fee= dback on the adoption of the MAP series as the standard track of working gr= oup documents. Moreover, the dIVI (an earlier version of MAP-T) has been ru= nning successfuly at CERNET2 for two years now.

4rd-U was submitted later, and the goal is to replace the MAP Series. T= here have been discussions in the mailing list, but the discussions are mai= nly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in th= e early design stage. Due to its proposed modification of the IPv6 architec= ture (V-Oct and the fragmentation header), the discussion should be extende= d at least to 6man WG before the Softwire WG makes any decision of adoption= . Furthermore, experimental data should be presented to the WG to show that= these modifications are not harmful. In addition, the fragmentation header= modifications actually only deal with a very corner case of double transla= tion (10e-5% of the packets, not production traffic).

Therefore, I don’t think we have any reason to change the procedu= re and in the coming meeting, we should discuss whether consensus can be re= ached for the adoption of the MAP series. We should discuss whether 4rd-U c= an be adopted in a later meeting when it gets proved by 6man and its modifi= cations are proved to be not harmful by experimental data.

Regards,

xing

 



=D3=DA 2012/3/20 7:38, Alain Durand =D0=B4=B5=C0:
Dear wg, After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T & = U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are reall= y significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' tho= se documents have at IETF. In particular, do we want to publish them as Ex= perimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U). Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to? If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track = document? If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational. If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)? If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E &am= p; T as Experimental. In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other. Alain & Yong, wg co-chairs. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www= .ietf.org/mailman/listinfo/softwires

______________________________________________= _
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--0015175cd64c1f70f604bbd4055c-- From wdec.ietf@gmail.com Thu Mar 22 06:32:38 2012 Return-Path: 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 53A2821F861D for ; Thu, 22 Mar 2012 06:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Fp+KzGD5Bik8 for ; Thu, 22 Mar 2012 06:32:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCE421F860B for ; Thu, 22 Mar 2012 06:32:37 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1496057qcs.31 for ; Thu, 22 Mar 2012 06:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FdTHzH/n7lP+vQfTLVgy3B+rjNLH1NVak9Wo4jDlERQ=; b=YYkC38eOYex6TQbXaRm3tTB6JEjVwK/+u91G2DuFvggeic1FlSahqXJ/zNKAutlglX BeEM+EoJunA1Ny9t4xW9SJTHLPMdtSPXeu9D4akNKG3z9tR3dlgU0y2TOR5ycNb5fKAW 9mUwUm/bg/4Bn+3SPEPsKRt4qbFgQYjCVtvaZv5xUnaD5KXB0zM63nO22Vbp8nGdb6m6 +BnxiJfI8jmmduWqE//UrkDUi9SJJ3XSosroQyc7k1tJuIy4HtUW+w2IezLGPP550K0H VF+ncvW6ulGUAuNizYh6ZXZ55z2gchTXBWGxdeX1JeTtpgh7avHsLmvdqHDLrQfr32xJ In+A== MIME-Version: 1.0 Received: by 10.224.8.208 with SMTP id i16mr10885600qai.51.1332423156642; Thu, 22 Mar 2012 06:32:36 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Thu, 22 Mar 2012 06:32:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 14:32:36 +0100 Message-ID: From: Wojciech Dec To: Alain Durand , Softwire Chairs Content-Type: multipart/alternative; boundary=bcaec51b15f5f132bb04bbd4f0a7 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:32:38 -0000 --bcaec51b15f5f132bb04bbd4f0a7 Content-Type: text/plain; charset=ISO-8859-1 Hello Chairs, all In essence, while at a very high level all solutions appear to solve a common problem, just like all ducks look the same, some solve extra problems that are of critical importance to some operators, this forms the basis for the different approaches, and what led to the MAP draft set, and in that set there is no way to "sqaure the circle" The "hybrid solution" also does not "square the circle", and what more raises several technical questions, besides lacking the trial implementation & experience factor that MAP's constituents have shown - it thus appears to be in a different, rather experimental, league . Respectfully thus, the view presented under item 1) below and ultimately the questions appear set to cause further thrashing of arguments all over again. All this going a long way off from actually progressing the development of solutions that solve problems the WG cares about and under majority consensus if universal consensus is not possible. As a way forward I would suggest a much simpler approach that is more likely to result in some progress, with the following questions being asked: 1. Should MAP (all MAP drafts) be adopted as WG drafts all on Informational track? 2. Should 4rd-u as WG draft on the Experimental or Informational track, if shown to be in line with existing specs. Along with an acceptance of any/all of the above, there should be a charter clause indicating that one, or all of these drafts can be moved to a Standards track following WG consensus, without altering the status of the others, unless similarly consented. Regards, Wojciech. On 20 March 2012 00:38, Alain Durand wrote: > Dear wg, > > After a number of discussions with my co-chair, our AD and various > authors, here is how we would like to move forward wrt 4rd. > > 1) There is an observation that all the solutions on the table E, T & U > actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are > really significant. E and T are the original Encapsulation and Translation > proposals, U is an hybrid unifying solution. > > 2) We have already agreed back in Beijing that we would publish all > necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as > Experimental, Informational or Standard Track. > > We are at the point now where we need to make progress. In Paris, we would > like to ask for presentations from the proponents of each candidate > solution (E, T & U). > Each presentation should cover an overview of the proposed solution, > explain how it compares to the others and make a case as why it should be > the one on the Standard Track. We will allocate 20 minutes for each > presentation. > > Then, we, chairs, would like to ask a series of questions to the working > group. In order to make this process transparent, here is the list of > questions we want to ask > and their sequence. > > Q1: Without pre-supposing which one will be selected, do you agree to > publish 1 of the 3 proposals on the Standard Track and publish the other(s) > as Informational if still asked to? > > If the answer is NO, then the process stops and we will publish everything > as Experimental and come back in 12-24 months to see what gets adopted by > the market. > If the answer is YES, we move to the next question. > > > Q2: Do you believe that the WG should publish U as the one Standards Track > document? > > If the answer is YES, the process stop, we put U on the Standard Track and > publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned or > published as Historical/Informational) > > > Q3: Which of E and T do you want to see moving on the standard track (you > can only express support for one)? > > If there is a clear outcome from this question, we would publish that > proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both E & > T as Experimental. > > In the meantime, we would like to encourage discussion on the mailing list > to foster our common understanding of the various technologies and how they > relate to each other. > > Alain & Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec51b15f5f132bb04bbd4f0a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Chairs, all

In essence, while at a very high level all solutio= ns appear to solve a common problem, just like all ducks look the same, som= e solve extra problems that are of critical importance to some operators, t= his forms the basis for the different approaches, and what led to the MAP d= raft set, and in that set there is no way to "sqaure the circle"<= br> The "hybrid solution" also does not "square the circle"= , and what more raises several technical questions, besides lacking the tri= al implementation & experience factor that MAP's constituents have = shown - it thus appears to be in a different, rather experimental, league .=

Respectfully thus, the view presented under item 1) below and ultimatel= y the questions appear set to cause further thrashing of arguments all over= again. All this going a long way off from actually progressing the develop= ment of solutions that solve problems the WG cares about and under majority= consensus if universal consensus is not possible.

As a way forward I would suggest a much simpler approach that is more l= ikely to result in some progress, with the following questions being asked:=
1. Should MAP (all MAP drafts) be adopted as WG drafts all on Informati= onal track?
2. Should 4rd-u as WG draft on the Experimental or Informational track, if = shown to be in line with existing specs.

Along with an acceptance of= any/all of the above, there should be a charter clause indicating that one= , or all of these drafts can be moved to a Standards track following WG con= sensus, without altering the status of the others, unless similarly consent= ed.

Regards,
Wojciech.

On 20 March 201= 2 00:38, Alain Durand <adurand@juniper.net> wrote:
Dear wg,

After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd.

1) There =A0is an observation that all the solutions on the table E, T &= ; U actually solve the stateless =A0problem we started with.
=A0 =A0There are differences, but it is unclear if those differences are r= eally significant. E and T are the original Encapsulation and Translation =A0 =A0proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' tho= se
=A0 =A0documents have at IETF. In particular, do we want to publish them a= s Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U).
Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation.<= br>
Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to?

If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards Track = document?

If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)?

If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E &am= p; T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other.

=A0Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--bcaec51b15f5f132bb04bbd4f0a7-- From jan@go6.si Thu Mar 22 06:54:02 2012 Return-Path: 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 7C61421F858E for ; Thu, 22 Mar 2012 06:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iWltx-ZuBYWE for ; Thu, 22 Mar 2012 06:54:02 -0700 (PDT) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id F095521F8549 for ; Thu, 22 Mar 2012 06:54:01 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 3362823780BB; Thu, 22 Mar 2012 14:54:00 +0100 (CET) Message-ID: <4F6B2EF7.3000208@go6.si> Date: Thu, 22 Mar 2012 14:53:59 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alain Durand References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:54:02 -0000 On 3/20/12 12:38 AM, Alain Durand wrote: > Q1: Without pre-supposing which one will be selected, do you agree to > publish 1 of the 3 proposals on the Standard Track and publish the > other(s) as Informational if still asked to? > > If the answer is NO, then the process stops and we will publish > everything as Experimental and come back in 12-24 months to see what > gets adopted by the market. If the answer is YES, we move to the next > question. Hi, I'm not really happy with this decision. RFC 6346 Stateless A+P (a.k.a. 4rd/MAP) world is polarized in encapsulation and translation part. MAP-U is brave attempt to unify both worlds, but I;m not sure all the best parts from both world ended up in -U proposal and that result is what I would like to see in reality. Coming from operational ISP world, where this stuff will actually be implemented in reality, I would suggest to publish -E and -T as documents in standards track - and -U as experimental or informational. What I would like to see as network architect is that vendors deploys -E and -T in the same product named 4RD and operator can choose operating mode when implementing the solution - deciding between encapsulation or translation at will. This way this working group work and effort would become useful for operations. Cheers and see you in few days, Jan Zorz Go6 Institute Slovenia From wzk@synet.edu.cn Thu Mar 22 07:09:44 2012 Return-Path: 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 734E321F85EC for ; Thu, 22 Mar 2012 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 EqOhlbUmigMw for ; Thu, 22 Mar 2012 07:09:42 -0700 (PDT) Received: from mail.synet.edu.cn (unknown [IPv6:2001:da8:a8:ffd:20c:29ff:fe9f:8138]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9A621F857D for ; Thu, 22 Mar 2012 07:09:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.synet.edu.cn (Postfix) with ESMTP id 5DA6C60F73; Thu, 22 Mar 2012 22:08:07 +0800 (CST) X-Virus-Scanned: amavisd-new at synet.edu.cn Received: from mail.synet.edu.cn ([127.0.0.1]) by localhost (mail.synet.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4lnhiryII-3; Thu, 22 Mar 2012 22:07:53 +0800 (CST) Received: from mail.synet.edu.cn (mail.synet.edu.cn [202.118.7.146]) by mail.synet.edu.cn (Postfix) with ESMTP id 927C060F5E; Thu, 22 Mar 2012 22:07:53 +0800 (CST) Date: Thu, 22 Mar 2012 22:07:53 +0800 (CST) From: Zhankao WEN To: Xing Li Message-ID: <508295242.21136.1332425273434.JavaMail.root@mail.synet.edu.cn> In-Reply-To: <4F69D9FB.9060105@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [202.118.0.200] X-Mailer: Zimbra 7.1.4_GA_2567 (ZimbraWebClient - FF3.0 (Win)/7.1.4_GA_2555) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=E2=80=A6?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:09:44 -0000 +1, support Best regards -- Name: Zhankao WEN(=E6=B8=A9=E5=8D=A0=E8=80=83) Email: wzk@synet.edu.cn wzk@mail.neu.edu.cn Tel&Fax: +86-24-83687240 Address: Networking Center Northeastern University Shenyang Liaoning Province P.R. China (110819) ----- Original Message ----- From: "Xing Li" To: "Alain Durand" Cc: "Softwires WG" , "Yong Cui" , "Ralph Droms" Sent: Wednesday, 21 March, 2012 9:39:07 PM Subject: Re: [Softwires] Path to move forward with 4rd=E2=80=A6 Hi, Alain, Yong and Ralph,=20 The newly posted agenda does not match the consensus as you mentioned on 6 = Oct 2011, that =E2=80=9Cmultiple address and port mapping technologies coul= d and should converge=E2=80=9D and you formally announced =E2=80=9Cthe crea= tion of the MAP (Mapping of Addresses and Ports) design team=E2=80=9D, a de= sign team which =E2=80=9Cis tasked to formulate a unified format to be used= either in an encapsulation or double translation mode=E2=80=9D ( http://ww= w.ietf.org/mail-archive/web/softwires/current/msg03024.html ). For the past= few months, the design team has produced a series of MAP documents, includ= ing MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed posi= tive feedback on the adoption of the MAP series as the standard track of wo= rking group documents. Moreover, the dIVI (an earlier version of MAP-T) has= been running successfuly at CERNET2 for two years now.=20 4rd-U was submitted later, and the goal is to replace the MAP Series. There= have been discussions in the mailing list, but the discussions are mainly = questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the ea= rly design stage. Due to its proposed modification of the IPv6 architecture= (V-Oct and the fragmentation header), the discussion should be extended at= least to 6man WG before the Softwire WG makes any decision of adoption. Fu= rthermore, experimental data should be presented to the WG to show that the= se modifications are not harmful. In addition, the fragmentation header mod= ifications actually only deal with a very corner case of double translation= (10e-5% of the packets, not production traffic).=20 Therefore, I don=E2=80=99t think we have any reason to change the procedure= and in the coming meeting, we should discuss whether consensus can be reac= hed for the adoption of the MAP series. We should discuss whether 4rd-U can= be adopted in a later meeting when it gets proved by 6man and its modifica= tions are proved to be not harmful by experimental data.=20 Regards,=20 xing=20 =E4=BA=8E 2012/3/20 7:38, Alain Durand =E5=86=99=E9=81=93:=20 Dear wg, After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T & U ac= tually solve the stateless problem we started with. There are differences, but it is unclear if those differences are reall= y significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Ex= perimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U). Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to? If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track = document? If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational. If the answer is NO, we are left with E & T (U then might be abandoned or p= ublished as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)? If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E & T= as Experimental. In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other. Alain & Yong, wg co-chairs. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/list= info/softwires=20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Thu Mar 22 07:23:38 2012 Return-Path: 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 11B7221F864F for ; Thu, 22 Mar 2012 07:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.884 X-Spam-Level: X-Spam-Status: No, score=-9.884 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 oD5zxhjhDaFS for ; Thu, 22 Mar 2012 07:23:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6851E21F860B for ; Thu, 22 Mar 2012 07:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3998; q=dns/txt; s=iport; t=1332426211; x=1333635811; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=RtnNgjFnz9/qQ/r3/YjDZhueEvaMNG/q4KceHICsx4Q=; b=RCRai2QZIX8/wfHz4pZqyCR5y2HCfyiGnJJP9HaBFEhrekgOR/GYIcs/ RD8YuhKDkA0ZJrCHiIUVsBE7KVKkzXKhoXV6U7w66U26zdk9bAJiHgI8r 5NwdDNGIXMaVNSZoEs/gqfc39QFUbXV0hbBr2qDWf9lSyeXrsu5EPIqdt Q=; X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="68578599" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 22 Mar 2012 14:23:31 +0000 Received: from [64.102.209.118] (dhcp-64-102-209-118.cisco.com [64.102.209.118]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MENR7K018664; Thu, 22 Mar 2012 14:23:28 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 10:23:25 -0400 From: Rajiv Asati To: Alain Durand , Softwires WG Message-ID: Thread-Topic: [Softwires] Path to move forward with =?ISO-8859-1?B?NHJkig==?= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] =?iso-8859-1?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:23:38 -0000 I am disappointed with this approach. Despite the support, the WG adoption of MAP documents has been delayed for a "label" reason. I find it unfair since the label can be changed any time until the IESG review. How can it be a hold-up? One would have to wonder the intent of forming the design team at first place. It seems that we keep putting roadblocks on the path for the stateless solutions to get standardized. One after another. What's the purpose? =20 It seems that the work done by the design team, which was formed for a reason, is being ignored. If not, then their documents would have been the WG documents by now and the email would be referring to MAP (and not 4rd). This is a bit disrespectful. I would suggest to put all the documents developed by the MAP design team as "Standards" track document, and anything else is up for discussion. Cheers, Rajiv -----Original Message----- From: Alain Durand Date: Mon, 19 Mar 2012 16:38:42 -0700 To: Softwires WG Cc: Yong Cui , Ralph Droms Subject: [Softwires] Path to move forward with 4rd=8A >Dear wg, > >After a number of discussions with my co-chair, our AD and various >authors, here is how we would like to move forward wrt 4rd. > >1) There is an observation that all the solutions on the table E, T & U >actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are >really significant. E and T are the original Encapsulation and Translation > proposals, U is an hybrid unifying solution. > >2) We have already agreed back in Beijing that we would publish all >necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as >Experimental, Informational or Standard Track. > >We are at the point now where we need to make progress. In Paris, we >would like to ask for presentations from the proponents of each candidate >solution (E, T & U). >Each presentation should cover an overview of the proposed solution, >explain how it compares to the others and make a case as why it should be >the one on the Standard Track. We will allocate 20 minutes for each >presentation. > >Then, we, chairs, would like to ask a series of questions to the working >group. In order to make this process transparent, here is the list of >questions we want to ask >and their sequence. > >Q1: Without pre-supposing which one will be selected, do you agree to >publish 1 of the 3 proposals on the Standard Track and publish the >other(s) as Informational if still asked to? > >If the answer is NO, then the process stops and we will publish >everything as Experimental and come back in 12-24 months to see what gets >adopted by the market. >If the answer is YES, we move to the next question. > > >Q2: Do you believe that the WG should publish U as the one Standards >Track document? > >If the answer is YES, the process stop, we put U on the Standard Track >and publish E & T as Informational. >If the answer is NO, we are left with E & T (U then might be abandoned or >published as Historical/Informational) > > >Q3: Which of E and T do you want to see moving on the standard track (you >can only express support for one)? > >If there is a clear outcome from this question, we would publish that >proposal on the Standard Track and the other one as Informational. >If there is no clear consensus on this question, we will publish both E & >T as Experimental. > >In the meantime, we would like to encourage discussion on the mailing >list to foster our common understanding of the various technologies and >how they relate to each other. > > Alain & Yong, wg co-chairs. >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Mar 22 07:40:13 2012 Return-Path: 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 B9A9021F8589 for ; Thu, 22 Mar 2012 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-1.895, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 THM7gZaaSB+t for ; Thu, 22 Mar 2012 07:40:12 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEB421F8575 for ; Thu, 22 Mar 2012 07:40:12 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1546389qcs.31 for ; Thu, 22 Mar 2012 07:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z89312Hhdo5KqMki2IHiL/FDkqIml1kZNuJqBmlFVsA=; b=i2gviHkiC7SvMiuBBv+67HtPoYngQpnsDj/y1T2yfzbZDd1E+H/k08uYjM07Z0oCKM p9mkDqIS3JjJb+AnqeCr0Vel4NeDb7EHamD/I4NMTw4mSYzDEGGOKpn13CSajXfIfxyV yhdeYIaEBaVTfQzfzATGHNhaEmAxE0Fos4VYdE0GSVpvxZjJZRm+Ex0iFiOLLTi2SU3w F87wf85aTnvYwAaUF3k2YEoh+fBXetUVYUf8OdEReMhiX2P/AGrFpLsWmhfaeWmhdIW6 f5BmsmVIM6b6i0F/V+uxVYrr98E+cDQVQgyIEpE/2Vn4fEljJp2ExbsATIiDt95bCyC7 l3Nw== MIME-Version: 1.0 Received: by 10.224.59.204 with SMTP id m12mr11246052qah.37.1332427212017; Thu, 22 Mar 2012 07:40:12 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Thu, 22 Mar 2012 07:40:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 14:40:11 +0000 Message-ID: From: Maoke To: Alain Durand Content-Type: multipart/alternative; boundary=20cf3074d9b4a94ef304bbd5e2e4 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:40:13 -0000 --20cf3074d9b4a94ef304bbd5e2e4 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team? The MAP series have reached running codes and the collective understanding of the community. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects. (I have pointed out in the 4rd-u discussion thread). We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. best regards, Maoke =D4=DA 2012=C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand =D0=B4= =B5=C0=A3=BA > Dear wg, > > After a number of discussions with my co-chair, our AD and various > authors, here is how we would like to move forward wrt 4rd. > > 1) There is an observation that all the solutions on the table E, T & U > actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are > really significant. E and T are the original Encapsulation and Translatio= n > proposals, U is an hybrid unifying solution. > > 2) We have already agreed back in Beijing that we would publish all > necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as > Experimental, Informational or Standard Track. > > We are at the point now where we need to make progress. In Paris, we woul= d > like to ask for presentations from the proponents of each candidate > solution (E, T & U). > Each presentation should cover an overview of the proposed solution, > explain how it compares to the others and make a case as why it should be > the one on the Standard Track. We will allocate 20 minutes for each > presentation. > > Then, we, chairs, would like to ask a series of questions to the working > group. In order to make this process transparent, here is the list of > questions we want to ask > and their sequence. > > Q1: Without pre-supposing which one will be selected, do you agree to > publish 1 of the 3 proposals on the Standard Track and publish the other(= s) > as Informational if still asked to? > > If the answer is NO, then the process stops and we will publish everythin= g > as Experimental and come back in 12-24 months to see what gets adopted by > the market. > If the answer is YES, we move to the next question. > > > Q2: Do you believe that the WG should publish U as the one Standards Trac= k > document? > > If the answer is YES, the process stop, we put U on the Standard Track an= d > publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned or > published as Historical/Informational) > > > Q3: Which of E and T do you want to see moving on the standard track (you > can only express support for one)? > > If there is a clear outcome from this question, we would publish that > proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both E & > T as Experimental. > > In the meantime, we would like to encourage discussion on the mailing lis= t > to foster our common understanding of the various technologies and how th= ey > relate to each other. > > Alain & Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074d9b4a94ef304bbd5e2e4 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable dear Alain, Yong, Ralph and all,

in program, the effort = of the MAP team should be respected. The formation of the MAP team was also= the consensus of our meeting in beijing and we have seen the the team is w= orking with clear progress. I don't think it is correct now to insert 4= rd-u into a sort of exclusive decision of choice. And 4rd-u also has the ad= dress format elements abondoned by the MAP design team. I believe the MAP f= ormat reflects that the common understanding concludes the insignificance o= f those features. Sorry but the chair's questions  a little confus= ed me: if we need to go back to the stage before the works of the MAP desig= n team?  

The MAP series have reached running codes and the colle= ctive understanding of the community. From a view of a middle-sized ISP and= cloud service provider, we do support to accept MAP series into standard t= rack in order we can utilize it into business as soon as possible. 

in technology, first of all, MAP now has approached add= ress mapping algorithm and that enough to make the series a unified solutio= n. In our practice, we need to use either encapsulation or translation acco= rding to the actual needs and environment. The most important is, both the = building blocks of transition architecture: virtual link (supported by enca= psulation/tunneling) and participant of the delivery path (supported by tra= nslation), have their suitable use cases. And their advantages and limitati= ons have been well investigated and understood by the community. 

second, i deeply discussed and explored 4rd-u, but i fo= und its attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable to = define what building block it really is. It is stated as tunneling but actu= ally behaves like tunnel in some aspects while like translation in some oth= er aspects. (I have pointed out in the 4rd-u discussion thread). We see it = only a yet-another-translation that try to solve some corner problems but i= ntroduces new, possibly major flaws (also pointed out in the technical thre= ads on 4rd.) In either the term of architectural philosophy or technical de= tails, introducing 4rd-u into standards would be harmful. 

personally, i respect the exploration of the author(s),= and the discussion between me and the author encouraged me to comprehensiv= ely review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward. 

regarding the chair's questions, my answer is: = ;MAP, MAP-E/T, MAP-DHCP are of a who= le suite needing to be put into standard track. Question is not about T, E = or U. 

best regards,
Maoke

=D4=DA 2012= =C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand =D0=B4=B5=C0=A3= =BA
Dear wg,

After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T &= amp; U actually solve the stateless  problem we started with.
   There are differences, but it is unclear if those differences= are really significant. E and T are the original Encapsulation and Transla= tion
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' tho= se
   documents have at IETF. In particular, do we want to publish = them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U).
Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation.<= br>
Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to?

If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards Track = document?

If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)?

If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E &am= p; T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--20cf3074d9b4a94ef304bbd5e2e4-- From shuwang@cisco.com Thu Mar 22 09:08:03 2012 Return-Path: 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 7867721F8633 for ; Thu, 22 Mar 2012 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] 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 DWXSYLBQMhEy for ; Thu, 22 Mar 2012 09:08:02 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBD21F8630 for ; Thu, 22 Mar 2012 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shuwang@cisco.com; l=16860; q=dns/txt; s=iport; t=1332432480; x=1333642080; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=FbJVMngA/6q76He7iTJZ9kS/Xg1VOmnTdSY9p1TIxas=; b=YQVbii5M4TYWeQoVI2Ab8O+O+yA2x2cARk48vE2Yo5GKYqEFupBPg3DK 428/GKC7M8zuVekYIYx/nUGLecx+UYUR9AkfUN/os40121n5Hef+mXWhe AOpeIgDz47RSuBaq4JccLIPEp9g5Sczu4nueqso155CstVhW303Zvla8s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEACZNa09Io8UY/2dsb2JhbABEgkaCebMEggkBAQEEAQEBDwEJEQM+BgUQAgEGAhEBAwEBCwYXAQQCASYfAwMDCAEBBAESCAwHB4doC5lJjQIIkhoBAwaPRDdjBIhUm0uBaIJ0 X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="8430075" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 22 Mar 2012 16:07:58 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MG7wnQ017995; Thu, 22 Mar 2012 16:07:58 GMT Received: from xmb-hkg-417.apac.cisco.com ([64.104.123.89]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 00:07:57 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0845.F21BEA89" Date: Fri, 23 Mar 2012 00:07:55 +0800 Message-ID: <2A8093F1B7F25A4B80531FEB55B885D70282C9A9@xmb-hkg-417.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W1NvZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmShrQ==?= Thread-Index: Ac0IObaYqYRDdNhiQ962ljyTBKEBpgAAa59w References: From: "Shu Wang (shuwang)" To: "Maoke" , "Alain Durand" X-OriginalArrivalTime: 22 Mar 2012 16:07:57.0660 (UTC) FILETIME=[F26CE1C0:01CD0845] Cc: Softwires WG , Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] =?gb2312?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmQ=?= =?gb2312?b?oa0=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:08:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0845.F21BEA89 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Fully agree with Maoke. From operation point of view, 4rd-u has too many = issues.=20 =20 From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On = Behalf Of Maoke Sent: 2012=C4=EA3=D4=C222=C8=D5 22:40 To: Alain Durand Cc: Softwires WG; Yong Cui; Ralph Droms (rdroms) Subject: Re: [Softwires] Path to move forward with 4rd=A1=AD =20 dear Alain, Yong, Ralph and all, =20 in program, the effort of the MAP team should be respected. The = formation of the MAP team was also the consensus of our meeting in = beijing and we have seen the the team is working with clear progress. I = don't think it is correct now to insert 4rd-u into a sort of exclusive = decision of choice. And 4rd-u also has the address format elements = abondoned by the MAP design team. I believe the MAP format reflects that = the common understanding concludes the insignificance of those features. = Sorry but the chair's questions a little confused me: if we need to go = back to the stage before the works of the MAP design team? =20 =20 The MAP series have reached running codes and the collective = understanding of the community. From a view of a middle-sized ISP and = cloud service provider, we do support to accept MAP series into standard = track in order we can utilize it into business as soon as possible.=20 =20 in technology, first of all, MAP now has approached address mapping = algorithm and that enough to make the series a unified solution. In our = practice, we need to use either encapsulation or translation according = to the actual needs and environment. The most important is, both the = building blocks of transition architecture: virtual link (supported by = encapsulation/tunneling) and participant of the delivery path (supported = by translation), have their suitable use cases. And their advantages and = limitations have been well investigated and understood by the community. = =20 second, i deeply discussed and explored 4rd-u, but i found its = attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable = to define what building block it really is. It is stated as tunneling = but actually behaves like tunnel in some aspects while like translation = in some other aspects. (I have pointed out in the 4rd-u discussion = thread). We see it only a yet-another-translation that try to solve some = corner problems but introduces new, possibly major flaws (also pointed = out in the technical threads on 4rd.) In either the term of = architectural philosophy or technical details, introducing 4rd-u into = standards would be harmful.=20 =20 personally, i respect the exploration of the author(s), and the = discussion between me and the author encouraged me to comprehensively = review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward.=20 =20 regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP = are of a whole suite needing to be put into standard track. Question is = not about T, E or U.=20 =20 best regards, Maoke =D4=DA 2012=C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand = =D0=B4=B5=C0=A3=BA Dear wg, After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T & U = actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as = Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. Then, we, chairs, would like to ask a series of questions to the working = group. In order to make this process transparent, here is the list of = questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards = Track document? If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational. If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E = & T as Experimental. In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. Alain & Yong, wg co-chairs. _______________________________________________ Softwires mailing list Softwires@ietf.org =20 https://www.ietf.org/mailman/listinfo/softwires ------_=_NextPart_001_01CD0845.F21BEA89 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Fully agree with Maoke. From operation point of view, 4rd-u has too = many issues.

 

From:= = softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On = Behalf Of Maoke
Sent: 2012=C4=EA3=D4=C222=C8=D5 = 22:40
To: Alain Durand
Cc: Softwires WG; Yong Cui; = Ralph Droms (rdroms)
Subject: Re: [Softwires] Path to move = forward with 4rd=A1=AD

 

dear Alain, = Yong, Ralph and all,

 

in program, the effort of the MAP team should be = respected. The formation of the MAP team was also the consensus of our = meeting in beijing and we have seen the the team is working with clear = progress. I don't think it is correct now to insert 4rd-u into a sort of = exclusive decision of choice. And 4rd-u also has the address format = elements abondoned by the MAP design team. I believe the MAP format = reflects that the common understanding concludes the insignificance of = those features. Sorry but the chair's questions  a little confused = me: if we need to go back to the stage before the works of the MAP = design team?  

 

The MAP series have reached running codes and the = collective understanding of the community. From a view of a middle-sized = ISP and cloud service provider, we do support to accept MAP series into = standard track in order we can utilize it into business as soon as = possible. 

 

in technology, first of all, MAP now has approached = address mapping algorithm and that enough to make the series a unified = solution. In our practice, we need to use either encapsulation or = translation according to the actual needs and environment. The most = important is, both the building blocks of transition architecture: = virtual link (supported by encapsulation/tunneling) and participant of = the delivery path (supported by translation), have their suitable use = cases. And their advantages and limitations have been well investigated = and understood by the community. 

 

second, i deeply discussed and explored 4rd-u, but i = found its attempting of mixing the tunneling and translation, if = accepted as standard, may trap the operators into a harsh situation of = being unable to define what building block it really is. It is stated as = tunneling but actually behaves like tunnel in some aspects while like = translation in some other aspects. (I have pointed out in the 4rd-u = discussion thread). We see it only a yet-another-translation that try to = solve some corner problems but introduces new, possibly major flaws = (also pointed out in the technical threads on 4rd.) In either the term = of architectural philosophy or technical details, introducing 4rd-u into = standards would be harmful. 

 

personally, i respect the exploration of the = author(s), and the discussion between me and the author encouraged me to = comprehensively review E and T, and the result is: i bacame much more = confident of the correctness of the MAP track. We should move = forward. 

 

regarding the chair's questions, my answer = is: MAP, MAP-E/T, MAP-DHCP are of a = whole suite needing to be put into standard track. Question is not about = T, E or U. 

 

best regards,

Maoke


=D4=DA 2012=C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand =D0=B4=B5=C0=A3=BA

Dear wg,

After a number of discussions with my = co-chair, our AD and various authors, here is how we would like to move = forward wrt 4rd.

1) There  is an observation that all the = solutions on the table E, T & U actually solve the stateless =  problem we started with.
   There are differences, = but it is unclear if those differences are really significant. E and T = are the original Encapsulation and Translation
  =  proposals, U is an hybrid unifying solution.

2) We have = already agreed back in Beijing that we would publish all necessary = documents. The issue here is the 'label' or 'status' those
  =  documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track.

We are at the = point now where we need to make progress. In Paris, we would like to ask = for presentations from the proponents of each candidate solution (E, T = & U).
Each presentation should cover an overview of the proposed = solution, explain how it compares to the others and make a case as why = it should be the one on the Standard Track. We will allocate 20 minutes = for each presentation.

Then, we, chairs, would like to ask a = series of questions to the working group. In order to make this process = transparent, here is the list of questions we want to ask
and their = sequence.

Q1: Without pre-supposing which one will be selected, = do you agree to publish 1 of the 3 proposals on the Standard Track and = publish the other(s) as Informational if still asked to?

If the = answer is NO, then the process stops and we will publish everything as = Experimental and come back in 12-24 months to see what gets adopted by = the market.
If the answer is YES, we move to the next = question.


Q2: Do you believe that the WG should publish U as = the one Standards Track document?

If the answer is YES, the = process stop, we put U on the Standard Track and publish E & T as = Informational.
If the answer is NO, we are left with E & T (U = then might be abandoned or published as = Historical/Informational)


Q3: Which of E and T do you want to = see moving on the standard track (you can only express support for = one)?

If there is a clear outcome from this question, we would = publish that proposal on the Standard Track and the other one as = Informational.
If there is no clear consensus on this question, we = will publish both E & T as Experimental.

In the meantime, we = would like to encourage discussion on the mailing list to foster our = common understanding of the various technologies and how they relate to = each other.

 Alain & Yong, wg = co-chairs.
_______________________________________________
Softwire= s mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

------_=_NextPart_001_01CD0845.F21BEA89-- From xing@cernet.edu.cn Thu Mar 22 18:55:12 2012 Return-Path: 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 D275B21F8476 for ; Thu, 22 Mar 2012 18:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.263 X-Spam-Level: X-Spam-Status: No, score=-101.263 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 3uTlDtFw0jxP for ; Thu, 22 Mar 2012 18:55:12 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF121F8475 for ; Thu, 22 Mar 2012 18:55:10 -0700 (PDT) Received: from [127.0.0.1] (unknown [202.38.102.1]) by centos (Coremail) with SMTP id AQAAf3BrcQQy12tPfx4TAA--.4167S2; Fri, 23 Mar 2012 09:51:47 +0800 (CST) Message-ID: <4F6BD7ED.4020909@cernet.edu.cn> Date: Fri, 23 Mar 2012 09:54:53 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> In-Reply-To: <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> Content-Type: multipart/alternative; boundary="------------020709070901020705080100" X-CM-TRANSID: AQAAf3BrcQQy12tPfx4TAA--.4167S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAry8GF1ktF4DZr17ZryUtrb_yoW5WFW8pF sxGFs7Ja9rJF1IyrZ7uw42gw1rAFWkK3y5Jw17t3Z0yws8CF9Fyr4j9Fyak348Ar1kJ3Wj qrWjkFn8Wan5AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUy0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2 jsIE14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzx vE52x082IY62kv0487Mc02F40E57IF67AEF4xIwI1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4l Yx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCjr7 xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCY02Avz4vE14v_KwCF04k2 0xvY0x0EwIxGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI 8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWU CwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJV WrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1U YxBIdaVFxhVjvjDU0xZFpf9x07j8nYwUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:55:12 -0000 This is a multi-part message in MIME format. --------------020709070901020705080100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Remi, 于 2012/3/19 21:22, Rémi Després 写é“: > Hi, Xing, > > I look forward to face to face discussions in Paris if we don't > clarify everything before that (I will be busy on something else in > the next 3 days). > > > Le 2012-03-18 à 23:39, Xing Li a écrit : > ... >>> >>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE >>> node, when it receives no 4rd mapping rule, to exercise single >>> translation. >>> Actually, I believe that using for this the BIH of RFC6535 is both >>> sufficient and recommendable. >>> Translated IPv4 packets, because they are sent from CE nodes to >>> DNS64 synthesized addresses, are appropriately routed to their >>> destinations. (It can be via the NAT64-CGN if needed, or via more >>> direct paths if possible.) >>> Anything missed? >> >> Sorry, this is a misunderstanding. >> Hint: Single translation and double translation are based on the same >> mapping rule in the CERNET2 deployment. > > I am well aware of this, but this doesn't explain why 4rd mapping > rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to > IPv6 communication (single translation) supported". > > As said in RFC6219, CERNET hosts have their IPv6 addresses configured > "via manual configuration or stateful autoconfiguration via DHCPv6". > Hosts can therefore be assigned Interface IDs that have the 4rd-u > format (with V octet and CNP). > > Now, when both addresses happen to be checksum neutral, RFC6145 > translation doesn't modify L4 data, so that it doesn't matter whether > the DS node has used 4rd-u header mapping or single translation. > Thus, IPv6-only hosts can exchange packets with IPv4 applications of > 4rd CE nodes. Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host. Regards, xing > > Regards, > RD > > > > > > > >> Regards, >> >> xing >> >> >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> >>>> Regards, >>>> >>>> xing >>>> >>>> >>>>> >>>>> Regards, >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> Le 2012-02-10 à 04:28, Xing Li a écrit : >>>>> ...| | | | | >>>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | >>>>>>>> | | packets | | | | | >>>>>>> suggest you rename to "IPv4 to IPv6 communication (single translation) supported" >>>>>>> >>>>>> >>>>>> (2) More clarification should be added here. I am not sure 4rd-H >>>>>> can support single translation. >>>>>> >>>>>> (a) According to (1), 4rd-H does not perform header translation >>>>>> defined by RFC6145. >>>>>> >>>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot >>>>>> support single translation. See the thread containing >>>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html >>>>>> and other posts. >>>>>> >>>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web >>>>>> caches work for IPv4 packets" requires special configurations, it >>>>>> cannot do IPv6 web caches for non 4rd-H packets. >>>>> >>>>> ... >>>>> >>>>>> (5) I would like to see the details of how 4rd-H handles ICMP and >>>>>> ICMP error messages. In the softwire mailing list there were some >>>>>> discussions. See the thread containing >>>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html >>>>>> and other posts.Please add >>>>>> >>>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>>> ... >>>>> >>>> >>> >> >> > --------------020709070901020705080100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Remi,

于 2012/3/19 21:22, Rémi Després 写é“:
Hi, Xing,

I look forward to face to face discussions in Paris if we don't clarify everything before that (I will be busy on something else in the next 3 days).


Le 2012-03-18 à 23:39, Xing Li a écrit :
...

 A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, to exercise single translation. 
 Actually, I believe that using for this the BIH of RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

I am well aware of this, but this doesn't explain why 4rd mapping rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication (single translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 addresses configured "via manual configuration or stateful autoconfiguration via DHCPv6".
Hosts can therefore be assigned Interface IDs that have the 4rd-u format (with V octet and CNP).

Now, when both addresses happen to be checksum neutral, RFC6145 translation doesn't modify L4 data, so that it doesn't matter whether the DS node has used 4rd-u header mapping or single translation. 
Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd CE nodes.

Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host.

Regards,

xing


Regards,
RD







Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 à 04:28, Xing Li a écrit :
... | | | | |
  |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |
...







--------------020709070901020705080100-- From washam.fan@gmail.com Thu Mar 22 19:08:41 2012 Return-Path: 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 09D7021E804C for ; Thu, 22 Mar 2012 19:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KGFp1eJ4ulgz for ; Thu, 22 Mar 2012 19:08:40 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 337A221E803D for ; Thu, 22 Mar 2012 19:08:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1251020wgb.13 for ; Thu, 22 Mar 2012 19:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GQH+0LOlRNHTAfFnKdKc0UuoGj4PxB4cS14MjOyD7Q4=; b=xyS1LltEI5a+fsJRs0fKqFfzlMX7w3Y4cuOoYQCHFyrDnAthXTkZ/uVb3z4WdUJ1Rt ZL8Ma0DV7u2Glv1NoQXhsX3GTpMmcC/6zllyjMuvey8rDb6pd9hYCwKr4MmycQw3SfSf aWmHxNlhQ8k+d9JftP8Z8xtJbf7TPJTUkkOv6GSy8H/8cCfzgwN/FvX50zzwS7oae5pF bZla1Vl73PmuIKrZJdft3bBJZWHvKHk0vF31vVPhHWs3ci1NdzDZ7wGimyQ12ZU38ZVO rAEsZVBVOncnVtg1o6bKgjbY+27lX2ep/sfZyAYRNqSF6pdq/8FkARAnDTRV2oEsEOcb tJug== MIME-Version: 1.0 Received: by 10.216.150.148 with SMTP id z20mr6187439wej.22.1332468519135; Thu, 22 Mar 2012 19:08:39 -0700 (PDT) Received: by 10.216.205.169 with HTTP; Thu, 22 Mar 2012 19:08:39 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Mar 2012 10:08:39 +0800 Message-ID: From: Washam Fan To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 02:08:41 -0000 There is no text saying 4rd-u BRs are anycasted to IPv4 network in the first place. Remi, could you clarify on this? Thanks, washam 2012/3/22 GangChen : > Dear Med, > > Yes. There are no texts targeting to this topics. > I mean we could leverage the consideration in 4rd-U to build a entry > table. One more REDIRECTION action obviously should be added to the > row of "RESULTING ACTIONS". Any received fragment looking for > conditions and execute a proper action(forwarding or redirection) > > BRs > > Gang > > 2012/3/22, mohamed.boucadair@orange.com : >> Dear Gang, >> >> Thanks, but I failed to find the text describing how to handle two fragm= ents >> received by two distinct BRs. >> >> Could you please point me to that text in case I miss it? >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : GangChen [mailto:phdgang@gmail.com] >>>Envoy=E9 : jeudi 22 mars 2012 08:33 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : Washam Fan; Softwires >>>Objet : Re: [Softwires] Fragmentation in sdnat-02 >>> >>>2012/3/21, mohamed.boucadair@orange.com : >>>> Dear Washam, >>>> >>>> This is an issue common to all stateless solutions, >>>including deterministic >>>> NAT with (anaycast) IPv4 address pool. >>>> >>>> FWIW, we recorded this issue here: >>>> http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>>> >>>> As a solution to this issue, we proposed to implement the >>>> fragmentation-related function in one single node: any >>>received fragment is >>>> redirected to a dedicated node which will be responsible for >>>reassembly or >>>> forward the fragment to the appropriate CPE. This node must dedicate >>>> resources to handle out of order fragments. >>> >>>FYI, I see another approach doing that with a entry table + >>>redirection action, similarly like >>>http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >>>ion-4.5.2. >>> >>>BRs >>> >>>Gang >>> >>>> Saying that, I can not quantify the severity of this issue in all >>>> operational networks. >>>> >>>> Cheers, >>>> Med >>>> >>>>>-----Message d'origine----- >>>>>De : softwires-bounces@ietf.org >>>>>[mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>>>Envoy=E9 : mercredi 21 mars 2012 07:25 >>>>>=C0 : Softwires >>>>>Objet : [Softwires] Fragmentation in sdnat-02 >>>>> >>>>>Hi Authors, >>>>> >>>>>In section 3.2, it states IPv4 address pool should be anycasted. This >>>>>introduces a risk where different incoming fragments go to different >>>>>AFTRs. Because one IPv4 address is shared between multiple >>>>>subscribers, reassemly is needed on AFTRs when receiving >>>fragments. If >>>>>different fragments go thru different =A0AFTRs, the reassmely process >>>>>would fail and incur DoS. >>>>> >>>>>Thanks, >>>>>washam >>>>>_______________________________________________ >>>>>Softwires mailing list >>>>>Softwires@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> From yiu_lee@cable.comcast.com Thu Mar 22 19:10:14 2012 Return-Path: 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 D323D21F8476 for ; Thu, 22 Mar 2012 19:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.229 X-Spam-Level: X-Spam-Status: No, score=-100.229 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 E+f0SWlpf7Mf for ; Thu, 22 Mar 2012 19:10:14 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0354021F8475 for ; Thu, 22 Mar 2012 19:10:13 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6935812; Thu, 22 Mar 2012 22:04:16 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 22:10:11 -0400 From: "Lee, Yiu" To: Guanghui Yu , Softwires WG Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=8A?= Thread-Index: AQHNCJoSj1sWNClPI0mmt+NUCmQE0g== Date: Fri, 23 Mar 2012 02:10:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415299008_1008498" MIME-Version: 1.0 Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 02:10:14 -0000 --B_3415299008_1008498 Content-type: multipart/alternative; boundary="B_3415299007_1012021" --B_3415299007_1012021 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Guanghui, I agree that both MAP and 4rd-u are similar technology and solving the same problem. From technical perspective, can you elaborate this a lithe bit? Thanks, Yiu From: Guanghui Yu Date: Thu, 22 Mar 2012 20:26:40 +0800 To: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd=8A I read 4rd-u draft and found it is flawed. --B_3415299007_1012021 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Guanghui,

<= /div>
I agree that both MAP and 4rd-u are similar technology and solving= the same problem. From technical perspective, can you elaborate this a= lithe bit? 

Thanks,
Yiu
<= br>
From: Guanghui Yu <yu.guanghui@gmail.com>
Date: Thu, 22 Mar 2012 20:26:40 +0800
To: Softwires WG <softwires@ietf.org>
Subj= ect: Re: [Softwires] Path to move forward with 4rd…
<= div>
I read 4rd-u draft and found it= is flawed. --B_3415299007_1012021-- --B_3415299008_1008498 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRhYfrc KiYwMFYR8Wq0KY9RtFCCrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMwMjEwMDdaMA0GCSqGSIb3DQEBAQUABIIBANE0OIRnC44y26EIRByhOlUG 8KpsciQzCeUum3WNag1EpjGFd2RXlLiYCSa9UkPHWUGnZ4w/WUP/x+dZd9kB/W60eU0V0f+B FcOVAfVuUzylX0ZPvQgq9xbsgDbyALJTyrACcX2+eshZgO3SH++HqvomKi/2XUEXDrEpfr+V o808a3FKA3r96sAuc0hQduNKmMHsYmJHOsrU/N/INkAaXmYZ5wIV+SOdcrX3lfRAC5moq0Ws D3tOBdWZKf/JEJDtE8ODsLmvTdjlDlaCUQdkVc5nl9paUN79IhUWIjlV1kJeldnsdmfkhMGC tB0Vee4ncMfnjvPEtRwZZyuFWeqoXik= --B_3415299008_1008498-- From yiu_lee@cable.comcast.com Thu Mar 22 19:29:31 2012 Return-Path: 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 3ACB521E8013 for ; Thu, 22 Mar 2012 19:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] 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 poS6ywga-86U for ; Thu, 22 Mar 2012 19:29:30 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBD21F8471 for ; Thu, 22 Mar 2012 19:29:30 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.10583643; Thu, 22 Mar 2012 20:17:27 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 22:29:26 -0400 From: "Lee, Yiu" To: Stig Venaas Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt Thread-Index: AQHNCJzEWSrNrUhoK0e0ytmpOiE94g== Date: Fri, 23 Mar 2012 02:29:26 +0000 Message-ID: In-Reply-To: <4F68ECD7.6030207@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415300166_1051975" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 02:29:31 -0000 --B_3415300166_1051975 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Stig, DS-Lite was designed to deliver v4 unicast packets over v6-only network to v4 host. However when we started thinking about how to deliver multicast packets in the same network setup, we will have to tunnel all multicast packets over tunnels. This is very inefficient to use of AFTR. This is the motivation of dslite-multicast draft. However, you are absolutely right. This is a solution for tunneling IPv4 multicast through an IPv6-only network. B.R., Yiu On 3/20/12 4:47 PM, "Stig Venaas" wrote: >I'm a little bit puzzled by how this document talks about DS-Lite. >Isn't this an entirely generic solution for tunneling IPv4 multicast >through an IPv6-only network? > >Stig >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3415300166_1051975 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRcMTCJ Mo3vYQ5L5vNzT1TVR0Q0fjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMwMjI5MjVaMA0GCSqGSIb3DQEBAQUABIIBAFdTmraFOYUegwmaa2neOKQZ 5dbc+PyVFWYi7J2/wY30Bt3DD5BfNZcxyAyDV08CkOap7OEzWxd6x0ZLnBHtVDU+a6QK97yQ j0x2DBQaiwHYrxF86r2VCWx9gC5/Xt/0mtKGv1gjl2yrKI5A8H9z3Tkns2OQBd2ynaZviN/A /VqIrU4tlyXGgijw83qBaQBVhqPXOkZaqUYTrAqUQV/vbyHSruH2yFF0yHxvhCM3Tnr9JoiE Xc9dB3wnPhwB4m6z+MIY901nFASywp5M5nBRSDwceQn9JZryNi6RKDdFzdQWZfFq1uXrG5Oh pT0939GV8Wn4l8U9cMUR7jEkrcGelp4= --B_3415300166_1051975-- From yiu_lee@cable.comcast.com Thu Mar 22 19:32:00 2012 Return-Path: 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 5638121F84A2 for ; Thu, 22 Mar 2012 19:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.03 X-Spam-Level: X-Spam-Status: No, score=-101.03 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 Vf8v+o7aSvth for ; Thu, 22 Mar 2012 19:31:59 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 83DE521E8048 for ; Thu, 22 Mar 2012 19:31:59 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6936701; Thu, 22 Mar 2012 22:26:02 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 22:31:56 -0400 From: "Lee, Yiu" To: Stig Venaas Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt Thread-Index: AQHNCJ0cSPZSQqlSg06I/DLPiaghsw== Date: Fri, 23 Mar 2012 02:31:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415300313_1093493" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 02:32:00 -0000 --B_3415300313_1093493 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit One more note. When we developed this draft, we focused on access network delivery. There is a mesh-multicast draft which also solve the same problem (i.e. Tunneling v4 mcast through v6-only network) in the core network. On 3/22/12 10:29 PM, "Lee, Yiu" wrote: >Hi Stig, > >DS-Lite was designed to deliver v4 unicast packets over v6-only network to >v4 host. However when we started thinking about how to deliver multicast >packets in the same network setup, we will have to tunnel all multicast >packets over tunnels. This is very inefficient to use of AFTR. This is the >motivation of dslite-multicast draft. However, you are absolutely right. >This is a solution for tunneling IPv4 multicast through an IPv6-only >network. > >B.R., >Yiu > >On 3/20/12 4:47 PM, "Stig Venaas" wrote: > >>I'm a little bit puzzled by how this document talks about DS-Lite. >>Isn't this an entirely generic solution for tunneling IPv4 multicast >>through an IPv6-only network? >> >>Stig >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3415300313_1093493 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQ5i2wl cfDVKXVrlI2hwZm4tyM3HjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMwMjMxNTJaMA0GCSqGSIb3DQEBAQUABIIBAF8oXD7R3qSs3p6iTLRbpV8L hWM6wjGQZ3YBQkuGv3fI0VWz6SwOsY4EX9KiFoOZwMn6mLeM1+LEbQcQc0Bq4JYLqRmzaH8I 8ddsHgVz/tuubZoSzyR1D/Ex4fu+6uoX53UFFjRKC6lKNiKqtf+rcRakMfnuTX9iXOdD51Vr BWKmF72HbiReargTPKfYkKAKTE/fafE8obbVdfdW7g0+7htbiTKU468Yc0774OW6SeEaypHr 4OZCi88YJrvh0J4Wi6oopHvuoorH7W7LePFYgZBvx+S/K+m3T04FNO1FAmjh7umBRZMGoEPX iyYvL1pz+9+xO0HULV7dcW2x2yeJ3rA= --B_3415300313_1093493-- From yu.guanghui@gmail.com Thu Mar 22 20:04:59 2012 Return-Path: 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 92A0321F848C for ; Thu, 22 Mar 2012 20:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 v14k9q3sXUr3 for ; Thu, 22 Mar 2012 20:04:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD55121F8495 for ; Thu, 22 Mar 2012 20:04:55 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2584538bku.31 for ; Thu, 22 Mar 2012 20:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxWNq3pz0yKh1b6/XxsoOGb65uNu9ZMa74BEyLhDsNQ=; b=VECRoRMJPQfpl3hSLn+Ya8i4c7shujzpRUOM7ritZYbAcQOiiEyQd8LV4wYJ6ByJdb v06pLeS9ZmkGy36UFyoqFigdyy8aAPDmwvompYsuNtcsYSJHQ7O2/ioi9TtFYvQ4VKUh LCgH2zNRvVF0731g5AvdBmatMEO9aslitYSrvgOFfW70bwN1jiT/tVDB85WSwcz34cVf Yes7+myLDFUIl66EgVWPPJoizHtyf9Qp+vZ+Xpcp/7Caum8kitr69zC+wvOrnJHBEEAZ oBd0KSyiHGlvcNBHU+ncnmvVJ2KpbwKzlYICBHolhhxvBP+/KDIo4tXkIRUQCssc62Lz YOJQ== MIME-Version: 1.0 Received: by 10.204.143.138 with SMTP id v10mr3805702bku.99.1332471894347; Thu, 22 Mar 2012 20:04:54 -0700 (PDT) Received: by 10.204.184.145 with HTTP; Thu, 22 Mar 2012 20:04:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 11:04:54 +0800 Message-ID: From: Guanghui Yu To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=0015175cd0f2ef91ad04bbe049ac Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 03:04:59 -0000 --0015175cd0f2ef91ad04bbe049ac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) and IPv6 address architecture (different meaning of u-bit when g-bit=3D1). These are the fundamental changes. If 4rd= -u becomes the standard, then there will be new defined =93IPv6=94 packets on the Internet, which are not compatible with existing IPv6 packets and no existing devices can understand those packets. Yu Guanghui Network and Information Center Dalian University of Technology, China On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu wrote= : > Hi Guanghui, > > I agree that both MAP and 4rd-u are similar technology and solving the > same problem. From technical perspective, can you elaborate this a lithe > bit? > > Thanks, > Yiu > > From: Guanghui Yu > Date: Thu, 22 Mar 2012 20:26:40 +0800 > To: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd=85 > > I read 4rd-u draft and found it is flawed. > --0015175cd0f2ef91ad04bbe049ac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Yiu

=A0 =A04rd-u changes the IPv6 header a= rchitecture (redefine fragmentation=A0header extension) and IPv6 address ar= chitecture (different meaning of=A0u-bit when g-bit=3D1). These are the fun= damental changes. If 4rd-u becomes=A0the standard, then there will be new d= efined =93IPv6=94 packets on the=A0Internet, which are not compatible with = existing IPv6 packets and no=A0existing devices can understand those packet= s.
=A0 =A0

Yu Guanghui <ygh at dlut.edu.cn>
Network and Information Center
Dalian University of Technology, China


On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com>= wrote:
Hi Guanghui,

I agree that both MAP and= 4rd-u are similar technology and solving the same problem.=A0From technica= l perspective, can you elaborate this a lithe bit?=A0

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Thu, 22 Mar 2012 20:26:= 40 +0800
To: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to mov= e forward with 4rd=85

I read 4rd-u = draft and found it is flawed.

--0015175cd0f2ef91ad04bbe049ac-- From yiu_lee@cable.comcast.com Thu Mar 22 21:55:19 2012 Return-Path: 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 22F9921E803C for ; Thu, 22 Mar 2012 21:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.179 X-Spam-Level: X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 X9TrG6e+lBD1 for ; Thu, 22 Mar 2012 21:55:17 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABEC21E8013 for ; Thu, 22 Mar 2012 21:55:16 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6940920; Fri, 23 Mar 2012 00:49:18 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 00:55:11 -0400 From: "Lee, Yiu" To: Guanghui Yu Thread-Topic: =?windows-1250?Q?[Softwires]_Path_to_move_forward_with_4rd=8A?= Thread-Index: AQHNCLEgLze7Z7XapECchGi4YJplpA== Date: Fri, 23 Mar 2012 04:55:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415308909_1583321" MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] =?windows-1250?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 04:55:19 -0000 --B_3415308909_1583321 Content-type: multipart/alternative; boundary="B_3415308898_1606884" --B_3415308898_1606884 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Hi Guanghui, I have to admit that I am not IPv6 protocol expert. I guess Remi took the fragmentation header and overload it for his design. Say he defines a new extension called "transition" extension, I would guess it would no longer overload the fragmentation extension. I don't know enough the current implementation of the FIB and how in 4rd-u design would impact the implementation. I have homework to do. Apart from that, I found MAP and 4rd-u are similar technologies trying to solve the same problem. So far I follow all the discussions in the mailing list about this topics. Technically speaking, they have pros and cons. I fail to see one is absolutely superior than the other. Both designs make trade-offs. =20 =20 When we come to WG adoption, I am completely fine if the WG decides one ove= r the other. That said, the current discussion reminds me about OSPF vs IS-IS= . They are so similar but yet have subtle differences. Today, both protocols are running in production. Best case scenario is the authors can balance th= e trade-offs and merge two drafts. If not WG could potentially publish both techs (e.g. one standard track and one informational/experimental) and let the market force to decide. B.R., Yiu P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series. From: Guanghui Yu Date: Fri, 23 Mar 2012 11:04:54 +0800 To: "Yiu L. LEE" Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd=A9 Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation heade= r extension) and IPv6 address architecture (different meaning of u-bit when g-bit=3D1). These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined "IPv6" packets on the Internet, which are no= t compatible with existing IPv6 packets and no existing devices can understan= d those packets. =20 Yu Guanghui > Network and Information Center Dalian University of Technology, China On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu wrote: > Hi Guanghui, >=20 > I agree that both MAP and 4rd-u are similar technology and solving the sa= me > problem. From technical perspective, can you elaborate this a lithe bit? >=20 > Thanks, > Yiu >=20 > From: Guanghui Yu > Date: Thu, 22 Mar 2012 20:26:40 +0800 > To: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd... >=20 > I read 4rd-u draft and found it is flawed. --B_3415308898_1606884 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable
Hi Guanghui,

<= /div>
I have to admit that I am not IPv6 protocol expert. I guess Remi t= ook the fragmentation header and overload it  for his design. Say he de= fines a new extension called "transition" extension, I would guess it would = no longer overload the fragmentation extension. I don't know enough the curr= ent implementation of the FIB and how <u,g> in 4rd-u design would impa= ct the implementation. I have homework to do.

Apart= from that, I found MAP and 4rd-u are similar technologies trying to solve t= he same problem. So far I follow all the discussions in the mailing lis= t about this topics. Technically speaking, they have pros and cons. I f= ail to see one is absolutely superior than the other. Both designs make trad= e-offs.  
 
When we come to WG adoption, I am = completely fine if the WG decides one over the other. That said, the current= discussion reminds me about OSPF vs IS-IS. They are so similar but yet have= subtle differences. Today, both protocols are running in production. Best c= ase scenario is the authors can balance the trade-offs and merge two drafts.= If not WG could potentially publish both techs (e.g. one standard track and= one informational/experimental) and let the market force to decide.

B.R.,
Yiu

P.S. When I s= ay MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series.
=


From: Guan= ghui Yu <yu.guanghui@gmail.com= >
Date: Fri, 23 Mar 2012 11:04:= 54 +0800
To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
= Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd=A9

Hi Yiu

   4rd-u chang= es the IPv6 header architecture (redefine fragmentation header extensio= n) and IPv6 address architecture (different meaning of u-bit when g-bit= =3D1). These are the fundamental changes. If 4rd-u becomes the standard, = then there will be new defined “IPv6” packets on the Intern= et, which are not compatible with existing IPv6 packets and no existing= devices can understand those packets.
   

Yu Guanghui <ygh at dlut.edu.cn>
Network and Information Center<= /div>
Dalian University of Technology, China


On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrot= e:
Hi Guanghui,

I agree that both MAP and 4rd-u are similar technology and solving the sa= me problem. From technical perspective, can you elaborate this a lithe = bit? 

Thanks,
Yiu

--B_3415308898_1606884-- --B_3415308909_1583321 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQhFUog a+k20HqU96pey+J8iCePWzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMwNDU0NThaMA0GCSqGSIb3DQEBAQUABIIBAL6dRBYGKItPaDIWwhV8G5eo DtPcL59CQHqw4m1GC/LUpigoCUVcr1Pj8ZAExOebrHrpfRodfDQiFHcAUt+CUgm/3VOlaQyS oi+KkS+LHaU81wa9oMmRQY8aG0yM0GL+uwfLYSHqrziWyk9ON1AER/mXTEK0DXrAsKHqiTHa pSTW0ugArdSs1WQPZv4l4Cu9+eADOcSMuzHj0rJ+KfAPjVlPzhBLy5SbYerlEVARioPLbDJR 06mxdPUAjgh6jDSi2emmozq2j5dKIQdRF5eZ2lVs08cmk164bYfv2wFpL9wXn0WyezmKE74g 4+JiDoMzsWU9W0PqPN82Z7IWFikdBAs= --B_3415308909_1583321-- From yu.guanghui@gmail.com Thu Mar 22 22:43:10 2012 Return-Path: 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 A2AF021E8039 for ; Thu, 22 Mar 2012 22:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 JAz0gKgDsarl for ; Thu, 22 Mar 2012 22:43:09 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAA7821E8013 for ; Thu, 22 Mar 2012 22:43:08 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2646428bku.31 for ; Thu, 22 Mar 2012 22:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/vZQrRPV/5g0HzSzcRLlI3tD16J8mPb7277UUd8buvM=; b=s1JMa+VaqOEGgkTEdj2M5xxZ4dDONoS9OmTp/z0yoZqQNvtjaaUC82tjRFd1557fy9 tBmNq9WgWWGBdZ2apx1cpcwmW+n+EqE0RAit1ftjxU/s4uqGFJT+lfeVyp9X4Md5iRW8 I2s5CzZWX7U07l1yhFhnvA5GpSLurm3cY253PtVChAts9QVglSVPtNdaZRF7iBNm8r5x Hn6kHvfoeP5zwsOHGus4O7fUfHmQ8qcshupQ1TFEt4R/6P518e4RJsLmcpeaa74SjZdT KhUQucC4oZRmX77WB7z3K7xbAgrDSkzk2kJsj35myIs4QKbsmWaiBx8KYGBjbd6cmVr/ zfYA== MIME-Version: 1.0 Received: by 10.204.149.204 with SMTP id u12mr1809375bkv.45.1332481387544; Thu, 22 Mar 2012 22:43:07 -0700 (PDT) Received: by 10.204.184.145 with HTTP; Thu, 22 Mar 2012 22:43:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 13:43:07 +0800 Message-ID: From: Guanghui Yu To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=0015175dd944c63fa004bbe27fe5 Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:43:10 -0000 --0015175dd944c63fa004bbe27fe5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all To define the "transtion" extension has the same problem, it still is a "new" packet for existing devices. 4rd-U cannot replace MAP-T, since it cannot support single translation. 4rd-U cannot replace MAP-E, since it cannot support IPv4 option. Therefore, it is no way for 4rd-U to replace MAP series. BTW, we need both encapsulation and translation, i.e. MAP-E and MAP-T. On Fri, Mar 23, 2012 at 12:55 PM, Lee, Yiu wrote= : > Hi Guanghui, > > I have to admit that I am not IPv6 protocol expert. I guess Remi took the > fragmentation header and overload it for his design. Say he defines a ne= w > extension called "transition" extension, I would guess it would no longer > overload the fragmentation extension. I don't know enough the current > implementation of the FIB and how in 4rd-u design would impact the > implementation. I have homework to do. > > Apart from that, I found MAP and 4rd-u are similar technologies trying to > solve the same problem. So far I follow all the discussions in the mailin= g > list about this topics. Technically speaking, they have pros and cons. I > fail to see one is absolutely superior than the other. Both designs make > trade-offs. > > When we come to WG adoption, I am completely fine if the WG decides one > over the other. That said, the current discussion reminds me about OSPF v= s > IS-IS. They are so similar but yet have subtle differences. Today, both > protocols are running in production. Best case scenario is the authors ca= n > balance the trade-offs and merge two drafts. If not WG could potentially > publish both techs (e.g. one standard track and one > informational/experimental) and let the market force to decide. > > B.R., > Yiu > > P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one > complete series. > > > From: Guanghui Yu > Date: Fri, 23 Mar 2012 11:04:54 +0800 > To: "Yiu L. LEE" > Cc: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 > > Hi Yiu > > 4rd-u changes the IPv6 header architecture (redefine > fragmentation header extension) and IPv6 address architecture (different > meaning of u-bit when g-bit=3D1). These are the fundamental changes. If 4= rd-u > becomes the standard, then there will be new defined =E2=80=9CIPv6=E2=80= =9D packets on > the Internet, which are not compatible with existing IPv6 packets and > no existing devices can understand those packets. > > > Yu Guanghui > Network and Information Center > Dalian University of Technology, China > > > On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu wro= te: > >> Hi Guanghui, >> >> I agree that both MAP and 4rd-u are similar technology and solving the >> same problem. From technical perspective, can you elaborate this a lithe >> bit? >> >> Thanks, >> Yiu >> >> From: Guanghui Yu >> Date: Thu, 22 Mar 2012 20:26:40 +0800 >> To: Softwires WG >> Subject: Re: [Softwires] Path to move forward with 4rd=E2=80=A6 >> >> I read 4rd-u draft and found it is flawed. >> > > --=20 Yu Guanghui Network and Information Center Dalian University of Technology, China --0015175dd944c63fa004bbe27fe5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To define the "transtion"= ; extension has the same problem,=C2=A0 it still is a "new" packe= t for existing devices.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4rd-U cannot repl= ace MAP-T, since it cannot support single translation. 4rd-U cannot replace= MAP-E, since it cannot support IPv4 option. Therefore, it is no way for 4r= d-U to replace MAP series. BTW, we need both encapsulation and translation,= i.e. MAP-E and MAP-T.

On Fri, Mar 23, 2012 at 12:55 PM, Lee, Yiu <= span dir=3D"ltr"><Yiu_Lee@c= able.comcast.com> wrote:
Hi Guanghui,

I have to admit that I am= not IPv6 protocol expert. I guess Remi took the fragmentation header and o= verload it =C2=A0for his design. Say he defines a new extension called &quo= t;transition" extension, I would guess it would no longer overload the= fragmentation extension. I don't know enough the current implementatio= n of the FIB and how <u,g> in 4rd-u design would impact the implement= ation. I have homework to do.

Apart from that, I found MAP and 4rd-u are similar tech= nologies trying to solve the same problem.=C2=A0So far I follow all the dis= cussions in the mailing list about this topics. Technically speaking,=C2=A0= they have pros and cons. I fail to see one is absolutely superior than the = other. Both designs make trade-offs. =C2=A0
=C2=A0
When we come to WG adoption, I am completely fine if = the WG decides one over the other. That said, the current discussion remind= s me about OSPF vs IS-IS. They are so similar but yet have subtle differenc= es. Today, both protocols are running in production. Best case scenario is = the authors can balance the trade-offs and merge two drafts. If not WG coul= d potentially publish both techs (e.g. one standard track and one informati= onal/experimental) and let the market force to decide.

B.R.,
Yiu

P.S. When = I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series.


From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Fri, 23 Mar 2012 11:04:= 54 +0800
To: "Yiu L. LEE" <yiu_lee@cable.c= omcast.com>
Cc: Softwire= s WG <softwires@= ietf.org>
Subject: Re: [Softwires] Path to m= ove forward with 4rd=C5=A0

<= div>Hi Yiu

=C2=A0 =C2=A04rd-u changes the IPv6 hea= der architecture (redefine fragmentation=C2=A0header extension) and IPv6 ad= dress architecture (different meaning of=C2=A0u-bit when g-bit=3D1). These = are the fundamental changes. If 4rd-u becomes=C2=A0the standard, then there= will be new defined =E2=80=9CIPv6=E2=80=9D packets on the=C2=A0Internet, w= hich are not compatible with existing IPv6 packets and no=C2=A0existing dev= ices can understand those packets.
=C2=A0 =C2=A0

Yu Guanghui <ygh at dlut.edu.cn>
Network an= d Information Center
Dalian University of Technology, China
=


On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <Yiu_Lee@cable.comcast.= com> wrote:
Hi Guanghui,

I agree that both MAP and= 4rd-u are similar technology and solving the same problem.=C2=A0From techn= ical perspective, can you elaborate this a lithe bit?=C2=A0

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Thu, 22 Mar 2012 20:26:= 40 +0800
To: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to mov= e forward with 4rd=E2=80=A6

I read 4rd-u = draft and found it is flawed.




--
Yu Guanghui <yg= h at dlut.edu.cn>
Network and Information Center
Dalian University of Tech= nology, China


--0015175dd944c63fa004bbe27fe5-- From james@ustc.edu.cn Thu Mar 22 23:06:56 2012 Return-Path: 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 8C49621E8042 for ; Thu, 22 Mar 2012 23:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.302 X-Spam-Level: *** X-Spam-Status: No, score=3.302 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 XZGacqw0+KVr for ; Thu, 22 Mar 2012 23:06:56 -0700 (PDT) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by ietfa.amsl.com (Postfix) with SMTP id AF86F21E8013 for ; Thu, 22 Mar 2012 23:06:54 -0700 (PDT) Received: from james ( [202.38.64.143] ) by ajax-webmail-mailweb (Coremail) ; Fri, 23 Mar 2012 14:06:50 +0800 (CST) Date: Fri, 23 Mar 2012 14:06:50 +0800 (CST) From: "Zhang Huanjie" To: "Softwires WG" Message-ID: <15748404.2078701332482810212.JavaMail.coremail@mailweb> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [202.38.64.143] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT_U3b build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn ustccn X-CM-TRANSID: yia_0ZDr6gP6EmxPgB0sBA--.37397W X-CM-SenderInfo: 5mdpv2w6xv3uoohg3hdfq/1tbiAQICB0qSNfMhDAAAs1 X-Coremail-Antispam: 1U50xBIdaVrnn0S07vEb7Iv0xC_Ar1lV2xY67kC6x804xJvcS sGvfC2KfnxnUU== Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 06:06:56 -0000 4rd-U is in the very early design stage, there is no running code. In addit= ion, it tries to modify the IPv6 address architecture. We need to see the e= xperimental data before making any decision. -- Zhang Huanjie E-mail/msn:=A0james@ustc.edu.cn=A0=A0=A0 From repenno@cisco.com Thu Mar 22 23:33:20 2012 Return-Path: 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 8B59921E8047 for ; Thu, 22 Mar 2012 23:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 rcI1SugAwz1x for ; Thu, 22 Mar 2012 23:33:20 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F398221E8013 for ; Thu, 22 Mar 2012 23:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=600; q=dns/txt; s=iport; t=1332484400; x=1333694000; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=JLzN1YAKnb5HXcFRW51+G9vLc86SyAfIDQUkwDqAxV8=; b=d17tyMBPYlpAqh97grT1VhWNhNv6ZPv1rlxU/Y4gPmvHK7FijnVlycbx zYSVdBO25N5izchstu6SaJ6u+sCSC5lD1rLsbcgDa11BKSvcPaZj77Ip2 o97ZbWiAzI4I+YnIqKh9NOeteQivL8Ui2s8ac0Un4ToSH1evBkAJOJUkF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMHAHwYbE+rRDoG/2dsb2JhbABDDoMJtFCBB4ILAQQBAQEPAScCATEGGAgOBFsiDgYBEiKHZwyeb5cfBIpjhiAEiFaNCYVtiFOBaIIwV4E8 X-IronPort-AV: E=Sophos;i="4.73,634,1325462400"; d="scan'208";a="34764193" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 23 Mar 2012 06:33:19 +0000 Received: from [10.21.72.225] ([10.21.72.225]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2N6X14J021274; Fri, 23 Mar 2012 06:33:09 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 22 Mar 2012 23:33:00 -0700 From: Reinaldo Penno To: Zhang Huanjie , Softwires WG Message-ID: Thread-Topic: [Softwires] Path to move forward with 4rd In-Reply-To: <15748404.2078701332482810212.JavaMail.coremail@mailweb> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 06:42:44 -0000 Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: > > >4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to >see the experimental data before making any decision. > >-- >Zhang Huanjie >E-mail/msn: james@ustc.edu.cn > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From phdgang@gmail.com Fri Mar 23 00:49:15 2012 Return-Path: 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 D2D8421F84E2 for ; Fri, 23 Mar 2012 00:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 bNR1JhbGGTnW for ; Fri, 23 Mar 2012 00:49:11 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01FA621F84D5 for ; Fri, 23 Mar 2012 00:49:10 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1366024wib.13 for ; Fri, 23 Mar 2012 00:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EE90TrRo2BSkYLX8rQGny/UlIe6NkRmx32iRjQJ0CoM=; b=Hw1H/t46g0AU8bKwW7AbI3LOKMbLN+fXf9W5Hp1C/6mOJVzraOpIgdimQvkpkG3LkB q7w5fPeo4DR3odmce3yNmR5tSGPY0ig9hPPBYx/sDNsKBUfZ5nHKLuMBo63gbnrc9GWa tdEDYMQelrzeCdmRMXA+DNuD/57oWe8a8ksAzSRvyY66bc4sesdqMqPD+oea6wDLMuH+ tXdLvS8obygvGMMtxEVvUA4BNRyiWxU1wIGFFC8oesA71QjVqx6AHFk/0uEVeEVuI040 gWVHVetK0B6mlHa1Hm9ybGLzCWlNM+FcBI3xX/PqjpYPXhtjV7uMRZyLAR3Bx00apXi4 k46A== MIME-Version: 1.0 Received: by 10.180.107.132 with SMTP id hc4mr4038725wib.21.1332488949791; Fri, 23 Mar 2012 00:49:09 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Fri, 23 Mar 2012 00:49:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 15:49:09 +0800 Message-ID: From: GangChen To: Guanghui Yu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 07:49:15 -0000 Hello Guanghui, 2012/3/23, Guanghui Yu : > Hi all > To define the "transtion" extension has the same problem, it still > is a "new" packet for existing devices. > 4rd-U cannot replace MAP-T, since it cannot support single > translation. I guess the concern of "single translation" has already been addressed in http://www.ietf.org/mail-archive/web/softwires/current/msg03724.html BRs Gang >4rd-U cannot replace MAP-E, since it cannot support IPv4 > option. Therefore, it is no way for 4rd-U to replace MAP series. BTW, we > need both encapsulation and translation, i.e. MAP-E and MAP-T. > > On Fri, Mar 23, 2012 at 12:55 PM, Lee, Yiu wro= te: > >> Hi Guanghui, >> >> I have to admit that I am not IPv6 protocol expert. I guess Remi took th= e >> fragmentation header and overload it for his design. Say he defines a n= ew >> extension called "transition" extension, I would guess it would no longe= r >> overload the fragmentation extension. I don't know enough the current >> implementation of the FIB and how in 4rd-u design would impact the >> implementation. I have homework to do. >> >> Apart from that, I found MAP and 4rd-u are similar technologies trying t= o >> solve the same problem. So far I follow all the discussions in the maili= ng >> list about this topics. Technically speaking, they have pros and cons. I >> fail to see one is absolutely superior than the other. Both designs make >> trade-offs. >> >> When we come to WG adoption, I am completely fine if the WG decides one >> over the other. That said, the current discussion reminds me about OSPF = vs >> IS-IS. They are so similar but yet have subtle differences. Today, both >> protocols are running in production. Best case scenario is the authors c= an >> balance the trade-offs and merge two drafts. If not WG could potentially >> publish both techs (e.g. one standard track and one >> informational/experimental) and let the market force to decide. >> >> B.R., >> Yiu >> >> P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one >> complete series. >> >> >> From: Guanghui Yu >> Date: Fri, 23 Mar 2012 11:04:54 +0800 >> To: "Yiu L. LEE" >> Cc: Softwires WG >> Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 >> >> Hi Yiu >> >> 4rd-u changes the IPv6 header architecture (redefine >> fragmentation header extension) and IPv6 address architecture (different >> meaning of u-bit when g-bit=3D1). These are the fundamental changes. If >> 4rd-u >> becomes the standard, then there will be new defined =E2=80=9CIPv6=E2=80= =9D packets on >> the Internet, which are not compatible with existing IPv6 packets and >> no existing devices can understand those packets. >> >> >> Yu Guanghui >> Network and Information Center >> Dalian University of Technology, China >> >> >> On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu >> wrote: >> >>> Hi Guanghui, >>> >>> I agree that both MAP and 4rd-u are similar technology and solving the >>> same problem. From technical perspective, can you elaborate this a lith= e >>> bit? >>> >>> Thanks, >>> Yiu >>> >>> From: Guanghui Yu >>> Date: Thu, 22 Mar 2012 20:26:40 +0800 >>> To: Softwires WG >>> Subject: Re: [Softwires] Path to move forward with 4rd=E2=80=A6 >>> >>> I read 4rd-u draft and found it is flawed. >>> >> >> > > > -- > Yu Guanghui > Network and Information Center > Dalian University of Technology, China > From bingxuere@gmail.com Fri Mar 23 01:23:20 2012 Return-Path: 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 1562C21F84B8 for ; Fri, 23 Mar 2012 01:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tnV+0vbpn9UQ for ; Fri, 23 Mar 2012 01:23:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 515F721F84B3 for ; Fri, 23 Mar 2012 01:23:19 -0700 (PDT) Received: by iazz13 with SMTP id z13so5066087iaz.31 for ; Fri, 23 Mar 2012 01:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cktU3lTBrkmlMcelCcHoO3j7G3wYxOyj98P5kHF0PKs=; b=YIknTjJXDt5oltgTiQedmEXq7aiIL6ylz2iNe9KOgn+LqyQzI/my2ZLugek/mASx3N QZ39Zpc5yAyKWDzBF6KGNg+MfapgJu84ziYu4MSEzv4S9sFweiPEJaix+Q/XRpuT0aIR e5CtThzy5/1jNkjBB0DDZ80pGMzkeJzHZI+i+Pe0DMLxhD+SZxvstG5IZJh/75p4czhK ujTg/Kikdra0EuVtFP9DV1DhApvf3DiXhzBNlmSvxSXnT6kyo1FC7cvrW7ngsc/bOrj0 9uOsB9HXENai/tS09ufXrPuG4P2tGn0293Jb+StIE7Ctq90jm7r0br9qdaJuxJdMKv6A SbLQ== Received: by 10.50.194.233 with SMTP id hz9mr1298023igc.11.1332490998854; Fri, 23 Mar 2012 01:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Fri, 23 Mar 2012 01:22:36 -0700 (PDT) From: Qiong Date: Fri, 23 Mar 2012 16:22:36 +0800 Message-ID: To: softwires@ietf.org, Durand Alain , draft-penno-softwire-sdnat@tools.ietf.org Content-Type: multipart/alternative; boundary=14dae9340c7da732d004bbe4bc06 Subject: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 08:23:20 -0000 --14dae9340c7da732d004bbe4bc06 Content-Type: text/plain; charset=UTF-8 Dear Alain and all, I'm trying to understand sd-nat-02 and I'm still wondering how to setup subscriber-based binding table in sd-nat. In my understanding, a totally static binding table will introduce a lot of workload for operators. But otherwise, I guess there might be an algorithmic relationship between IPv6 and IPv4 + port range. In this way, would it become some kind of MAP, in which IPv4 address and IPv6 address is tightly coupled and need to be planned in advance ? I'm just wondering why do we still need to maintain per-subscriber table in AFTR while still keeping stateless. Please correct me if I miss something here : ) Thanks a lot! Best wishes Qiong --14dae9340c7da732d004bbe4bc06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Alain and all,

I'm trying to understand sd-nat-02 and I'= ;m still wondering how to setup subscriber-based binding table in sd-nat. I= n my understanding, a totally static binding table will introduce a lot of = workload for operators. But otherwise, I guess there might be an algorithmi= c relationship between IPv6 and IPv4 + port range. In this way, would it be= come some kind of MAP, in which IPv4 address and IPv6 address is tightly=20 coupled and need to be planned in advance ?=C2=A0 I'm just wondering wh= y do we still need to maintain per-subscriber table in AFTR while still=C2= =A0keeping stateless. Please correct me if I miss something here : )
Thanks a lot!

Best wishes
Qiong
--14dae9340c7da732d004bbe4bc06-- From despres.remi@laposte.net Fri Mar 23 02:02:45 2012 Return-Path: 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 8114121F84B2 for ; Fri, 23 Mar 2012 02:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 HhXFHYCuX4HO for ; Fri, 23 Mar 2012 02:02:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id B505321F84EA for ; Fri, 23 Mar 2012 02:02:38 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A05F094012A; Fri, 23 Mar 2012 10:02:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Mar 2012 10:02:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:02:45 -0000 Hi, Med, Thanks for this question. 1. As we know, all fragments of a packet from a given off-domain host to = a given in-domain IPv4 address usually enter the domain via the same BR. = (Otherwise packet disordering would badly disrupt TCP). 2. When fragments of a packet enter a domain via distinct BRs (e.g. due = to some change in routing or load balancing information bases), the = algorithm of = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. (3) is such that the packet will be lost: - A fragments going via a BR that didn't receive the first fragment is = discarded by this BR. This results from the last column of the decision = table. - Reassembly in the destination becomes therefore impossible. OK? Cheers, RD =20 Le 2012-03-22 =E0 08:51, = a =E9crit : > Dear Gang, >=20 > Thanks, but I failed to find the text describing how to handle two = fragments received by two distinct BRs. >=20 > Could you please point me to that text in case I miss it? >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : GangChen [mailto:phdgang@gmail.com]=20 >> Envoy=E9 : jeudi 22 mars 2012 08:33 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : Washam Fan; Softwires >> Objet : Re: [Softwires] Fragmentation in sdnat-02 >>=20 >> 2012/3/21, mohamed.boucadair@orange.com = : >>> Dear Washam, >>>=20 >>> This is an issue common to all stateless solutions,=20 >> including deterministic >>> NAT with (anaycast) IPv4 address pool. >>>=20 >>> FWIW, we recorded this issue here: >>> = http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>>=20 >>> As a solution to this issue, we proposed to implement the >>> fragmentation-related function in one single node: any=20 >> received fragment is >>> redirected to a dedicated node which will be responsible for=20 >> reassembly or >>> forward the fragment to the appropriate CPE. This node must dedicate >>> resources to handle out of order fragments. >>=20 >> FYI, I see another approach doing that with a entry table + >> redirection action, similarly like >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >> ion-4.5.2. >>=20 >> BRs >>=20 >> Gang >>=20 >>> Saying that, I can not quantify the severity of this issue in all >>> operational networks. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org >>>> [mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>> Envoy=E9 : mercredi 21 mars 2012 07:25 >>>> =C0 : Softwires >>>> Objet : [Softwires] Fragmentation in sdnat-02 >>>>=20 >>>> Hi Authors, >>>>=20 >>>> In section 3.2, it states IPv4 address pool should be anycasted. = This >>>> introduces a risk where different incoming fragments go to = different >>>> AFTRs. Because one IPv4 address is shared between multiple >>>> subscribers, reassemly is needed on AFTRs when receiving=20 >> fragments. If >>>> different fragments go thru different AFTRs, the reassmely process >>>> would fail and incur DoS. >>>>=20 >>>> Thanks, >>>> washam >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Mar 23 02:14:23 2012 Return-Path: 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 9C94921F852D for ; Fri, 23 Mar 2012 02:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 4nZeE+WL5r76 for ; Fri, 23 Mar 2012 02:14:19 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 967EA21F84EA for ; Fri, 23 Mar 2012 02:14:16 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 77353940109; Fri, 23 Mar 2012 10:14:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--147967221 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F6BD7ED.4020909@cernet.edu.cn> Date: Fri, 23 Mar 2012 10:13:54 +0100 Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> <4F6BD7ED.4020909@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:14:23 -0000 --Apple-Mail-3--147967221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-23 =C3=A0 02:54, Xing Li a =C3=A9crit : > Hi, Remi, >=20 > =E4=BA=8E 2012/3/19 21:22, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93: >>=20 >> Hi, Xing, >>=20 >> I look forward to face to face discussions in Paris if we don't = clarify everything before that (I will be busy on something else in the = next 3 days). >>=20 >>=20 >> Le 2012-03-18 =C3=A0 23:39, Xing Li a =C3=A9crit : >> ... >>>>=20 >>>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack = CE node, when it receives no 4rd mapping rule, to exercise single = translation.=20 >>>> Actually, I believe that using for this the BIH of RFC6535 is both = sufficient and recommendable. >>>> Translated IPv4 packets, because they are sent from CE nodes to = DNS64 synthesized addresses, are appropriately routed to their = destinations. (It can be via the NAT64-CGN if needed, or via more direct = paths if possible.) >>>> Anything missed? >>>=20 >>> Sorry, this is a misunderstanding.=20 >>> Hint: Single translation and double translation are based on the = same mapping rule in the CERNET2 deployment. >>=20 >> I am well aware of this, but this doesn't explain why 4rd mapping = rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to = IPv6 communication (single translation) supported". >>=20 >> As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via manual configuration or stateful autoconfiguration via DHCPv6". >> Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with V octet and CNP). >>=20 >> Now, when both addresses happen to be checksum neutral, RFC6145 = translation doesn't modify L4 data, so that it doesn't matter whether = the DS node has used 4rd-u header mapping or single translation.=20 >> Thus, IPv6-only hosts can exchange packets with IPv4 applications of = 4rd CE nodes.=20 >=20 > Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for = host. Let me ask again, then, for an example with its mapping rules and IPv4 = prefixes. We can then discuss with facts. Without that "IPv4 to IPv6 communication = (single translation) supported" remains a claim, not a feature others = can verify. Thanks, RD >=20 >=20 > Regards, >=20 > xing >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Regards, >>>=20 >>> xing >>>=20 >>>=20 >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Regards, >>>>>=20 >>>>> xing >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> RD >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit : >>>>>> ... | | | | | >>>>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y = | N | >>>>>>>>> | | packets | | | = | | >>>>>>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>>>>>=20 >>>>>>>=20 >>>>>>> (2) More clarification should be added here. I am not sure 4rd-H = can support single translation. >>>>>>>=20 >>>>>>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>>>>>=20 >>>>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot = support single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. >>>>>>>=20 >>>>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>>> (5) I would like to see the details of how 4rd-H handles ICMP = and ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>>>>>=20 >>>>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>>>> ... >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail-3--147967221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=20 =20
Hi, Remi,

=E4=BA=8E 2012/3/19 21:22, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93:
Hi, Xing,

I look forward to face to face discussions in Paris if we don't clarify everything before that (I will be busy on something else in the next 3 days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a =C3=A9crit :
...

 A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE node, when it = receives no 4rd mapping rule, to exercise single translation. 
 Actually, I believe that using for this the = BIH of RFC6535 is both sufficient and = recommendable.
 Translated IPv4 packets, because they are = sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

I am well aware of this, but this doesn't explain why 4rd mapping rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication (single translation) supported".

As said = in RFC6219, CERNET hosts have their IPv6 addresses configured "via manual configuration or stateful autoconfiguration via DHCPv6".
Hosts = can therefore be assigned Interface IDs that have = the 4rd-u format (with V octet and CNP).

Now, when both addresses happen to be checksum neutral, RFC6145 translation doesn't modify L4 data, so that it doesn't matter whether the DS node has used 4rd-u header mapping or single translation. 
Thus, IPv6-only hosts can = exchange packets with IPv4 applications of 4rd CE nodes.

Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host.

Let me ask again, then, for = an example with its mapping rules and IPv4 prefixes.
We can = then discuss with facts. Without that "IPv4 to IPv6 communication (single = translation) supported" remains a claim, not a feature others can = verify.

Thanks,
RD





Regards,

xing


Regards,
RD







Regards,

xing



Regards,
RD





= Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :
... | | | | = |
= 
  |  5 | IPv6 web =
caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to =
"IPv4 to IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the = thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...








= --Apple-Mail-3--147967221-- From mohamed.boucadair@orange.com Fri Mar 23 02:17:00 2012 Return-Path: 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 62A6C21F854C for ; Fri, 23 Mar 2012 02:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] 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 IC113OfeK5BQ for ; Fri, 23 Mar 2012 02:16:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4C21F854D for ; Fri, 23 Mar 2012 02:16:55 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6B4FE22C5D4; Fri, 23 Mar 2012 10:16:54 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 50A4827C053; Fri, 23 Mar 2012 10:16:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 23 Mar 2012 10:16:54 +0100 From: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Fri, 23 Mar 2012 10:16:53 +0100 Thread-Topic: [Softwires] Fragmentation in sdnat-02 Thread-Index: Ac0I07M1MoJx5IztRwKKpT2/NcXbIQAAHsIA Message-ID: <94C682931C08B048B7A8645303FDC9F36E2867C8FA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.23.84517 Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:17:00 -0000 Hi R=E9mi, This is well understood. The issue and the behaviour you are describing is = common to all address sharing solutions with or without NAT; including all = A+P flavours (MAP, 4rd, SDNAT).=20 The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** is= sue, consider the solution presented in http://tools.ietf.org/html/draft-de= c-stateless-4v6-04#section-5.15.2. Cheers, Med=20 >-----Message d'origine----- >De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 >Envoy=E9 : vendredi 23 mars 2012 10:02 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : GangChen; Softwires >Objet : Re: [Softwires] Fragmentation in sdnat-02 > >Hi, Med, > >Thanks for this question. > >1. As we know, all fragments of a packet from a given=20 >off-domain host to a given in-domain IPv4 address usually=20 >enter the domain via the same BR. (Otherwise packet=20 >disordering would badly disrupt TCP). > >2. When fragments of a packet enter a domain via distinct BRs=20 >(e.g. due to some change in routing or load balancing=20 >information bases), the algorithm of=20 >http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >ion-4.5.2. (3) is such that the packet will be lost: >- A fragments going via a BR that didn't receive the first=20 >fragment is discarded by this BR. This results from the last=20 >column of the decision table. >- Reassembly in the destination becomes therefore impossible. >OK? > > >Cheers, >RD >=20 >Le 2012-03-22 =E0 08:51, =20 > a =E9crit : > >> Dear Gang, >>=20 >> Thanks, but I failed to find the text describing how to=20 >handle two fragments received by two distinct BRs. >>=20 >> Could you please point me to that text in case I miss it? >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : GangChen [mailto:phdgang@gmail.com]=20 >>> Envoy=E9 : jeudi 22 mars 2012 08:33 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Washam Fan; Softwires >>> Objet : Re: [Softwires] Fragmentation in sdnat-02 >>>=20 >>> 2012/3/21, mohamed.boucadair@orange.com=20 >: >>>> Dear Washam, >>>>=20 >>>> This is an issue common to all stateless solutions,=20 >>> including deterministic >>>> NAT with (anaycast) IPv4 address pool. >>>>=20 >>>> FWIW, we recorded this issue here: >>>>=20 >http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>>>=20 >>>> As a solution to this issue, we proposed to implement the >>>> fragmentation-related function in one single node: any=20 >>> received fragment is >>>> redirected to a dedicated node which will be responsible for=20 >>> reassembly or >>>> forward the fragment to the appropriate CPE. This node=20 >must dedicate >>>> resources to handle out of order fragments. >>>=20 >>> FYI, I see another approach doing that with a entry table + >>> redirection action, similarly like >>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >>> ion-4.5.2. >>>=20 >>> BRs >>>=20 >>> Gang >>>=20 >>>> Saying that, I can not quantify the severity of this issue in all >>>> operational networks. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : softwires-bounces@ietf.org >>>>> [mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>>> Envoy=E9 : mercredi 21 mars 2012 07:25 >>>>> =C0 : Softwires >>>>> Objet : [Softwires] Fragmentation in sdnat-02 >>>>>=20 >>>>> Hi Authors, >>>>>=20 >>>>> In section 3.2, it states IPv4 address pool should be=20 >anycasted. This >>>>> introduces a risk where different incoming fragments go=20 >to different >>>>> AFTRs. Because one IPv4 address is shared between multiple >>>>> subscribers, reassemly is needed on AFTRs when receiving=20 >>> fragments. If >>>>> different fragments go thru different AFTRs, the=20 >reassmely process >>>>> would fail and incur DoS. >>>>>=20 >>>>> Thanks, >>>>> washam >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >= From ichiroumakino@gmail.com Fri Mar 23 02:28:42 2012 Return-Path: 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 DA99021F84F8 for ; Fri, 23 Mar 2012 02:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 uIx8d1V4LWNL for ; Fri, 23 Mar 2012 02:28:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED6421F84AE for ; Fri, 23 Mar 2012 02:28:41 -0700 (PDT) Received: by werb10 with SMTP id b10so2991846wer.31 for ; Fri, 23 Mar 2012 02:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rl8j79GSbrDhHETZZNM24v63ik+Pu8/RXYSeHOVelPI=; b=W9pqB0nHS05aeihYyMacG+/WVyAYMnNzybXyJHvSrS2C3H5qN/BCi1by07mjljKc9d RGz6zmbiVnC+gqcABk1QSaPd4tVjJTIyVbfGICfoVPwXh7sZh13fhysgtxti5/nvTvoe /9aqH7N01sAeNHsarQbM4HUOwngqX7Wv0JC4fp+5VCtwAr/YZxqkCadGLpnisrwt3M/3 t2ov+Xcmjjywbi4HomCpPJ67kFgKmWrepjacCkkLReQ3mE7QT1+JxQ9QodC1Q+4p2Pid 2C8FTmVo6PcQ5ShsuA8R6Y9kK/TgZb76tXzdKAHzACo2mxYi8ywIkedBIxv8lWZ/9Wxh yQLw== Received: by 10.180.79.135 with SMTP id j7mr4738029wix.19.1332494921163; Fri, 23 Mar 2012 02:28:41 -0700 (PDT) Received: from [10.147.13.60] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 17sm12876057wis.0.2012.03.23.02.28.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 02:28:40 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 23 Mar 2012 10:28:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:28:43 -0000 Yiu, > I have to admit that I am not IPv6 protocol expert. I guess Remi took = the fragmentation header and overload it for his design. Say he defines = a new extension called "transition" extension, I would guess it would no = longer overload the fragmentation extension. I don't know enough the = current implementation of the FIB and how in 4rd-u design would = impact the implementation. I have homework to do. Type 3 Routing Header? we've tried this type of tunneling before. ;-) > Apart from that, I found MAP and 4rd-u are similar technologies trying = to solve the same problem. So far I follow all the discussions in the = mailing list about this topics. Technically speaking, they have pros and = cons. I fail to see one is absolutely superior than the other. Both = designs make trade-offs. =20 > =20 > When we come to WG adoption, I am completely fine if the WG decides = one over the other. That said, the current discussion reminds me about = OSPF vs IS-IS. They are so similar but yet have subtle differences. = Today, both protocols are running in production. Best case scenario is = the authors can balance the trade-offs and merge two drafts. If not WG = could potentially publish both techs (e.g. one standard track and one = informational/experimental) and let the market force to decide. the authors did already do that. the dIVI and 4rd authors met 16th of = November at the last IETF. we collectively went through the complete feature list. the result is = what you find in the MAP document series. Remi, who was also at that meeting, later came up with a different = solution and new features and decided to create a competing proposal. = MAP is largely original 4rd and dIVI, considering its roots. there has = been a continuing exchange of ideas and improvement of the proposals. = Remi's latest 4rd-U proposal largely represents all the functions that = there was no support for in the MAP design team. I do not think = attempting yet another merger will be a good use of our time. > P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one = complete series. yes, that makes sense. OK, what if we try this: MAP is a unified solution consisting of two = transport modes (T/E), a provisioning (DHCP) and a deployment document. then we can pick between MAP and 4rd-U. the winner gets published on = standards track. the looser gets documented as informational for the = purpose of historical reference. cheers, Ole= From ichiroumakino@gmail.com Fri Mar 23 02:46:31 2012 Return-Path: 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 C3F7121F84C8 for ; Fri, 23 Mar 2012 02:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0f6e0hgHgHzg for ; Fri, 23 Mar 2012 02:46:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0121F849B for ; Fri, 23 Mar 2012 02:46:30 -0700 (PDT) Received: by werb10 with SMTP id b10so3004770wer.31 for ; Fri, 23 Mar 2012 02:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CZboaKezEiHBcoQxLIaKDf3+5zScXDkl7t5dcGg6gis=; b=Qj1CPY7awAYIvs0wDusfmXZTmTujJKjRrcqpsTzxHIveEMpO3b+Hd55p1tIL7r8yJJ YeKZ+XTNJBj9B6basNagFx1gZFcaXfHFJ2qjr6oPnHirCh+poUXPiaq3XQUF/v3rU/i8 /PVcoBEubYBU7MiyoBWDQVse0DwtezNj0s6m9K47MKmbiM7bIHgBj/MswpZEC/3I9Q8/ TIh1kwoDqvyEp4hGgl+d4J8G5Rgp6iyuT/NuBraa4FtyAZp6fBek9SD35qGhzbml5Mnx s4xdvraWrIwjXgBvFZJ4bQviVQhlppNG3SEFVOKTFE8k4uQN4E8yqLL1ccd0ywW86xc/ m8lg== Received: by 10.180.102.231 with SMTP id fr7mr4921270wib.10.1332495989904; Fri, 23 Mar 2012 02:46:29 -0700 (PDT) Received: from [10.147.13.60] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o2sm20817463wiv.11.2012.03.23.02.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 02:46:29 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 23 Mar 2012 10:46:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15D8606F-0EB6-4A6B-927D-B5B2C861B285@employees.org> References: To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:46:31 -0000 Alain, et al, we have been at an impasse, so thank you very much for proposing a path = forward. > After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. > 1) There is an observation that all the solutions on the table E, T & = U actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation > proposals, U is an hybrid unifying solution. I do agree with that. the Venn diagram for the three solutions would = look awfully similar to a single circle. ;-) there are some use cases though, that can only be fulfilled with one = mode of transport versus the other. I left the interim meeting in Beijing having been convinced that there = are use cases requiring both encapsulation and requiring translation. if = we for a moment accept that, I would suggest that we treat MAP as one = single solution. it will have two options/flavours of transport. > 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >=20 > We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). > Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. > Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask > and their sequence. >=20 > Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >=20 > If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. > If the answer is YES, we move to the next question. >=20 >=20 > Q2: Do you believe that the WG should publish U as the one Standards = Track document? >=20 > If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational) >=20 >=20 > Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >=20 > If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both = E & T as Experimental. with the above proposal, we can drop question 3. > In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. can ask the chairs to take a hum of how many would want t-shirts for the = meeting with: "Just pick one for F's sake and stop arguing". ;-) cheers, Ole= From despres.remi@laposte.net Fri Mar 23 03:02:12 2012 Return-Path: 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 3D22B21F8549 for ; Fri, 23 Mar 2012 03:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 fyyO-Vw59k7W for ; Fri, 23 Mar 2012 03:02:07 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 787E121F8545 for ; Fri, 23 Mar 2012 03:02:05 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 218139401D5; Fri, 23 Mar 2012 11:01:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2867C8FA@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Mar 2012 11:01:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <461847BF-3941-4990-A462-0A0E5E01A74C@laposte.net> References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C8FA@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:02:12 -0000 Le 2012-03-23 =E0 10:16, a =E9crit : > Hi R=E9mi, >=20 > This is well understood. The issue and the behaviour you are = describing is common to all address sharing solutions with or without = NAT; including all A+P flavours (MAP, 4rd, SDNAT).=20 >=20 > The point is: ** IF ** the issue raised by Washam is judged ** SEVERE = ** issue, consider the solution presented in = http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. In this context, the important consideration is AFAIK that it is = completely acceptable to lose fragmented packets that, with bad luck, = happen to be routed via distinct BRs when there is a route change. = Frequent route changes would have many more severe consequences than = this one if considered normal. Do we agree on this? Cheers, RD >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : R=E9mi Despr=E9s [mailto:despres.remi@laposte.net]=20 >> Envoy=E9 : vendredi 23 mars 2012 10:02 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : GangChen; Softwires >> Objet : Re: [Softwires] Fragmentation in sdnat-02 >>=20 >> Hi, Med, >>=20 >> Thanks for this question. >>=20 >> 1. As we know, all fragments of a packet from a given=20 >> off-domain host to a given in-domain IPv4 address usually=20 >> enter the domain via the same BR. (Otherwise packet=20 >> disordering would badly disrupt TCP). >>=20 >> 2. When fragments of a packet enter a domain via distinct BRs=20 >> (e.g. due to some change in routing or load balancing=20 >> information bases), the algorithm of=20 >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >> ion-4.5.2. (3) is such that the packet will be lost: >> - A fragments going via a BR that didn't receive the first=20 >> fragment is discarded by this BR. This results from the last=20 >> column of the decision table. >> - Reassembly in the destination becomes therefore impossible. >> OK? >>=20 >>=20 >> Cheers, >> RD >>=20 >> Le 2012-03-22 =E0 08:51, =20 >> a =E9crit : >>=20 >>> Dear Gang, >>>=20 >>> Thanks, but I failed to find the text describing how to=20 >> handle two fragments received by two distinct BRs. >>>=20 >>> Could you please point me to that text in case I miss it? >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : GangChen [mailto:phdgang@gmail.com]=20 >>>> Envoy=E9 : jeudi 22 mars 2012 08:33 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : Washam Fan; Softwires >>>> Objet : Re: [Softwires] Fragmentation in sdnat-02 >>>>=20 >>>> 2012/3/21, mohamed.boucadair@orange.com=20 >> : >>>>> Dear Washam, >>>>>=20 >>>>> This is an issue common to all stateless solutions,=20 >>>> including deterministic >>>>> NAT with (anaycast) IPv4 address pool. >>>>>=20 >>>>> FWIW, we recorded this issue here: >>>>>=20 >> http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>>>>=20 >>>>> As a solution to this issue, we proposed to implement the >>>>> fragmentation-related function in one single node: any=20 >>>> received fragment is >>>>> redirected to a dedicated node which will be responsible for=20 >>>> reassembly or >>>>> forward the fragment to the appropriate CPE. This node=20 >> must dedicate >>>>> resources to handle out of order fragments. >>>>=20 >>>> FYI, I see another approach doing that with a entry table + >>>> redirection action, similarly like >>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >>>> ion-4.5.2. >>>>=20 >>>> BRs >>>>=20 >>>> Gang >>>>=20 >>>>> Saying that, I can not quantify the severity of this issue in all >>>>> operational networks. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : softwires-bounces@ietf.org >>>>>> [mailto:softwires-bounces@ietf.org] De la part de Washam Fan >>>>>> Envoy=E9 : mercredi 21 mars 2012 07:25 >>>>>> =C0 : Softwires >>>>>> Objet : [Softwires] Fragmentation in sdnat-02 >>>>>>=20 >>>>>> Hi Authors, >>>>>>=20 >>>>>> In section 3.2, it states IPv4 address pool should be=20 >> anycasted. This >>>>>> introduces a risk where different incoming fragments go=20 >> to different >>>>>> AFTRs. Because one IPv4 address is shared between multiple >>>>>> subscribers, reassemly is needed on AFTRs when receiving=20 >>>> fragments. If >>>>>> different fragments go thru different AFTRs, the=20 >> reassmely process >>>>>> would fail and incur DoS. >>>>>>=20 >>>>>> Thanks, >>>>>> washam >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 From cx.cernet@gmail.com Fri Mar 23 03:04:52 2012 Return-Path: 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 370B021F8510 for ; Fri, 23 Mar 2012 03:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 JulTQSRLN2Vv for ; Fri, 23 Mar 2012 03:04:48 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCB8E21F84EC for ; Fri, 23 Mar 2012 03:04:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2853385ghb.31 for ; Fri, 23 Mar 2012 03:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/JjiAT3opSwYbuHxxRrNy/qV9Pw2Mdh9aksGvX3aFQ=; b=SvDg2h8if/3qEk+eR4SvLAkEM263apgmyjWmQmIflUXGrDYbq8YJxB4JZtF/YF81ZG xE8XehaSjvnLR6Zw+RAKG3OmpgE6YhSSu8WbIzKCdM+dhiFYZOQCzPr41zVzd6VlB+fZ cuya9YzU1GZxvYNH8Cf0G3B02FL4QP0HD7fJFEPssa7sSfidcGt8nGQVJbmIo0g6Jk9g XxEek0VbiuHTyAehpuHMI8s80EQ64k4/GgCvaJFZzpxdgVhs1bX33/gxCNH4+VImpT1A aKdhWRiV3WjTyqAyoREGeZH8/WIT7DbK9axwEHWRl6mMzCKRrSZvPkLPdgKhDTDUjHIq 50Vw== MIME-Version: 1.0 Received: by 10.68.218.228 with SMTP id pj4mr28443782pbc.167.1332497087264; Fri, 23 Mar 2012 03:04:47 -0700 (PDT) Received: by 10.142.105.20 with HTTP; Fri, 23 Mar 2012 03:04:47 -0700 (PDT) In-Reply-To: References: <15748404.2078701332482810212.JavaMail.coremail@mailweb> Date: Fri, 23 Mar 2012 18:04:47 +0800 Message-ID: From: Congxiao Bao To: Reinaldo Penno Content-Type: multipart/alternative; boundary=047d7b2ee1618cf6ce04bbe627bf Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:04:52 -0000 --047d7b2ee1618cf6ce04bbe627bf Content-Type: text/plain; charset=ISO-8859-1 Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno > Is there experimental data for MAP running on production networks? > Certainly that is an important point to consider. > > On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: > > > > > > >4rd-U is in the very early design stage, there is no running code. In > >addition, it tries to modify the IPv6 address architecture. We need to > >see the experimental data before making any decision. > > > >-- > >Zhang Huanjie > >E-mail/msn: james@ustc.edu.cn > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7b2ee1618cf6ce04bbe627bf Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Penno,
 
= MAP-T was derived from dIVI and d= IVI-PD, which has been running at CERNET2 for two years and have been tested at Chi= na Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last Septe= mber. BTW, the MAP-T code will be available soon.
 
Congxiao


2012/3/23 Reinaldo Penno <repenno@cisco.com>= ;
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <james@ustc.edu.cn> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to<= br> >see the experimental data before making any decision.
>
>--
>Zhang Huanjie
>E-mail/msn: james@ustc.edu.cn<= br> >
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--047d7b2ee1618cf6ce04bbe627bf-- From mohamed.boucadair@orange.com Fri Mar 23 03:13:07 2012 Return-Path: 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 5F6CE21F8532 for ; Fri, 23 Mar 2012 03:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 H9g301+pDHxB for ; Fri, 23 Mar 2012 03:13:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C771121F8531 for ; Fri, 23 Mar 2012 03:13:03 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 37F7D2DC08D; Fri, 23 Mar 2012 11:13:03 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1A3174C069; Fri, 23 Mar 2012 11:13:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 23 Mar 2012 11:13:03 +0100 From: To: Alain Durand , Softwires WG Date: Fri, 23 Mar 2012 11:13:02 +0100 Thread-Topic: Path to move forward with 4rd. Thread-Index: Ac0GKWtjiwfJTLnPSeG4n7AZAdsQIACrJdww Message-ID: <94C682931C08B048B7A8645303FDC9F36E2867C95F@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.23.91517 Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] Path to move forward with 4rd. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:13:07 -0000 Dear WG members, I didn't had time to read the last version of 4rd-U but I read carefully -0= 3 when it was published.=20 I really appreciated the work done by R=E9mi to write down -03. The documen= t is well written, easy to read and the requirements are clearly sketched. = I really think this spirit should be adopted by MAP documents. As I already told R=E9mi, I would like if all proponents of stateless A+P c= onverge and avoid wasting energies in comparing individual proposals. I tho= ught this is what has been agreed during the softwire interim meeting: IMO,= MAP effort meets the objective of group work. Some of the points raised by R=E9mi can be easily considered in the context= of MAP; except the idea of unified header which is a step forward. Adopt a= unified approach is exclusive to encapsulation and/or translation.=20 The question now is: Does the unified approach bring new features + simplif= ication compared to the normal IPv4-in-IPv6 encapsulation scheme (which I'm= mainly interested in)? The answer is: No.=20 Perhaps this is selfish but given what I mentioned above, I vote for the fo= llowing: * Adopt the work of the MAP design team as the base specification for state= less A+P effort. * Make sure proposals from R=E9mi (except U) are discussed: e.g., Checksum = neutrality (1) Share the archives of MAP Design Team discussion (2) Use IETF Issue Tracker to record the issues and the consensus/conclusio= n (3) Adopt a clear procedure within the Design Team to make decisions when t= here are conflicts * Reduce the amount of MAP documents: IMHO, three documents are needed (1) MAP Address Format (2) MAP Overall Architecture and Design Recommendations (3) MAP DHCPv6 Options Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Alain Durand >Envoy=E9 : mardi 20 mars 2012 00:39 >=C0 : Softwires WG >Cc : Yong Cui; Ralph Droms >Objet : [Softwires] Path to move forward with 4rd. > >Dear wg, > >After a number of discussions with my co-chair, our AD and=20 >various authors, here is how we would like to move forward wrt 4rd. > >1) There is an observation that all the solutions on the=20 >table E, T & U actually solve the stateless problem we started with. > There are differences, but it is unclear if those=20 >differences are really significant. E and T are the original=20 >Encapsulation and Translation > proposals, U is an hybrid unifying solution. > >2) We have already agreed back in Beijing that we would=20 >publish all necessary documents. The issue here is the 'label'=20 >or 'status' those > documents have at IETF. In particular, do we want to=20 >publish them as Experimental, Informational or Standard Track. > >We are at the point now where we need to make progress. In=20 >Paris, we would like to ask for presentations from the=20 >proponents of each candidate solution (E, T & U). >Each presentation should cover an overview of the proposed=20 >solution, explain how it compares to the others and make a=20 >case as why it should be the one on the Standard Track. We=20 >will allocate 20 minutes for each presentation. > >Then, we, chairs, would like to ask a series of questions to=20 >the working group. In order to make this process transparent,=20 >here is the list of questions we want to ask >and their sequence. > >Q1: Without pre-supposing which one will be selected, do you=20 >agree to publish 1 of the 3 proposals on the Standard Track=20 >and publish the other(s) as Informational if still asked to? > >If the answer is NO, then the process stops and we will=20 >publish everything as Experimental and come back in 12-24=20 >months to see what gets adopted by the market. >If the answer is YES, we move to the next question. > > >Q2: Do you believe that the WG should publish U as the one=20 >Standards Track document? > >If the answer is YES, the process stop, we put U on the=20 >Standard Track and publish E & T as Informational. >If the answer is NO, we are left with E & T (U then might be=20 >abandoned or published as Historical/Informational) > > >Q3: Which of E and T do you want to see moving on the standard=20 >track (you can only express support for one)? > >If there is a clear outcome from this question, we would=20 >publish that proposal on the Standard Track and the other one=20 >as Informational. >If there is no clear consensus on this question, we will=20 >publish both E & T as Experimental. > >In the meantime, we would like to encourage discussion on the=20 >mailing list to foster our common understanding of the various=20 >technologies and how they relate to each other. > > Alain & Yong, wg co-chairs. >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From james@ustc.edu.cn Fri Mar 23 03:35:24 2012 Return-Path: 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 17A2121F852C for ; Fri, 23 Mar 2012 03:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.636 X-Spam-Level: **** X-Spam-Status: No, score=4.636 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, RELAY_IS_222=2.179] 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 xj00W-DZKfJ6 for ; Fri, 23 Mar 2012 03:35:20 -0700 (PDT) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by ietfa.amsl.com (Postfix) with SMTP id 07A5121F84C2 for ; Fri, 23 Mar 2012 03:35:17 -0700 (PDT) Received: from james ( [222.130.141.213] ) by ajax-webmail-mailweb (Coremail) ; Fri, 23 Mar 2012 18:35:07 +0800 (CST) Date: Fri, 23 Mar 2012 18:35:07 +0800 (CST) From: "Zhang Huanjie" To: "Reinaldo Penno" Message-ID: <13067618.2104941332498908311.JavaMail.coremail@mailweb> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [222.130.141.213] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT_U3b build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn ustccn X-CM-TRANSID: yia_0ZD7vAHcUWxPwF87BA--.44728W X-CM-SenderInfo: 5mdpv2w6xv3uoohg3hdfq/1tbiAQECB0qSNfNiVgABsu X-Coremail-Antispam: 1U50xBIdaVrnn0S07vEb7Iv0xC_Cr1lV2xY67kC6x804xJvcS sGvfC2KfnxnUU== Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:35:24 -0000 I have been running single translation (IVI) for one year and have tested divi in the same environment by cascading second translator successfully. -- Zhang Huanjie E-mail/msn: james@ustc.edu.cn =20 > -----Original E-mail----- > From: "Reinaldo Penno" > Sent Time: 2012-3-23 14:33:00 > To: "Zhang Huanjie" , "Softwires WG" > Cc:=20 > Subject: Re: [Softwires] Path to move forward with 4rd >=20 > Is there experimental data for MAP running on production networks? > Certainly that is an important point to consider. >=20 > On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: >=20 > > > > > >4rd-U is in the very early design stage, there is no running code. In > >addition, it tries to modify the IPv6 address architecture. We need to > >see the experimental data before making any decision. > > > >-- > >Zhang Huanjie > >E-mail/msn: james@ustc.edu.cn > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 -- =E5=BC=A0=E7=84=95=E6=9D=B0=C2=A0 E-mail/msn: james@ustc.edu.cn=C2=A0=C2=A0= =C2=A0 =E5=AE=89=E5=BE=BD=E7=9C=81=E5=90=88=E8=82=A5=E5=B8=82=E9=87=91=E5=AF=A8=E8= =B7=AF96=E5=8F=B7 =E4=B8=AD=E5=9B=BD=E7=A7=91=E5=AD=A6=E6=8A=80=E6=9C=AF= =E5=A4=A7=E5=AD=A6=E7=BD=91=E7=BB=9C=E4=BF=A1=E6=81=AF=E4=B8=AD=E5=BF=83 (2= 30026)=20 Mobile: +86-13505693311=C2=A0=C2=A0 Tel: +86-551-3601897 From despres.remi@laposte.net Fri Mar 23 03:36:00 2012 Return-Path: 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 AB91221F855B for ; Fri, 23 Mar 2012 03:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 eLZmSqpBOOmg for ; Fri, 23 Mar 2012 03:35:55 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 32D0521F855F for ; Fri, 23 Mar 2012 03:35:53 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7D183940091; Fri, 23 Mar 2012 11:35:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--143077373 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 11:35:24 +0100 Message-Id: <6693B0EB-77F7-4400-BBC8-F9FCB729FAA4@laposte.net> References: To: Guanghui Yu X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:36:00 -0000 --Apple-Mail-4--143077373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-22 =C3=A0 13:26, Guanghui Yu a =C3=A9crit : > Hi all=20 > This mail raises a very important issue. MAP-T and MAP-E are not = competing technologies. They have different user scenarios. > I read 4rd-u draft and found it is flawed. Please explain what, in your understanding, would be flawed.=20 > I will not support the adoption of 4rd-u, since there is no running = code and there is no experimental evaluation. The theory of Reversible header mapping is so simple that, AFAIK, nobody = with implementation experience would negate that it will work when = tested.=20 Other features of the U proposal may be debated, but they are not = necessary to replace T and E by a solution that is suitable for use = cases of these two. =20 > In summary, 4rd-U is not in the same level of MAP series Would you claim that there are no inconsistencies today in the MAP set = of drafts? Actually, the U draft is more complete and self consistent than the set = of MAP documents. Regard, RD > and it should not be considered for adoption in coming Paris IETF = meeting. >=20 > PS: I'am sorry if this mail sends more than one time, the mail system = of our university may have problems with this mail list today. >=20 > Yu Guanghui > Network and Information Center > Dalian University of Technology, China > Tel: +86 411 84708117 >=20 > =E5=9C=A8 2012-3-21=EF=BC=8C=E4=B8=8B=E5=8D=889:39=EF=BC=8C Xing Li = =E5=86=99=E9=81=93=EF=BC=9A >=20 >> Hi, Alain, Yong and Ralph, >>=20 >> The newly posted agenda does not match the consensus as you mentioned = on 6 Oct 2011, that =E2=80=9Cmultiple address and port mapping = technologies could and should converge=E2=80=9D and you formally = announced =E2=80=9Cthe creation of the MAP (Mapping of Addresses and = Ports) design team=E2=80=9D, a design team which =E2=80=9Cis tasked to = formulate a unified format to be used either in an encapsulation or = double translation mode=E2=80=9D = (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). = For the past few months, the design team has produced a series of MAP = documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list = has also showed positive feedback on the adoption of the MAP series as = the standard track of working group documents. Moreover, the dIVI (an = earlier version of MAP-T) has been running successfuly at CERNET2 for = two years now. >>=20 >> 4rd-U was submitted later, and the goal is to replace the MAP Series. = There have been discussions in the mailing list, but the discussions are = mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still = in the early design stage. Due to its proposed modification of the IPv6 = architecture (V-Oct and the fragmentation header), the discussion should = be extended at least to 6man WG before the Softwire WG makes any = decision of adoption. Furthermore, experimental data should be presented = to the WG to show that these modifications are not harmful. In addition, = the fragmentation header modifications actually only deal with a very = corner case of double translation (10e-5% of the packets, not production = traffic). >>=20 >> Therefore, I don=E2=80=99t think we have any reason to change the = procedure and in the coming meeting, we should discuss whether consensus = can be reached for the adoption of the MAP series. We should discuss = whether 4rd-U can be adopted in a later meeting when it gets proved by = 6man and its modifications are proved to be not harmful by experimental = data. >>=20 >> Regards, >>=20 >> xing >> =20 >>=20 >>=20 >> =E4=BA=8E 2012/3/20 7:38, Alain Durand =E5=86=99=E9=81=93: >>>=20 >>> Dear wg, >>>=20 >>> After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >>>=20 >>> 1) There is an observation that all the solutions on the table E, T = & U actually solve the stateless problem we started with. >>> There are differences, but it is unclear if those differences = are really significant. E and T are the original Encapsulation and = Translation >>> proposals, U is an hybrid unifying solution. >>>=20 >>> 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those >>> documents have at IETF. In particular, do we want to publish = them as Experimental, Informational or Standard Track. >>>=20 >>> We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). >>> Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >>>=20 >>> Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask >>> and their sequence. >>>=20 >>> Q1: Without pre-supposing which one will be selected, do you agree = to publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >>>=20 >>> If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. >>> If the answer is YES, we move to the next question. >>>=20 >>>=20 >>> Q2: Do you believe that the WG should publish U as the one Standards = Track document? >>>=20 >>> If the answer is YES, the process stop, we put U on the Standard = Track and publish E & T as Informational. >>> If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational) >>>=20 >>>=20 >>> Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >>>=20 >>> If there is a clear outcome from this question, we would publish = that proposal on the Standard Track and the other one as Informational. >>> If there is no clear consensus on this question, we will publish = both E & T as Experimental. >>>=20 >>> In the meantime, we would like to encourage discussion on the = mailing list to foster our common understanding of the various = technologies and how they relate to each other. >>>=20 >>> Alain & Yong, wg co-chairs. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-4--143077373 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = all 
    This mail raises = a very important issue. MAP-T and MAP-E are not competing technologies. = They have different user = scenarios.


I read 4rd-u = draft and found it is = flawed.

Please explain = what, in your understanding, would be = flawed. 


I will not support the adoption of 4rd-u, since = there is no running code and there is no experimental = evaluation.

The theory of = Reversible header mapping is so simple that, AFAIK, nobody with = implementation experience would negate that it will work when = tested. 
Other features of the U proposal may be debated, = but they are not necessary to replace T and E by a solution that is = suitable for use cases of these two.  

In summary, 4rd-U = is not in the same level of MAP = series

Would you claim that = there are no inconsistencies today in the MAP set of = drafts?
Actually, the U draft is more complete and self = consistent than the set of MAP = documents.

Regard,
RD


and it should = not be considered for adoption in coming Paris IETF = meeting.

PS: I'am sorry if this mail sends more than one = time, the mail system of our university may have problems with this mail = list today.

Yu Guanghui <ygh at dlut.edu.cn>
Network and Information Center
Dalian University of = Technology, China
Tel: +86 411 84708117

=E5=9C=A8 2012-3-21=EF=BC=8C=E4=B8=8B=E5=8D=889= :39=EF=BC=8C Xing Li =E5=86=99=E9=81=93=EF=BC=9A

Hi, Alain, Yong and = Ralph,

The newly posted agenda does not match the consensus as = you mentioned on 6 Oct 2011, that =E2=80=9Cmultiple address and port = mapping technologies could and should converge=E2=80=9D and you formally = announced =E2=80=9Cthe creation of the MAP (Mapping of Addresses and = Ports) design team=E2=80=9D, a design team which =E2=80=9Cis tasked to = formulate a unified format to be used either in an encapsulation or = double translation mode=E2=80=9D (http://www.ietf.org/mail-ar= chive/web/softwires/current/msg03024.html). For the past few months, = the design team has produced a series of MAP documents, including MAP, = MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive = feedback on the adoption of the MAP series as the standard track of = working group documents. Moreover, the dIVI (an earlier version of = MAP-T) has been running successfuly at CERNET2 for two years now.

4rd-U was submitted later, and the goal is to replace the MAP = Series. There have been discussions in the mailing list, but the = discussions are mainly questions concerning the 4rd-U proposal. = Actually, 4rd-U is still in the early design stage. Due to its proposed = modification of the IPv6 architecture (V-Oct and the fragmentation = header), the discussion should be extended at least to 6man WG before = the Softwire WG makes any decision of adoption. Furthermore, = experimental data should be presented to the WG to show that these = modifications are not harmful. In addition, the fragmentation header = modifications actually only deal with a very corner case of double = translation (10e-5% of the packets, not production traffic).

Therefore, I don=E2=80=99t think we have any reason to change the = procedure and in the coming meeting, we should discuss whether consensus = can be reached for the adoption of the MAP series. We should discuss = whether 4rd-U can be adopted in a later meeting when it gets proved by = 6man and its modifications are proved to be not harmful by experimental = data.

Regards,

xing

 



=E4=BA=8E 2012/3/20 7:38, Alain Durand =E5=86=99=E9=81=93:
Dear wg,

After a number of discussions with my co-chair, our AD and various =
authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T =
& U actually solve the stateless  problem we started with.
    There are differences, but it is unclear if those differences are =
really significant. E and T are the original Encapsulation and =
Translation
    proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all =
necessary documents. The issue here is the 'label' or 'status' those
    documents have at IETF. In particular, do we want to publish them as =
Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we =
would like to ask for presentations from the proponents of each =
candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, =
explain how it compares to the others and make a case as why it should =
be the one on the Standard Track. We will allocate 20 minutes for each =
presentation.

Then, we, chairs, would like to ask a series of questions to the working =
group. In order to make this process transparent, here is the list of =
questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to =
publish 1 of the 3 proposals on the Standard Track and publish the =
other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish =
everything as Experimental and come back in 12-24 months to see what =
gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards =
Track document?

If the answer is YES, the process stop, we put U on the Standard Track =
and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be =
abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track =
(you can only express support for one)?

If there is a clear outcome from this question, we would publish that =
proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E =
& T as Experimental.

In the meantime, we would like to encourage discussion on the mailing =
list to foster our common understanding of the various technologies and =
how they relate to each other.

  Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailma=
n/listinfo/softwires

=

_____________________________________________= __
Softwires mailing list
Softwires@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/softwires" = style=3D"color:blue;text-decoration:underline">https://www.ietf.org/mailma= n/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-4--143077373-- From despres.remi@laposte.net Fri Mar 23 04:22:19 2012 Return-Path: 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 B2DF121F84F3 for ; Fri, 23 Mar 2012 04:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] 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 v3K8NFEtGDBN for ; Fri, 23 Mar 2012 04:22:02 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8303521F8569 for ; Fri, 23 Mar 2012 04:21:59 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5A6FF940075; Fri, 23 Mar 2012 12:21:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Priority: 3 In-Reply-To: <13067618.2104941332498908311.JavaMail.coremail@mailweb> Date: Fri, 23 Mar 2012 12:21:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13067618.2104941332498908311.JavaMail.coremail@mailweb> To: Zhang Huanjie X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:22:19 -0000 Le 2012-03-23 =C3=A0 11:35, Zhang Huanjie a =C3=A9crit : > I have been running single translation (IVI) for one year and have > tested divi in the same environment by cascading second translator > successfully. 1. Draft U-03 (Dec 29) raised the issue of reassembly of packets from = shared-address CEs, with a solution. Draft E-01 (Jan 27) dealt with the issue. It described a simpler = solution, also used in U-05 (March 12) Draft T deals with the subject (although the issue is real and must be = dealt with). The current Draft T is therefore clearly incomplete, and tests were = unable to show it. Similarly, it has been acknowledged that MAP as is doesn't support = hub&spoke (a DHCP parameter is missing). No experiment has found it. 2. Understanding that reversible header mapping is more transparent than = double translation needs no experiment. RD =20 >=20 > -- > Zhang Huanjie > E-mail/msn: james@ustc.edu.cn =20 >=20 >> -----Original E-mail----- >> From: "Reinaldo Penno" >> Sent Time: 2012-3-23 14:33:00 >> To: "Zhang Huanjie" , "Softwires WG" = >> Cc:=20 >> Subject: Re: [Softwires] Path to move forward with 4rd >>=20 >> Is there experimental data for MAP running on production networks? >> Certainly that is an important point to consider. >>=20 >> On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: >>=20 >>>=20 >>>=20 >>> 4rd-U is in the very early design stage, there is no running code. = In >>> addition, it tries to modify the IPv6 address architecture. We need = to >>> see the experimental data before making any decision. >>>=20 >>> -- >>> Zhang Huanjie >>> E-mail/msn: james@ustc.edu.cn >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 >=20 > -- > =E5=BC=A0=E7=84=95=E6=9D=B0 E-mail/msn: james@ustc.edu.cn =20 > =E5=AE=89=E5=BE=BD=E7=9C=81=E5=90=88=E8=82=A5=E5=B8=82=E9=87=91=E5=AF=A8= =E8=B7=AF96=E5=8F=B7 =E4=B8=AD=E5=9B=BD=E7=A7=91=E5=AD=A6=E6=8A=80=E6=9C=AF= =E5=A4=A7=E5=AD=A6=E7=BD=91=E7=BB=9C=E4=BF=A1=E6=81=AF=E4=B8=AD=E5=BF=83 = (230026)=20 > Mobile: +86-13505693311 Tel: +86-551-3601897 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From repenno@cisco.com Fri Mar 23 05:10:52 2012 Return-Path: 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 D003921F850B for ; Fri, 23 Mar 2012 05:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.153 X-Spam-Level: X-Spam-Status: No, score=-9.153 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 C+R0NXWWVaw0 for ; Fri, 23 Mar 2012 05:10:47 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 047FB21F8505 for ; Fri, 23 Mar 2012 05:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=6517; q=dns/txt; s=iport; t=1332504647; x=1333714247; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=G6TYyFbHTZXl89rjZ2kfCMyHoTrpG4+B539E0z5Nvog=; b=FWSCsSSiGUpiISGGaU/Rj4+ojsjG1bOXoo/Exl/QtdKL0xA+jx2L1Njj x0QyybqRFlBauVHiMuDn/Iem+1JB13YMvcRDvdSypDWUrNyfqpPXOfROg QiwVdt/ib4JsTmqaeAhDryLZMHj+AiZ/IfFxcacqicujErSMw+MVDG29d M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYHALFnbE+rRDoJ/2dsb2JhbABDgk9ItAF4gQeCCQEBAQQBAQEPASoxBgUTCA4DAQIBAgFPBiIGCAYOBSKHZwyedpcTBIltdoYiBIhXjQmFboVCgxSBaIMHgTw X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208,217";a="37367695" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Mar 2012 12:10:46 +0000 Received: from [10.21.72.225] ([10.21.72.225]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2NCATl1027224; Fri, 23 Mar 2012 12:10:39 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 23 Mar 2012 05:10:28 -0700 From: Reinaldo Penno To: Congxiao Bao Message-ID: Thread-Topic: [Softwires] Path to move forward with 4rd In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415324246_10421977" Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:10:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415324246_10421977 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thank you. I believe the answer to my question is 'no'. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee Cc: Zhang Huanjie , Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno > Is there experimental data for MAP running on production networks? > Certainly that is an important point to consider. > > On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: > >> > >> > >> >4rd-U is in the very early design stage, there is no running code. In >> >addition, it tries to modify the IPv6 address architecture. We need to >> >see the experimental data before making any decision. >> > >> >-- >> >Zhang Huanjie >> >E-mail/msn: james@ustc.edu.cn >> > >> >_______________________________________________ >> >Softwires mailing list >> >Softwires@ietf.org >> >https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3415324246_10421977 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Thank you.  I believe t= he answer to my question is  'no'. 

Still= , it is good to see that you are planning to deploy MAP-T.  It is certa= inly an important data point.

Do you plan to substi= tute dIVI and dIVI-PD by MAP-T or run them in parallel?  
From: Congxiao Bao <cx.cernet@gmail.com>
Date: Fri, 23 Mar 2012 18:04:47 +0800
To: Cisco Employee <repenno@cisco.com>
Cc: Zhang Huanjie <james@ustc.edu.cn>, Softwires WG <softwires@ietf.o= rg>
Subject: Re: [Softwires= ] Path to move forward with 4rd

Hi Penno,
 
MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at Chi= na Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last Septe= mber. BTW, the MAP-T code will be available soon.
<= /font> 
<= span lang=3D"EN-US">Congxiao


201= 2/3/23 Reinaldo Penno <repenno@cisco.com>
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <james@ustc.edu.cn> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to<= br> >see the experimental data before making any decision.
>
>--
>Zhang Huanjie
>E-mail/msn: james@ustc.edu.cn >
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@iet= f.org
https://www.ietf.org/mailman/listinfo/softwires

 --B_3415324246_10421977-- From wdec.ietf@gmail.com Fri Mar 23 05:26:53 2012 Return-Path: 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 B46F421F8526 for ; Fri, 23 Mar 2012 05:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 KjjX2ojVqd9D for ; Fri, 23 Mar 2012 05:26:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22821F84EF for ; Fri, 23 Mar 2012 05:26:49 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2234420qcs.31 for ; Fri, 23 Mar 2012 05:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OVwXUUqoIb3tq8GuOFoZPchlYNeNe+IqCrfGIJq1ZM0=; b=jYyQMjwBkqMIIHQWpTiQgUd1ncknP+O/k/EACI7pZsJHDSRY1PelKU/Wqt55T8U/yM yjhfou94XUElLO6tdAvu5/NXBya9hEDAxRkkDI94Fpe5bHxd0lLhkKrkWg1h0myZg2Yc TrO0TPDTVH5d7oZ+OrNbPQcIHS4Sif/+TJjHcX7MbVgpDHFyEvRbOf0/tbRsODBXUKMJ 9mLEpp1P3DM1wqoZ9S5HYsz/q/LT6dYn3nC+L/DCoZ4C43gKo54HsYj+hfa22/B51LrJ SFDwEUa+qndGmccK6GUmdaXPQy9v7U+uZpovpcWefeq20qsCqXHIpRtH1q/eOcU7D0uK hwuA== MIME-Version: 1.0 Received: by 10.224.101.69 with SMTP id b5mr15576624qao.25.1332505608789; Fri, 23 Mar 2012 05:26:48 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Fri, 23 Mar 2012 05:26:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 13:26:48 +0100 Message-ID: From: Wojciech Dec To: Reinaldo Penno Content-Type: multipart/alternative; boundary=20cf30667fc7791db104bbe823d6 Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:26:53 -0000 --20cf30667fc7791db104bbe823d6 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 23 March 2012 13:10, Reinaldo Penno wrote: > Thank you. I believe the answer to my question is 'no'. > divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of "on-the-wire" encoding would not appear to have any tangible effect on experimental data collected for divi. Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 -Woj. > > Still, it is good to see that you are planning to deploy MAP-T. It is > certainly an important data point. > > Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in > parallel? > > From: Congxiao Bao > Date: Fri, 23 Mar 2012 18:04:47 +0800 > To: Cisco Employee > Cc: Zhang Huanjie , Softwires WG > > Subject: Re: [Softwires] Path to move forward with 4rd > > Hi Penno, > > MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 > for two years and have been tested at China Telcom both in Beijing and > Hunan last year. In addition, the dIVI-PD was demonstrated successfully in > Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code > will be available soon. > > Congxiao > > > 2012/3/23 Reinaldo Penno > >> Is there experimental data for MAP running on production networks? >> Certainly that is an important point to consider. >> >> On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: >> >> > >> > >> >4rd-U is in the very early design stage, there is no running code. In >> >addition, it tries to modify the IPv6 address architecture. We need to >> >see the experimental data before making any decision. >> > >> >-- >> >Zhang Huanjie >> >E-mail/msn: james@ustc.edu.cn >> > >> >_______________________________________________ >> >Softwires mailing list >> >Softwires@ietf.org >> >https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf30667fc7791db104bbe823d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 23 March 2012 13:10, Reinaldo Penn= o <repenno@cisco.= com> wrote:
Thank you. =A0I believe the answer to my question is =A0'no= '.=A0

divi and divi-pd and MAP-T are e= ssentially the same, algorithmically, ie with the MAP algorithm and certain= paramaters set (eg M=3D1) they are the same. The difference of "on-th= e-wire" encoding would not appear to have any tangible effect on exper= imental data collected for divi.
Eg http:/= /tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02

-Woj.
<= blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Still, it is good to see that you are planning t= o deploy MAP-T. =A0It is certainly an important data point.

<= /div>
Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in par= allel? =A0

From: Congxiao Bao <cx.cernet@gmail.com>Date: Fri, 23 Mar 2012 18:04:47 = +0800
To: Cisco Employee <repenno@cisco.com>
Cc: Zhang Huanjie <james@ustc.edu.cn>, Softwir= es WG <softwires= @ietf.org>

Subject: Re: [Softwires] Path = to move forward with 4rd

Hi Penno,
= =A0
MAP-T was de= rived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at Chi= na Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last Septe= mber. BTW, the MAP-T code will be available soon.
=A0
Congxiao


2012/3/23 Reinaldo Penno <repenno@cisco.com>
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <james@ustc.edu.cn> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to<= br> >see the experimental data before making any decision.
>
>--
>Zhang Huanjie
>E-mail/msn: jame= s@ustc.edu.cn
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.= org
>https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--20cf30667fc7791db104bbe823d6-- From repenno@cisco.com Fri Mar 23 05:40:32 2012 Return-Path: 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 3362B21F84EF for ; Fri, 23 Mar 2012 05:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.944 X-Spam-Level: X-Spam-Status: No, score=-8.944 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 3ddoQQX7fAw1 for ; Fri, 23 Mar 2012 05:40:27 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6021F84E2 for ; Fri, 23 Mar 2012 05:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=10712; q=dns/txt; s=iport; t=1332506427; x=1333716027; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=io7/dkSkrvz/pMCS+WUB2clF0Y7zWqRNmOboLfYX/xI=; b=Zp/yGs+R0UbiwSPHXDjWan9VRI3iUpREBt12yu02537Exg6c1FIfU1U4 HhTqREkujeeatgoFrRGdijnhKvM0/jF4073eOQibwy3xLgSmBokX6EVOE Ap76vN1t+mHhwkTpZCBaAFT1YMBOSXPlgxFgvVHDzEWmZvEAgaDP7FGfn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYHAPtubE+rRDoJ/2dsb2JhbABEgkZIq30BiAN4gQeCCQEBAQQBAQEPASoxBgUTCA4DAQIBAgFPBiIGCAYOBSKHZwyZSZ59iW12hiIEiFeNCYVuhUKDFIFogweBPA X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208,217";a="37278500" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 23 Mar 2012 12:40:27 +0000 Received: from [10.21.72.225] ([10.21.72.225]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2NCeBHQ012182; Fri, 23 Mar 2012 12:40:20 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 23 Mar 2012 05:40:09 -0700 From: Reinaldo Penno To: Wojciech Dec Message-ID: Thread-Topic: [Softwires] Path to move forward with 4rd In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415326027_10530101" Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:40:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415326027_10530101 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Wojciech Dec Date: Fri, 23 Mar 2012 13:26:48 +0100 To: Cisco Employee Cc: Congxiao Bao , Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd Hi, On 23 March 2012 13:10, Reinaldo Penno wrote: > Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of "on-the-wire" encoding would not appear to have any tangible effect on experimental data collected for divi. [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essentially the same? Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 [RP] I will read it and provide feedback. Thanks for the pointer. -Woj. > > Still, it is good to see that you are planning to deploy MAP-T. It is > certainly an important data point. > > Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? > > From: Congxiao Bao > Date: Fri, 23 Mar 2012 18:04:47 +0800 > To: Cisco Employee > Cc: Zhang Huanjie , Softwires WG > > Subject: Re: [Softwires] Path to move forward with 4rd > > Hi Penno, > > MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for > two years and have been tested at China Telcom both in Beijing and Hunan last > year. In addition, the dIVI-PD was demonstrated successfully in Softwire > Interim Meeting in Beijing last September. BTW, the MAP-T code will be > available soon. > > Congxiao > > > 2012/3/23 Reinaldo Penno >> Is there experimental data for MAP running on production networks? >> Certainly that is an important point to consider. >> >> On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: >> >>> > >>> > >>> >4rd-U is in the very early design stage, there is no running code. In >>> >addition, it tries to modify the IPv6 address architecture. We need to >>> >see the experimental data before making any decision. >>> > >>> >-- >>> >Zhang Huanjie >>> >E-mail/msn: james@ustc.edu.cn >>> > >>> >_______________________________________________ >>> >Softwires mailing list >>> >Softwires@ietf.org >>> >https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --B_3415326027_10530101 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Fri, 23 Mar 2012 13:26:48 +0100
To: Cisco Employee <rep= enno@cisco.com>
Cc: Congxia= o Bao <cx.cernet@gmail.com>, = Softwires WG <softwires@ietf.org&= gt;
Subject: Re: [Softwires] Path = to move forward with 4rd

Hi,

On 23 March 2012 13:10, Reinaldo Penno <repenno@cisco.com> wrote:
Thank you.  I believe the answer to my que= stion is  'no'. 

divi and divi-pd= and MAP-T are essentially the same, algorithmically, ie with the MAP algori= thm and certain paramaters set (eg M=3D1) they are the same. The difference of= "on-the-wire" encoding would not appear to have any tangible effect on expe= rimental data collected for divi.

[RP= ] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs i= nteroperate given they are essentially the same?


[RP] I will read it and provide feedback. Thanks = for the pointer.


-Woj.
=

Still, it is good to see that you are planning to de= ploy MAP-T.  It is certainly an important data point.

Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in p= arallel?  

From: Congxiao Bao <cx.cernet@gmail.com>
Date: Fri, 23 Mar 2012 18:04:47 +0800
To: Cisco Employee <repenno@cisco.com>
Cc: <= /span> Zhang Huanjie <= james@ustc.edu.cn>, Softwires WG <softwires@ietf.org>

Subject: Re: [Softwires] Path to move forward w= ith 4rd

Hi Penno,
<= div style=3D"margin:0cm 0cm 0pt" class=3D"MsoNormal"> 
MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at Chi= na Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last Septe= mber. BTW, the MAP-T code will be available soon.
<= /font> 
<= span lang=3D"EN-US">Congxiao


201= 2/3/23 Reinaldo Penno <repenno@cisco.com>
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <james@ustc.edu.cn> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to<= br> >see the experimental data before making any decision.
>
>--
>Zhang Huanjie
>E-mail/msn: james@us= tc.edu.cn
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


______= _________________________________________
Softwires mailing list
Softwires@iet= f.org
https://www.ietf.org/mailman/listinfo/softwires


 --B_3415326027_10530101-- From wdec.ietf@gmail.com Fri Mar 23 05:46:58 2012 Return-Path: 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 6F6A721F84DC for ; Fri, 23 Mar 2012 05:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 yZ+t4e5Ro0-w for ; Fri, 23 Mar 2012 05:46:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0621F84DF for ; Fri, 23 Mar 2012 05:46:53 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2248526qcs.31 for ; Fri, 23 Mar 2012 05:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sBx6f/QvzDDqUA8R/zAQwaAbkCsuk8je36WlYXJgSFE=; b=Z6ez9H0I+HZlKZt5hPq+r4r1CDSAHs1pNB7b8BkLT3jcB4102vBSvbB3Jy380qhbCd BnXwNJZnvpgALzcQiWV2ye7YJKRwPtF7ZMDtZN+E9xAgmj5dOFT1y6Qp3z4g/ppO5ax+ Pxyrv7kXfzi6XCEaddxxh1efO2dpnWzbicIGwB6ASv7m3fUxQwRywMLj2AaQOMxsjFDz V/sPwUXqVvMeRgOcj3egWuSB6UMl5PV7SufEgxeBghPxUwoxqacdu63182boHTlpXilZ ve9y91IyYtURCWI1ZkEi1BliCrQYx9L28BlPQwb9KyaH1LemPJNTNpZb7V+HdwrGTYbe Gtbw== MIME-Version: 1.0 Received: by 10.224.59.7 with SMTP id j7mr15789005qah.38.1332506813595; Fri, 23 Mar 2012 05:46:53 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Fri, 23 Mar 2012 05:46:53 -0700 (PDT) In-Reply-To: <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> Date: Fri, 23 Mar 2012 13:46:53 +0100 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f74de48ffd004bbe86bbb Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:46:58 -0000 --20cf306f74de48ffd004bbe86bbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19 March 2012 14:22, R=E9mi Despr=E9s wrote: > Hi, Xing, > > I look forward to face to face discussions in Paris if we don't clarify > everything before that (I will be busy on something else in the next 3 > days). > > > Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : > ... > > > A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE > node, when it receives no 4rd mapping rule, to exercise single translatio= n. > Actually, I believe that using for this the BIH of RFC6535 is both > sufficient and recommendable. > Translated IPv4 packets, because they are sent from CE nodes to DNS64 > synthesized addresses, are appropriately routed to their destinations. (I= t > can be via the NAT64-CGN if needed, or via more direct paths if possible.= ) > Anything missed? > > > Sorry, this is a misunderstanding. > Hint: Single translation and double translation are based on the same > mapping rule in the CERNET2 deployment. > > > I am well aware of this, but this doesn't explain why 4rd mapping rules > similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 > communication (single translation) supported". > > As said in RFC6219, CERNET hosts have their IPv6 addresses configured "vi= a > manual configuration or stateful autoconfiguration via DHCPv6". > Hosts can therefore be assigned Interface IDs that have the 4rd-u format > (with V octet and CNP). > > Now, when both addresses happen to be checksum neutral, RFC6145 > translation doesn't modify L4 data, so that it doesn't matter whether the > DS node has used 4rd-u header mapping or single translation. > Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd > CE nodes. > If those packets are UDP checksum 0, the IPv6 host would either need to be customized, or something else would need to changed/configured on the 4rd-u CE specifically to get that to work for specific IPv6 destinations, while with MAP-t this would be transparent (and not require specific forwarding rules). -Woj. > > Regards, > RD > > > > > > > > Regards, > > xing > > > > Regards, > RD > > > > > > Regards, > > xing > > > > Regards, > RD > > > > > > Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : > ... | | | | | > > | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | > | | packets | | | | | > > suggest you rename to "IPv4 to IPv6 communication (single translation) s= upported" > > > > (2) More clarification should be added here. I am not sure 4rd-H can > support single translation. > > (a) According to (1), 4rd-H does not perform header translation defined b= y > RFC6145. > > (b) In the softwire mailing list, it seems that 4rd-H cannot support > single translation. See the thread containing > http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and > other posts. > > (c) If 4rd-H cannot support single translation, then "IPv6 web caches wor= k > for IPv4 packets" requires special configurations, it cannot do IPv6 web > caches for non 4rd-H packets. > > > ... > > (5) I would like to see the details of how 4rd-H handles ICMP and ICMP > error messages. In the softwire mailing list there were some discussions.= See > the thread containing > http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and > other posts. Please add > > | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | > > ... > > > > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf306f74de48ffd004bbe86bbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 19 March 2012 14:22, R=C3=A9mi Despr= =C3=A9s <d= espres.remi@laposte.net> wrote:
Hi, Xing,

I look for= ward to face to face discussions in Paris if we don't clarify everythin= g before that (I will be busy on something else in the next 3 days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a =C3= =A9crit :
...

=C2=A0A key point is that 4rd doesn't prevent a=C2=A04rd-c= apable dual-stack CE node,=C2=A0when it receives no 4rd mapping rule, to exercise single translation.=C2=A0
=C2=A0Actually, I believe that using for this the BIH of RFC65= 35 is both sufficient and recommendable.
=C2=A0Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

I am well aware of this, but this=C2=A0doesn't explain= why 4rd mapping rules similar to those of CERNET2 wouldn't have, like = MAP-T, "IPv4 to IPv6 communication (= single translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 addresses config= ured "via manual configuration or stateful autoconfiguration via DHCPv= 6".
Hosts can therefore=C2=A0be assigned Interface IDs that have the 4rd-u format (w= ith V octet and CNP).
Now, when both addresses happen to b= e checksum neutral, RFC6145 translation doesn't modify L4 data, so that= it doesn't matter whether the DS node has used 4rd-u header mapping=C2= =A0or single translation.=C2=A0
Thus,=C2=A0IPv6-only hosts can exchange=C2=A0packets with IPv4 applications of 4rd CE nodes.=C2=A0

If those packets are UDP checksum 0, the IPv6 host wo= uld either need to be customized, or something else would need to changed/c= onfigured on the 4rd-u CE specifically to get that to work for specific IPv= 6 destinations, while with MAP-t this would be transparent (and not require= specific forwarding rules).

-Woj.
=C2=A0

Regards,
RD

=






=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
=C2=A0




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :=
... | | | | |
  |  5 | IPv6 web caches work for IPv4    =
    |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 com=
munication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.=C2= =A0 See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configuration= s, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail= -archive/web/softwires/current/msg03324.html and other posts. Plea= se add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ?=
 |
...







______________________________= _________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--20cf306f74de48ffd004bbe86bbb-- From wdec.ietf@gmail.com Fri Mar 23 06:02:07 2012 Return-Path: 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 9AAD621F8514 for ; Fri, 23 Mar 2012 06:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hMM6MGxb4D62 for ; Fri, 23 Mar 2012 06:02:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7421F850C for ; Fri, 23 Mar 2012 06:02:00 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2259751qcs.31 for ; Fri, 23 Mar 2012 06:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ySclvc/A/NDfOmNAWJC3rwEeXrEQeckaHMpWl6esYcA=; b=IZSJS+3B7IbQogxLRsjLf7oY7If3617bRAcfP3tiz+H9/xn61yeOciQ33Z2x/8qLTu uymyJkuP8Kk+1v4yTckgTAFpk0p3GUogfrmnUsUJnWbS66BQob0tYK/XPCXZnVK5ZzAT sbBYPQ/+flb53V7/UFb8PtjhCnLsqENPUEsiWGjo0Lv0c5l8tKRj+QXo5KTzjwwEuKbX tvrGTEjwjIG3+uVsY5D0bBVmNxsDBZcpINqvWgJP+T7+4xElXoCs6mf20fY2vyYPKfAG KhGBEW8g6W/OkXz80PdXWg8PQNGJ+xm1V85hyS8PDa2OwAfA5G+uu8AvO5lzlqteSXNJ yvJg== MIME-Version: 1.0 Received: by 10.224.101.69 with SMTP id b5mr15718633qao.25.1332507720059; Fri, 23 Mar 2012 06:02:00 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Fri, 23 Mar 2012 06:01:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 14:01:59 +0100 Message-ID: From: Wojciech Dec To: Reinaldo Penno Content-Type: multipart/alternative; boundary=20cf30667fc7508a0c04bbe8a19f Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:02:07 -0000 --20cf30667fc7508a0c04bbe8a19f Content-Type: text/plain; charset=ISO-8859-1 On 23 March 2012 13:40, Reinaldo Penno wrote: > > > From: Wojciech Dec > Date: Fri, 23 Mar 2012 13:26:48 +0100 > To: Cisco Employee > Cc: Congxiao Bao , Softwires WG > > Subject: Re: [Softwires] Path to move forward with 4rd > > Hi, > > On 23 March 2012 13:10, Reinaldo Penno wrote: > >> Thank you. I believe the answer to my question is 'no'. >> > > divi and divi-pd and MAP-T are essentially the same, algorithmically, ie > with the MAP algorithm and certain paramaters set (eg M=1) they are the > same. The difference of "on-the-wire" encoding would not appear to have any > tangible effect on experimental data collected for divi. > > [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T > hosts/CPEs interoperate given they are essentially the same? > Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the "on-the-wire" encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. > > > Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 > > > [RP] I will read it and provide feedback. Thanks for the pointer. > > > -Woj. > >> >> Still, it is good to see that you are planning to deploy MAP-T. It is >> certainly an important data point. >> >> Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in >> parallel? >> >> From: Congxiao Bao >> Date: Fri, 23 Mar 2012 18:04:47 +0800 >> To: Cisco Employee >> Cc: Zhang Huanjie , Softwires WG >> >> Subject: Re: [Softwires] Path to move forward with 4rd >> >> Hi Penno, >> >> MAP-T was derived from dIVI and dIVI-PD, which has been running at >> CERNET2 for two years and have been tested at China Telcom both in Beijing >> and Hunan last year. In addition, the dIVI-PD was demonstrated successfully >> in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code >> will be available soon. >> >> Congxiao >> >> >> 2012/3/23 Reinaldo Penno >> >>> Is there experimental data for MAP running on production networks? >>> Certainly that is an important point to consider. >>> >>> On 3/22/12 11:06 PM, "Zhang Huanjie" wrote: >>> >>> > >>> > >>> >4rd-U is in the very early design stage, there is no running code. In >>> >addition, it tries to modify the IPv6 address architecture. We need to >>> >see the experimental data before making any decision. >>> > >>> >-- >>> >Zhang Huanjie >>> >E-mail/msn: james@ustc.edu.cn >>> > >>> >_______________________________________________ >>> >Softwires mailing list >>> >Softwires@ietf.org >>> >https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --20cf30667fc7508a0c04bbe8a19f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 23 March 2012 13:40, Reinaldo Penno <= span dir=3D"ltr"><repenno@cisco.com= > wrote:


From: Wojciech Dec <wdec.ietf@gmail.com>Date: Fri, 23 Mar 2012 13:26:48 = +0100
To: Cisco Employee <repenno@cisco.com>
Cc: Congxiao Bao <cx.cernet@gmail.com>, Soft= wires WG <softwi= res@ietf.org>

Subject: Re: [Softwires] Path = to move forward with 4rd

Hi= ,

On 23 March 2012 13:10, Reinaldo Penno = <repenno@cisco.com> wrote:
Thank you. =A0I believe the answ= er to my question is =A0'no'.=A0

divi and divi-pd and MAP-T are essentially the = same, algorithmically, ie with the MAP algorithm and certain paramaters set= (eg M=3D1) they are the same. The difference of "on-the-wire" en= coding would not appear to have any tangible effect on experimental data co= llected for divi.

[RP] Interesting, thanks for the cla= rification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essen= tially the same?

Well, MAP-T and divi-pd i= n non-address-sharing mode (ie 1:1) should be totally compatible. However, = given that the "on-the-wire" encoding of the PSID is different in= the address sharing mode, interoperability in that mode won't be there= .

Cheers,
Woj.

=


[RP] I will read it and pro= vide feedback. Thanks for the pointer.


-Woj.<= br>

Still, it is good to see that you are planning to deplo= y MAP-T. =A0It is certainly an important data point.

Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in paral= lel? =A0

From: Congxiao Bao <cx.cernet@gmail.com>Date: Fri, 23 Mar 2012 18:04:47 = +0800
To: Cisco Employee <repenno@cisco.com>
Cc: Zhang Huanjie <james@ustc.edu.cn>, Softwir= es WG <softwires= @ietf.org>

Subject: Re: [Softwires] Path = to move forward with 4rd

Hi Penn= o,
= =A0
MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at Chi= na Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last Septe= mber. BTW, the MAP-T code will be available soon.
=A0
Congxiao


2012/3/23 Reinaldo Penno <repenno@cisco.com>
Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <james@ustc.edu.cn> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In >addition, it tries to modify the IPv6 address architecture. We need to<= br> >see the experimental data before making any decision.
>
>--
>Zhang Huanjie
>E-mail/msn: jame= s@ustc.edu.cn
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.= org
>https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires


___________= ____________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires



--20cf30667fc7508a0c04bbe8a19f-- From despres.remi@laposte.net Fri Mar 23 06:51:31 2012 Return-Path: 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 88DE921F8594 for ; Fri, 23 Mar 2012 06:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 TjtYbE528-ro for ; Fri, 23 Mar 2012 06:51:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A855E21F858E for ; Fri, 23 Mar 2012 06:51:24 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6F09E940195; Fri, 23 Mar 2012 14:51:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2867C95F@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Mar 2012 14:51:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <172A95A2-98A9-4D3B-A813-86C55E137F5A@laposte.net> References: <94C682931C08B048B7A8645303FDC9F36E2867C95F@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Path to move forward with 4rd. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:51:31 -0000 Le 2012-03-23 =E0 11:13, = a =E9crit : > Dear WG members, >=20 > I didn't had time to read the last version of 4rd-U but I read = carefully -03 when it was published.=20 Note that -04 and -05 are significantly improved. Expertise of its now co-authors include broadband and mobile services as = ell as product vendors. AFAIK, no reason why it wouldn't work, or do less than claimed, remained = unanswered. If later on a flaw or uncertainty is identified, and confirmed after = discussion, this will be fairly acknowledged. > I really appreciated the work done by R=E9mi to write down -03. The = document is well written, easy to read and the requirements are clearly = sketched. I really think this spirit should be adopted by MAP documents. >=20 > As I already told R=E9mi, I would like if all proponents of stateless = A+P converge and avoid wasting energies in comparing individual = proposals. I thought this is what has been agreed during the softwire = interim meeting: IMO, MAP effort meets the objective of group work. >=20 > Some of the points raised by R=E9mi can be easily considered in the = context of MAP; except the idea of unified header which is a step = forward. Adopt a unified approach is exclusive to encapsulation and/or = translation.=20 >=20 > The question now is: Does the unified approach bring new features + = simplification compared to the normal IPv4-in-IPv6 encapsulation scheme = (which I'm mainly interested in)? The answer is: No.=20 >=20 > Perhaps this is selfish but given what I mentioned above, I vote for = the following: > * Adopt the work of the MAP design team as the base specification for = stateless A+P effort. >=20 > * Make sure proposals from R=E9mi (except U) are discussed: This may be taken as "I don't care how many designs are standardized... = provided my use case is covered by one of them".=20 This is not AFAIK the best approach to simplify standards we make for = the future. The chair encouraged further work on U after IETF 82 after arguments = used to exclude it in Taipei were acknowledged to be invalid.=20 Excluding to discuss U although it provides a unified design, with more = operational features than either T or E, seems to me difficult to = justify. Regards, RD > e.g., Checksum neutrality > (1) Share the archives of MAP Design Team discussion > (2) Use IETF Issue Tracker to record the issues and the = consensus/conclusion > (3) Adopt a clear procedure within the Design Team to make decisions = when there are conflicts >=20 > * Reduce the amount of MAP documents: IMHO, three documents are needed > (1) MAP Address Format > (2) MAP Overall Architecture and Design Recommendations > (3) MAP DHCPv6 Options >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de Alain Durand >> Envoy=E9 : mardi 20 mars 2012 00:39 >> =C0 : Softwires WG >> Cc : Yong Cui; Ralph Droms >> Objet : [Softwires] Path to move forward with 4rd. >>=20 >> Dear wg, >>=20 >> After a number of discussions with my co-chair, our AD and=20 >> various authors, here is how we would like to move forward wrt 4rd. >>=20 >> 1) There is an observation that all the solutions on the=20 >> table E, T & U actually solve the stateless problem we started with. >> There are differences, but it is unclear if those=20 >> differences are really significant. E and T are the original=20 >> Encapsulation and Translation >> proposals, U is an hybrid unifying solution. >>=20 >> 2) We have already agreed back in Beijing that we would=20 >> publish all necessary documents. The issue here is the 'label'=20 >> or 'status' those >> documents have at IETF. In particular, do we want to=20 >> publish them as Experimental, Informational or Standard Track. >>=20 >> We are at the point now where we need to make progress. In=20 >> Paris, we would like to ask for presentations from the=20 >> proponents of each candidate solution (E, T & U). >> Each presentation should cover an overview of the proposed=20 >> solution, explain how it compares to the others and make a=20 >> case as why it should be the one on the Standard Track. We=20 >> will allocate 20 minutes for each presentation. >>=20 >> Then, we, chairs, would like to ask a series of questions to=20 >> the working group. In order to make this process transparent,=20 >> here is the list of questions we want to ask >> and their sequence. >>=20 >> Q1: Without pre-supposing which one will be selected, do you=20 >> agree to publish 1 of the 3 proposals on the Standard Track=20 >> and publish the other(s) as Informational if still asked to? >>=20 >> If the answer is NO, then the process stops and we will=20 >> publish everything as Experimental and come back in 12-24=20 >> months to see what gets adopted by the market. >> If the answer is YES, we move to the next question. >>=20 >>=20 >> Q2: Do you believe that the WG should publish U as the one=20 >> Standards Track document? >>=20 >> If the answer is YES, the process stop, we put U on the=20 >> Standard Track and publish E & T as Informational. >> If the answer is NO, we are left with E & T (U then might be=20 >> abandoned or published as Historical/Informational) >>=20 >>=20 >> Q3: Which of E and T do you want to see moving on the standard=20 >> track (you can only express support for one)? >>=20 >> If there is a clear outcome from this question, we would=20 >> publish that proposal on the Standard Track and the other one=20 >> as Informational. >> If there is no clear consensus on this question, we will=20 >> publish both E & T as Experimental. >>=20 >> In the meantime, we would like to encourage discussion on the=20 >> mailing list to foster our common understanding of the various=20 >> technologies and how they relate to each other. >>=20 >> Alain & Yong, wg co-chairs. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Mar 23 06:55:30 2012 Return-Path: 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 CACFE21F84CD for ; Fri, 23 Mar 2012 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 d0fo8ZCu-gRO for ; Fri, 23 Mar 2012 06:55:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C68CA21F854F for ; Fri, 23 Mar 2012 06:55:24 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6952E94011F; Fri, 23 Mar 2012 14:55:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--131096490 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 14:55:05 +0100 Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:55:30 -0000 --Apple-Mail-5--131096490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Wojciech, Are you suggesting that T would work with IPv4 packets having UDP = checksum =3D 0? RFC6145 says that IPv4 packets with UDP checksum =3D 0 are either always = discarded, or optionally discarded if not fragmented (with checksum = recomputed if not discarded).=20 I don't see: - how this would work with double translation - why anything should be added to U for checksum-less UDP (IPv6-only = hosts don't support it anyway). Cheers, RD Le 2012-03-23 =E0 13:46, Wojciech Dec a =E9crit : >=20 >=20 > On 19 March 2012 14:22, R=E9mi Despr=E9s = wrote: > Hi, Xing, >=20 > I look forward to face to face discussions in Paris if we don't = clarify everything before that (I will be busy on something else in the = next 3 days). >=20 >=20 > Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : > ... >>>=20 >>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE = node, when it receives no 4rd mapping rule, to exercise single = translation.=20 >>> Actually, I believe that using for this the BIH of RFC6535 is both = sufficient and recommendable. >>> Translated IPv4 packets, because they are sent from CE nodes to = DNS64 synthesized addresses, are appropriately routed to their = destinations. (It can be via the NAT64-CGN if needed, or via more direct = paths if possible.) >>> Anything missed? >>=20 >> Sorry, this is a misunderstanding.=20 >> Hint: Single translation and double translation are based on the same = mapping rule in the CERNET2 deployment. >=20 > I am well aware of this, but this doesn't explain why 4rd mapping = rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to = IPv6 communication (single translation) supported". >=20 > As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via manual configuration or stateful autoconfiguration via DHCPv6". > Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with V octet and CNP). >=20 > Now, when both addresses happen to be checksum neutral, RFC6145 = translation doesn't modify L4 data, so that it doesn't matter whether = the DS node has used 4rd-u header mapping or single translation.=20 > Thus, IPv6-only hosts can exchange packets with IPv4 applications of = 4rd CE nodes.=20 >=20 > If those packets are UDP checksum 0, the IPv6 host would either need = to be customized, or something else would need to changed/configured on = the 4rd-u CE specifically to get that to work for specific IPv6 = destinations, while with MAP-t this would be transparent (and not = require specific forwarding rules).=20 >=20 > -Woj. > =20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Regards, >>=20 >> xing >>=20 >>=20 >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Regards, >>>>=20 >>>> xing >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> RD >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >>>>> ... | | | | | >>>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y = | N | >>>>>>>> | | packets | | | = | | >>>>>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>>>>=20 >>>>>>=20 >>>>>> (2) More clarification should be added here. I am not sure 4rd-H = can support single translation. >>>>>>=20 >>>>>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>>>>=20 >>>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot = support single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. >>>>>>=20 >>>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>>>>=20 >>>>> ... >>>>>=20 >>>>>> (5) I would like to see the details of how 4rd-H handles ICMP and = ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>>>>=20 >>>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>>> ... >>>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-5--131096490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Wojciech,

Are you suggesting that T would work with = IPv4 packets having UDP checksum =3D = 0?

RFC6145 says that IPv4 packets with UDP = checksum =3D 0 are either always discarded, or optionally discarded if = not fragmented (with checksum recomputed if not = discarded). 
I don't see:
- how this would work = with double translation
- why anything should be added to U = for checksum-less UDP  (IPv6-only hosts don't support it = anyway).

Cheers,
RD



Le 2012-03-23 =C3=A0 13:46, = Wojciech Dec a =C3=A9crit :



On 19 March 2012 14:22, R=C3=A9mi Despr=C3=A9s = <despres.remi@laposte.net><= /span> wrote:
Hi, Xing,

I look = forward to face to face discussions in Paris if we don't clarify = everything before that (I will be busy on something else in the next 3 = days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a = =C3=A9crit :
...

 A key point is that 4rd doesn't prevent = a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, = to exercise single translation. 
 Actually, I believe that using for this the BIH of = RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from = CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 = deployment.

I am well aware = of this, but this doesn't explain why 4rd mapping rules similar to = those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication (single = translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 = addresses configured "via manual configuration or stateful = autoconfiguration via DHCPv6".
Hosts can therefore be assigned Interface IDs that have = the 4rd-u format (with V octet and CNP).

Now, when both addresses happen = to be checksum neutral, RFC6145 translation doesn't modify L4 data, so = that it doesn't matter whether the DS node has used 4rd-u header = mapping or single = translation. 
Thus, IPv6-only hosts can = exchange packets with IPv4 = applications of 4rd CE nodes. 

If those packets are UDP checksum 0, the IPv6 host = would either need to be customized, or something else would need to = changed/configured on the 4rd-u CE specifically to get that to work for = specific IPv6 destinations, while with MAP-t this would be transparent = (and not require specific forwarding rules).

-Woj.
 

Regards,
RD







=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit = :
... | | | | = |
  |  5 | IPv6 web caches work for IPv4  =
      |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 =
communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single = translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

= (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts. = Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? =
| ? |
...





=


_____________________________= __________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-5--131096490-- From despres.remi@laposte.net Fri Mar 23 06:59:48 2012 Return-Path: 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 088B321F852D for ; Fri, 23 Mar 2012 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 Arilt4PvFQOD for ; Fri, 23 Mar 2012 06:59:47 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4921F851D for ; Fri, 23 Mar 2012 06:59:45 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id F1CB09400BE; Fri, 23 Mar 2012 14:59:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 14:59:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2867C3C7@PUEXCB1B.nanterre.francetelecom.fr> To: Washam Fan X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:59:48 -0000 Hi, Washam, Le 2012-03-23 =E0 03:08, Washam Fan a =E9crit : > There is no text saying 4rd-u BRs are anycasted to IPv4 network in the > first place. Remi, could you clarify on this? > Thanks, > washam Not sure to understand the question. IPv4 routing toward BRs is based on IPv4 prefixes (which are anycast by = nature). RD From adurand@juniper.net Fri Mar 23 07:09:06 2012 Return-Path: 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 4370821F846E for ; Fri, 23 Mar 2012 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 dNHLuyPJCX6n for ; Fri, 23 Mar 2012 07:09:05 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2583021F844E for ; Fri, 23 Mar 2012 07:08:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT2yD7m/+aQaUrQhFdE1DDW0zSs65jqXu@postini.com; Fri, 23 Mar 2012 07:08:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 23 Mar 2012 07:06:21 -0700 From: Alain Durand To: Qiong Date: Fri, 23 Mar 2012 07:06:21 -0700 Thread-Topic: [Softwire] Algorithmic feature for SD-NAT Thread-Index: Ac0I/iAI+AwKWVM/QyClRHLP/ZKOtg== Message-ID: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:09:06 -0000 On Mar 23, 2012, at 4:22 AM, Qiong wrote: > Dear Alain and all, >=20 > I'm trying to understand sd-nat-02 and I'm still wondering how to setup s= ubscriber-based binding table in sd-nat. In my understanding, a totally sta= tic binding table will introduce a lot of workload for operators. Not necessarily. Operators maintain large database for customers, this is j= ust one more field there. The real question is how to propagate this static table to the AFTRs. This = is implementation specific, but our proposed solution is to use netconf. > But otherwise, I guess there might be an algorithmic relationship between= IPv6 and IPv4 + port range. In this way, would it become some kind of MAP,= in which IPv4 address and IPv6 address is tightly coupled and need to be p= lanned in advance ? This can be done too, but you loose the most important advantage of SD-Nat:= the absence of hard coupling between the IPv4 and IPv6 address. Not coupling both addresses enables great flexibility on how you allocate a= ddresses and port. > I'm just wondering why do we still need to maintain per-subscriber tabl= e in AFTR while still keeping stateless. Please correct me if I miss someth= ing here :=20 SD-Nat is per-flow stateless, with a per-subscriber static state. - Alain.= From yiu_lee@cable.comcast.com Fri Mar 23 07:24:30 2012 Return-Path: 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 34FE521F850F for ; Fri, 23 Mar 2012 07:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.144 X-Spam-Level: X-Spam-Status: No, score=-100.144 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 rJI6rAMdSzfa for ; Fri, 23 Mar 2012 07:24:29 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB4E21F8466 for ; Fri, 23 Mar 2012 07:24:29 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6970640; Fri, 23 Mar 2012 10:18:32 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:24:25 -0400 From: "Lee, Yiu" To: Guanghui Yu Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9?= Thread-Index: AQHNCQCkLze7Z7XapECchGi4YJplpA== Date: Fri, 23 Mar 2012 14:24:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415343060_77816" MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:24:30 -0000 --B_3415343060_77816 Content-type: multipart/alternative; boundary="B_3415343039_127155" --B_3415343039_127155 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Hi Guanghui, Just curious, how common IPv4 option is used these days? I don't have any data in-hand. Thanks, Yiu From: Guanghui Yu Date: Fri, 23 Mar 2012 13:43:07 +0800 To: "Yiu L. LEE" Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd=A9 it cannot support IPv4 option.=20 --B_3415343039_127155 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable
Hi Guanghui,

<= /div>
Just curious, how common IPv4 option is used these days? I don't h= ave any data in-hand.

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>
Date: Fri, 23 Mar 2012 13:43:07 +0800
To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd=A9

= it cannot support IPv4 option.  --B_3415343039_127155-- --B_3415343060_77816 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQLmpRO 1rJzxDuVbI5pkf1ydVWAZjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMxNDIzNTlaMA0GCSqGSIb3DQEBAQUABIIBAFg0UBJ+mCcsXdlKGw185oFh uSDcCaVNCikNsyzE9+QeVK31pkrckGSuYQUFdpK+U64HhqT8WOyzAtNgQhbLPXAf/7GTFdSo 9EakuAYda+mM72x2sfnp91fI4iHmVB8R+QiTpgwKvZiojF9wSDDVkaqYwlL5gqVuhBXK4PDK SlVjdZ341jRtHBtR075JFxYCXzBIaGjzMWbfTTE0ocDDcrhzKXtxR25ji94Qe65OG6kb5J3d Gk0m3CJlh3MJ9L4eMPxeoav8lZGo/OsMafqAk2VcR7FeELQcavQTZLXU+2wz2ICNPnRYLS+u v7wJplgQMXaQ8YFsS/9nHxvpnbknDiY= --B_3415343060_77816-- From yiu_lee@cable.comcast.com Fri Mar 23 07:29:03 2012 Return-Path: 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 4A67921F84B2 for ; Fri, 23 Mar 2012 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.277 X-Spam-Level: X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 NQiV+u3OboKk for ; Fri, 23 Mar 2012 07:29:02 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 63DAD21F84AA for ; Fri, 23 Mar 2012 07:29:02 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.10629943; Fri, 23 Mar 2012 08:16:54 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 10:28:57 -0400 From: "Lee, Yiu" To: Guanghui Yu Thread-Topic: =?iso-8859-2?Q?[Softwires]_Path_to_move_forward_with_4rd=A9?= Thread-Index: AQHNCQFHLze7Z7XapECchGi4YJplpA== Date: Fri, 23 Mar 2012 14:28:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415343335_103432" MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] =?iso-8859-2?q?Path_to_move_forward_with_4rd=A9?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:29:03 -0000 --B_3415343335_103432 Content-type: multipart/alternative; boundary="B_3415343334_130994" --B_3415343334_130994 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Hi Guanghui, Is the original use case for MAP is to deliver v4 over v6 in a stateless fashion in the network? This is stated in the stateless-requirements draft. If we can get v4-v6 (single translation) for free, I am all for it. But thi= s isn't the original requirements we are trying to solve. Right? Thanks, Yiu From: Guanghui Yu Date: Fri, 23 Mar 2012 13:43:07 +0800 To: "Yiu L. LEE" Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd=A9 4rd-U cannot replace MAP-T, since it cannot support single translation. --B_3415343334_130994 Content-type: text/html; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable
Hi Guanghui,

<= /div>
Is the original use case for MAP is to deliver v4 over v6 in a sta= teless fashion in the network? This is stated in the stateless-requirements = draft. If we can get v4-v6 (single translation) for free, I am all for it. B= ut this isn't the original requirements we are trying to solve. Right?
=

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>
Date:= Fri, 23 Mar 2012 13:43:07 +0800
T= o: "Yiu L. LEE" <yiu_l= ee@cable.comcast.com>
Cc: S= oftwires WG <softwires@ietf.org&g= t;
Subject: Re: [Softwires] Path t= o move forward with 4rd=A9

 4rd-U cannot replace MAP-T, since it cannot support single translati= on.


--B_3415343334_130994-- --B_3415343335_103432 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSq3rUM 5rhj8rhL/Qpv3oMOo2xp2TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMxNDI4NTRaMA0GCSqGSIb3DQEBAQUABIIBAGzlQsnKNoRb4njv2kvcl0m0 u0srawtX0otARvq/fXmMpHsgcJUU/UbhGy6Il8toYPptnI44VdYygEnbB2Sllfbe8kc9pk5s /Y4VtW5Xeklm4YqX8+upccP3ZkGo5APqCvAXmubL1XXIhZprJNeKeG9FkuR4B5mW/6bQ/GbU nVJUWBTSYsu8+a2T4tG6Xtu7C2nDg/bmNYY9VV+BXXBVcPGcNW6RAZ2qrvKQnJoc0G6SbnFF nXUbK+SrnGlnSkT1j9JAs1EO1LA2fhMq1B8OYm5s5JZHfe5+YP2c5Gafl8YnSUlV9gh7jrik loGV0+WmgTGATbs+291iiFfu0Acu+F8= --B_3415343335_103432-- From despres.remi@laposte.net Fri Mar 23 09:12:28 2012 Return-Path: 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 ABDC721F85D2 for ; Fri, 23 Mar 2012 09:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] 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 KxUOOdS3j0q6 for ; Fri, 23 Mar 2012 09:12:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A594321F85C9 for ; Fri, 23 Mar 2012 09:12:21 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id C8241940184; Fri, 23 Mar 2012 17:12:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--122897870 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 17:11:43 +0100 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 16:12:28 -0000 --Apple-Mail-6--122897870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-22 =C3=A0 15:40, Maoke a =C3=A9crit : > dear Alain, Yong, Ralph and all, >=20 > in program, the effort of the MAP team should be respected. The = formation of the MAP team was also the consensus of our meeting in = beijing and we have seen the the team is working with clear progress. I = don't think it is correct now to insert 4rd-u into a sort of exclusive = decision of choice. And 4rd-u also has the address format elements = abondoned by the MAP design team. I believe the MAP format reflects that = the common understanding concludes the insignificance of those features. = Sorry but the chair's questions a little confused me: if we need to go = back to the stage before the works of the MAP design team? =20 >=20 > The MAP series have reached running codes > and the collective understanding of the community. Here are some issues among those remaining before reaching "collective = understanding": a) T operation in hub&spoke (hasn't been so far answered in an = understandable way). b) IDs from shared-address CEs. T currently has so far no solution = while both U and E include one.=20 c) MAP-A+P says "Each MAP node in the domain has the same set of rules" = while MAP-T says "if a CE knows only a subset of the mapping rules ..." =20= d) Whether T can work with a single mapping rule (as was, I think, the = case for IVI). So far DMR and BMR seem exclusive, and there is no way to = distinguish them in MAP-dhcp. The fact that no-one involved in the MAP design raised any of these = issues is AFAIK sign that MAP has NOT reached "collective understanding = of the community". (Note that, concerning stateless v4/v6 solutions, I think I should be = considered part of this community. Right? ). Maoke, clarifications on these points will be welcome. > =46rom a view of a middle-sized ISP and cloud service provider, we do = support to accept MAP series into standard track in order we can utilize = it into business as soon as possible.=20 >=20 > in technology, first of all, MAP now has approached address mapping = algorithm and that enough to make the series a unified solution. In our = practice, we need to use either encapsulation or translation according = to the actual needs and environment. Note: This excludes ISPs that would like to offer full IPv4 transparency = with some IPv6-only middles boxes. Right? > The most important is, both the building blocks of transition = architecture: virtual link (supported by encapsulation/tunneling) and = participant of the delivery path (supported by translation), have their = suitable use cases. And their advantages and limitations have been well = investigated and understood by the community.=20 >=20 > second, i deeply discussed and explored 4rd-u, but i found its = attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable = to define what building block it really is. Such an operator would know it uses 4rd-U.=20 This doesn't seem to justify any FUD from co-authors from broadband and = mobile operators (or from product vendors). > It is stated as tunneling but actually behaves like tunnel in some = aspects while like translation in some other aspects. Yes indeed, thus achieving the best of both worlds without making it = more complex. Actually making it clearly less complex than supporting = both T and E. > (I have pointed out in the 4rd-u discussion thread). > We see it only a yet-another-translation that try to solve some corner = problems but introduces new, possibly major flaws (also pointed out in = the technical threads on 4rd.) "Possibly major flaws" isn't an identified point on which U would do = less than what it has been designed to do (unified replacement of T + = E). IMPORTANT: =20 - The essential characterization of U (vs T and E) is its Reversible = header mapping (as replacement of both Double RFC6145 translation and = Encapsulation). - Other features of U that differ from MAP (V-octet, CNP), or are = complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this = respect. Each of these features could be abandoned in U, or, if the WG = appreciates what they offer, added to MAP. - For this, community acceptance to listen to explanations, would be the = normal process. I will be available this week for this. Cheers, RD > In either the term of architectural philosophy or technical details, = introducing 4rd-u into standards would be harmful.=20 >=20 > personally, i respect the exploration of the author(s), and the = discussion between me and the author encouraged me to comprehensively = review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward.=20 >=20 > regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP = are of a whole suite needing to be put into standard track. Question is = not about T, E or U.=20 >=20 > best regards, > Maoke >=20 > =E5=9C=A8 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF= =BC=8CAlain Durand =E5=86=99=E9=81=93=EF=BC=9A > Dear wg, >=20 > After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >=20 > 1) There is an observation that all the solutions on the table E, T & = U actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation > proposals, U is an hybrid unifying solution. >=20 > 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >=20 > We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). > Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >=20 > Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask > and their sequence. >=20 > Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >=20 > If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. > If the answer is YES, we move to the next question. >=20 >=20 > Q2: Do you believe that the WG should publish U as the one Standards = Track document? >=20 > If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational) >=20 >=20 > Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >=20 > If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both = E & T as Experimental. >=20 > In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. >=20 > Alain & Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-6--122897870 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
dear Alain, Yong, Ralph and all,

in = program, the effort of the MAP team should be respected. The formation = of the MAP team was also the consensus of our meeting in beijing and we = have seen the the team is working with clear progress. I don't think it = is correct now to insert 4rd-u into a sort of exclusive decision of = choice. And 4rd-u also has the address format elements abondoned by the = MAP design team. I believe the MAP format reflects that the common = understanding concludes the insignificance of those features. Sorry but = the chair's questions  a little confused me: if we need to go back = to the stage before the works of the MAP design team?  

The MAP series have reached running codes =

and the collective = understanding of the = community.

Here are some issues = among those remaining before reaching "collective = understanding":
a) T operation in hub&spoke (hasn't been = so far answered in an understandable way).
b) IDs from = shared-address CEs.  T currently has so far no solution = while both U and E include one. 
c) MAP-A+P says "Each = MAP node in the domain has the same set of rules" while MAP-T says "if a = CE knows only a subset of the mapping rules ..."  
d) = Whether T can work with a single mapping rule (as was, I think, the case = for IVI). So far DMR and BMR seem exclusive, and there is no way to = distinguish them in = MAP-dhcp.


The fact that = no-one involved in the MAP design raised any of these issues is AFAIK = sign that MAP has NOT reached "collective understanding of the = community".
(Note that, concerning stateless v4/v6 solutions, = I think I should be considered part of this community. Right? = ).

Maoke, clarifications on these points will = be welcome.


=46rom a view of a middle-sized ISP and cloud service = provider, we do support to accept MAP series into standard track in = order we can utilize it into business as soon as possible. 

in technology, first of all, MAP now has approached = address mapping algorithm and that enough to make the series a unified = solution. In our practice, we need to use either encapsulation or = translation according to the actual needs and environment. =

Note: This excludes ISPs that = would like to offer full IPv4 transparency with some IPv6-only middles = boxes.
Right?

The = most important is, both the building blocks of transition architecture: = virtual link (supported by encapsulation/tunneling) and participant of = the delivery path (supported by translation), have their suitable use = cases. And their advantages and limitations have been well investigated = and understood by the community. 

second, i deeply discussed and explored 4rd-u, but i = found its attempting of mixing the tunneling and translation, if = accepted as standard, may trap the operators into a harsh situation of = being unable to define what building block it really is. =

Such an operator would know it = uses 4rd-U. 
This doesn't seem to justify any = FUD from co-authors from broadband and mobile operators (or from = product vendors).

It is stated = as tunneling but actually behaves like tunnel in some aspects while like = translation in some other = aspects.

Yes indeed, thus = achieving the best of both worlds without making it more complex. = Actually making it clearly less complex than supporting both T and = E.

(I have pointed = out in the 4rd-u discussion = thread).
We = see it only a yet-another-translation that try to solve some corner = problems but introduces new, possibly major flaws (also pointed out in = the technical threads on 4rd.) =

"Possibly major flaws" isn't an = identified point on which U would do less than what it has been designed = to do (unified replacement of T + = E).

IMPORTANT:  
- The essential = characterization of U (vs T and E) is its Reversible header mapping (as = replacement of both Double RFC6145 translation and = Encapsulation).
- Other features of U that differ from = MAP (V-octet, CNP), or are complementary to it (Rule IPv6 = suffix, NAT64+), are secondary in this respect. Each of these = features could be abandoned in U, or, if the WG appreciates what = they offer, added to MAP.
- For this, community acceptance to = listen to explanations, would be the normal process. I will be = available this week for = this.

Cheers,
RD

In either the term of architectural = philosophy or technical details, introducing 4rd-u into standards would = be harmful. 

personally, i respect the exploration of the = author(s), and the discussion between me and the author encouraged me to = comprehensively review E and T, and the result is: i bacame much more = confident of the correctness of the MAP track. We should move = forward. 

regarding the chair's questions, my answer = is: MAP, MAP-E/T, = MAP-DHCP are of a whole suite needing to be put into standard track. = Question is not about T, E or U. 

best regards,
Maoke

=E5=9C=A8 = 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF=BC=8CAlai= n Durand =E5=86=99=E9=81=93=EF=BC=9A
Dear wg,

After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, = T & U actually solve the stateless  problem we started = with.
   There are differences, but it is unclear if those = differences are really significant. E and T are the original = Encapsulation and Translation
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those
   documents have at IETF. In particular, do we want to = publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation.

Then, we, chairs, would like to ask a series of questions to the working = group. In order to make this process transparent, here is the list of = questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards = Track document?

If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)?

If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E = & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-6--122897870-- From stig@venaas.com Fri Mar 23 10:02:17 2012 Return-Path: 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 A5C3A21F85F0 for ; Fri, 23 Mar 2012 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3nzaj72a2t9j for ; Fri, 23 Mar 2012 10:02:13 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E07D721F85E3 for ; Fri, 23 Mar 2012 10:02:12 -0700 (PDT) Received: from [10.33.12.81] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 92FED8010; Fri, 23 Mar 2012 18:02:11 +0100 (CET) Message-ID: <4F6CAC91.10003@venaas.com> Date: Fri, 23 Mar 2012 10:02:09 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:02:17 -0000 On 3/22/2012 7:29 PM, Lee, Yiu wrote: > Hi Stig, > > DS-Lite was designed to deliver v4 unicast packets over v6-only network to > v4 host. However when we started thinking about how to deliver multicast > packets in the same network setup, we will have to tunnel all multicast > packets over tunnels. This is very inefficient to use of AFTR. This is the > motivation of dslite-multicast draft. However, you are absolutely right. > This is a solution for tunneling IPv4 multicast through an IPv6-only > network. I agree that double tunneling is a non-starter, so the draft seems to do the right thing. But since we seem to agree it is a more general solution, why not change the title and the text to make it more generic? You can still say that one of the use-cases is to provide IPv4 multicast for DS-Lite deployments. Stig > > B.R., > Yiu > > On 3/20/12 4:47 PM, "Stig Venaas" wrote: > >> I'm a little bit puzzled by how this document talks about DS-Lite. >> Isn't this an entirely generic solution for tunneling IPv4 multicast >> through an IPv6-only network? >> >> Stig >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Mar 23 10:14:30 2012 Return-Path: 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 CF72E21F85D9 for ; Fri, 23 Mar 2012 10:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 u5kclxXr1FlB for ; Fri, 23 Mar 2012 10:14:19 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5404621F858B for ; Fri, 23 Mar 2012 10:14:17 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id D10759400D6; Fri, 23 Mar 2012 18:14:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7--119188278 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 18:13:33 +0100 Message-Id: References: To: Guanghui Yu X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:14:31 -0000 --Apple-Mail-7--119188278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Guanghui, Le 2012-03-23 =E0 04:04, Guanghui Yu a =E9crit : > Hi Yiu >=20 > 4rd-u changes the IPv6 header architecture (redefine fragmentation = header extension) 4rd-U uses between CEs and BRs an IPv6 packet format that not only is = completely authorized, but that is already=20 used in double translation: RFC6145 also adds a fragmentation header to = some unfragmented packets (sec 4.). > and IPv6 address architecture (different meaning of u-bit when = g-bit=3D1). - U builds on the fact that all IPv6 unicast addresses are so far either = universal scope (u=3D1 g=3D0) or local link scope (u=3D0 g=3Dany value). = This (fortunately) leaves an escape combination for new types of = addresses (U is only one of these possible addresses, but the first = one). - A 4rd-U address happens to be partially universal scope (embedded = public IPv4 addresses) and partially ISP-domain scope (dependent on ISP = defined mapping rules). None of the existing formats is therefore = mandatorily applicable. - Impact on IPv6 address architecture is only a backward compatible = extension: no interference is possible with anything that works in = conformance with current IPv6 specifications. > These are the fundamental changes. If 4rd-u becomes the standard, then = there will be new defined =93IPv6=94 packets on the Internet, which are = not compatible with existing IPv6 packets and Please see above. > no existing devices can understand those packets. Only BRs and CEs need to understand that these packets have IPv4 = compatible payloads. Regards, RD > =20 >=20 > Yu Guanghui > Network and Information Center > Dalian University of Technology, China >=20 >=20 > On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu = wrote: > Hi Guanghui, >=20 > I agree that both MAP and 4rd-u are similar technology and solving the = same problem. =46rom technical perspective, can you elaborate this a = lithe bit?=20 >=20 > Thanks, > Yiu >=20 > From: Guanghui Yu > Date: Thu, 22 Mar 2012 20:26:40 +0800 > To: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd=85 >=20 > I read 4rd-u draft and found it is flawed. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-7--119188278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Guanghui,

Le 2012-03-23 =E0 04:04, Guanghui Yu a =E9crit= :

Hi Yiu

   4rd-u = changes the IPv6 header architecture (redefine fragmentation header = extension)

4rd-U uses between CEs = and BRs an IPv6 packet format that not only is completely authorized, = but that is already 
used in double = translation: RFC6145 also adds a fragmentation header to some = unfragmented packets (sec 4.).


and IPv6 address architecture (different meaning = of u-bit when g-bit=3D1).

- = U builds on the fact that all IPv6 unicast addresses are so far either = universal scope (u=3D1 g=3D0) or local link scope (u=3D0 g=3Dany = value). This (fortunately) leaves an escape combination for new = types of addresses (U is only one of these possible addresses, but the = first one).
- A 4rd-U address happens to be partially = universal scope (embedded public IPv4 addresses) and partially = ISP-domain scope (dependent on ISP defined mapping rules). None of the = existing formats is therefore mandatorily applicable.
- Impact = on IPv6 address architecture is only a backward compatible extension: no = interference is possible with anything that works in conformance with = current IPv6 specifications.


These are the fundamental changes. If 4rd-u = becomes the standard, then there will be new defined =93IPv6=94 = packets on the Internet, which are not compatible with existing = IPv6 packets and

Please see = above.

no existing devices = can understand those packets.

Only = BRs and CEs need to understand that these packets have IPv4 compatible = payloads.


Regards,
RD
   

Yu Guanghui <ygh at dlut.edu.cn>
Network and = Information Center
Dalian University of Technology, = China


On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com>= ; wrote:
Hi Guanghui,

I agree that both MAP and = 4rd-u are similar technology and solving the same problem. =46rom = technical perspective, can you elaborate this a lithe bit? 

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>
Date: Thu, 22 Mar 2012 20:26:40 = +0800
To: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to move = forward with 4rd=85

I read 4rd-u = draft and found it is flawed.

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail-7--119188278-- From yiu_lee@cable.comcast.com Fri Mar 23 11:02:51 2012 Return-Path: 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 73B6621F8650 for ; Fri, 23 Mar 2012 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 HYI2BdfBK83G for ; Fri, 23 Mar 2012 11:02:47 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 394C521F864C for ; Fri, 23 Mar 2012 11:02:47 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.6998587; Fri, 23 Mar 2012 13:56:50 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 14:02:43 -0400 From: "Lee, Yiu" To: Stig Venaas Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt Thread-Index: AQHNCR8kxhKuE+UR+E6WP7iWLWJvVQ== Date: Fri, 23 Mar 2012 18:02:43 +0000 Message-ID: In-Reply-To: <4F6CAC91.10003@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415356160_903765" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:02:51 -0000 --B_3415356160_903765 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Good feed back. We started to address dslite and like what you said this could be more generic then just dslite. I will talk to the authors and see what we should do. Thanks again! On 3/23/12 1:02 PM, "Stig Venaas" wrote: >On 3/22/2012 7:29 PM, Lee, Yiu wrote: >> Hi Stig, >> >> DS-Lite was designed to deliver v4 unicast packets over v6-only network >>to >> v4 host. However when we started thinking about how to deliver multicast >> packets in the same network setup, we will have to tunnel all multicast >> packets over tunnels. This is very inefficient to use of AFTR. This is >>the >> motivation of dslite-multicast draft. However, you are absolutely right. >> This is a solution for tunneling IPv4 multicast through an IPv6-only >> network. > >I agree that double tunneling is a non-starter, so the draft seems to do >the right thing. But since we seem to agree it is a more general >solution, why not change the title and the text to make it more >generic? You can still say that one of the use-cases is to provide IPv4 >multicast for DS-Lite deployments. > >Stig > >> >> B.R., >> Yiu >> >> On 3/20/12 4:47 PM, "Stig Venaas" wrote: >> >>> I'm a little bit puzzled by how this document talks about DS-Lite. >>> Isn't this an entirely generic solution for tunneling IPv4 multicast >>> through an IPv6-only network? >>> >>> Stig >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires > --B_3415356160_903765 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRTX8EU 6uDRLZHiIb+K20Kv+V8m8TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMxODAyMzlaMA0GCSqGSIb3DQEBAQUABIIBAFUTwPIvvJGNbZzUCzkLlWy9 QnDDns11azC1Qzau9bKpG5IZ4tpbYlfYDt0jDt5oJG4vPkUxYOx30fCyTrXeJjOHdjMCwzQX +sQ46v9/+mQUMw5qDF0MaYbkT5SYSxDpKApnXXlQWE5nmAL64mSIKQHHTg64JeoZHHCizMsR NKy/LV50kaCysNubILz3vfqcXZuP8v8Dmbj4aXLYuApfNru+Ik4cM3FDceO8nYF4j++GxoNP U81Yn45vjbFzh4GPk9i0nPaXdLCbVQlv6V7mjVln8/OamyhnEMVag8UuaVAqn8npwVvn9lF9 1mzfeamuHOL3ZyOUq9YjywdkQ11j+nY= --B_3415356160_903765-- From yiu_lee@cable.comcast.com Fri Mar 23 11:26:04 2012 Return-Path: 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 C89AD21E801A for ; Fri, 23 Mar 2012 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.936 X-Spam-Level: X-Spam-Status: No, score=-100.936 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 InXyyZ9HF2TI for ; Fri, 23 Mar 2012 11:26:04 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB421E8013 for ; Fri, 23 Mar 2012 11:26:04 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7002311; Fri, 23 Mar 2012 14:20:06 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 14:26:01 -0400 From: "Lee, Yiu" To: Alain Durand , Qiong Thread-Topic: [Softwires] [Softwire] Algorithmic feature for SD-NAT Thread-Index: AQHNCSJljfo79dAR6U2Sfk7ncskEyw== Date: Fri, 23 Mar 2012 18:26:00 +0000 Message-ID: In-Reply-To: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415357558_976290" MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:26:04 -0000 --B_3415357558_976290 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Alain, Quick question. What snag suggests to keep in the customer database? Port range info? Thanks, Yiu On 3/23/12 10:06 AM, "Alain Durand" wrote: >Not necessarily. Operators maintain large database for customers, this is >just one more field there. >The real question is how to propagate this static table to the AFTRs. >This is implementation specific, >but our proposed solution is to use netconf. --B_3415357558_976290 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT08ogQ o94bSD1V3L5iZ44KWMeF6jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMxODI1NTVaMA0GCSqGSIb3DQEBAQUABIIBAJbt9UIgLJ1vcad6FhRNY94H 1eMvn/oDQpWUFw95udhcPp8c8e/yyxRDKNkxvF9eNYdq1Qi9d9c6NQzzOFKG1Ya5cM6NPf1K dBvnREAW9ChWvNaChBE+eQAjAzh+7T9Vh9iVyJWYHazfTy7Gtjcz0AuGpSySl8ESTY7zjTwJ VHRjLmkYn8V+XxGoWwkELxozClEbP8b8zFWCRwX7utHGE43EzgKT/WD3JcDRCMYCV0NKVeJs Cf45pQsPKT4yWp4J9FMVtZsDvXjJIlfzrTywkZbRiWQA3QqBzFRWC9LssZ1FOpzga/Tap6hl lGGSWzFVF+eRrhOrN92VEVMAgQ3UHNA= --B_3415357558_976290-- From yiu_lee@cable.comcast.com Fri Mar 23 11:28:44 2012 Return-Path: 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 16A7321F84E1 for ; Fri, 23 Mar 2012 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.237 X-Spam-Level: X-Spam-Status: No, score=-100.237 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 M+11RpuR4CNz for ; Fri, 23 Mar 2012 11:28:43 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7532B21F84DD for ; Fri, 23 Mar 2012 11:28:43 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7002953; Fri, 23 Mar 2012 14:22:45 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 14:28:40 -0400 From: "Lee, Yiu" To: Wojciech Dec , Reinaldo Penno Thread-Topic: [Softwires] Path to move forward with 4rd Thread-Index: AQHNCSLE/ddVFUyBX0WrXeoqWvFgxQ== Date: Fri, 23 Mar 2012 18:28:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415357718_950157" MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:28:44 -0000 --B_3415357718_950157 Content-type: multipart/alternative; boundary="B_3415357717_956109" --B_3415357717_956109 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Wjociech, So the only different between MAP-T and dIVI-PD is the new PSID calculation in MAP. Otherwise, they are identical. Thanks, Yiu From: Wojciech Dec Date: Fri, 23 Mar 2012 14:01:59 +0100 To: Reinaldo Penno Cc: Softwires WG Subject: Re: [Softwires] Path to move forward with 4rd Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the "on-the-wire" encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. --B_3415357717_956109 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Wjociech,

<= /div>
So the only different between MAP-T and dIVI-PD is the new PSID ca= lculation in MAP. Otherwise, they are identical.

Th= anks,
Yiu 

Fr= om: Wojciech Dec <wdec.ietf@= gmail.com>
Date: Fri, 23 Ma= r 2012 14:01:59 +0100
To: Reinaldo= Penno <repenno@cisco.com>
<= span style=3D"font-weight:bold">Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rd
=

Well, MAP-T and divi-pd in non-address-shar= ing mode (ie 1:1) should be totally compatible. However, given that the "on-= the-wire" encoding of the PSID is different in the address sharing mode, int= eroperability in that mode won't be there.

Cheers,
Woj. --B_3415357717_956109-- --B_3415357718_950157 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSQsUz2 twMBxwqEsETroBPoZFOa3jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMxODI4MzdaMA0GCSqGSIb3DQEBAQUABIIBAH4gdTXlJR8NS3OmWxx2Y266 nEBpC5E1g86U9q1HDYBf/f51L1ja984X8wuqG6I8GXW5PSMYBztmxaxlAajzmOzbGhgItQ3J 1khXlzReG1ii1+Bjy79GsPGKEKERSb/QY9Sw9GEIKy4poAb3hXPvmroWoKEWQgJJGij72Y1I xZORFV0Q39EjUvES+tclrUGS9l9iawKhKupVGvwaYCuyHb4LSb7QmujAwaouNGUHA9eb1iNl tH7yph/vwtrVhVpleN5catyEDzgT6KcCE84QS5u6NgW2/8BPExXHPj0+1CrwyhcBTMV30YYq sydywKFiLibLns4Z2IbQxcpY2Rv71Yo= --B_3415357718_950157-- From yiu_lee@cable.comcast.com Fri Mar 23 15:22:33 2012 Return-Path: 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 9809B21E8089 for ; Fri, 23 Mar 2012 15:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.767 X-Spam-Level: X-Spam-Status: No, score=-100.767 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 K0L6QyT1kfzj for ; Fri, 23 Mar 2012 15:22:33 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 059E721E8028 for ; Fri, 23 Mar 2012 15:22:32 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7042538; Fri, 23 Mar 2012 18:16:32 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 18:22:29 -0400 From: "Lee, Yiu" To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=8A?= Thread-Index: AQHNCUNtLze7Z7XapECchGi4YJplpA== Date: Fri, 23 Mar 2012 22:22:26 +0000 Message-ID: In-Reply-To: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415371744_416642" MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 22:22:33 -0000 --B_3415371744_416642 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Ole, Technically, I think it now comes down to one question to debate between MAP-T and 4rd-u. Btw reservable header and double-translation, what technology better serves the requirements. Do you agree? Thanks, Yiu On 3/23/12 5:28 AM, "Ole Tr=F8an" wrote: >Remi, who was also at that meeting, later came up with a different >solution and new features and decided to create a competing proposal. MAP >is largely original 4rd and dIVI, considering its roots. there has been a >continuing exchange of ideas and improvement of the proposals. Remi's >latest 4rd-U proposal largely represents all the functions that there was >no support for in the MAP design team. I do not think attempting yet >another merger will be a good use of our time. > --B_3415371744_416642 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRSwjzo Q03zxpEUWYzqaN/1bTXUWzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjAzMjMyMjIyMjNaMA0GCSqGSIb3DQEBAQUABIIBACX+fBk59NvldzwCY6tR4J92 4ePY+8SWXHWkhZfYJJViLUClizwhRzDnVQPcPr0tssb3AD4gIj7ObAqc3lFVl3X/9Kyc8t4n iyAh/u8bQFSCr+GD5KiUFr9Dh9PrRDmv6IhfOK9RhnusIegscJ0CNVWEZ0wgPieqlOgG5G4e EmwICa3YWp1FeOiFVmOUtKRppyN3wn2UmVmsYIW9AI8sTFTseRsIZUggB3pvCla4erxKSwhA zTgYP/PwX9WstokfPO3e80iGgfZuZau1jhZiojTpZgDuYwIEqO7fUI9XTlTouJUKdk59mkM1 6p9W1lE/urbRz3R0KS4Dyfl0wNh1kaQ= --B_3415371744_416642-- From despres.remi@laposte.net Sat Mar 24 01:23:06 2012 Return-Path: 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 9482B21F85C6 for ; Sat, 24 Mar 2012 01:23:06 -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.072, BAYES_00=-2.599, 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 GOJatZKzrXJB for ; Sat, 24 Mar 2012 01:23:06 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8B21F853D for ; Sat, 24 Mar 2012 01:23:04 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id pLP11i00E37Y3f403LP1a9; Sat, 24 Mar 2012 09:23:03 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> Date: Sat, 24 Mar 2012 09:23:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F8D43A5-9D98-4BD3-9503-AF548D53403C@laposte.net> References: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 08:23:06 -0000 Le 2012-03-23 =E0 10:28, Ole Tr=F8an a =E9crit : > Yiu, >=20 >> I have to admit that I am not IPv6 protocol expert. I guess Remi took = the fragmentation header and overload it for his design. Say he defines = a new extension called "transition" extension, I would guess it would no = longer overload the fragmentation extension. I don't know enough the = current implementation of the FIB and how in 4rd-u design would = impact the implementation. I have homework to do. >=20 > Type 3 Routing Header? > we've tried this type of tunneling before. ;-) >=20 >> Apart from that, I found MAP and 4rd-u are similar technologies = trying to solve the same problem. So far I follow all the discussions in = the mailing list about this topics. Technically speaking, they have pros = and cons. I fail to see one is absolutely superior than the other. Both = designs make trade-offs. =20 >>=20 >> When we come to WG adoption, I am completely fine if the WG decides = one over the other. That said, the current discussion reminds me about = OSPF vs IS-IS. They are so similar but yet have subtle differences. = Today, both protocols are running in production. Best case scenario is = the authors can balance the trade-offs and merge two drafts. If not WG = could potentially publish both techs (e.g. one standard track and one = informational/experimental) and let the market force to decide. >=20 > the authors did already do that. the dIVI and 4rd authors met 16th of = November at the last IETF. > we collectively went through the complete feature list. the result is = what you find in the MAP document series. This MAP meeting was immediately after the Taipei Softwire meeting. At = this meeting, with an invalid technical argument, you had convinced most = participants that -U couldn't work, so that a majority didn't believe = the -U approach could be useful.=20 During this MAP meeting, a majority consequently expressed no interest = in considering further, for MAP, new features that were part of the -U = proposal (Reversible header mapping; Checksum neutrality, AKA CNP; = Distinguishable address format, AKA V octet). =20 After you had acknowledged on the WG list that, contrary to the = technical argument made during the meeting, -U could work, the chair = encouraged a separate work on -U. (On nov 29, Alain wrote to me, with = copy on the WG ML, "I'd like to encourage you to keep working on 4rd-u = and come back next meeting in Paris").=20 Knowing that a majority expressed during an informal and unscheduled = meeting of MAP contributors is in no way a full WG consensus, this was a = fair decision. > Remi, who was also at that meeting, later came up with a different = solution and new features and decided to create a competing proposal. = MAP is largely original 4rd and dIVI, considering its roots. there has = been a continuing exchange of ideas and improvement of the proposals. = Remi's latest 4rd-U proposal largely represents all the functions that = there was no support for in the MAP design team. I do not think = attempting yet another merger will be a good use of our time. >=20 >> P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one = complete series. >=20 > yes, that makes sense. > OK, what if we try this: MAP is a unified solution consisting of two = transport modes (T/E), a provisioning (DHCP) and a deployment document. > then we can pick between MAP and 4rd-U. the winner gets published on = standards track. the looser gets documented as informational for the = purpose of historical reference. As already said, if MAP-T and/or MAP-E is standardized, I see no point = in confusing people with, in addition, a -U RFC. The ONLY purpose of -U is having simultaneously -E transparency and -T = IPv6 compatibility. It is NOT to multiply RFCs. Chers, RD =20 >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Sat Mar 24 01:24:49 2012 Return-Path: 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 ; 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 ; 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 ; 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: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 24 Mar 2012 09:24:46 +0100 Message-Id: <33FA6DA8-2623-4C3D-9A07-A395894984F3@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF 9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 08:24:49 -0000 --Apple-Mail-3--64515689 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-03-19 11:44, Maoke: > 2012/3/19 R=E9mi Despr=E9s > Le 2012-03-19 =E0 10:21, Maoke a =E9crit : >> 2012/3/19 R=E9mi Despr=E9s >> Le 2012-03-19 =E0 09:16, Maoke a =E9crit : >>> 2012/3/16 R=E9mi Despr=E9s >>> Maoke, >>>=20 >>> Let me try a more complete picture than before: >>>=20 >>>=20 >>> A1 -----. =20 >>> RFC6145-host| .-- 4rd BR --.=20 >>> | | | >>> A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 >>> 4rd-CE | | | UDP Lite appli = =20 >>> (no IPv4 @) | '-- NAT64+ --'=20 >>> | =20 >>> A3 -----'=20 >>> 4rd-CE =20 >>> (IPv4 @, shared or not) >>>=20 >>>=20 >>> 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) >>>=20 >>> Connectivities I get are:=20 >>> A2 =3D> B (via NAT64+) >>> A3 <=3D> B (via 4rd BR) >>> (There is no A1-B connectivity) >>>=20 ... >> let me have the following propositions:=20 >>=20 >> a. NAT64 suitable for any case no matter A2 is assigned with any kind = of address, but currently only works for TCP and UDP.=20 >=20 > Yes (but with the DF bit transparency limitation that is avoided in = case of NAT64+) >=20 >> 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. >> =20 >> c. NAT64+ works like:=20 >> if A2 has a V-CNP-address, then it doesn't update the checksum for = any L4 protocols;=20 >> 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.=20 Seems right too, and more precise.=20 >>=20 >> i think we are common that a. is true, right? >=20 > Right, with the caveat above. >=20 >> do you mean c. instead of b. ? >=20 > 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.=20 >=20 > 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.)=20 If pressed to make a choice, c. seems a better expression of what is = specified than b. =20 Cheers, RD (Retransmitted with much unnecessary text deleted. The message was = refused as being too long for the mailing list)=20 --Apple-Mail-3--64515689 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/19 R=E9mi Despr=E9s = <despres.remi@laposte.net><= /span>
Le 2012-03-19 =E0 = 10:21, Maoke a =E9crit :
2012/3/19 R=E9mi Despr=E9s = <despres.remi@laposte.net>
Le 2012-03-19 =E0 09:16, Maoke = a =E9crit :
2012/3/16 R=E9mi Despr=E9s <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 =  =3D> B (via NAT64+)
 A3 <=3D> 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

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

= --Apple-Mail-3--64515689-- From jan@go6.si Sat Mar 24 09:29:51 2012 Return-Path: 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 85E3621F8602 for ; Sat, 24 Mar 2012 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6VMtAULnxelV for ; Sat, 24 Mar 2012 09:29:51 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF54921F85EA for ; Sat, 24 Mar 2012 09:29:46 -0700 (PDT) Received: from jan-mac.local (unknown [213.250.27.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id BAD4822B4069 for ; Sat, 24 Mar 2012 17:29:43 +0100 (CET) Message-ID: <4F6DF677.8080505@go6.si> Date: Sat, 24 Mar 2012 17:29:43 +0100 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:29:51 -0000 On 3/23/12 4:04 AM, Guanghui Yu wrote: > Hi Yiu > > 4rd-u changes the IPv6 header architecture (redefine > fragmentation header extension) and IPv6 address architecture (different > meaning of u-bit when g-bit=1). These are the fundamental changes. If > 4rd-u becomes the standard, then there will be new defined “IPv6” > packets on the Internet, which are not compatible with existing IPv6 > packets and no existing devices can understand those packets. Exactly. +1 Cheers, Jan Zorz From awoodman@isc.org Sat Mar 24 09:38:12 2012 Return-Path: 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 45DF021F8656 for ; Sat, 24 Mar 2012 09:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 da2p1NHIcqf4 for ; Sat, 24 Mar 2012 09:38:11 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4906B21F8622 for ; Sat, 24 Mar 2012 09:38:11 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B09ED5F9887; Sat, 24 Mar 2012 16:37:59 +0000 (UTC) (envelope-from awoodman@isc.org) Received: from awoodmanpc12 (dhcp-408f.meeting.ietf.org [130.129.64.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 408A9216C3B; Sat, 24 Mar 2012 16:37:54 +0000 (UTC) (envelope-from awoodman@isc.org) From: "Alistair Woodman" To: Date: Sat, 24 Mar 2012 09:37:53 -0700 Message-ID: <356701cd09dc$7872b190$695814b0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3568_01CD09A1.CC13D990" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0J3HXBOLXiBdAkQwCmebLmmsmt0g== Content-Language: en-us Cc: fdupont@isc.org Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:41:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_3568_01CD09A1.CC13D990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, you are cordially invited. Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of draft-penno-softwire-sdnat-02. The following will be shown: 1) Stateless DS-Lite 2) Stateless CPE B4 NAT 3) Anycast Failover 4) DHCPv4 proxy over v6 5) NAT Port range re-allocation via ICMP method. When: Sunday the 25th from 15h30 to 17h00. Where: Room #201 (Front left of Hall Maillot when facing Porte Maillot), IETF 83, Paris ------=_NextPart_000_3568_01CD09A1.CC13D990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All, you = are cordially invited…

 

Francis = Dupont, Paul Selkirk and Alain Durant are hosting a live demo of = draft-penno-softwire-sdnat-02.

 

The = following will be shown:

 

1) Stateless = DS-Lite

2) Stateless CPE B4 = NAT

3) Anycast = Failover

4) DHCPv4 proxy over = v6

5) NAT Port range re-allocation = via ICMP method.

 

When:   =             &= nbsp;  Sunday the 25th from 15h30 to = 17h00.

Where:  =             &= nbsp;  Room #201 (Front left of Hall Maillot when facing Porte = Maillot), IETF 83, Paris

------=_NextPart_000_3568_01CD09A1.CC13D990-- From despres.remi@laposte.net Sat Mar 24 09:59:09 2012 Return-Path: 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 852FE21F85F1 for ; Sat, 24 Mar 2012 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 v76QUoy5winY for ; Sat, 24 Mar 2012 09:59:09 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id A237521F85EF for ; Sat, 24 Mar 2012 09:59:08 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id pUz51i00837Y3f403Uz5az; Sat, 24 Mar 2012 17:59:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F6DF677.8080505@go6.si> Date: Sat, 24 Mar 2012 17:58:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C41A97B-38A7-4BED-9CA5-96E39FAD4EBB@laposte.net> References: <4F6DF677.8080505@go6.si> To: Jan Zorz @ go6.si X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:59:09 -0000 Hi, Jan, Please see my answer to Guanghui. Thanks, RD Le 2012-03-24 =E0 17:29, Jan Zorz @ go6.si a =E9crit : > On 3/23/12 4:04 AM, Guanghui Yu wrote: >> Hi Yiu >>=20 >> 4rd-u changes the IPv6 header architecture (redefine >> fragmentation header extension) and IPv6 address architecture = (different >> meaning of u-bit when g-bit=3D1). These are the fundamental changes. = If >> 4rd-u becomes the standard, then there will be new defined =93IPv6=94 >> packets on the Internet, which are not compatible with existing IPv6 >> packets and no existing devices can understand those packets. >=20 > Exactly. >=20 > +1 >=20 > Cheers, Jan Zorz >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Mar 23 10:47:04 2012 Return-Path: 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 1E62121F85FF for ; Fri, 23 Mar 2012 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.073, 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 9gzb1GOvLFvt for ; Fri, 23 Mar 2012 10:47:00 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 23C2D21F8602 for ; Fri, 23 Mar 2012 10:46:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id p5mv1i00D37Y3f4035mvC1; Fri, 23 Mar 2012 18:46:56 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--117189120 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 23 Mar 2012 18:46:52 +0100 Message-Id: <51BA7F56-7B83-4EF5-9223-7B21AB37BDE8@laposte.net> References: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <5B73A592-AEFC-4010-8960-FCF6012DDAA6@laposte.net> <533DDBBF-FE50-4BF 9-8554-58C1340CCDC6@laposte.net> <429F424B-8C6F-4DED-B0F6-95D492A7B9F3@laposte.net> <7EF05FA7-4C35-44D8-BD5A-7ABF63E96598@laposte.net> <36C8C1E2-AF1A-44C5-B97E-2A912B4525B7@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 24 Mar 2012 10:47:22 -0700 Cc: Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:47:04 -0000 --Apple-Mail-1--117189120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 =E0 11:44, Maoke a =E9crit : >=20 >=20 > 2012/3/19 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 10:21, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/19 R=E9mi Despr=E9s >>=20 >> Le 2012-03-19 =E0 09:16, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/16 R=E9mi Despr=E9s >>> Maoke, >>>=20 >>> Let me try a more complete picture than before: >>>=20 >>>=20 >>> A1 -----. =20 >>> RFC6145-host| .-- 4rd BR --.=20 >>> | | | >>> A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 >>> 4rd-CE | | | UDP Lite appli = =20 >>> (no IPv4 @) | '-- NAT64+ --'=20 >>> | =20 >>> A3 -----'=20 >>> 4rd-CE =20 >>> (IPv4 @, shared or not) >>>=20 >>>=20 >>> 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) >>>=20 >>> Connectivities I get are:=20 >>> A2 =3D> B (via NAT64+) >>> A3 <=3D> B (via 4rd BR) >>> (There is no A1-B connectivity) >>>=20 >>> A2 is IPv6-only, right? >>=20 >> There seems to be a misunderstanding on what is IPv6-only. >> a) A2 is dual stack. Being a CE node, it supports IPv4 applications, = and typically includes a NAT44.=20 >> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it = has no assigned public IPv4 address (even shared). >> c) Because it has received a NAT64+ mapping rule, it knows it can = tunnel IPv4 packets to the NAT64+. >>=20 >>=20 >>> if so, let me go down.=20 >>=20 >> Not so =3D> doesn't apply.=20 >> (Yet some further comments below) >>=20 >> RD >>=20 >>=20 >>> =20 >>>=20 >>> Anything missed? >>>=20 >>>=20 >>> Other detailed comments follow. >>>=20 >>> Le 2012-03-16 =E0 01:59, Maoke a =E9crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/15 R=E9mi Despr=E9s >>>>=20 >>>> Le 2012-03-15 =E0 14:47, Maoke a =E9crit : >>>>=20 >>>>>=20 >>>>>=20 >>>>> 2012/3/15 R=E9mi Despr=E9s >>>>>=20 >>>>> Le 2012-03-15 =E0 11:45, Maoke a =E9crit : >>>>>=20 >>>>>> i understand NAT64 makes translation between arbitrary IPv6 = address to arbitrary IPv4 address. i don't understand how you make CNP = in any IPv6 address. >>>>>=20 >>>>>=20 >>>>>> in other words, we cannot limit NAT64 stateful service only serve = those IPv6 addresses with CNP. >>>>>=20 >>>>> That's no the case at all(!).=20 >>>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely unchanged). >>>>>=20 >>>>> The draft says: >>>>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format." >>>>> =20 >>>>> =20 >>>>> this phrase is not understood yet. do you mean using = 4rd-IPv6-address format for stateful translation service? >>>>=20 >>>> Yes (but, &s said, only for CE nodes that are 4rd capable (with the = advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). >>>>=20 >>>>> please draw an example of A <---> B communication as i did for = clarification. >>>>=20 >>>> Here is an example scenario: >>>>=20 >>>> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH = uses RFC6145)=20 >>>> A1 | =20 >>>> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- = Server >>>> | UDP-lite = UDP-lite >>>> v4Appli-4rdCE --' capable B >>>> A2 =3D> A-B OK >>>>=20 >>>>=20 >>>> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but = exactly speaking, if the "not support" means passing-it-through without = checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right? >>>=20 >>> A NAT64 that supports UDP Lite MUST update checksum for hosts that = have native IPv6 addresses. >>> That's why A1 =3D> B doesn't work unless the NAT64 recognizes which = packets are those of IPv4 applications in DS hosts. >>>=20 >>> A1 -> B doesn't need stateful NAT64 but stateless service is enough. = well, stateful is also ok. it is true NAT64 supporting UDP-Lite must = update checksum.=20 >>> =20 >>>=20 >>>> B --> A is a question mark, if we use the NAT64+ which does nothing = with the L4 checksum, it is also not a problem. >>>=20 >>>=20 >>>> however, if we use, as you mentioned before, an UDP-Lite-aware = update of RFC6146, that may updates the checksum while the BIH doesn't = know that.=20 >>>=20 >>> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and = NAT64+) to support more protocols than the two required by the RFC. It = is just an extension which cannot break anything (backward compatible). >>>=20 >>> confusing. upgrade vs. extension??=20 >>> =20 >>>=20 >>>=20 >>>>=20 >>>> my point here is: what is the use case with the details of = addressing? if and only if A1 or A2 is configured with an RFC6052 or a = MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 = address to serve B for the communications, A1 BIH or A2 CE may do the = stateless processing successfuly. if NAT64+ hasn't such a address pool = for B, things will fail because only one among src and dst is = checksum-neutral.=20 >>>=20 >>> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address = reaches the NAT64+ at this IPv6 address: >>>=20 >>> +-------------------------------+---+---+-------------+------+ >>> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >>> +-------------------------------+---+---+-------------+------+ >>> : 64 : 8 : 8 : 32 : 16 : >>>=20 >>> In the reverse direction, and for the same IPv4 address, it is the = same IPv6 address that must be synthesized by the NAT64+. >>>=20 >>> this address is used for A2 or used for B? if you mean B, then may i = conclude that NAT64+ is serving between A2 (native IPv6 address with = 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted = address having CNP)? if i can, may i further conclude that NAT64+ serves = only for the case where A2 has the 4rd-U-style address?=20 >>=20 >> Let me repeat that: >> - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. >> - The only difference is that NAT64+ has a plus for addresses that = are those of 4RD-u CEs (better IPv4 transparency). >>=20 >> accepted. but i have pointed out the "better transparency" has some = cost and uncertaity up to now (see another thread).=20 >> =20 >>=20 >>=20 >>> if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right?=20 >>>=20 >>> if so, i do really suggest you call it NAT64- instead of NAT64+ = because NAT64 can also serve hosts with any native IPv6 address to = connect with an IPv4 peer. >>>=20 >>> your answer below didn't respond my question, sorry. for example (in = the use case of NAT64 instead of NAT64-), A2 has native IPv6 address = 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE = might synthesize an IPv6 address for B, with the NAT64+ prefix and the = 0xc0204d32 and a CNP embedded, say B', and let A2 connect to B' through = IPv6; however, when this packet goes through the NAT64+, >>=20 >>> because only B' is checksum-neutral while A2 is not, >>=20 >> If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, = per Fig 6, 2001:db8:1234:5678:3000::=20 >> It IS checksum neutral. >>=20 >> well, it is saying A2 must have the 4rd address in order to get the = benefit of NAT64-, right? >=20 > (*) For native IPv6, it has whatever address applies (that of your = example is OK). > Its CE is reached with all destination addresses starting with the = site /64 followed by with the V octet. =20 >=20 >=20 >> i have typed "for example (in the use case of NAT64 instead of = NAT64-), ..." as the prerequisite of the above discussion. let me have = the following propositions:=20 >>=20 >> a. NAT64 suitable for any case no matter A2 is assigned with any kind = of address, but currently only works for TCP and UDP.=20 >=20 > Yes (but with the DF bit transparency limitation that is avoided in = case of NAT64+) >=20 >> 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. >> =20 >> c. NAT64+ works like:=20 >> if A2 has a V-CNP-address, then it doesn't update the checksum for = any L4 protocols;=20 >> 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.=20 Seems right too. >>=20 >> i think we are common that a. is true, right? >=20 > Right, with the caveat above. >=20 >> do you mean c. instead of b. ? >=20 > 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.=20 >=20 > not yet cleared. "receives a NAT64+ mapping rule" for what? To know what to do with IPv4 packets if assigned no public IPv4 address. > is the NAT64+ mapping rule stateless or stateful? The rule 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.)=20 If pressed to make a choice, c. seems closer to what I described. RD >=20 > thanks,=20 > maoke > =20 >=20 > That's IMHO clear enough, especially with the (*) above which = clarifies AFAIK which native and 4rd IPv6 addresses are used by CEs. >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >>=20 >> thanks, >> maoke >>=20 >> =20 >>=20 >>> NAT64+ passing it without L4 checksum adjustment will make B receive = a packet with wrong checksum, for any L4 protocols.=20 >>>=20 >>> the above example works well for TCP and UDP with today's NAT64, = without limitations on A2's address.=20 >>>=20 >>> - maoke >>> =20 >>> This is I suppose implicit, but it can advantageously be made = explicit in the draft. >>> Thanks. >>>=20 >>>=20 >>>>> Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE addresses. >>>>> =20 >>>>> =20 >>>>> we need to make sure if the NAT64s make both src and dst addresses = checksum-neutral. >>>>=20 >>>> Correct, iff the host address has the V octet. >>>>=20 >>>> 1. without the V-octet, CE and NAT64 can also distinguish the = 4rd-CE addresses from others.=20 >>>=20 >>> True, but while testing the V octet is sufficient in 4rd, the NAT64 = has in MAP to process mapping rules to find for null subnet IDs whose = lengths depend on which mapping rule applies. >>> That's IMHO one instance where the V-octet potential is clear. >>>=20 >>>=20 >>>> 2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=20 >>>=20 >>> Yes (see above). >>>=20 >>>> if 2 is true, why you use stateful NAT64+ here for B rather than a = stateless one? >>>=20 >>> Because we consider hosts that are not assigned any public IPv4 = address, even shared. >>>=20 >>>> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address = for B's communications, and such a case results only A's mapped address = is checksum-neutral, and thus anyway L4 adjustment is needed.=20 >>>>=20 >>>> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, = because NAT64 doesn't have the limitation on the IPv6 address pool in = use.=20 >>>=20 >>> Suggestion not retained ;-). >>> What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix.=20 >>>=20 >>>=20 >>>> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is = NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit = this for the time being).=20 >>>=20 >>> Right. >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> - maoke=20 >>>> =20 >>>>=20 >>>>> i cannot imagine what the use case is. please specify! >>>>=20 >>>> Hope the picture above helps. >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>> =20 >>>>> - maoke >>>>> =20 >>>>> =20 >>>>>=20 >>>>> RD=20 >>>>>=20 >>>>>=20 >>>>>> - maoke=20 >>>>>>=20 >>>>>> 2012/3/15 R=E9mi Despr=E9s >>>>>>=20 >>>>>> Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit : >>>>>>=20 >>>>>> > Maoke, >>>>>> > >>>>>> > Thanks for this question. >>>>>> > This subject being new, I take it on a new thread. >>>>>> > >>>>>> > 2012-03-15 10:38, Maoke: >>>>>> > ... >>>>>> >> i didn't understand the how the stateful NAT64 benefits from = CNP. >>>>>> > >>>>>> > The point is that if a NAT64 is upgraded to support 4rd-u = tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >>>>>> > Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs >>>>>> > These CEs need not being dependent on which NAT64 supports = which protocols. >>>>>> > >>>>>> > Note that the NAT64 doesn't need to have CNP code. It just = happens that host IPv6 addresses it sees are checksum neutral. (Thus, = IPv6 and IPv4 payloads are the same for all protocols that have ports at = the same place as TCP/UDP/..., and the same checksum algorithm) >>>>>>=20 >>>>>> Oops. >>>>>> This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >>>>>> Sorry for having hastily added this sentence. >>>>>>=20 >>>>>> RD >>>>>>=20 >>>>>> > >>>>>> > RD >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Softwires mailing list >>>>>> > Softwires@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-1--117189120 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 10:21, Maoke a =E9crit :



2012/3/19 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-19 =E0 = 09:16, Maoke a =E9crit :



2012/3/16 R=E9mi = Despr=E9s <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 =  =3D> B (via NAT64+)
 A3 <=3D> B (via 4rd = BR)
(There is no A1-B = connectivity)

A2 is IPv6-only, = right?

There seems to = be a misunderstanding on what is IPv6-only.
a) A2 is dual = stack. Being a CE node, it supports IPv4 applications, and = typically includes a NAT44. 
b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it = has no assigned public IPv4 address (even shared).
c) Because = it has received a NAT64+ mapping rule, it knows it can tunnel IPv4 = packets to the NAT64+.


if so, let me go = down. 

Not so =3D> = doesn't apply. 
(Yet some further comments below)
=

RD


 

Anything = missed?


Other detailed comments follow.

Le = 2012-03-16 =E0 01:59, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 14:47, Maoke a =E9crit :



2012/3/15 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 = 11:45, Maoke a =E9crit :

i = understand NAT64 makes translation between arbitrary IPv6 address to = arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 = address.


in other words, = we cannot limit NAT64 stateful service only serve those IPv6 addresses = with CNP.

That's no the case at = all(!). 
A NAT64+ is a *backward compatible* extension of NAT64 (everything = that worked before still works completely = unchanged).

The draft says:
"NAT64+: =  An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the = 4rd-IPv6-address format."
 
 
this = phrase is not understood yet. do you mean using 4rd-IPv6-address format = for stateful translation service? =

Yes (but, &s said, = only for CE nodes that are 4rd capable (with the advantage of better = IPv4 transparency between CEs and NAT64+ than between RFC6145 and = NAT64).

please draw an example of A <---> B = communication as i did for clarification. =

Here is an example = scenario:

v4appli-BIH ----. =3D> A>B NOK (because, = according to RFC6535, BIH uses RFC6145) 
    =  A1         |    =  
                = :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server
                |   =              UDP-lite     =                 =  UDP-lite
v4Appli-4rdCE --'         =         capable        =                 =  B
     A2         =  =3D> A-B OK


yes, BIH = uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly = speaking, if the "not support" means passing-it-through without checksum = adjustment, A --> B is fine because neither BIH nor NAT64+ does = nothing with the L4, right?

A NAT64 that supports UDP = Lite MUST update checksum for hosts that have native IPv6 = addresses.
That's why A1 =3D> B doesn't work unless the = NAT64 recognizes which packets are those of IPv4 applications in DS = hosts.

A1 -> B doesn't = need stateful NAT64 but stateless service is enough. well, stateful is = also ok. it is true NAT64 supporting UDP-Lite must update = checksum. 
 

B --> A is a question mark, if we use the NAT64+ which does = nothing with the L4 checksum, it is also not a problem. =


however, if we use, as you mentioned before, an UDP-Lite-aware update of = RFC6146, that may updates the checksum while the BIH doesn't know = that. 

Note that an = upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to support more = protocols than the two required by the RFC. It is just an extension = which cannot break anything (backward compatible).

confusing. upgrade vs. = extension?? 
 



my point here is: what is the use case with the = details of addressing? if and only if A1 or A2 is configured with an = RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of = checksum-neutral IPv6 address to serve B for the communications, A1 BIH = or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't = such a address pool for B, things will fail because only one among src = and dst is checksum-neutral. 

Sec 4.4 (8) says that a CE = that targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 = address:

+-------------------------------+--= -+---+-------------+------+
|      NAT64+ IPv6 prefix       |"u"| = 0 |DST IPv4 add.|  CNP = |
+-------------------------------+---+---+-------------+------+=
:               64   =            : 8 : 8 :     =  32     :  16  :

In the reverse direction, and for the = same IPv4 address, it is the same IPv6 address that must be = synthesized by the = NAT64+.

this = address is used for A2 or used for B? if you mean B, then may i conclude = that NAT64+ is serving between A2 (native IPv6 address with 4rd-U CNP) = and B (synthesized by NAT64+ into another IPv6-converted address having = CNP)? if i can, may i further conclude that NAT64+ serves only for the = case where A2 has the 4rd-U-style address? 

Let me repeat = that:
- NAT64+ works as a NAT64 for addresses that aren't = 4rd-u style.
- The only difference is that NAT64+ has a plus = for addresses that are those of 4RD-u CEs (better IPv4 = transparency).

accepted. but i have = pointed out the "better transparency" has some cost and uncertaity up to = now (see another thread). 
 


if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right? 

if so, i do really suggest you = call it NAT64- instead of NAT64+ because NAT64 can also serve hosts with = any native IPv6 address to connect with an IPv4 peer.

your answer below didn't respond my question, sorry. = for example (in the use case of NAT64 instead of NAT64-), A2 has native = IPv6 address 2001:db8:1234:5678:208:1fff:fe4d:606e while B is = 192.32.77.50. the CE might synthesize an IPv6 address for B, with the = NAT64+ prefix and the 0xc0204d32 and a CNP embedded, say B', and let A2 = connect to B' through IPv6; however, when this packet goes through the = NAT64+,

because only B' is checksum-neutral while A2 = is not,

If the /64 of = A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address = is, per Fig = 6, 2001:db8:1234:5678:3000::<CNP> 
It IS checksum = neutral.

well, it is = saying A2 must have the 4rd address in order to get the benefit of = NAT64-, right?

(*) For native IPv6, it has whatever address applies (that of = your example is OK).
Its CE is reached with all destination = addresses starting with the site /64 followed by with the V octet. =  


i have typed "for example (in the use case = of NAT64 instead of NAT64-), ..." as the prerequisite of the above = discussion. 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.

 
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.



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

To know what to do with IPv4 = packets if assigned no public IPv4 address.

is the NAT64+ mapping rule = stateless or stateful?

The rule = 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 closer to what I = described.

RD


=



thanks, 
maoke
 

That's IMHO = clear enough, especially with the (*) above which clarifies AFAIK which = native and 4rd IPv6 addresses are used by = CEs.


Cheers,
RD





thanks,
maoke

 

NAT64+ passing it without = L4 checksum adjustment will make B receive a packet with wrong checksum, = for any L4 protocols. 

the above example works well for TCP and UDP with = today's NAT64, without limitations on A2's = address. 

- = maoke
 
This is I suppose = implicit, but it can advantageously be made explicit in the = draft.
Thanks.


Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with = CNPs ONLY for addresses that actually are 4rd CE = addresses.
 
 
we need to make sure if the NAT64s = make both src and dst addresses = checksum-neutral.
Correct, iff the host address = has the V octet.

1. without = the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from = others. 

True, but while testing the = V octet is sufficient in 4rd, the NAT64 has in MAP to process mapping = rules to find for null subnet IDs whose lengths depend on which mapping = rule applies.
That's IMHO one instance where the V-octet potential is = clear.


2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 = address? 

Yes (see = above).

if 2 is = true, why you use stateful NAT64+ here for B rather than a stateless = one?

Because we consider = hosts that are not assigned any public IPv4 address, even shared.

if= 2 is not true, then the NAT64 can use any arbitrary IPv6 address for = B's communications, and such a case results only A's mapped address is = checksum-neutral, and thus anyway L4 adjustment is needed. 

if 2 is true, i do suggest you naming NAT64+ as = NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 = address pool in = use. 

Suggestion = not retained ;-).
What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its = unchanged /64 prefix. 


3. RFC6535 states, explicitly, "Use of = BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above = technical discussion can omit this for the time = being). 

Right.

RD






- maoke 
 

i cannot imagine what the use case is. = please specify!

Hope = the picture above helps.

RD



 
- = maoke
 
 

RD 


- maoke 

2012/3/15 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-15 =E0 10:59, R=E9mi Despr=E9s a =E9crit :

> Maoke,
>
> Thanks for this question.
> This subject being new, I take it on a new thread.
>
> 2012-03-15 10:38, Maoke:
> ...
>> i didn't understand the how the stateful NAT64 benefits from = CNP.
>
> The point is that if a NAT64 is upgraded to support 4rd-u tunnels = (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads.
> Any protocol that this NAT64 supports is then supported e2e for = 4rd-u CEs
> These CEs need not being dependent on which NAT64 supports which = protocols.
>
> Note that the NAT64 doesn't need to have CNP code. It just happens = that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and = IPv4 payloads are the same for all protocols that have ports at the same = place as TCP/UDP/..., and the same checksum algorithm)

Oops.
This is only true for the IPv6 host address. To construct an IPv6 = address when transmitting to  a 4rd-u CE, the NAT64 should compute = a CNP. (This is to maintain the property that that middleboxes can treat = tunnel packets as valid IPv6 packets. Not a big deal, but = necessary).
Sorry for having hastily added this sentence.

RD

>
> RD
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires













= --Apple-Mail-1--117189120-- From fdupont@isc.org Sat Mar 24 09:41:17 2012 Return-Path: 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 B7A1F21F85D6 for ; Sat, 24 Mar 2012 09:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 7FuvJdcxP-5T for ; Sat, 24 Mar 2012 09:41:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1C21F85C9 for ; Sat, 24 Mar 2012 09:41:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 27A86C9432; Sat, 24 Mar 2012 16:41:07 +0000 (UTC) (envelope-from fdupont@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10295) id 055FD216C36; Sat, 24 Mar 2012 16:41:07 +0000 (UTC) From: Francis Dupont To: "Alistair Woodman" In-reply-to: <356701cd09dc$7872b190$695814b0$@org> References: <356701cd09dc$7872b190$695814b0$@org> Comments: In-reply-to "Alistair Woodman" message dated "Sat, 24 Mar 2012 09:37:53 -0700." Date: Sat, 24 Mar 2012 16:41:07 +0000 Sender: fdupont@isc.org Message-Id: <20120324164107.055FD216C36@bikeshed.isc.org> X-Mailman-Approved-At: Sat, 24 Mar 2012 10:47:22 -0700 Cc: softwires@ietf.org, fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:41:17 -0000 Durand with a 'd' (as sensible as Dupont with a 't' :-)! Francis Dupont From pengwu.thu@gmail.com Sat Mar 24 10:56:09 2012 Return-Path: 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 91C8721F856C for ; Sat, 24 Mar 2012 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 N5l+2uhxlsA7 for ; Sat, 24 Mar 2012 10:56:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F10B21F856A for ; Sat, 24 Mar 2012 10:56:09 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3996290pbb.31 for ; Sat, 24 Mar 2012 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rQFE4u/SyAk4D2qr8bHSpWsqNwrLCHM2OINJAEHE9i0=; b=r3j4y/2wVi6teuaOnM+PScloVP+SrVthYYknxbfrihXHCzGlaGEhrkxLxw0N0HVe4t jzGUaYY97aDWyJtgjCMhcSkJD3EJM8V5KHiJzT0Di0ugW7joHcx5/3UfDqYlleMOn6Lf /VVbX3Zgo1mUrNuXf8Pr7yeblea5WL4ymmc1klVkmjRDHbDIViML1eQbPhScHJt19HYX g2dnYFPADs6V8LHB9ZoMdwBsqLfibbXYOcIqcaIglzQcSXFbh/2snuA8ImUX94+XDM33 ejjOHHBBvpjBgqu8Mvo3hRtBxLyd+Xr0WTighMV0uVFZbRHSt8xg8kJKMT7uBs1YHq2T LREQ== MIME-Version: 1.0 Received: by 10.68.219.34 with SMTP id pl2mr39311067pbc.56.1332611768765; Sat, 24 Mar 2012 10:56:08 -0700 (PDT) Received: by 10.68.242.132 with HTTP; Sat, 24 Mar 2012 10:56:08 -0700 (PDT) In-Reply-To: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> References: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> Date: Sun, 25 Mar 2012 01:56:08 +0800 Message-ID: From: Peng Wu To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 17:56:09 -0000 Hi Alain, Same question I raised in the other thread. 1) So this table is fully static, and we don't consider user entering or leaving which may affect the bindings. Instead, the bindings only rely on the addresses which won't change along the time. 2) Then this falls in the manner of pre-configuration for every possible user IPv6 address, not on-demand allocation. Am I correct on the two points? Thx~ 2012/3/23 Alain Durand : > > On Mar 23, 2012, at 4:22 AM, Qiong wrote: > >> Dear Alain and all, >> >> I'm trying to understand sd-nat-02 and I'm still wondering how to setup = subscriber-based binding table in sd-nat. In my understanding, a totally st= atic binding table will introduce a lot of workload for operators. > > Not necessarily. Operators maintain large database for customers, this is= just one more field there. > The real question is how to propagate this static table to the AFTRs. Thi= s is implementation specific, > but our proposed solution is to use netconf. > >> But otherwise, I guess there might be an algorithmic relationship betwee= n IPv6 and IPv4 + port range. In this way, would it become some kind of MAP= , in which IPv4 address and IPv6 address is tightly coupled and need to be = planned in advance ? > > This can be done too, but you loose the most important advantage of SD-Na= t: the absence of hard coupling between the IPv4 and IPv6 address. > Not coupling both addresses enables great flexibility on how you allocate= addresses and port. > > >> =A0 I'm just wondering why do we still need to maintain per-subscriber t= able in AFTR while still keeping stateless. Please correct me if I miss som= ething here : > > SD-Nat is per-flow stateless, with a per-subscriber static state. > > =A0- Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From pengwu.thu@gmail.com Sat Mar 24 11:06:09 2012 Return-Path: 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 8CBF121F8585 for ; Sat, 24 Mar 2012 11:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lmAtt9w13dsc for ; Sat, 24 Mar 2012 11:06:09 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0809D21F8581 for ; Sat, 24 Mar 2012 11:06:08 -0700 (PDT) Received: by iazz13 with SMTP id z13so7373176iaz.31 for ; Sat, 24 Mar 2012 11:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nSC++rSXjMSos9TMszilngYOgNUNhXZUVItGuqfuesU=; b=twC5jPHAmwwT/nfkWs9Y4XCdbRGUi6ls7ph3JsPT0sCkTkkM5z9QM+MyH/0w/jbEZw e4bmVbTGklSjlfy3+LuAAm6RxfpFM6eYN29NXiKwgh816sAS9wIk6pyytalkQvE53zlj z6zKbrkC0gogig0ZRqV3PjZwyM05B60CAH4MFYahgR0aL8qdFbPF7UJKmh5DwlPCZbdT 3bgzLR1Lw1p9zGJWWWfTwlexfe7Svlbz25pn8vXRYgdRKaxVXXKBX2vtD9eB0ge4mAbj kw5pa0r8+DOYB8A2Hxw+HIgeKhpXgKVmiCxo3tXSuBdhBxTy4Bq3Uv0BKi2YYnK41nPF 05BQ== MIME-Version: 1.0 Received: by 10.68.194.3 with SMTP id hs3mr39247262pbc.119.1332612368300; Sat, 24 Mar 2012 11:06:08 -0700 (PDT) Received: by 10.68.242.132 with HTTP; Sat, 24 Mar 2012 11:06:08 -0700 (PDT) In-Reply-To: <356701cd09dc$7872b190$695814b0$@org> References: <356701cd09dc$7872b190$695814b0$@org> Date: Sun, 25 Mar 2012 02:06:08 +0800 Message-ID: From: Peng Wu To: Alistair Woodman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 18:06:09 -0000 Great. So ISC already has DHCPv4 over IPv6 implementation now. //Pity I couldn't make it on Sunday. 2012/3/25 Alistair Woodman : > All, you are cordially invited=85 > > > > Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of > draft-penno-softwire-sdnat-02. > > > > The following will be shown: > > > > 1) Stateless DS-Lite > > 2) Stateless CPE B4 NAT > > 3) Anycast Failover > > 4) DHCPv4 proxy over v6 > > 5) NAT Port range re-allocation via ICMP method. > > > > When:=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Sunday the 25th fr= om 15h30 to 17h00. > > Where:=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Room #201 (Front lef= t of Hall Maillot when facing > Porte Maillot), IETF 83, Paris > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From Tina.Tsou.Zouting@huawei.com Sat Mar 24 13:18:38 2012 Return-Path: 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 8332021F859A for ; Sat, 24 Mar 2012 13:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] 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 Ik9ncdb9kt4j for ; Sat, 24 Mar 2012 13:18:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E986C21F8599 for ; Sat, 24 Mar 2012 13:18:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEI93365; Sat, 24 Mar 2012 16:18:36 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Mar 2012 13:18:27 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Mar 2012 13:18:36 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Sun, 25 Mar 2012 04:18:31 +0800 From: Tina TSOU To: "Lee, Yiu" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt Thread-Index: AQHNCR8tFzcunvLASUqKXOQaZ0/P+JZ55FKi Date: Sat, 24 Mar 2012 20:18:31 +0000 Message-ID: <30BCC47B-DEDD-48E4-ABCB-EED0AE549A4A@huawei.com> References: <4F6CAC91.10003@venaas.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:18:38 -0000 Sounds like a logical step forward.=20 This should be an applicability statement for the Mboned-defined AF for a 4= -6-4 network scenario. Sent from my iPad On Mar 23, 2012, at 11:02 AM, "Lee, Yiu" wrote: > Good feed back. We started to address dslite and like what you said this > could be more generic then just dslite. I will talk to the authors and se= e > what we should do. >=20 > Thanks again! >=20 >=20 > On 3/23/12 1:02 PM, "Stig Venaas" wrote: >=20 >> On 3/22/2012 7:29 PM, Lee, Yiu wrote: >>> Hi Stig, >>>=20 >>> DS-Lite was designed to deliver v4 unicast packets over v6-only network >>> to >>> v4 host. However when we started thinking about how to deliver multicas= t >>> packets in the same network setup, we will have to tunnel all multicast >>> packets over tunnels. This is very inefficient to use of AFTR. This is >>> the >>> motivation of dslite-multicast draft. However, you are absolutely right= . >>> This is a solution for tunneling IPv4 multicast through an IPv6-only >>> network. >>=20 >> I agree that double tunneling is a non-starter, so the draft seems to do >> the right thing. But since we seem to agree it is a more general >> solution, why not change the title and the text to make it more >> generic? You can still say that one of the use-cases is to provide IPv4 >> multicast for DS-Lite deployments. >>=20 >> Stig >>=20 >>>=20 >>> B.R., >>> Yiu >>>=20 >>> On 3/20/12 4:47 PM, "Stig Venaas" wrote: >>>=20 >>>> I'm a little bit puzzled by how this document talks about DS-Lite. >>>> Isn't this an entirely generic solution for tunneling IPv4 multicast >>>> through an IPv6-only network? >>>>=20 >>>> Stig >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>=20 From bingxuere@gmail.com Sat Mar 24 15:12:01 2012 Return-Path: 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 C9F5E21F84B4 for ; Sat, 24 Mar 2012 15:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 8os3wWr+fO+S for ; Sat, 24 Mar 2012 15:12:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5D21F84B2 for ; Sat, 24 Mar 2012 15:12:00 -0700 (PDT) Received: by iazz13 with SMTP id z13so7564983iaz.31 for ; Sat, 24 Mar 2012 15:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tpwzTy3UBoHGBG2LMMcK1WYqBrrU9dzJGtbs+PJqBc8=; b=sfx+Y1c/v/PC4noZKP3yESe6TV3WRfDFwyGNKLOChoWzePrauweV5Z9DaOSGcVWfiX 1oQ7oZVBMBpS6hzEtc+GO0UfW6Kdz23Hdtw9/jaqQfDILmAD8mWfsMRub2RvbmjeRk1x AW/Jmhg8gW56e/3q7yyfGKZyYxeUzO7f3nayGEWYO86efRCPdQm7oBYv7XG2phJWTVq/ W47NWF+dLZAujzSBeVYXDVhyJCJAAPfsYzJ4AOqZJh4DA1ja3xi+p2VtRAW18+p+5y5b 4O53WhmFU3l+pHNPRD+gVSVBtwb7Y55aMBsQDog1aXbXP+iUixJp+IWFq/NLSU/pyVfA MENw== Received: by 10.50.217.230 with SMTP id pb6mr2334627igc.1.1332627119471; Sat, 24 Mar 2012 15:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Sat, 24 Mar 2012 15:11:19 -0700 (PDT) In-Reply-To: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> References: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> From: Qiong Date: Sun, 25 Mar 2012 06:11:19 +0800 Message-ID: To: Alain Durand Content-Type: multipart/alternative; boundary=14dae93411e712fcf304bc046ecd Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 22:12:01 -0000 --14dae93411e712fcf304bc046ecd Content-Type: text/plain; charset=UTF-8 Hi Alain, Thanks a lot for your explaination. It is much clearer now. Please see inline ~~ On Fri, Mar 23, 2012 at 10:06 PM, Alain Durand wrote: > > On Mar 23, 2012, at 4:22 AM, Qiong wrote: > > > Dear Alain and all, > > > > I'm trying to understand sd-nat-02 and I'm still wondering how to setup > subscriber-based binding table in sd-nat. In my understanding, a totally > static binding table will introduce a lot of workload for operators. > > Not necessarily. Operators maintain large database for customers, this is > just one more field there. > The real question is how to propagate this static table to the AFTRs. This > is implementation specific, > but our proposed solution is to use netconf. > [Qiong] Well, then do you mean operators should plan the specific relationship between IPv4 address, IPv6 address+ port set for each subscriber? In CT's case, although we do maintain a large database for subscriber's infomation, e.g. subscriber type, username, password, etc., we seldom make planning of each subscriber's IPv4 address. Only a small amount of top high priority subcribers will be configured with static addresses. > > > But otherwise, I guess there might be an algorithmic relationship > between IPv6 and IPv4 + port range. In this way, would it become some kind > of MAP, in which IPv4 address and IPv6 address is tightly coupled and need > to be planned in advance ? > > This can be done too, but you loose the most important advantage of > SD-Nat: the absence of hard coupling between the IPv4 and IPv6 address. > Not coupling both addresses enables great flexibility on how you allocate > addresses and port. > [Qiong] I do regard this as an important feature when we designed for lightweight 4over6 at the very beginning. But it is still not clear to me how to achieve it by using algorithmic method rather than MAP, especially in case there are multiple IPv4 pools, IPv6 pools with hierarchical relationship. Maybe the simplest way is still to configure a fully static mapping table, thoughts ? Thanks a lot ! Best wishes Qiong > > > I'm just wondering why do we still need to maintain per-subscriber > table in AFTR while still keeping stateless. Please correct me if I miss > something here : > > SD-Nat is per-flow stateless, with a per-subscriber static state. > > - Alain. --14dae93411e712fcf304bc046ecd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alain,

Thanks a lot for your explaination. It is much clearer now= . Please see inline ~~

On Fri, Mar 23, 20= 12 at 10:06 PM, Alain Durand <adurand@juniper.net> wrote:<= br>

On Mar 23, 2012, at 4:22 AM, Qiong wrote:

> Dear Alain and all,
>
> I'm trying to understand sd-nat-02 and I'm still wondering how= to setup subscriber-based binding table in sd-nat. In my understanding, a = totally static binding table will introduce a lot of workload for operators= .

Not necessarily. Operators maintain large database for customers, thi= s is just one more field there.
The real question is how to propagate this static table to the AFTRs. This = is implementation specific,
but our proposed solution is to use netconf.
[Qiong] W= ell, then do you mean operators should plan the specific relationship betwe= en IPv4 address, IPv6 address+ port set for each subscriber? In CT's ca= se, although we do maintain a large database for subscriber's infomatio= n, e.g. subscriber type, username, password, etc., we seldom make planning = of each subscriber's IPv4 address. Only a small amount of top high prio= rity subcribers will be configured with static addresses. =C2=A0
=C2=A0

> But otherwise, I guess there might be an algorithmic relationship betw= een IPv6 and IPv4 + port range. In this way, would it become some kind of M= AP, in which IPv4 address and IPv6 address is tightly coupled and need to b= e planned in advance ?

This can be done too, but you loose the most important advantage of S= D-Nat: the absence of hard coupling between the IPv4 and IPv6 address.
Not coupling both addresses enables great flexibility on how you allocate a= ddresses and port.
=C2=A0
[Qiong] I do regar= d this as an important feature when we designed for lightweight 4over6 at t= he very beginning. But it is still not clear to me how to achieve it by usi= ng algorithmic method rather than MAP, especially in case there are multipl= e IPv4 pools, IPv6 pools with hierarchical relationship. Maybe the simplest= way is still to configure a fully static mapping table, thoughts ?

Thanks a lot !

Best wishes
Qiong



> =C2=A0 I'm just wondering why do we still need to maintain per-sub= scriber table in AFTR while still keeping stateless. Please correct me if I= miss something here :

SD-Nat is per-flow stateless, with a per-subscriber static state.

=C2=A0- Alain.

--14dae93411e712fcf304bc046ecd-- From adurand@juniper.net Sat Mar 24 15:53:07 2012 Return-Path: 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 95CBC21F84F9 for ; Sat, 24 Mar 2012 15:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DR6-c7Hunjhh for ; Sat, 24 Mar 2012 15:53:06 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id ED53521F84A0 for ; Sat, 24 Mar 2012 15:52:58 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT25QSUTgYeL9TJRE/7IkQXdQRP1HUYbo@postini.com; Sat, 24 Mar 2012 15:53:06 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 24 Mar 2012 15:51:46 -0700 From: Alain Durand To: Peng Wu Date: Sat, 24 Mar 2012 15:51:46 -0700 Thread-Topic: [Softwires] [Softwire] Algorithmic feature for SD-NAT Thread-Index: Ac0KELDwon6PcXi6QNmleyW+yff8RQ== Message-ID: References: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 22:53:07 -0000 On Mar 24, 2012, at 1:56 PM, Peng Wu wrote: > Hi Alain, >=20 > Same question I raised in the other thread. > 1) So this table is fully static, and we don't consider user entering > or leaving which may affect the bindings. Instead, the bindings only > rely on the addresses which won't change along the time. The bindings are created for paying customers. The idea is that you do not = need to make any pre-supposition on the format of their IPv6 nor the IPv4 address they w= ill be give, both are totally independent. In particular, this does not require sequential alloca= tion of IP addresses. Now, how do those static stables change when a customer is added or deleted= ? There are essentially 2 ways. 1) out of band configuration. For example Netconf. When the provisioning sy= stem add/dele a subscriber, part of the process is to send a Netconf update to the AFTR. 2) dynamic. When the AFTR sees a new potential subscriber (outside of the k= nown ranges), it ask the central repository about this subscriber. This could be a radius query. THe results is then ca= che for next packets. The advantage is that a 'brand new' AFTR can learn the state on the go, the inconvenient is that = it may take a while. > 2) Then this falls in the manner of pre-configuration for every > possible user IPv6 address, not on-demand allocation. Configuration for every IPv6 subscriber, not every possible IPv6 address in= the various /64 This is actually not that bad. Compare to BNGs that do the same and more to= day for IPv4 or IPv6. In the end, this is about clustering subscribers on groups of AFTR, the siz= e of the cluster being in the order of magnitude of the number of subscriber per BNGs, maybe up to 10x mo= re. Alain From adurand@juniper.net Sat Mar 24 15:56:48 2012 Return-Path: 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 E5A7521F84F7 for ; Sat, 24 Mar 2012 15:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 61nSwJnRu2yH for ; Sat, 24 Mar 2012 15:56:48 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1368421F84A0 for ; Sat, 24 Mar 2012 15:56:31 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT25RHaQvtKUUopIBDbPUu6McxTwjUaKl@postini.com; Sat, 24 Mar 2012 15:56:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sat, 24 Mar 2012 15:56:17 -0700 From: Alain Durand To: Qiong Date: Sat, 24 Mar 2012 15:56:16 -0700 Thread-Topic: [Softwire] Algorithmic feature for SD-NAT Thread-Index: Ac0KEVG++HvQ0dDpT/CCzK6humW+bw== Message-ID: <2E9189E8-8DE6-4642-8486-077DCDFAAF50@juniper.net> References: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 22:56:49 -0000 On Mar 24, 2012, at 6:11 PM, Qiong wrote: \> I'm trying to understand sd-nat-02 and I'm still wondering how to setup = subscriber-based binding table in sd-nat. In my understanding, a totally st= atic binding table will introduce a lot of workload for operators. Not necessarily. Operators maintain large database for customers, this is j= ust one more field there. The real question is how to propagate this static table to the AFTRs. This = is implementation specific, but our proposed solution is to use netconf. [Qiong] Well, then do you mean operators should plan the specific relations= hip between IPv4 address, IPv6 address+ port set for each subscriber? In CT= 's case, although we do maintain a large database for subscriber's infomati= on, e.g. subscriber type, username, password, etc., we seldom make planning= of each subscriber's IPv4 address. Only a small amount of top high priorit= y subcribers will be configured with static addresses. [Alain] I understand this is the practice now, when IPv4 addresses are esse= ntially free. When we move to a mode of operation where IPv4 addresses are a scarce and expensive resource, you want to be able to manage it tight= ly, just like you manage bandwidth for subscribers. > But otherwise, I guess there might be an algorithmic relationship between= IPv6 and IPv4 + port range. In this way, would it become some kind of MAP,= in which IPv4 address and IPv6 address is tightly coupled and need to be p= lanned in advance ? This can be done too, but you loose the most important advantage of SD-Nat:= the absence of hard coupling between the IPv4 and IPv6 address. Not coupling both addresses enables great flexibility on how you allocate a= ddresses and port. [Qiong] I do regard this as an important feature when we designed for light= weight 4over6 at the very beginning. But it is still not clear to me how to= achieve it by using algorithmic method rather than MAP, especially in case= there are multiple IPv4 pools, IPv6 pools with hierarchical relationship. = Maybe the simplest way is still to configure a fully static mapping table, = thoughts ? In the end, if you have a large number of small IPv4 blocks, there is not m= uch to be gained with deterministic formulas, you end up with a long and di= fficult to manage static list of formulas that are not tight to a business = logic. I would agree with you that at that point, you'd be better off with = a full static per subscriber table, managed out of band by netconf or other= tool. Alain. From adurand@juniper.net Sat Mar 24 16:00:14 2012 Return-Path: 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 A6C2721E8028 for ; Sat, 24 Mar 2012 16:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Obn-CmZkG65d for ; Sat, 24 Mar 2012 16:00:13 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1021E8019 for ; Sat, 24 Mar 2012 16:00:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT25R9l/b11tJMxQzeeUY3K4JyYIRBVii@postini.com; Sat, 24 Mar 2012 16:00:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 24 Mar 2012 15:58:39 -0700 From: Alain Durand To: "Lee, Yiu" Date: Sat, 24 Mar 2012 15:58:38 -0700 Thread-Topic: [Softwires] [Softwire] Algorithmic feature for SD-NAT Thread-Index: Ac0KEaaSH8LL9Zt+Ru6F1svAveRsdw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 23:00:14 -0000 The per subscriber mapping table looks like: Subscriber ID (usually IPv6 address of CPE) Assigned IPv4 public address (the one assigned by DHCPv4 over IPv6) port range Alain On Mar 23, 2012, at 2:26 PM, Lee, Yiu wrote: > Hi Alain, >=20 > Quick question. What snag suggests to keep in the customer database? Port > range info? >=20 > Thanks, > Yiu >=20 > On 3/23/12 10:06 AM, "Alain Durand" wrote: >=20 >> Not necessarily. Operators maintain large database for customers, this i= s >> just one more field there. >> The real question is how to propagate this static table to the AFTRs. >> This is implementation specific, >> but our proposed solution is to use netconf. From yong@csnet1.cs.tsinghua.edu.cn Sat Mar 24 18:07:59 2012 Return-Path: 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 38FCB21F850D for ; Sat, 24 Mar 2012 18:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] 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 L5rb-qBwPG8W for ; Sat, 24 Mar 2012 18:07:58 -0700 (PDT) Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6321F84D8 for ; Sat, 24 Mar 2012 18:07:37 -0700 (PDT) Received: from [192.168.0.155] (unknown [219.143.128.111]) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPA id 119B57108B47; Sun, 25 Mar 2012 09:01:09 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 25 Mar 2012 09:06:46 +0800 From: Yong Cui To: Alistair Woodman , Message-ID: Thread-Topic: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris In-Reply-To: <356701cd09dc$7872b190$695814b0$@org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415511211_14051997" Cc: fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 01:07:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415511211_14051997 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks for the demo. Would you please also give a summary to the mailing list, especially for someone who cannot join the demo. Yong From: Alistair Woodman Date: Sat, 24 Mar 2012 09:37:53 -0700 To: Cc: Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris > All, you are cordially invited=8A > =20 > Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of > draft-penno-softwire-sdnat-02. > =20 > The following will be shown: > =20 > 1) Stateless DS-Lite > 2) Stateless CPE B4 NAT > 3) Anycast Failover > 4) DHCPv4 proxy over v6 > 5) NAT Port range re-allocation via ICMP method. > =20 > When: Sunday the 25th from 15h30 to 17h00. > Where: Room #201 (Front left of Hall Maillot when facing = Porte > Maillot), IETF 83, Paris > _______________________________________________ Softwires mailing list > Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --B_3415511211_14051997 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Thanks for the demo.
Would you please also give a summary to the mailing list, especially for = someone who cannot join the demo.

Yong
From: Alistair Woodman <awoodman@isc.org>
Date: Sat, 24 Mar 2012 09:37:53 -0700
To: <softwire= s@ietf.org>
Cc: <fdupont@isc.org>
Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -= - Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris
=

All, you are cordially in= vited…

 

Francis Dupont, Paul Selkirk and Alain Durant are hosting a li= ve demo of draft-penno-softwire-sdnat-02.

 

The following will be shown:

 

1)= Stateless DS-Lite

2) Stateless CPE B4 NA= T

3) Anycast Failover

4) DHCPv4 proxy over v6

5= ) NAT Port range re-allocation via ICMP method.

 

When:    &nb= sp;             = Sunday the 25th from 15h30 to 17h00.

Where:           &n= bsp;     Room #201 (Front left of Hall Maillot when faci= ng Porte Maillot), IETF 83, Paris

__________= _____________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.= org/mailman/listinfo/softwires
--B_3415511211_14051997-- From fibrib@gmail.com Sat Mar 24 18:50:53 2012 Return-Path: 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 76AFE21F8501 for ; Sat, 24 Mar 2012 18:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 cDyBHuFCpG9d for ; Sat, 24 Mar 2012 18:50:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82C0221F84FF for ; Sat, 24 Mar 2012 18:50:52 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3119913qcs.31 for ; Sat, 24 Mar 2012 18:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q+HVtd2g5gljjhb8qccf73gDzBIbsLlr/uq+V1zamD8=; b=vL2oJBIaHw0wRPQ8e1Vhvu6knFWH0+NhWxItYeq7VnijwgZnE+D0ydchAEeMsmYXrV WbfKa8KyrBtOHvboc0/8R9sVW54X/FqZTivaxNPvBX481/i0CnHNyQ2u4Hf587QL9+dm XT2d6xXZIZna8K8jZfIS6E6VGlFy3lm9W+rb57RMhZC8hwBvzm/MSGcH6I632CQ6Tz// mn5I7cHjO5Vi5HCrY6p2IWinAwiewDMRf3OUkHIK2c7xRE7RhnGxgS0LyImE7B4SDEZt iaewk1MgOoqeiHxCImcprLTcewN/OxQ5JjYLxSHkQHmypM+0BOap1/7qNcEokkeyBu/D ZoLQ== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr22304299qab.11.1332640252032; Sat, 24 Mar 2012 18:50:52 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sat, 24 Mar 2012 18:50:51 -0700 (PDT) In-Reply-To: <16124E27-9D5C-45DE-9EC1-6BC5CC41E909@laposte.net> References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> <16124E27-9D5C-45DE-9EC1-6BC5CC41E909@laposte.net> Date: Sun, 25 Mar 2012 10:50:51 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b4b8d5f6e504bc077cc0 Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 01:50:53 -0000 --20cf3074b4b8d5f6e504bc077cc0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/20 R=E9mi Despr=E9s > > Le 2012-03-19 =E0 16:12, Maoke a =E9crit : > > > > 2012/3/20 R=E9mi Despr=E9s > >> >> Le 2012-03-19 =E0 15:30, Maoke a =E9crit : >> >> >> >> 2012/3/19 R=E9mi Despr=E9s >> >>> >>> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >>> ... >>> >>> >>>>> let me draw an example for that: >>>>> >>>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>>> router R2 here)--- B >>>>> >>>>> ... >>> >>> 4rd-u isn't concerned with what happens between A and CE. >>>> There, internal hosts have RFC1918 addresses and external hosts public >>>> IPv4 addresses. >>>> >>> >>> no problem here for 4rd-u, but RFC6145/6146 work also in the case the >>> translator is not located next to the end hosts. then i understand 4rd-= u is >>> less flexible. >>> >>> >>> I don't see the configuration you have in mind. >>> >>> >> >> people often insert a router between the home CE and their computers ;-) >> sometimes, e.g., because the CE has limited number of ports for connecti= on >> or less funtioning. >> >> >> >> I still don't see the problem with a NAT44 in the CE. >> >> > > the topic is about 0.0.0.0 as the source address for the ICMPv6-translate= d > ICMPv4 message's IP header. if there is a router between the CE and the > host, the packet with 0.0.0.0 will be discarded rather than being > forwarded, according to the common definition of the "unspecified address= ". > > > As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, of > course, nor in IPv4 where the only in-site IPv4 addresses are RFC1918. > Anything missed? > > well, not understood at all. Remi, may you please make a numerical example to explain in detail how the "unspecified IPv4 address" is used in 4rd-u/NAT64+? thanks in advance! - maoke > RD > > > --20cf3074b4b8d5f6e504bc077cc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-19 =E0 16:12, = Maoke a =E9crit :


=
2012/3/20 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-19 =E0 15:30, = Maoke a =E9crit :



2012/3/19 R=E9mi Despr=E9s <despres.remi@laposte= .net>

Le 2012-03-19 =E0 11:38, = Maoke a =E9crit :
...


let me draw an ex= ample for that:

A --- CE ----(IPv6 domain; router = R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
=
...

<= blockquote type=3D"cite">
4rd-u isn't concerne= d with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for 4rd-= u, but RFC6145/6146 work also in the case the translator is not located nex= t to the end hosts. then i understand 4rd-u is less flexible.=A0

I don't see the configuration yo= u have in mind.
=A0
=A0
<= div>people often insert a router between the home CE and their computers ;-= ) sometimes, e.g., because the CE has limited number of ports for connectio= n or less funtioning.


I still don't se= e the problem with a NAT44 in the CE.
=A0
=A0
the topic is about 0.0.0.0 as the source address for th= e ICMPv6-translated ICMPv4 message's IP header. if there is a router be= tween the CE and the host, the packet with 0.0.0.0 will be discarded rather= than being forwarded, according to the common definition of the "unsp= ecified address".

As I already said, 0.0.0.0 nev= er appears on any wire: neither in IPv6, of course, nor in IPv4 where the o= nly in-site IPv4 addresses are RFC1918.
Anything missed?

=A0
well, not unders= tood at all. Remi, may you please make a numerical example to explain in de= tail how the "unspecified IPv4 address" is used in 4rd-u/NAT64+? = thanks in advance!
=A0
- maoke
=A0
RD


<= /div>

--20cf3074b4b8d5f6e504bc077cc0-- From fibrib@gmail.com Sat Mar 24 20:34:32 2012 Return-Path: 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 CAEF121E8042 for ; Sat, 24 Mar 2012 20:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=-2.718, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 lri8RgQelGfX for ; Sat, 24 Mar 2012 20:34:30 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C221E8011 for ; Sat, 24 Mar 2012 20:34:30 -0700 (PDT) Received: by qadc14 with SMTP id c14so1645286qad.10 for ; Sat, 24 Mar 2012 20:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SWMXHAKOAgKif1Fyf0eGl+HmeOXEgHdAfLohzBWl5Xs=; b=uXuok3O/MpLQ1kG0PQ/vtTIUNzczcdOvmYaojuJyYI6jllD+N9Nwnnrx9jJMJEEKpU 2pUO5C+odmtuK/Tb+oVDw2qNk2ufmzZs71yfUx4n0cGuKgmpWCL7dM4uepyh1yGQ8bd+ BfX9gZW++6ojIVAmdLn7wquP9XHv0eFPH2M07Q8lLzS5Bu/ToJ4M9k6N2QdS1uqD5nIi GobhGV9WYSwOgrIUlj8dX/35SieUbUvTyqMeWaTosIZkXPAc8c9+9a05xrO/tNQRc5ra LzvytNCMprp2/pmVI9YM3E21zsnPQGfwpBcupJy2j0QtID24nBNksuT+zVLalnTCryDE xjVw== MIME-Version: 1.0 Received: by 10.229.77.141 with SMTP id g13mr6754559qck.11.1332646466361; Sat, 24 Mar 2012 20:34:26 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sat, 24 Mar 2012 20:34:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Mar 2012 12:34:26 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235429cbe03d1c0c04bc08ef7c Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 03:34:32 -0000 --00235429cbe03d1c0c04bc08ef7c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/3/24 R=A8=A6mi Despr=A8=A6s > > Le 2012-03-22 =A8=A4 15:40, Maoke a =A8=A6crit : > > dear Alain, Yong, Ralph and all, > > in program, the effort of the MAP team should be respected. The formation > of the MAP team was also the consensus of our meeting in beijing and we > have seen the the team is working with clear progress. I don't think it i= s > correct now to insert 4rd-u into a sort of exclusive decision of choice. > And 4rd-u also has the address format elements abondoned by the MAP desig= n > team. I believe the MAP format reflects that the common understanding > concludes the insignificance of those features. Sorry but the chair's > questions a little confused me: if we need to go back to the stage befor= e > the works of the MAP design team? > > The MAP series have reached running codes > > > and the collective understanding of the community. > > > Here are some issues among those remaining before reaching "collective > understanding": > > some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the 1) MAP address format and the corresponding algorithms 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 3) DHCP extensions as a way of distributing rules. the above big picture are what i call "collective understanding". the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy. > > a) T operation in hub&spoke (hasn't been so far answered in an > understandable way). > i doubt i understand what you mean. may you please specify the question in details? > > b) IDs from shared-address CEs. T currently has so far no solution while > both U and E include one. > > what do you mean with the IDs? or do you mean interface IDs? i don't see "IDs from shared-address CEs" in U too. please teach! > > c) MAP-A+P says "Each MAP node in the domain has the same set of rules" > while MAP-T says "if a CE knows only a subset of the mapping rules ..." > > first of all, they are not conflicting logically. second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple. > > d) Whether T can work with a single mapping rule (as was, I think, the > case for IVI). So far DMR and BMR seem exclusive, and there is no way to > distinguish them in MAP-dhcp. > > single mapping rule for a domain !=3D single mapping rule for the IPv4 worl= d. the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. > > The fact that no-one involved in the MAP design raised any of these issue= s > is AFAIK sign that MAP has NOT reached "collective understanding of the > community". > (Note that, concerning stateless v4/v6 solutions, I think I should be > considered part of this community. Right? ). > > well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle. > > > Maoke, clarifications on these points will be welcome. > > > From a view of a middle-sized ISP and cloud service provider, we do > support to accept MAP series into standard track in order we can utilize = it > into business as soon as possible. > > in technology, first of all, MAP now has approached address mapping > algorithm and that enough to make the series a unified solution. In our > practice, we need to use either encapsulation or translation according to > the actual needs and environment. > > > Note: This excludes ISPs that would like to offer full IPv4 transparency > with some IPv6-only middles boxes. > Right? > > i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely. > > > The most important is, both the building blocks of transition > architecture: virtual link (supported by encapsulation/tunneling) and > participant of the delivery path (supported by translation), have their > suitable use cases. And their advantages and limitations have been well > investigated and understood by the community. > > second, i deeply discussed and explored 4rd-u, but i found its attempting > of mixing the tunneling and translation, if accepted as standard, may tra= p > the operators into a harsh situation of being unable to define what > building block it really is. > > > Such an operator would know it uses 4rd-U. > > well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, "i give you a horse", while the other said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 possible results, not certain right now: A. donkorse is just another sort of donkey, somehow good but somehow flawed. B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases. no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now. Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not? > > This doesn't seem to justify any FUD from co-authors from broadband and > mobile operators (or from product vendors). > > It is stated as tunneling but actually behaves like tunnel in some aspect= s > while like translation in some other aspects. > > > Yes indeed, thus achieving the best of both worlds without making it more > complex. Actually making it clearly less complex than supporting both T a= nd > E. > > i don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler. > (I have pointed out in the 4rd-u discussion thread). > > We see it only a yet-another-translation that try to solve some corner > problems but introduces new, possibly major flaws (also pointed out in th= e > technical threads on 4rd.) > > > "Possibly major flaws" isn't an identified point on which U would do less > than what it has been designed to do (unified replacement of T + E). > > i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me. > > > IMPORTANT: > - The essential characterization of U (vs T and E) is its Reversible > header mapping (as replacement of both Double RFC6145 translation and > Encapsulation). > > yet-another-translation, with some issues still in debates. > > - Other features of U that differ from MAP (V-octet, CNP), or are > complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this > respect. Each of these features could be abandoned in U, or, if the WG > appreciates what they offer, added to MAP. > > MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time. > > - For this, community acceptance to listen to explanations, would be the > normal process. I will be available this week for this. > > i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car. regards, maoke > > > Cheers, > RD > > > In either the term of architectural philosophy or technical details, > introducing 4rd-u into standards would be harmful. > > personally, i respect the exploration of the author(s), and the discussio= n > between me and the author encouraged me to comprehensively review E and T= , > and the result is: i bacame much more confident of the correctness of the > MAP track. We should move forward. > > regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are > of a whole suite needing to be put into standard track. Question is not > about T, E or U. > > best regards, > Maoke > > =D4=DA 2012=C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand =D0= =B4=B5=C0=A3=BA > >> Dear wg, >> >> After a number of discussions with my co-chair, our AD and various >> authors, here is how we would like to move forward wrt 4rd. >> >> 1) There is an observation that all the solutions on the table E, T & U >> actually solve the stateless problem we started with. >> There are differences, but it is unclear if those differences are >> really significant. E and T are the original Encapsulation and Translati= on >> proposals, U is an hybrid unifying solution. >> >> 2) We have already agreed back in Beijing that we would publish all >> necessary documents. The issue here is the 'label' or 'status' those >> documents have at IETF. In particular, do we want to publish them as >> Experimental, Informational or Standard Track. >> >> We are at the point now where we need to make progress. In Paris, we >> would like to ask for presentations from the proponents of each candidat= e >> solution (E, T & U). >> Each presentation should cover an overview of the proposed solution, >> explain how it compares to the others and make a case as why it should b= e >> the one on the Standard Track. We will allocate 20 minutes for each >> presentation. >> >> Then, we, chairs, would like to ask a series of questions to the working >> group. In order to make this process transparent, here is the list of >> questions we want to ask >> and their sequence. >> >> Q1: Without pre-supposing which one will be selected, do you agree to >> publish 1 of the 3 proposals on the Standard Track and publish the other= (s) >> as Informational if still asked to? >> >> If the answer is NO, then the process stops and we will publish >> everything as Experimental and come back in 12-24 months to see what get= s >> adopted by the market. >> If the answer is YES, we move to the next question. >> >> >> Q2: Do you believe that the WG should publish U as the one Standards >> Track document? >> >> If the answer is YES, the process stop, we put U on the Standard Track >> and publish E & T as Informational. >> If the answer is NO, we are left with E & T (U then might be abandoned o= r >> published as Historical/Informational) >> >> >> Q3: Which of E and T do you want to see moving on the standard track (yo= u >> can only express support for one)? >> >> If there is a clear outcome from this question, we would publish that >> proposal on the Standard Track and the other one as Informational. >> If there is no clear consensus on this question, we will publish both E = & >> T as Experimental. >> >> In the meantime, we would like to encourage discussion on the mailing >> list to foster our common understanding of the various technologies and = how >> they relate to each other. >> >> Alain & Yong, wg co-chairs. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --00235429cbe03d1c0c04bc08ef7c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable dear Remi,
2012/3/24 R=A8=A6mi Despr=A8=A6s <= span dir=3D"ltr"><despres.re= mi@laposte.net>

Le 2012-03-22 =A8=A4 15:4= 0, Maoke a =A8=A6crit :

dear Alain, Yong, Ralph and all,

in program, the effor= t of the MAP team should be respected. The formation of the MAP team was al= so the consensus of our meeting in beijing and we have seen the the team is= working with clear progress. I don't think it is correct now to insert= 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the = address format elements abondoned by the MAP design team. I believe the MAP= format reflects that the common understanding concludes the insignificance= of those features. Sorry but the chair's questions  a little conf= used me: if we need to go back to the stage before the works of the MAP des= ign team?  

The MAP series have reached running codes

and the collective understanding o= f the community.

Here are some = issues among those remaining before reaching "collective understanding= ":
 
 
some issues= remaining not yet reaching collective undertanding is not a reason of maki= ng things over. the collective understanding has been reached for the major= part of the
1) MAP address format and the corresponding algorithms
2) en= capsulation and translation modes being supported by MAP format and th= e existing header processing standards 
3) DHCP extensi= ons as a way of distributing rules.
 
the above big picture are what i call "coll= ective understanding". the correct way is: making these alre= ady gained approaches as bases, continuing discussion or even dabate o= n the details. i don't think it is a correct way of action to disrespec= t a team's work. 4rd-u's problem is even its big picture is st= ill fuzzy.
 
=
 
a) T operation in hub&spoke (hasn't been so far answered in an= understandable way).
 
i= doubt i understand what you mean. may you please specify the question in d= etails?
 
=
 
b) IDs from shared-address CEs.  T currently has so far= no solution while both U and E include one. 
 
 
what do you mean with the IDs?= or do you mean interface IDs? i don't see "IDs fro= m shared-address CEs" in U too. please teach!
 
=
 
c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mappi= ng rules ..."  
 
 
first of all, they are not conflicting logically. second, if you mean = one doc is superior than multiple with better consistency in writing, i cou= ld agree. but it doesn't mean one doc is definitely reflecting "co= llective understanding" better than multiple.
 
=
 
d) Whether T can work with a single mapping rule (as was, I think, the= case for IVI). So far DMR and BMR seem exclusive, and there is no way to d= istinguish them in MAP-dhcp.
 
 
single mapping rule for a domain !=3D single mapping = rule for the IPv4 world. the IVI (RFC6052/6145/6219) practice does the latt= er. the latter doesn't need DHCP to distribute the mapping rule. in the= MAP, i don't think DMR and BMR being exclusive is a problem.
 
=
 
The fact that no-one involved in the MAP design raised any of th= ese issues is AFAIK sign that MAP has NOT reached "collective understa= nding of the community".
(Note that, concerning stateless v4= /v6 solutions, I think I should be considered part of this community. = Right? ).
 
 
well, "colle= ctive understanding" was mentioned by Sally Floyd to the community of = Internet researchers, and i borrowed her term. but i understand: no ma= tter it is research or engineering, collective understanding is the underst= anding on the problems and the architecture rather than the detailed t= echnical solutions. the MAP architecture has been reflected in the works of= the draft suite. on the other hand, the community is not the softwires wg = but the whole Internet engineering circle.
 
=  

Maoke, clarifications on these points will be welcome.<= /div>


From a view of a middle-sized ISP and cloud service provider= , we do support to accept MAP series into standard track in order we can ut= ilize it into business as soon as possible. 

in technology, first of all, MAP now has approached add= ress mapping algorithm and that enough to make the series a unified solutio= n. In our practice, we need to use either encapsulation or translation acco= rding to the actual needs and environment.

Note: This excludes ISPs that would = like to offer full IPv4 transparency with some IPv6-only middles boxes.
Right?
 
 
i cannot follow your "full IPv4 transparency" with "some&q= uot; IPv6-only middle boxes. what does the "transparency" mean fo= r the middle boxes? i understand, when we talk about the Internet transpare= ncy, we refer to the "end-to-end transparency". please specify yo= ur question concretely.
 
=  

The most importan= t is, both the building blocks of transition architecture: virtual link (su= pported by encapsulation/tunneling) and participant of the delivery path (s= upported by translation), have their suitable use cases. And their advantag= es and limitations have been well investigated and understood by the commun= ity. 

second, i deeply discussed and explored 4rd-u, but i fo= und its attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable to = define what building block it really is.

Such an operator would know it uses = 4rd-U. 
 
 
well, this is what i mean the uncertainty of 4rd-U in the = architecture to the common understanding. as a analogy, one of Mr. E a= nd Mr. T said, "i give you a horse", while the other sa= id "i give you a donkey". then people well understand when they n= eed a horse when they need a donkey. now Mr. U said "wow, i give you a= fantastic donkorse!". there would be 2 possible results, not cer= tain right now:
A. donkorse is just another sort of donkey, somehow good but somehow f= lawed.
B. donkorse is just donkorse, and people, taking a long t= ime to understand it, and finally find it either a flawed or a quite good h= ybrid, like mule, useful in some cases.
 
no matter if the future result is A or B, now Mr. O u= nderstand what he needs for his business is either a horse and a donkey, wi= th their well-known characteristics. Mr. MAP provides a wheeled car as = ;the common instrument, while Mr. O needs a standard suite for the wheeled-= car, the horse-driving and donkey-driving methods and the way of feeding th= e horse and donkey. this is the task of our wg, right now.  =
 
Mr. U said you must have another type of wheel and dr= ive it with my donkorse --- and when Mr. O asked him, what your donkorse is= , he answered: you will know it is donkorse, having both the advantages of = the horse and the advantages of the donkey. however, Mr. O doubts donkorse = hasn't also the disadvantages of horse and the disadvantages of donkey = and some flaws not yet documented. why not?
 
=
 
This doesn't seem to justify any FUD from co-authors from bro= adband and mobile operators (or from product vendors).

It is stated as tunneling but actuall= y behaves like tunnel in some aspects while like translation in some other = aspects.

Yes indeed, thus achieving the best = of both worlds without making it more complex. Actually making it clearly l= ess complex than supporting both T and E.
 
 
i don't think those who made out mul= e expected the mule could replace horse and donkey and achieving a better w= orld without horse and donkey but only mule. surely mule-only world is simp= ler.
 
=
(I have pointed out in the 4rd-u discussion= thread).
We see it only a yet-another-translation that try to so= lve some corner problems but introduces new, possibly major flaws (also poi= nted out in the technical threads on 4rd.)

"Possibly major flaws" isn= 't an identified point on which U would do less than what it has been d= esigned to do (unified replacement of T + E).
 
<= /div>
 
i believe they are major flaws but i was= gently argued with the "possibly" because i respected that maybe= others didn't think so critically like me.
 
 

IMPORTANT:  
- The essential characterization of U (vs T = and E) is its Reversible header mapping (as replacement of both Double RFC6= 145 translation and Encapsulation).
 
 
yet-another= -translation, with some issues still in debates.  
 
 
- Other feat= ures of U that differ from MAP (V-octet, CNP), or are complementary to= it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of= these features could be abandoned in U, or, if the WG appreciates wha= t they offer, added to MAP.
 
 
MAP team ha= s concluded V-octet and CNP are not necessary. do we need to debate again? = i doubt people have unlimited time.
 
 
- For this, = community acceptance to listen to explanations, would be the normal process= . I will be available this week for this.
 
=
 
i think we are all open to listen to and to discuss o= n any explorations but it doesn't mean we should stop standardization o= f our wheeled-car/horse-driving/donkey-driving/feeding suite with an expect= ation of a "better world" with only donkorse and the donkorse-spe= cific wheeled car.
 
regards,
maoke
 
 

Cheers,
RD


In either the term of architectural p= hilosophy or technical details, introducing 4rd-u into standards would be h= armful. 

personally, i respect the exploration of the author(s),= and the discussion between me and the author encouraged me to comprehensiv= ely review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward. 

regarding the chair's questions, my answer is: = ;MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into s= tandard track. Question is not about T, E or U. 

best regards,
Maoke

=D4=DA 2012= =C4=EA3=D4=C220=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACAlain Durand =D0=B4=B5=C0=A3= =BA
Dear wg,

After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T &= amp; U actually solve the stateless  problem we started with.
   There are differences, but it is unclear if those differences= are really significant. E and T are the original Encapsulation and Transla= tion
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' tho= se
   documents have at IETF. In particular, do we want to publish = them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U).
Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation.<= br>
Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to?

If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards Track = document?

If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)?

If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E &am= p; T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


--00235429cbe03d1c0c04bc08ef7c-- From pengwu.thu@gmail.com Sat Mar 24 21:29:45 2012 Return-Path: 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 705CD21F847B for ; Sat, 24 Mar 2012 21:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZVyJvn5BxHmy for ; Sat, 24 Mar 2012 21:29:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9221F847A for ; Sat, 24 Mar 2012 21:29:45 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4466221pbb.31 for ; Sat, 24 Mar 2012 21:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/BLAq8ULXRmydm/eDXxa7RIGGLyOr71SBT8B+HHJoY=; b=LUJY9aBbqy7hCjx7O0TK7y/Bmgqt6LtoXKsFYUlsRBJ4uSpLMrTbPify2jas68wHmb rMCJmPlAnf9pcOpsI3ZfqyJOW1emx2b1uB87NFUjmoposuscE5Eu1xaijbhpm22qcHZ+ RkxVjf1GQ70pH3cxmTcwx/ptkR6drxrdX/KWWWH+wbTx6iNd5B7b/MFeQ3C+hgfE72by cIHTOHhB92HcQedy9a+dnC+XMlAs4NKcOPIinfziSxO2M7XJdFSx6LueoCjFXJP5IvMU AknKmN0BOeSd1ZR3Lj7+4mpCcqomAWbWCnxiTeu8YvofwZmtvEAMZ02MFrpUruBNoHcF g2AA== MIME-Version: 1.0 Received: by 10.68.234.134 with SMTP id ue6mr43115378pbc.14.1332649784785; Sat, 24 Mar 2012 21:29:44 -0700 (PDT) Received: by 10.68.242.132 with HTTP; Sat, 24 Mar 2012 21:29:44 -0700 (PDT) In-Reply-To: References: <78A5B8D9-3439-490E-9B3B-638BA28E3504@juniper.net> Date: Sun, 25 Mar 2012 12:29:44 +0800 Message-ID: From: Peng Wu To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 04:29:45 -0000 Hi Alain, Thanks. It really helps. > Configuration for every IPv6 subscriber, not every possible IPv6 address in the various /64 > This is actually not that bad. Compare to BNGs that do the same and more today for IPv4 or IPv6. > In the end, this is about clustering subscribers on groups of AFTR, the size of the cluster being in the > order of magnitude of the number of subscriber per BNGs, maybe up to 10x more. I agree. This is pretty much my general understanding. From ichiroumakino@gmail.com Sat Mar 24 22:31:46 2012 Return-Path: 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 B752821F843A for ; Sat, 24 Mar 2012 22:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 hiJp6AzhUq1C for ; Sat, 24 Mar 2012 22:31:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B43AD21F8562 for ; Sat, 24 Mar 2012 22:31:45 -0700 (PDT) Received: by lbol12 with SMTP id l12so3610726lbo.31 for ; Sat, 24 Mar 2012 22:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OeahMrpqDSI/bN+nIWQQ647V4rpici0gBfSWdnte7hw=; b=IeddFvpCmTgsdOv978/6L2Ke2U1knRDDEET8Qn3wkn9qE9ysu1jU/A82hVQVncaUAU BkZSILpNUVhzE39dkn9DauDlMNvPZVjANTS69tfaXpVrrjfj5ZNAdyAYZE2R+RF53dkp MmG05uJLrwh17zaU4ZQfaAV0ksBGInoaDk5n/VNNVGFe8m1ivvBFsvu4o075ItrOWWmU 1SBvCBmFvTzDZHPX+Q8hXHyEN0hjl5gHrW2DllRAwcnZMeGInXSHbaB+4i17vpgHBbwG W9zTmOGZBzqwK1HPpefR0OEctV0Pm5dfm1JOHKhOwDLEc7991Q0icQ10NcfolO+4W9Bo wzeA== Received: by 10.112.86.229 with SMTP id s5mr6426037lbz.0.1332653504621; Sat, 24 Mar 2012 22:31:44 -0700 (PDT) Received: from [172.20.10.2] (77.19.4.15.tmi.telenormobil.no. [77.19.4.15]) by mx.google.com with ESMTPS id h8sm16739391lbx.8.2012.03.24.22.31.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 22:31:43 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <3F8D43A5-9D98-4BD3-9503-AF548D53403C@laposte.net> Date: Sun, 25 Mar 2012 07:31:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <923D5842-2C9E-4CF6-86FC-5DB8773ADA53@employees.org> References: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> <3F8D43A5-9D98-4BD3-9503-AF548D53403C@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 05:31:46 -0000 Remi, >> the authors did already do that. the dIVI and 4rd authors met 16th of = November at the last IETF. >> we collectively went through the complete feature list. the result is = what you find in the MAP document series. >=20 > This MAP meeting was immediately after the Taipei Softwire meeting. At = this meeting, with an invalid technical argument, you had convinced most = participants that -U couldn't work, so that a majority didn't believe = the -U approach could be useful.=20 that's not quite how I remember it. there were a number of issues = discussed with 4rd-U. - destination spread, caused by Max PSID, CNP (I was wrong about CNP = causing destination spread). - V-octet; implications - how -U achieves transparency by overloading information in the = fragmentation header > During this MAP meeting, a majority consequently expressed no interest = in considering further, for MAP, new features that were part of the -U = proposal (Reversible header mapping; Checksum neutrality, AKA CNP; = Distinguishable address format, AKA V octet). the MAP effort has focused on the mandatory functionality and features = only. all the "features" between 4rd-U and MAP are interchangeable. in this = instance I do believe "less is more" though. the distinguishing part of 4rd-U is that is uses a different form of = translation than what MAP does. cheers, Ole From Francis.Dupont@fdupont.fr Sat Mar 24 23:55:41 2012 Return-Path: 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 63E8921F854B for ; Sat, 24 Mar 2012 23:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 zs5OSoNrZkcM for ; Sat, 24 Mar 2012 23:55:40 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id CE71621F854D for ; Sat, 24 Mar 2012 23:55:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2P6tYMx018964; Sun, 25 Mar 2012 08:55:34 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203250655.q2P6tYMx018964@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Sun, 25 Mar 2012 02:06:08 +0800. Date: Sun, 25 Mar 2012 08:55:34 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires@ietf.org, fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 06:55:41 -0000 In your previous mail you wrote: > Great. So ISC already has DHCPv4 over IPv6 implementation now. => yes but it is experimental: we don't use the IANA assigned number for CRA6ADDR for instance (as IANA will be involved later in the IETF process) and there are some interesting technical problems raised by the spec... Look at the DHC WG mailing list. Regards Francis.Dupont@fdupont.fr From despres.remi@laposte.net Sun Mar 25 00:00:12 2012 Return-Path: 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 6353521F8599 for ; Sun, 25 Mar 2012 00:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 7QjwH8kfHABV for ; Sun, 25 Mar 2012 00:00:10 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39E21F8597 for ; Sun, 25 Mar 2012 00:00:09 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id pj051i00437Y3f403j05P4; Sun, 25 Mar 2012 09:00:07 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-16735757 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sun, 25 Mar 2012 08:58:57 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:00:12 -0000 --Apple-Mail-9-16735757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-03-25 =C3=A0 05:34, Maoke a =C3=A9crit : > dear Remi, > 2012/3/24 R=C3=A9mi Despr=C3=A9s >=20 > Le 2012-03-22 =C3=A0 15:40, Maoke a =C3=A9crit : >=20 >> dear Alain, Yong, Ralph and all, >>=20 >> in program, the effort of the MAP team should be respected. The = formation of the MAP team was also the consensus of our meeting in = beijing and we have seen the the team is working with clear progress. I = don't think it is correct now to insert 4rd-u into a sort of exclusive = decision of choice. And 4rd-u also has the address format elements = abondoned by the MAP design team. I believe the MAP format reflects that = the common understanding concludes the insignificance of those features. = Sorry but the chair's questions a little confused me: if we need to go = back to the stage before the works of the MAP design team? =20 >>=20 >> The MAP series have reached running codes >=20 >> and the collective understanding of the community. >=20 > Here are some issues among those remaining before reaching "collective = understanding": > =20 > =20 > some issues remaining not yet reaching collective undertanding is not = a reason of making things over. the collective understanding has been = reached for the major part of the > 1) MAP address format and the corresponding algorithms > 2) encapsulation and translation modes being supported by MAP format = and the existing header processing standards=20 > 3) DHCP extensions as a way of distributing rules. > =20 > the above big picture are what i call "collective understanding". the = correct way is: making these already gained approaches as bases, = continuing discussion or even dabate on the details. i don't think it is = a correct way of action to disrespect a team's work. 4rd-u's problem is = even its big picture is still fuzzy. Not more fuzzy than MAP (actually less fuzzy IMHO). Debate on details is possible for U as wall as for T+E. > a) T operation in hub&spoke (hasn't been so far answered in an = understandable way). > =20 > i doubt i understand what you mean. may you please specify the = question in details? Is a DHCPv6 parameter needed, yes or no? > b) IDs from shared-address CEs. T currently has so far no solution = while both U and E include one.=20 > =20 > =20 > what do you mean with the IDs? or do you mean interface IDs? i don't = see "IDs from shared-address CEs" in U too. please teach! Sec 4.5.3. is "Packet Identifications from Shared-Address CEs". Did you read the complete draft? > c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 > =20 > =20 > first of all, they are not conflicting logically. ??? > second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed.=20 Remaining question: which one? > but it doesn't mean one doc is definitely reflecting "collective = understanding" better than multiple. > =20 > =20 > d) Whether T can work with a single mapping rule (as was, I think, the = case for IVI). So far DMR and BMR seem exclusive, and there is no way to = distinguish them in MAP-dhcp. > =20 > =20 > single mapping rule for a domain !=3D single mapping rule for the IPv4 = world. ??? > the IVI (RFC6052/6145/6219) practice does the latter. the latter = doesn't need DHCP to distribute the mapping rule. in the MAP, i don't = think DMR and BMR being exclusive is a problem. How many MAP mapping rules do you see for the equivalent of the IVI use = case in a MAP domain?=20 None?=20 If one, is it a DMR or a BMR? If two, what are they? > The fact that no-one involved in the MAP design raised any of these = issues is AFAIK sign that MAP has NOT reached "collective understanding = of the community". > (Note that, concerning stateless v4/v6 solutions, I think I should be = considered part of this community. Right? ). > =20 > =20 > well, "collective understanding" was mentioned by Sally Floyd to the = community of Internet researchers, and i borrowed her term. but i = understand: no matter it is research or engineering, collective = understanding is the understanding on the problems and the architecture = rather than the detailed technical solutions. the MAP architecture has = been reflected in the works of the draft suite. on the other hand, the = community is not the softwires wg but the whole Internet engineering = circle. > =20 > =20 >=20 > Maoke, clarifications on these points will be welcome. >=20 >=20 >> =46rom a view of a middle-sized ISP and cloud service provider, we do = support to accept MAP series into standard track in order we can utilize = it into business as soon as possible.=20 >>=20 >> in technology, first of all, MAP now has approached address mapping = algorithm and that enough to make the series a unified solution. In our = practice, we need to use either encapsulation or translation according = to the actual needs and environment. >=20 > Note: This excludes ISPs that would like to offer full IPv4 = transparency with some IPv6-only middles boxes. > Right? > =20 > =20 > i cannot follow your "full IPv4 transparency" with "some" IPv6-only = middle boxes. what does the "transparency" mean for the middle boxes? i = understand, when we talk about the Internet transparency, we refer to = the "end-to-end transparency". please specify your question concretely. OK, could have been clearer. Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. >> The most important is, both the building blocks of transition = architecture: virtual link (supported by encapsulation/tunneling) and = participant of the delivery path (supported by translation), have their = suitable use cases. And their advantages and limitations have been well = investigated and understood by the community.=20 >>=20 >> second, i deeply discussed and explored 4rd-u, but i found its = attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable = to define what building block it really is. >=20 > Such an operator would know it uses 4rd-U.=20 > =20 > =20 > well, this is what i mean the uncertainty of 4rd-U in the architecture = to the common understanding. as a analogy, one of Mr. E and Mr. T said, = "i give you a horse", while the other said "i give you a donkey". then = people well understand when they need a horse when they need a donkey. = now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 = possible results, not certain right now: > A. donkorse is just another sort of donkey, somehow good but somehow = flawed. > B. donkorse is just donkorse, and people, taking a long time to = understand it, and finally find it either a flawed or a quite good = hybrid, like mule, useful in some cases. > =20 > no matter if the future result is A or B, now Mr. O understand what he = needs for his business is either a horse and a donkey, with their = well-known characteristics. Mr. MAP provides a wheeled car as the common = instrument, while Mr. O needs a standard suite for the wheeled-car, the = horse-driving and donkey-driving methods and the way of feeding the = horse and donkey. this is the task of our wg, right now. =20 > =20 > Mr. U said you must have another type of wheel and drive it with my = donkorse --- and when Mr. O asked him, what your donkorse is, he = answered: you will know it is donkorse, having both the advantages of = the horse and the advantages of the donkey. however, Mr. O doubts = donkorse hasn't also the disadvantages of horse and the disadvantages of = donkey and some flaws not yet documented. why not? > =20 > =20 > This doesn't seem to justify any FUD from co-authors from broadband = and mobile operators (or from product vendors). >=20 >> It is stated as tunneling but actually behaves like tunnel in some = aspects while like translation in some other aspects. >=20 > Yes indeed, thus achieving the best of both worlds without making it = more complex. Actually making it clearly less complex than supporting = both T and E. > =20 > =20 > i don't think those who made out mule expected the mule could replace = horse and donkey and achieving a better world without horse and donkey = but only mule. surely mule-only world is simpler. Comparison is not reason (French proverb). > =20 >> (I have pointed out in the 4rd-u discussion thread). >=20 >> We see it only a yet-another-translation that try to solve some = corner problems but introduces new, possibly major flaws (also pointed = out in the technical threads on 4rd.) >=20 > "Possibly major flaws" isn't an identified point on which U would do = less than what it has been designed to do (unified replacement of T + = E). > =20 > =20 > i believe they are major flaws but i was gently argued with the = "possibly" because i respected that maybe others didn't think so = critically like me. I have still to understand where you see "major flaws". Just asserting they exist, without explanation although others who read = the specification don't see them isn't enough. Saying that E+T is better because its current inconsistencies are = "details" isn't enough either (IMHO). > IMPORTANT: =20 > - The essential characterization of U (vs T and E) is its Reversible = header mapping (as replacement of both Double RFC6145 translation and = Encapsulation). > =20 > =20 > yet-another-translation, with some issues still in debates. You can call it as you wish, but the point remains that, with U, one = doesn't need both E and T. > - Other features of U that differ from MAP (V-octet, CNP), or are = complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this = respect. Each of these features could be abandoned in U, or, if the WG = appreciates what they offer, added to MAP. > =20 > =20 > MAP team has concluded V-octet and CNP are not necessary. do we need = to debate again? i doubt people have unlimited time. I made the point many times that the right to analyze problems didn't = stop after a majority decision obtained during an improvised meeting. Many MAP contributors were absents, and no time was given to correct = invalid objections that had been made just before during a WG meeting. Note that several co-authors of the U proposal have been MAP = contributors. =20 > - For this, community acceptance to listen to explanations, would be = the normal process. I will be available this week for this. > =20 > =20 > i think we are all open to listen to and to discuss on any = explorations but it doesn't mean we should stop standardization of our = wheeled-car/horse-driving/donkey-driving/feeding suite with an = expectation of a "better world" with only donkorse and the = donkorse-specific wheeled car. Your stand is clear, but comparison isn't reason. RD > regards, > maoke > =20 > =20 >=20 > Cheers, > RD >=20 >=20 >> In either the term of architectural philosophy or technical details, = introducing 4rd-u into standards would be harmful.=20 >>=20 >> personally, i respect the exploration of the author(s), and the = discussion between me and the author encouraged me to comprehensively = review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward.=20 >>=20 >> regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP = are of a whole suite needing to be put into standard track. Question is = not about T, E or U.=20 >>=20 >> best regards, >> Maoke >>=20 >> =E5=9C=A8 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C= =EF=BC=8CAlain Durand =E5=86=99=E9=81=93=EF=BC=9A >> Dear wg, >>=20 >> After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >>=20 >> 1) There is an observation that all the solutions on the table E, T = & U actually solve the stateless problem we started with. >> There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation >> proposals, U is an hybrid unifying solution. >>=20 >> 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those >> documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >>=20 >> We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). >> Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >>=20 >> Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask >> and their sequence. >>=20 >> Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >>=20 >> If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. >> If the answer is YES, we move to the next question. >>=20 >>=20 >> Q2: Do you believe that the WG should publish U as the one Standards = Track document? >>=20 >> If the answer is YES, the process stop, we put U on the Standard = Track and publish E & T as Informational. >> If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational) >>=20 >>=20 >> Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >>=20 >> If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. >> If there is no clear consensus on this question, we will publish both = E & T as Experimental. >>=20 >> In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. >>=20 >> Alain & Yong, wg co-chairs. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-9-16735757 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
dear Remi,
2012/3/24 R=C3=A9mi= Despr=C3=A9s <despres.remi@laposte.net><= /span>

Le 2012-03-22 =C3=A0 = 15:40, Maoke a =C3=A9crit :

dear Alain, Yong, Ralph and all,

in = program, the effort of the MAP team should be respected. The formation = of the MAP team was also the consensus of our meeting in beijing and we = have seen the the team is working with clear progress. I don't think it = is correct now to insert 4rd-u into a sort of exclusive decision of = choice. And 4rd-u also has the address format elements abondoned by the = MAP design team. I believe the MAP format reflects that the common = understanding concludes the insignificance of those features. Sorry but = the chair's questions  a little confused me: if we need to go back = to the stage before the works of the MAP design team?  

The MAP series have reached running codes =

and the collective = understanding of the = community.

Here are some = issues among those remaining before reaching "collective = understanding":
 
 
some = issues remaining not yet reaching collective undertanding is not a = reason of making things over. the collective understanding has been = reached for the major part of the
1) MAP address format and the corresponding algorithms
2) = encapsulation and translation modes being supported by MAP format = and the existing header processing standards 
3) = DHCP extensions as a way of distributing rules.
 
the above big picture are what i call = "collective understanding". the correct way is: making these = already gained approaches as bases, continuing discussion or even = dabate on the details. i don't think it is a correct way of action to = disrespect a team's work. 4rd-u's problem is even its big picture = is still fuzzy.

Not more = fuzzy than MAP (actually less fuzzy IMHO).
Debate on details = is possible for U as wall as for T+E.

a) T operation in hub&spoke (hasn't been so far answered in an = understandable = way).
 
i doubt i = understand what you mean. may you please specify the question in = details?

Is a DHCPv6 parameter = needed, yes or no?


b) IDs from shared-address CEs.  T currently has so = far no solution while both U and E include = one. 
 
 
what do you mean with the IDs? or do you mean interface = IDs? i don't see "IDs from shared-address CEs" in U too. = please teach!

Sec 4.5.3. is = "Packet Identifications from Shared-Address CEs".
Did you read = the complete draft?


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean = one doc is superior than multiple with better consistency in writing, i = could agree.

This is not the = point.
Separate documents can be consistent, but they aren't = on this point.

One of the two assertions must = be changed. 
Remaining question: which = one?

but it doesn't mean one doc is definitely = reflecting "collective understanding" better than multiple.
 
 
d) Whether T can work with a single mapping rule (as was, I think, = the case for IVI). So far DMR and BMR seem exclusive, and there is no = way to distinguish them in = MAP-dhcp.
 
 
single mapping rule for a domain !=3D single = mapping rule for the IPv4 world. =

???

the IVI = (RFC6052/6145/6219) practice does the latter. the latter doesn't need = DHCP to distribute the mapping rule. in the MAP, i don't think DMR and = BMR being exclusive is a problem. =

How many MAP mapping rules do = you see for the equivalent of the IVI use case in a MAP = domain? 
None? 
If one, is it a DMR or a = BMR?
If two, what are = they?


The fact that no-one involved in the = MAP design raised any of these issues is AFAIK sign that MAP has NOT = reached "collective understanding of the community".
(Note = that, concerning stateless v4/v6 solutions, I think I should be = considered part of this community. Right? ).
 
 
well, = "collective understanding" was mentioned by Sally Floyd to the community = of Internet researchers, and i borrowed her term. but i understand: = no matter it is research or engineering, collective understanding is the = understanding on the problems and the architecture rather than the = detailed technical solutions. the MAP architecture has been reflected in = the works of the draft suite. on the other hand, the community is not = the softwires wg but the whole Internet engineering circle.
 
 

Maoke, clarifications on these points will be = welcome.


=46rom a view of a = middle-sized ISP and cloud service provider, we do support to accept MAP = series into standard track in order we can utilize it into business as = soon as possible. 

in technology, first of all, MAP now has approached = address mapping algorithm and that enough to make the series a unified = solution. In our practice, we need to use either encapsulation or = translation according to the actual needs and environment.

Note: This excludes ISPs that = would like to offer full IPv4 transparency with some IPv6-only middles = boxes.
Right?
 
&nbs= p;
i cannot follow your "full IPv4 transparency" with "some" = IPv6-only middle boxes. what does the "transparency" mean for the middle = boxes? i understand, when we talk about the Internet transparency, we = refer to the "end-to-end transparency". please specify your question = concretely.

OK, could have = been clearer.
Yet, I think you understand that with U, = one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP = ports.


The most important is, both the building blocks of = transition architecture: virtual link (supported by = encapsulation/tunneling) and participant of the delivery path (supported = by translation), have their suitable use cases. And their advantages and = limitations have been well investigated and understood by the = community. 

second, i deeply discussed and explored 4rd-u, but i = found its attempting of mixing the tunneling and translation, if = accepted as standard, may trap the operators into a harsh situation of = being unable to define what building block it really is.

Such an operator would know it = uses = 4rd-U. 
 
 
well, this is what i mean the uncertainty of 4rd-U in = the architecture to the common understanding. as a analogy, one of = Mr. E and Mr. T said, "i give you a horse", while the = other said "i give you a donkey". then people well understand when = they need a horse when they need a donkey. now Mr. U said "wow, i give = you a fantastic donkorse!". there would be 2 possible results, not = certain right now:
A. donkorse is just another sort of donkey, somehow good but = somehow flawed.
B. donkorse is just donkorse, and people, = taking a long time to understand it, and finally find it either a flawed = or a quite good hybrid, like mule, useful in some cases.
 
no matter if the future result is A or B, now Mr. = O understand what he needs for his business is either a horse and a = donkey, with their well-known characteristics. Mr. MAP provides a = wheeled car as the common instrument, while Mr. O needs a standard = suite for the wheeled-car, the horse-driving and donkey-driving methods = and the way of feeding the horse and donkey. this is the task = of our wg, right now.  
 
Mr. U said you must have another type of wheel and = drive it with my donkorse --- and when Mr. O asked him, what your = donkorse is, he answered: you will know it is donkorse, having both the = advantages of the horse and the advantages of the donkey. however, Mr. O = doubts donkorse hasn't also the disadvantages of horse and the = disadvantages of donkey and some flaws not yet documented. why not? =
 
 
This doesn't seem to justify any FUD from co-authors from = broadband and mobile operators (or from product vendors).

It is stated as = tunneling but actually behaves like tunnel in some aspects while like = translation in some other aspects.

Yes indeed, thus achieving the = best of both worlds without making it more complex. Actually making it = clearly less complex than supporting both T and = E.
 
 
i don't think those who made out mule = expected the mule could replace horse and donkey and achieving a better = world without horse and donkey but only mule. surely mule-only world is = simpler.

Comparison is not = reason (French proverb).

 
(I have pointed out in the 4rd-u = discussion thread).
We see it only a = yet-another-translation that try to solve some corner problems but = introduces new, possibly major flaws (also pointed out in the technical = threads on 4rd.)

"Possibly major flaws" isn't an = identified point on which U would do less than what it has been designed = to do (unified replacement of T + E).
 
 
i believe they are major flaws but i = was gently argued with the "possibly" because i respected that maybe = others didn't think so critically like me. =

I have still to understand = where you see "major flaws".
Just asserting they exist, = without explanation although others who read the specification don't see = them isn't enough.
Saying that E+T is better because its = current inconsistencies are "details" isn't enough either = (IMHO).

IMPORTANT:  
- = The essential characterization of U (vs T and E) is its Reversible = header mapping (as replacement of both Double RFC6145 translation and = Encapsulation).
=
 
 
yet-anothe= r-translation, with some issues still in debates. =

You can call it as you = wish, but the point remains that, with U, one doesn't need both E and = T.


- = Other features of U that differ from MAP (V-octet, CNP), or are = complementary to it (Rule IPv6 suffix, NAT64+), are secondary in = this respect. Each of these features could be abandoned in U, or, = if the WG appreciates what they offer, added to MAP.
 
 
MAP team = has concluded V-octet and CNP are not necessary. do we need to debate = again? i doubt people have unlimited time. =

I made the point many times = that the right to analyze problems didn't stop after a majority decision = obtained during an improvised meeting.
Many MAP contributors = were absents, and no time was given to correct invalid objections that = had been made just before during a WG = meeting.

Note that several co-authors of the U = proposal have been MAP contributors. =  


- = For this, community acceptance to listen to explanations, would be the = normal process. I will be available this week for = this.
 
 
i think we are all open to listen to and to = discuss on any explorations but it doesn't mean we should stop = standardization of our wheeled-car/horse-driving/donkey-driving/feeding = suite with an expectation of a "better world" with only donkorse and the = donkorse-specific wheeled = car.

Your stand is clear, = but comparison isn't = reason.

RD




regards,
maoke
 
=
 

C= heers,
RD


In either = the term of architectural philosophy or technical details, introducing = 4rd-u into standards would be harmful. 

personally, i respect the exploration of the = author(s), and the discussion between me and the author encouraged me to = comprehensively review E and T, and the result is: i bacame much more = confident of the correctness of the MAP track. We should move = forward. 

regarding the chair's questions, my answer = is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be = put into standard track. Question is not about T, E or = U. 

best regards,
Maoke

=E5=9C=A8 = 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF=BC=8CAlai= n Durand =E5=86=99=E9=81=93=EF=BC=9A
Dear wg,

After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, = T & U actually solve the stateless  problem we started = with.
   There are differences, but it is unclear if those = differences are really significant. E and T are the original = Encapsulation and Translation
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those
   documents have at IETF. In particular, do we want to = publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation.

Then, we, chairs, would like to ask a series of questions to the working = group. In order to make this process transparent, here is the list of = questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards = Track document?

If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)?

If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E = & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-9-16735757-- From despres.remi@laposte.net Sun Mar 25 00:19:45 2012 Return-Path: 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 967BD21F85A0 for ; Sun, 25 Mar 2012 00:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.072, 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 nE3aMoYA+5-f for ; Sun, 25 Mar 2012 00:19:45 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67A21F8581 for ; Sun, 25 Mar 2012 00:19:43 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id pjKh1i00237Y3f403jKh7b; Sun, 25 Mar 2012 09:19:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-17909524 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sun, 25 Mar 2012 09:18:31 +0200 Message-Id: References: <0F8E254F-5CA6-47AD-A662-F72D16E45E8F@laposte.net> <1E07E9DD-F1D5-4315-8AB0-FA19CB3C6556@laposte.net> <7AB31910-D378-42F1-9464-7A18549EDF75@laposte.net> <39C5FEB6-60F9-4702-AA49-2AD79AFBB21D@laposte.net> <16124E27-9D5C-45DE-9EC1-6BC5CC41E909@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Draft 4rd-u-05 is available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:19:45 -0000 --Apple-Mail-10-17909524 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-25 =E0 03:50, Maoke a =E9crit : >=20 >=20 > 2012/3/20 R=E9mi Despr=E9s >=20 > Le 2012-03-19 =E0 16:12, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/20 R=E9mi Despr=E9s >>=20 >> Le 2012-03-19 =E0 15:30, Maoke a =E9crit : >>=20 >>>=20 >>>=20 >>> 2012/3/19 R=E9mi Despr=E9s >>>=20 >>> Le 2012-03-19 =E0 11:38, Maoke a =E9crit : >>> ... >>>=20 >>>>>>=20 >>>>>> let me draw an example for that: >>>>>>=20 >>>>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 = Internet; router R2 here)--- B >>> ... >>>=20 >>>> 4rd-u isn't concerned with what happens between A and CE. >>>> There, internal hosts have RFC1918 addresses and external hosts = public IPv4 addresses. >>>>=20 >>>> no problem here for 4rd-u, but RFC6145/6146 work also in the case = the translator is not located next to the end hosts. then i understand = 4rd-u is less flexible.=20 >>>=20 >>> I don't see the configuration you have in mind. >>> =20 >>> =20 >>> people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning. >>=20 >>=20 >> I still don't see the problem with a NAT44 in the CE. >> =20 >> =20 >> the topic is about 0.0.0.0 as the source address for the = ICMPv6-translated ICMPv4 message's IP header. if there is a router = between the CE and the host, the packet with 0.0.0.0 will be discarded = rather than being forwarded, according to the common definition of the = "unspecified address". >=20 > As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, = of course, nor in IPv4 where the only in-site IPv4 addresses are = RFC1918. > Anything missed? >=20 > =20 > well, not understood at all. Remi, may you please make a numerical = example to explain in detail how the "unspecified IPv4 address" is used = in 4rd-u/NAT64+? thanks in advance! OK, there is a point for ICMPv4 whose source is not a public IPv4 = address.=20 I agree that using 0../0 in this case creates a problem because some = routers or FWs may discard packets having this address as source. This should be avoided by coming back to what there was in draft-03, = i.e. 192.70.192.254=20 Thanks. =20 Regards, RD > =20 > - maoke > =20 > RD >=20 >=20 >=20 --Apple-Mail-10-17909524 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/20 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-19 =E0 = 16:12, Maoke a =E9crit :



2012/3/20 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-19 =E0 = 15:30, Maoke a =E9crit :



2012/3/19 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-19 =E0 = 11:38, Maoke a =E9crit :
...


let me = draw an example for that:

A --- CE ----(IPv6 = domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- = B
=
...
4rd-u isn't concerned = with what happens between A and CE.
There, internal hosts have = RFC1918 addresses and external hosts public IPv4 addresses.

no problem here for = 4rd-u, but RFC6145/6146 work also in the case the translator is not = located next to the end hosts. then i understand 4rd-u is less = flexible. 

I don't see the configuration you = have in = mind.
 
 
people often insert a router between the home CE and their computers = ;-) sometimes, e.g., because the CE has limited number of ports for = connection or less funtioning.


I still don't see = the problem with a NAT44 in the = CE.
 
 
the = topic is about 0.0.0.0 as the source address for the ICMPv6-translated = ICMPv4 message's IP header. if there is a router between the CE and the = host, the packet with 0.0.0.0 will be discarded rather than being = forwarded, according to the common definition of the "unspecified = address".

As I already said, 0.0.0.0 = never appears on any wire: neither in IPv6, of course, nor in IPv4 where = the only in-site IPv4 addresses are RFC1918.
Anything = missed?

 
well, not = understood at all. Remi, may you please make a numerical example to = explain in detail how the "unspecified IPv4 address" is used in = 4rd-u/NAT64+? thanks in = advance!

OK, there is a = point for ICMPv4 whose source is not a public IPv4 = address. 
I agree that using 0../0 in this case creates a = problem because some routers or FWs may discard packets having this = address as source.
This should be avoided by coming back to = what there was in draft-03, i.e. = 192.70.192.254 
Thanks.
 
Regards,=
RD


 
- maoke
 
RD




= --Apple-Mail-10-17909524-- From despres.remi@laposte.net Sun Mar 25 00:44:30 2012 Return-Path: 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 D1EC921F8598 for ; Sun, 25 Mar 2012 00:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 CNmzQA6gKTRr for ; Sun, 25 Mar 2012 00:44:30 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9968F21F8593 for ; Sun, 25 Mar 2012 00:44:29 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id pjkR1i00737Y3f403jkReY; Sun, 25 Mar 2012 09:44:27 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <923D5842-2C9E-4CF6-86FC-5DB8773ADA53@employees.org> Date: Sun, 25 Mar 2012 09:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> <3F8D43A5-9D98-4BD3-9503-AF548D53403C@laposte.net> <923D5842-2C9E-4CF6-86FC-5DB8773ADA53@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:44:30 -0000 Le 2012-03-25 =E0 07:31, Ole Tr=F8an a =E9crit : > Remi, >=20 >>> the authors did already do that. the dIVI and 4rd authors met 16th = of November at the last IETF. >>> we collectively went through the complete feature list. the result = is what you find in the MAP document series. >>=20 >> This MAP meeting was immediately after the Taipei Softwire meeting. = At this meeting, with an invalid technical argument, you had convinced = most participants that -U couldn't work, so that a majority didn't = believe the -U approach could be useful.=20 >=20 > that's not quite how I remember it. there were a number of issues = discussed with 4rd-U. > - destination spread, caused by Max PSID, CNP (I was wrong about CNP = causing destination spread). > - V-octet; implications > - how -U achieves transparency by overloading information in the = fragmentation header No contradiction. - Destination spread was claimed to be caused by CNP.=20 - Max PSID was unanimously abandoned during you meeting. - Your (invalid) objection to CNP was maintained, with no time to argue = about it, so that you got a majority vote for not considering CNP = anymore in the MAP team.=20 >> During this MAP meeting, a majority consequently expressed no = interest in considering further, for MAP, new features that were part of = the -U proposal (Reversible header mapping; Checksum neutrality, AKA = CNP; Distinguishable address format, AKA V octet). >=20 > the MAP effort has focused on the mandatory functionality and features = only. >=20 > all the "features" between 4rd-U and MAP are interchangeable. in this = instance I do believe "less is more" though. > the distinguishing part of 4rd-U is that is uses a different form of = translation than what MAP does. Whatever you call it, its virtue is that: - it never modifies payloads - it completely restores IPv4 headers (except for IPv4 options, but = these are not needed for IPv4 applications). Double RFC6145 translation, as you brilliantly explained yourself in = Beijing, sometimes breaks e2e transparency.=20 Cheers, RD =20 >=20 > cheers, > Ole >=20 From fibrib@gmail.com Sun Mar 25 05:28:41 2012 Return-Path: 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 9076B21F84A2 for ; Sun, 25 Mar 2012 05:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 7+Gjyr0TjUjt for ; Sun, 25 Mar 2012 05:28:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C021F849C for ; Sun, 25 Mar 2012 05:28:39 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3248583qcs.31 for ; Sun, 25 Mar 2012 05:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9NIjez6nIu8aW1WaEzPHGQocfxxwo8gBQ2NGN7d6xbg=; b=pvtH1j0b6RGle5y/K93bxQ4lzomvPybUcB3nL1EUmisP5CigWxPbBlExLG65Q0ol/c mfyuAxsIAd4j3ezRWH91bd7I98BZqCqpWI3cRdXrowDCZtA10gFAsGRTl/JZAHD0WwpY EgAITUeGLBEgVYXvckvOMNjSaet/sbZV1vb+CixixiGA40FVn+UV6jibUPPKowNik3CU sFNuGHIvlj6zvrs6ApiXnLbt2py7F0rkGSsr3djZLydkiv7jiOQ/3fZ1N8ZZF50CqU2b kdQ/G+ZuDfIeTWnCwTwW8EOD7fQyYaXXBmwRwgzOUUC+ZHQqMSIGvVrMhTzEfzXeB2k3 I56A== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr23591087qab.11.1332678518968; Sun, 25 Mar 2012 05:28:38 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sun, 25 Mar 2012 05:28:38 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Mar 2012 21:28:38 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b4b8b911cf04bc1065c2 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 12:28:41 -0000 --20cf3074b4b8b911cf04bc1065c2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/25 R=E9mi Despr=E9s despres.remi@laposte.net > > > some issues remaining not yet reaching collective undertanding is not a > reason of making things over. the collective understanding has been reach= ed > for the major part of the > 1) MAP address format and the corresponding algorithms > 2) encapsulation and translation modes being supported by MAP format and > the existing header processing standards > 3) DHCP extensions as a way of distributing rules. > > the above big picture are what i call "collective understanding". the > correct way is: making these already gained approaches as bases, continui= ng > discussion or even dabate on the details. i don't think it is a correct w= ay > of action to disrespect a team's work. 4rd-u's problem is even its big > picture is still fuzzy. > > > Not more fuzzy than MAP (actually less fuzzy IMHO). > Debate on details is possible for U as wall as for T+E. > > you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the "4rd-u tunnel" is. you said it is just a reversible header mapping that is not tunnel nor translation path section. then what does the "reversible header mapping" provides to the architecture of transition? you never clearly state this. > > > a) T operation in hub&spoke (hasn't been so far answered in an >> understandable way). >> > > i doubt i understand what you mean. may you please specify the question i= n > details? > > > Is a DHCPv6 parameter needed, yes or no? > > i am not sure i know about the details of what you mean. do you mean the feature of R-2.C? if so, i happen to have following questions: 1) why hub&spoke topology should be announced to the CE? (IMHO, if a CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hub&spoke. i think this has been clarified in MAP Section 5.) 2) to this parameter issue, what is the difference between T and E? look forward to your further clarification/discussions! if you mean not the hub&spoke mode indicator, please specify your question further. > > b) IDs from shared-address CEs. T currently has so far no solution >> while both U and E include one. >> >> > > what do you mean with the IDs? or do you mean interface IDs? i don't see > "IDs from shared-address CEs" in U too. please teach! > > > Sec 4.5.3. is "Packet Identifications from Shared-Address CEs". > Did you read the complete draft? > > execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot! > > > > c) MAP-A+P says "Each MAP node in the domain has the same set of rules" >> while MAP-T says "if a CE knows only a subset of the mapping rules ..." >> >> > > first of all, they are not conflicting logically. > > ??? > > second, if you mean one doc is superior than multiple with better > consistency in writing, i could agree. > > > This is not the point. > Separate documents can be consistent, but they aren't on this point. > > One of the two assertions must be changed. > Remaining question: which one? > > well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hub&spokes mode for an unknown destination CE. the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified). > but it doesn't mean one doc is definitely reflecting "collective > understanding" better than multiple. > > >> >> d) Whether T can work with a single mapping rule (as was, I think, the >> case for IVI). So far DMR and BMR seem exclusive, and there is no way to >> distinguish them in MAP-dhcp. >> >> > > single mapping rule for a domain !=3D single mapping rule for the IPv4 > world. > > ??? > > the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't > need DHCP to distribute the mapping rule. in the MAP, i don't think DMR a= nd > BMR being exclusive is a problem. > > > How many MAP mapping rules do you see for the equivalent of the IVI use > case in a MAP domain? > None? > > if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question. > > If one, is it a DMR or a BMR? > If two, what are they? > > ... > > Note: This excludes ISPs that would like to offer full IPv4 transparency >> with some IPv6-only middles boxes. >> Right? >> >> > > i cannot follow your "full IPv4 transparency" with "some" IPv6-only middl= e > boxes. what does the "transparency" mean for the middle boxes? i > understand, when we talk about the Internet transparency, we refer to the > "end-to-end transparency". please specify your question concretely. > > > OK, could have been clearer. > Yet, I think you understand that with U, one has SIMULTANEOUSLY, > transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes t= hat > look at TCP ports. > > ok. then may i conclude, for the major part of U, that 1) U, as a stated enhancement for double translation, gain the transparency for DF=3DMF=3D1 (= the 10^-6 minor cases, commonly thought abnormal); 2) with introducing #1. uncommon definition of the fragment header of IPv6; #2 uncommon packet of IPv6 carrying ICMPv4 messages? > > > The most important is, both the building blocks of transition >> architecture: virtual link (supported by encapsulation/tunneling) and >> participant of the delivery path (supported by translation), have their >> suitable use cases. And their advantages and limitations have been well >> investigated and understood by the community. >> >> second, i deeply discussed and explored 4rd-u, but i found its attemptin= g >> of mixing the tunneling and translation, if accepted as standard, may tr= ap >> the operators into a harsh situation of being unable to define what >> building block it really is. >> >> >> Such an operator would know it uses 4rd-U. >> >> > > well, this is what i mean the uncertainty of 4rd-U in the architecture to > the common understanding. as a analogy, one of Mr. E and Mr. T said, "i > give you a horse", while the other said "i give you a donkey". then peopl= e > well understand when they need a horse when they need a donkey. now Mr. U > said "wow, i give you a fantastic donkorse!". there would be 2 possible > results, not certain right now: > A. donkorse is just another sort of donkey, somehow good but somehow > flawed. > B. donkorse is just donkorse, and people, taking a long time to understan= d > it, and finally find it either a flawed or a quite good hybrid, like mule= , > useful in some cases. > > no matter if the future result is A or B, now Mr. O understand what he > needs for his business is either a horse and a donkey, with their > well-known characteristics. Mr. MAP provides a wheeled car as the common > instrument, while Mr. O needs a standard suite for the wheeled-car, the > horse-driving and donkey-driving methods and the way of feeding the horse > and donkey. this is the task of our wg, right now. > > Mr. U said you must have another type of wheel and drive it with my > donkorse --- and when Mr. O asked him, what your donkorse is, he answered= : > you will know it is donkorse, having both the advantages of the horse and > the advantages of the donkey. however, Mr. O doubts donkorse hasn't also > the disadvantages of horse and the disadvantages of donkey and some flaws > not yet documented. why not? > > >> >> This doesn't seem to justify any FUD from co-authors from broadband and >> mobile operators (or from product vendors). >> >> It is stated as tunneling but actually behaves like tunnel in some >> aspects while like translation in some other aspects. >> >> >> Yes indeed, thus achieving the best of both worlds without making it mor= e >> complex. Actually making it clearly less complex than supporting both T = and >> E. >> >> > > i don't think those who made out mule expected the mule could replace > horse and donkey and achieving a better world without horse and donkey bu= t > only mule. surely mule-only world is simpler. > > > Comparison is not reason (French proverb). > > i mean "such an operator would know it uses 4rd-U" can approve nothing. i just try to understand what the 4rd-u reversible header mapping really is, in the term of architecture. this analogy is written as problem understanding rather than a reason of anything. > > > (I have pointed out in the 4rd-u discussion thread). >> >> We see it only a yet-another-translation that try to solve some corner >> problems but introduces new, possibly major flaws (also pointed out in t= he >> technical threads on 4rd.) >> >> >> "Possibly major flaws" isn't an identified point on which U would do les= s >> than what it has been designed to do (unified replacement of T + E). >> >> > > i believe they are major flaws but i was gently argued with the "possibly= " > because i respected that maybe others didn't think so critically like me. > > > I have still to understand where you see "major flaws". > Just asserting they exist, without explanation although others who read > the specification don't see them isn't enough. > > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are major flaws (as we discussed so much, i was not convinced at all). i don't think others who read the specification don't see them and other issues. > > Saying that E+T is better because its current inconsistencies are > "details" isn't enough either (IMHO). > > different problems. E + T is actually not only the MAP-E and MAP-T, but the utilization of existing, already mature E and T with the new MAP format. > IMPORTANT: >> - The essential characterization of U (vs T and E) is its Reversible >> header mapping (as replacement of both Double RFC6145 translation and >> Encapsulation). >> >> > > yet-another-translation, with some issues still in debates. > > > You can call it as you wish, but the point remains that, with U, one > doesn't need both E and T. > > no. U has changed the layered model of Internet protocol stack. an operator definitely needs the encapsulation as a fully featured virtual link (underlay infrastructure) in real O&A for IPv4 communications over IPv6 infrastructure. U cannot replace E at all. on the other hand, an operator needs the translation to encourage transition and mutual communications between IPv4 and IPv6 and double translation is included in such an environment. T has specifications for this working but U needs still discussion and running code approval. it cannot replace T at least this moment. > - Other features of U that differ from MAP (V-octet, CNP), or are >> complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this >> respect. Each of these features could be abandoned in U, or, if the WG >> appreciates what they offer, added to MAP. >> >> > > MAP team has concluded V-octet and CNP are not necessary. do we need to > debate again? i doubt people have unlimited time. > > > I made the point many times that the right to analyze problems didn't sto= p > after a majority decision obtained during an improvised meeting. > Many MAP contributors were absents, and no time was given to correct > invalid objections that had been made just before during a WG meeting. > > MAP can work even without the V-octet and CNP, at least in significant cases. if we have the standard of MAP, we can immediately deploy it into practice through applying MAP rules into the already well understood, well approved, well standardized encapsulation and translation modules, without waiting for the approval of the new features in the address format, and the approval of the reversible header mapping tightly coupled with the address format. - maoke > > > Note that several co-authors of the U proposal have been MAP contributors= . > > > > - For this, community acceptance to listen to explanations, would be the >> normal process. I will be available this week for this. >> >> > > i think we are all open to listen to and to discuss on any explorations > but it doesn't mean we should stop standardization of our > wheeled-car/horse-driving/donkey-driving/feeding suite with an expectatio= n > of a "better world" with only donkorse and the donkorse-specific wheeled > car. > > > Your stand is clear, but comparison isn't reason. > > RD > > --20cf3074b4b8b911cf04bc1065c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/3/25 R=E9mi Despr=E9s despres.remi@lap= oste.net
=A0
some issues remaining not yet re= aching collective undertanding is not a reason of making things over. the c= ollective understanding has been reached for the major part of the
1) MAP address format and the corresponding algorithms
2) en= capsulation and translation modes being=A0supported by MAP format and the e= xisting header processing=A0standards=A0
3) DHCP extensions as a = way of distributing rules.
=A0
the above big picture=A0are what i call "collective= understanding". the correct way is:=A0making=A0these already gained a= pproaches as bases, continuing discussion=A0or even dabate on the details. = i don't think it is a correct way of action to disrespect a team's = work. 4rd-u's=A0problem is even its big picture is still fuzzy.

Not more fuzzy than MAP (actua= lly less fuzzy IMHO).
Debate on details is possible for U as wall= as for T+E.
=A0
=A0
you may argue that MAP is much more fuzzy. but as i said, nobody knows exac= tly what the "4rd-u tunnel" is. you said it is just a reversible = header mapping that is not tunnel nor translation path section. then what d= oes the "reversible header mapping" provides to the architecture = of transition? you never clearly state this.
=A0
=A0

a) T operation in hub&spoke (hasn't been so far answered in an= understandable way).
=A0
i do= ubt i understand what you mean. may you please specify the question in deta= ils?

Is a DHCPv6 parameter needed, yes o= r no?
=A0
=A0
i am not sur= e i know about the details of what you mean. do you mean the feature of R-2= .C? if so, i happen to have following questions:
1) why hub&spoke topology should be announced to the CE? (IMHO, if= a=A0 CE is informed with the FMR involving other CEs, it works as mesh; if= only BMR and DMR is informed, surely it is hub&spoke. i think this has= been clarified in MAP Section 5.)
2) to this parameter issue, what is the difference between T and E?
look forward to your further clarification/discussions! if you mea= n not the hub&spoke mode indicator, please specify your question furthe= r.
=A0
=A0

b) IDs from shared-address CEs.=A0=A0T currently has=A0so far no solut= ion while both U and E include one.=A0
=A0
=A0
what do you mean with the IDs? or=A0do you mean = interface IDs?=A0i don't see "IDs=A0from shared-address=A0CEs"= ; in U too. please teach!

Sec 4.5.3. is "Packet Ide= ntifications from Shared-Address CEs".
Did you read the comp= lete draft?
=A0
=A0
execuse me. it is my fault. i read it but i didn't realize you mean the= datagram identification here. it is a good point, and not only this but al= so the issue of how BR deals with fragments of the same datagram where only= the first fragment has the port number. for this point, i think MAP-T also= needs to consider this problem described in the MAP-E Section 7, last 2 pa= ragraphs. thanks a lot!
=A0

=A0
c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mappi= ng rules ..." =A0
=A0
=A0=
first of all, they are not conflicting logically.
???
second, if you mean one doc is superior than multiple with= better consistency in writing, i could agree.

This is not the point.
Se= parate documents can be consistent, but they aren't on this point.
=A0
One of the two assertions must be changed.=A0
Remaining question: which one?
=A0
=A0
well. this is why i said they are not conflict in l= ogic. as a definition of the MAP rule, right, each MAP node in the domain S= HOULD have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information losses= (which is often happens in the Internet environment), MAP-T defines the CE= working as it were in hub&spokes mode for an unknown destination CE. t= he text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough t= o me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly = agree with you that one could be further clarified).
=A0
=A0
but it = doesn't mean one doc is definitely reflecting "collective understa= nding" better than multiple.
=A0
=A0
d) Whether T can work with a single mapping rule (as was, I think, the= case for IVI). So far DMR and BMR seem exclusive, and there is no way to d= istinguish them in MAP-dhcp.
=A0
=A0
single mapping rule for a domain !=3D single mapping rul= e for the IPv4 world.
???
the IVI (RFC6052= /6145/6219) practice does the latter. the latter doesn't need DHCP to d= istribute the mapping rule. in the MAP, i don't think DMR and BMR being= exclusive is a problem.

How many MAP mapping rules do you s= ee for the equivalent of the IVI use case in a MAP domain?=A0
Non= e?=A0
=A0
=A0
if you mean = the single mapping rule in IVI case, the answer is NONE, surely. IVI uses R= FC6052 address format rather than the MAP, without the business of MAP.
=A0
if you mean using the MAP for the single translation as = we did in IVI (though actually we have IVI working for both single and doub= le translations simultaneously), MAP-T Sec 8.3 has answered your question. =
=A0
=A0=
If one, is it a DMR or a BMR?
If two, what are they?

...
Note: This excludes=A0ISPs that wo= uld like to offer full IPv4 transparency with some IPv6-only middles boxes.=
Right?
=A0
=A0
= i cannot follow your "full IPv4 transparency" with "some&quo= t; IPv6-only middle boxes. what does the "transparency" mean for = the middle boxes? i understand, when we talk about the Internet transparenc= y, we refer to the "end-to-end transparency". please specify your= question concretely.

OK, could have been clearer.
Yet, I think you understand that with U, one=A0has=A0SIMULTANEOUSL= Y, transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports.
=A0
=A0=A0
ok.= then may i conclude, for the major part of U, that 1) U, as a stated enhan= cement for double translation, gain the transparency for DF=3DMF=3D1 (the 1= 0^-6 minor cases, commonly thought abnormal); 2) with introducing #1.=A0unc= ommon=A0definition of the fragment header of IPv6; #2=A0uncommon packet of = IPv6 carrying ICMPv4 messages? =A0
=A0
=A0
The most important is, both the building blocks of transition architec= ture: virtual link (supported by encapsulation/tunneling) and participant o= f the delivery path (supported by translation), have their suitable use cas= es. And their advantages and limitations have been well investigated and un= derstood by the community.=A0

second, i deeply discussed and explored 4rd-u, but i fo= und its attempting of mixing the tunneling and translation, if accepted as = standard, may trap the operators into a harsh situation of being unable to = define what building block it really is.

Such an operator would know it uses = 4rd-U.=A0
=A0
=A0
we= ll, this is=A0what i=A0mean the uncertainty of 4rd-U in the architecture to= the common understanding. as a analogy, one of Mr.=A0E and Mr. T said, &qu= ot;i give you a horse", while=A0the other=A0said "i give you a do= nkey". then people well understand when they need a horse when they ne= ed a donkey. now Mr. U said "wow, i give you a fantastic donkorse!&quo= t;. there would be=A02 possible results, not certain right now:
A. donkorse is just another sort of donkey, somehow good but somehow f= lawed.
B. donkorse is just donkorse, and people, taking a long t= ime to understand it, and finally find it either a flawed or a quite good h= ybrid, like mule, useful in some cases.
=A0
no matter if the future result is A or B, now Mr. O unde= rstand what he needs for his business is either a horse and a donkey, with = their well-known characteristics. Mr. MAP provides a wheeled car as=A0the c= ommon instrument, while Mr. O needs a standard suite for the wheeled-car, t= he horse-driving and donkey-driving methods and the way of feeding the hors= e and donkey.=A0this is the=A0task of our wg, right now. =A0
=A0
Mr. U said you must have another type of wheel and drive= it with my donkorse --- and when Mr. O asked him, what your donkorse is, h= e answered: you will know it is donkorse, having both the advantages of the= horse and the advantages of the donkey. however, Mr. O doubts donkorse has= n't also the disadvantages of horse and the disadvantages of donkey and= some flaws not yet documented. why not?
=A0
=A0
This doesn't seem to justify any FUD=A0from co-authors from broadb= and and mobile operators (or from product vendors).

It is stated as tunneling but actually behaves like t= unnel in some aspects while like translation in some other aspects.

Yes indeed, thus achieving the best = of both worlds without making it more complex. Actually making it clearly l= ess complex than supporting both T and E.
=A0
=A0
i don't think those who made out mule e= xpected the mule could replace horse and donkey and achieving a better worl= d without horse and donkey but only mule. surely mule-only world is simpler= .

Comparison is not reason (Fren= ch proverb).
=A0
=A0
i mean "such an operator would know it uses 4rd-U" can approve n= othing. i just try to understand what the 4rd-u reversible header mapping r= eally is, in the term of architecture. this analogy is written as problem u= nderstanding rather than a reason of anything.=A0
=A0
=A0
(I have pointed out in the 4rd-u discussion= thread).
We see it only a yet-another-translation that try to solve some corn= er problems but introduces new, possibly major flaws (also pointed out in t= he technical threads on 4rd.)

"Possibly major flaws" isn= 't an identified point on which U would do less than what it has been d= esigned to do (unified replacement of T + E).
=A0
=A0
i believe they are major flaws but i was ge= ntly argued with the "possibly" because i respected that maybe ot= hers didn't think so critically like me.

I have still to understand where you see "major f= laws".
Just asserting they exist, without explanation althou= gh others who read the specification don't see them isn't enough.
=A0
=A0
well, i mostly ar= gue that the ICMPv4 being carried by IPv6 and CNP are major flaws (as we di= scussed so much, i was not convinced at all). i don't think others who = read the specification don't see them and other issues.
=A0
=A0
Saying that E+T is better because its current inconsistencies are &quo= t;details" isn't enough either (IMHO).
=A0
=A0
different problems. E + T is actually n= ot only the MAP-E and MAP-T, but the utilization of existing, already matur= e E and T with the new MAP format.=A0
IMPORTANT: =A0
- The essential characterization of U (v= s T and E) is its Reversible header mapping (as replacement of both Double = RFC6145 translation and Encapsulation).
=A0
=A0
yet-another-trans= lation, with some issues still in debates.
You can call it as you wish, but the point remains that,= with U, one doesn't need both E and T.
=A0
=A0
no. U has changed= the layered model of Internet protocol stack. an operator definitely needs= the encapsulation as a fully featured virtual link (underlay infrastructur= e) in real O&A for IPv4 communications over IPv6 infrastructure. U cann= ot replace E at all. on the other hand, an operator needs the translation t= o encourage transition and mutual communications between IPv4 and IPv6 and = double translation is included in such an environment. T has specifications= for this working but U needs still discussion and running code approval. i= t cannot replace T at least this moment.
=A0
- Other features of U that di= ffer from MAP=A0(V-octet, CNP), or are complementary to it (Rule=A0IPv6 suf= fix, NAT64+), are secondary in this respect. Each of these features=A0could= be abandoned in U, or, if the WG appreciates what they offer, added to MAP= .
=A0
=A0
MAP team has conc= luded V-octet and CNP are not necessary. do we need to debate again? i doub= t people have unlimited time.

I made the point many times that the right to analyze problems didn= 9;t stop after a majority decision obtained during an improvised meeting.
Many MAP contributors were absents, and no time was given to corre= ct invalid objections that had been made just before during a WG meeting.
=A0
=A0
MAP can work even= without the V-octet and CNP, at least in significant cases. if we have the= standard of MAP, we can immediately deploy it into practice through applyi= ng MAP rules into the already well understood, well approved, well standard= ized encapsulation and translation modules,=A0 without waiting for the appr= oval of the new features in the address format, and the approval of the rev= ersible header mapping tightly coupled with the address format.
=A0
- maoke
=A0
=A0

Note that several co-authors of the U proposal have bee= n MAP contributors. =A0


- For this, community accepta= nce to listen to explanations, would be the normal process. I=A0will be ava= ilable this week for this.
=A0
=A0
i think we are all open to listen to and to discuss on a= ny explorations but it doesn't mean we should stop standardization of o= ur wheeled-car/horse-driving/donkey-driving/feeding suite with an expectati= on of a "better world" with only donkorse and the donkorse-specif= ic wheeled car.

Your stand is clear, but compa= rison isn't reason.

RD=
=A0

--20cf3074b4b8b911cf04bc1065c2-- From achatz@forthnetgroup.gr Sun Mar 25 06:31:51 2012 Return-Path: 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 5AE1A21F8497 for ; Sun, 25 Mar 2012 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 c30talT0rJjS for ; Sun, 25 Mar 2012 06:31:50 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id F10E321F8495 for ; Sun, 25 Mar 2012 06:31:49 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2PDVmWp009071; Sun, 25 Mar 2012 16:31:48 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2PDVmJ1001434; Sun, 25 Mar 2012 16:31:48 +0300 Received: from [130.129.21.212] (dhcp-15d4.meeting.ietf.org [130.129.21.212]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2PDVjrb004393; Sun, 25 Mar 2012 16:31:47 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F6F1E40.2030203@forthnetgroup.gr> Date: Sun, 25 Mar 2012 15:31:44 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Alistair Woodman References: <356701cd09dc$7872b190$695814b0$@org> In-Reply-To: <356701cd09dc$7872b190$695814b0$@org> Content-Type: multipart/alternative; boundary="------------080403050600060107000100" Cc: softwires@ietf.org, fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:31:51 -0000 This is a multi-part message in MIME format. --------------080403050600060107000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is this the same room as IAOC/IAD? -- Tassos On 24/3/2012 5:37 ??, Alistair Woodman wrote: > > All, you are cordially invited... > > Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo > of draft-penno-softwire-sdnat-02. > > The following will be shown: > > 1) Stateless DS-Lite > > 2) Stateless CPE B4 NAT > > 3) Anycast Failover > > 4) DHCPv4 proxy over v6 > > 5) NAT Port range re-allocation via ICMP method. > > When: Sunday the 25^th from 15h30 to 17h00. > > Where: Room #201 (Front left of Hall Maillot when > facing Porte Maillot), IETF 83, Paris > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --------------080403050600060107000100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Is this the same room as IAOC/IAD?

--
Tassos

On 24/3/2012 5:37 μμ, Alistair Woodman wrote:

All, you are cordially invited…

 

Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of draft-penno-softwire-sdnat-02.

 

The following will be shown:

 

1) Stateless DS-Lite

2) Stateless CPE B4 NAT

3) Anycast Failover

4) DHCPv4 proxy over v6

5) NAT Port range re-allocation via ICMP method.

 

When:                  Sunday the 25th from 15h30 to 17h00.

Where:                 Room #201 (Front left of Hall Maillot when facing Porte Maillot), IETF 83, Paris


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--------------080403050600060107000100-- From despres.remi@laposte.net Sun Mar 25 07:03:10 2012 Return-Path: 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 5AC4C21F8471 for ; Sun, 25 Mar 2012 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 Zt9kTMfHtQex for ; Sun, 25 Mar 2012 07:03:08 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7922C21F846F for ; Sun, 25 Mar 2012 07:03:06 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id pq311i00337Y3f403q31oM; Sun, 25 Mar 2012 16:03:05 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-42162086 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sun, 25 Mar 2012 16:02:43 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 14:03:10 -0000 --Apple-Mail-1-42162086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maoke, (Retransmission after deleting unnecessary old text. Message was too big = for the mailing list) 2012-03-25 14:08, Maoke : > 2012/3/25 R=C3=A9mi Despr=C3=A9s ... > you may argue that MAP is much more fuzzy. but as i said, nobody knows = exactly what the "4rd-u tunnel" is. > you said it is just a reversible header mapping that is not tunnel I rather say that reversible header mapping implements a "tunnel" = variant. =20 > nor translation path section. > then what does the "reversible header mapping" provides to the = architecture of transition? you never clearly state this.=20 The draft is AFAIK not ambiguous. I tried to answer all your questions on this point I barely understand = (neither an implementation nor an operation issue) End of this point for me, if there is nothing significantly new. >> a) T operation in hub&spoke (hasn't been so far answered in an = understandable way). >> =20 >> i doubt i understand what you mean. may you please specify the = question in details? >=20 > Is a DHCPv6 parameter needed, yes or no? > =20 > =20 > i am not sure i know about the details of what you mean. Today, there is no DHCPv6 parameter to require H&S, right? My question is then: "is it sufficient to have none, or is it needed to = add a new parameter". Looking at more details would be premature for me until you have = answered this question. > do you mean the feature of R-2.C? if so, i happen to have following = questions: > 1) why hub&spoke topology should be announced to the CE? (IMHO, if a = CE is informed with the FMR involving other CEs, it works as mesh; if = only BMR and DMR is informed, surely it is hub&spoke. i think this has = been clarified in MAP Section 5.) > 2) to this parameter issue, what is the difference between T and E? None AFAIK. > look forward to your further clarification/discussions! if you mean = not the hub&spoke mode indicator, please specify your question further. > =20 > =20 >> b) IDs from shared-address CEs. T currently has so far no solution = while both U and E include one.=20 >> =20 >> =20 >> what do you mean with the IDs? or do you mean interface IDs? i don't = see "IDs from shared-address CEs" in U too. please teach! >=20 > Sec 4.5.3. is "Packet Identifications from Shared-Address CEs". > Did you read the complete draft? > =20 > =20 > execuse me. it is my fault. i read it but i didn't realize you mean = the datagram identification here. it is a good point, and not only this = but also the issue of how BR deals with fragments of the same datagram = where only the first fragment has the port number. for this point, i = think MAP-T also needs to consider this problem described in the MAP-E = Section 7, last 2 paragraphs. thanks a lot! (*) End of this subject. >> c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =20 >> =20 >> =20 >> first of all, they are not conflicting logically. >=20 > ??? >=20 >> second, if you mean one doc is superior than multiple with better = consistency in writing, i could agree. >=20 > This is not the point. > Separate documents can be consistent, but they aren't on this point. >=20 > One of the two assertions must be changed.=20 > Remaining question: which one? > =20 > =20 > well. this is why i said they are not conflict in logic. as a = definition of the MAP rule, right, each MAP node in the domain SHOULD = have the same set of rules. however, in practice of operation, it is = possible that this MAY not strictly achieved due to some information = losses (which is often happens in the Internet environment), MAP-T = defines the CE working as it were in hub&spokes mode for an unknown = destination CE. I am not aware that a CE might receive some of the MAP DHCPv6 parameters = but not all due to lost packets. Clarification on this will be welcome. > the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear = enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i = may partly agree with you that one could be further clarified). ...=20 >=20 >> How many MAP mapping rules do you see for the equivalent of the IVI = use case in a MAP domain?=20 > if you mean the single mapping rule in IVI case, the answer is NONE, = surely. IVI uses RFC6052 address format rather than the MAP, without the = business of MAP. OK (In this respect at least, IVI significantly differs from a running = version of MAP-T). > if you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. Saying that there is no mapping rule in IVI is sufficient an answer. ... > ... with U, one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports. > =20 > =20 > ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); 1) A statistic at a given time, and in a given place, isn't a proof that = the same ratio will be found later and somewhere else. 2) Those that happen to be in the sacrificed minority, be it small, may = not like their situation. Solving the problem, be it only for them, is = progress. > 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? AFAIK, not weird to those who are open to accept that it is very simple. >> i don't think those who made out mule expected the mule could replace = horse and donkey and achieving a better world without horse and donkey = but only mule. surely mule-only world is simpler. >=20 > Comparison is not reason (French proverb). > =20 > =20 > i just try to understand what the 4rd-u reversible header mapping = really is, in the term of architecture. this analogy is written as = problem understanding rather than a reason of anything. ... > I have still to understand where you see "major flaws". > Just asserting they exist, without explanation although others who = read the specification don't see them isn't enough. > =20 > =20 > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are = major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. If a host is IPv6 only, it isn't a 4rd-U host.=20 For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20 A new solution for this isn't needed.=20 ... > ... U has changed the layered model of Internet protocol stack. > an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. Different understanding. A detailed E use case that cannot be supported by U (if it exists) would = give substance to this claim. Open to look at it. =20 > on the other hand, an operator needs the translation to encourage = transition and mutual communications between IPv4 and IPv6 and double = translation is included in such an environment. T has specifications for = this working BIH does the job with single translation. Where U applies, both ends are IPv4, T has AFAIK no operational = superiority while U is more transparent. > but U needs still discussion T too. See, for example, (*) above. > and running code approval. it cannot replace T at least this moment. Understanding how U's header mapping works doesn't need great expertise. Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. Running code as soon couldn't be done yet, but isn't a big deal at all = (see (**) below) ... > MAP can work even without the V-octet and CNP, at least in significant = cases. Not a valid reason to stop progress, especially if easy to understand. At least Med suggested to look at V octet even in the context of MAP (if = chosen for standard track). > if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. (**) When we discussed in Taipei, you first said you might code 4rd-U so that = it could be tested for real. You didn't do it for reasons that I = perfectly respect. Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. Regards, RD =20 > =20 > - maoke > =20 > Note that several co-authors of the U proposal have been MAP = contributors. =20 > =20 > =20 >=20 >=20 >> - For this, community acceptance to listen to explanations, would be = the normal process. I will be available this week for this. >> =20 >> =20 >> i think we are all open to listen to and to discuss on any = explorations but it doesn't mean we should stop standardization of our = wheeled-car/horse-driving/donkey-driving/feeding suite with an = expectation of a "better world" with only donkorse and the = donkorse-specific wheeled car. >=20 > Your stand is clear, but comparison isn't reason. >=20 > RD >=20 >=20 >=20 >=20 >> regards, >> maoke >> =20 >> =20 >>=20 >> Cheers, >> RD >>=20 >>=20 >>> In either the term of architectural philosophy or technical details, = introducing 4rd-u into standards would be harmful.=20 >>>=20 >>> personally, i respect the exploration of the author(s), and the = discussion between me and the author encouraged me to comprehensively = review E and T, and the result is: i bacame much more confident of the = correctness of the MAP track. We should move forward.=20 >>>=20 >>> regarding the chair's questions, my answer is: MAP, MAP-E/T, = MAP-DHCP are of a whole suite needing to be put into standard track. = Question is not about T, E or U.=20 >>>=20 >>> best regards, >>> Maoke >>>=20 >>> =E5=9C=A8 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C= =EF=BC=8CAlain Durand =E5=86=99=E9=81=93=EF=BC=9A >>> Dear wg, >>>=20 >>> After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >>>=20 >>> 1) There is an observation that all the solutions on the table E, T = & U actually solve the stateless problem we started with. >>> There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation >>> proposals, U is an hybrid unifying solution. >>>=20 >>> 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those >>> documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >>>=20 >>> We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). >>> Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >>>=20 >>> Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask >>> and their sequence. >>>=20 >>> Q1: Without pre-supposing which one will be selected, do you agree = to publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >>>=20 >>> If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. >>> If the answer is YES, we move to the next question. >>>=20 >>>=20 >>> Q2: Do you believe that the WG should publish U as the one Standards = Track document? >>>=20 >>> If the answer is YES, the process stop, we put U on the Standard = Track and publish E & T as Informational. >>> If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational) >>>=20 >>>=20 >>> Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >>>=20 >>> If there is a clear outcome from this question, we would publish = that proposal on the Standard Track and the other one as Informational. >>> If there is no clear consensus on this question, we will publish = both E & T as Experimental. >>>=20 >>> In the meantime, we would like to encourage discussion on the = mailing list to foster our common understanding of the various = technologies and how they relate to each other. >>>=20 >>> Alain & Yong, wg co-chairs. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 --Apple-Mail-1-42162086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
2012/3/25 = R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span>
...
you may argue that MAP is much more fuzzy. but as i said, nobody knows = exactly what the "4rd-u tunnel" is. =

you said it is just a reversible header = mapping that is not tunnel

I = rather say that reversible header mapping implements a "tunnel" = variant.
 
nor translation path section. =

then what does the "reversible header = mapping" provides to the architecture of transition? you never clearly = state this.

The draft is AFAIK = not ambiguous.
I tried to answer all your questions on this = point I barely understand (neither an implementation nor an operation = issue)

End of this point for me, if there is = nothing significantly new.


a) T operation in hub&spoke (hasn't been so far answered in an = understandable = way).
 
i doubt i = understand what you mean. may you please specify the question in = details?

Is a DHCPv6 parameter needed, = yes or = no?
 
 
i am = not sure i know about the details of what you mean. =

Today, there is no DHCPv6 = parameter to require H&S, right?
My question is then: "is = it sufficient to have none, or is it needed to add a new = parameter".
Looking at more details would be premature for me = until you have answered this = question.


do you mean the feature of R-2.C? if so, i = happen to have following questions:
1) why hub&spoke topology should be announced to the CE? (IMHO, = if a  CE is informed with the FMR involving other CEs, it works as = mesh; if only BMR and DMR is informed, surely it is hub&spoke. i = think this has been clarified in MAP Section 5.)
2) to this parameter issue, what is the difference between T and E? =

None = AFAIK.


look forward to your further = clarification/discussions! if you mean not the hub&spoke mode = indicator, please specify your question further.
 
 
b) IDs from shared-address CEs.  T currently has so = far no solution while both U and E include = one. 
 
 
what do you mean with the IDs? or do you mean interface = IDs? i don't see "IDs from shared-address CEs" in U too. = please teach!

Sec 4.5.3. is "Packet = Identifications from Shared-Address CEs".
Did you read the = complete = draft?
 
 
execuse me. it is my fault. i read it but i didn't realize you mean the = datagram identification here. it is a good point, and not only this but = also the issue of how BR deals with fragments of the same datagram where = only the first fragment has the port number. for this point, i = think MAP-T also needs to consider this problem described in the MAP-E = Section 7, last 2 paragraphs. thanks a = lot!

(*)
End of = this subject.


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mapping = rules ..." =  
 
 
first of all, they are not conflicting = logically.

???

second, if you mean one doc is superior than = multiple with better consistency in writing, i could agree.

This is not the = point.
Separate documents can be consistent, but they aren't = on this point.

One of the two assertions must = be changed. 
Remaining question: which = one?
 
 
well. = this is why i said they are not conflict in logic. as a definition of = the MAP rule, right, each MAP node in the domain SHOULD have the same = set of rules. however, in practice of operation, it is possible that = this MAY not strictly achieved due to some information losses (which is = often happens in the Internet environment), MAP-T defines the CE working = as it were in hub&spokes mode for an unknown destination = CE.

I am not aware that a CE = might receive some of the MAP DHCPv6 parameters but not all due to lost = packets.
Clarification on this will be = welcome.


the text of Sec 8.2 of MAP-T and that of Sec = 8.2 of MAP-E are clear enough to me. no one among = MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with = you that one could be further clarified). =
... 
How many MAP mapping rules do you see for the = equivalent of the IVI use case in a MAP = domain? 

if you mean the single mapping rule in IVI = case, the answer is NONE, surely. IVI uses RFC6052 address format rather = than the MAP, without the business of MAP. =

OK
(In this = respect at least, IVI significantly differs from a running version of = MAP-T).

if you mean using the MAP for the single translation as we did in = IVI (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your = question.

Saying that there is = no mapping rule in IVI is sufficient an = answer.

...
... with U, one has SIMULTANEOUSLY, transparency to = DF=3DMF=3D1 and applicability of IPv6-only middle boxes that look at TCP = ports.
 
 
ok. then = may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a = given time, and in a given place, isn't a proof that the same ratio will = be found later and somewhere else.
2) Those that happen to be = in the sacrificed minority, be it small, may not like their situation. = Solving the problem, be it only for them, is = progress.

2) with introducing #1. weird definition of = the fragment header of IPv6; #2 weird packet of IPv6 carrying ICMPv4 = messages?

AFAIK, not weird to = those who are open to accept that it is very = simple.


i don't think those who made out mule expected the mule could = replace horse and donkey and achieving a better world without horse and = donkey but only mule. surely mule-only world is simpler.

Comparison is not reason = (French = proverb).
 
 
=
i just try to understand what the 4rd-u reversible header mapping = really is, in the term of architecture. this analogy is = written as problem understanding rather than a reason of = anything.

...

I have still to understand = where you see "major flaws".
Just asserting they exist, = without explanation although others who read the specification don't see = them isn't enough.
 
 
well, i = mostly argue that the ICMPv4 being carried by IPv6 and CNP are = major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues.

ICMPv4 payloads in = IPv6 packets appear only during domain traversal, where they don't hurt = anyone.

If a host is IPv6 only, it isn't a = 4rd-U host. 
For communication between IPv4-only = applications of DS hosts and IPv6-only hosts, there are already = workable RFCs. 
BIH in DS hosts is AFAIK particularly = powerful, and IMHO sufficient. 
A new solution for this = isn't needed. 

...
... U has changed the layered model of Internet protocol stack. =

an operator definitely needs the = encapsulation as a fully featured virtual link (underlay = infrastructure) in real O&A for IPv4 communications over IPv6 = infrastructure. U cannot replace E at all. =

Different = understanding.
A detailed E use case that cannot be supported = by U (if it exists) would give substance to this = claim.
Open to look at it.  

on the other hand, an = operator needs the translation to encourage transition and mutual = communications between IPv4 and IPv6 and double translation is included = in such an environment. T has specifications for this = working

BIH does the job with = single translation.
Where U applies, both ends are IPv4, T = has AFAIK no operational superiority while U is more = transparent.


but U needs still discussion =

T too.
See, for = example, (*) above.

and running code approval. it cannot replace = T at least this moment. =

Understanding how U's = header mapping works doesn't need great expertise.
Co-autors = readily understood it, with origins as varied as router-and-host vendor, = software vendor, broadband operator, mobile = operator.

Running code as soon couldn't be done = yet, but isn't a big deal at all (see (**) = below)

...
MAP can work even without the V-octet and = CNP, at least in significant = cases.

Not a valid reason to stop = progress, especially if easy to understand.
At least Med = suggested to look at V octet even in the context of MAP (if chosen for = standard track).

 if we have the standard of MAP, = we can immediately deploy it into practice through applying = MAP rules into the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format. =

(**)
When we = discussed in Taipei, you first said you might code 4rd-U so that it = could be tested for real. You didn't do it for reasons that I perfectly = respect.
Yet, modifying T code to support header mapping = remains quite simple (you even call it a translation variant). Starting = from E code, it's simple too.
When this is done, all = verifications can be easily done that what analysis says is right is = also right with running = code.


Regards,
RD
<= div>


 

 
- maoke
 
Note that several co-authors of the U proposal have = been MAP contributors. =  
 
 


- For this, community = acceptance to listen to explanations, would be the normal process. = I will be available this week for = this.
 
 
i think we are all open to listen to and to = discuss on any explorations but it doesn't mean we should stop = standardization of our wheeled-car/horse-driving/donkey-driving/feeding = suite with an expectation of a "better world" with only donkorse and the = donkorse-specific wheeled car.

Your stand is clear, but = comparison isn't reason.

RD




regards,
maoke
 
=
 

C= heers,
RD


In either the term of architectural philosophy or = technical details, introducing 4rd-u into standards would be = harmful. 

personally, i respect the exploration of the = author(s), and the discussion between me and the author encouraged me to = comprehensively review E and T, and the result is: i bacame much more = confident of the correctness of the MAP track. We should move = forward. 

regarding the chair's questions, my answer = is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be = put into standard track. Question is not about T, E or = U. 

best regards,
Maoke

=E5=9C=A8 = 2012=E5=B9=B43=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF=BC=8CAlai= n Durand =E5=86=99=E9=81=93=EF=BC=9A
Dear wg,

After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, = T & U actually solve the stateless  problem we started = with.
   There are differences, but it is unclear if those = differences are really significant. E and T are the original = Encapsulation and Translation
   proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those
   documents have at IETF. In particular, do we want to = publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation.

Then, we, chairs, would like to ask a series of questions to the working = group. In order to make this process transparent, here is the list of = questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards = Track document?

If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)?

If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E = & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other.

 Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires





= --Apple-Mail-1-42162086-- From Francis.Dupont@fdupont.fr Sun Mar 25 13:55:35 2012 Return-Path: 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 2DC9D21F8433 for ; Sun, 25 Mar 2012 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 bNmyZtp4AXzo for ; Sun, 25 Mar 2012 13:55:34 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5621F8455 for ; Sun, 25 Mar 2012 13:55:34 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2PKtUMU069524; Sun, 25 Mar 2012 22:55:30 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203252055.q2PKtUMU069524@givry.fdupont.fr> From: Francis Dupont To: Peng Wu In-reply-to: Your message of Sun, 25 Mar 2012 01:56:08 +0800. Date: Sun, 25 Mar 2012 22:55:30 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "softwires@ietf.org" , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:55:35 -0000 In your previous mail you wrote: > Same question I raised in the other thread. > 1) So this table is fully static, and we don't consider user entering > or leaving which may affect the bindings. Instead, the bindings only > rely on the addresses which won't change along the time. > 2) Then this falls in the manner of pre-configuration for every > possible user IPv6 address, not on-demand allocation. => IMHO these points are not about the SD-NAT class of mechanisms but more about the interface between the SD-CGN and the provisioning system. So you can implement what you want (static/dynamic, on demand or provisioning pushing a config to the SD-CGN). I think the only thing you can't (easily) do is the SD-NAT doing the provisioning itself because the SD-CPE needs to get the right configuration too and until we define a working in-band solution it will receive it out-of-band, by DHCP for instance. Note I don't say the questions are not interesting (they need to be solved for a production deployment) but they are not on the same plan than the SD-NAT mechanism itself. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Mar 25 14:45:24 2012 Return-Path: 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 0C72621E800F for ; Sun, 25 Mar 2012 14:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] 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 C-kLcDKmbFgP for ; Sun, 25 Mar 2012 14:45:23 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1EF21E800C for ; Sun, 25 Mar 2012 14:45:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2PLibT4072543; Sun, 25 Mar 2012 23:44:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203252144.q2PLibT4072543@givry.fdupont.fr> From: Francis Dupont To: Yong Cui In-reply-to: Your message of Sun, 25 Mar 2012 09:06:46 +0800. Date: Sun, 25 Mar 2012 23:44:37 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires@ietf.org, fdupont@isc.org Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 21:45:24 -0000 In your previous mail you wrote: > Thanks for the demo. > Would you please also give a summary to the mailing list, especially for > someone who cannot join the demo. => we setup a SD-AFTR and a pair of SD-B4s (one Netgear WNDR3800 and one laptop) and a client attached to one of the SD-B4s with: - connection from the client to the Internet - connection from the Internet to the client using a port returned by PCP (server running on a SD-B4) - replacement of a SD-AFTR by a spare SD-AFTR with the same config (but without dynamic state sharing): connections still alive, in fact if you don't take care of the packets lost during the manual operation it is really transparent - we had not enough time to finish the DHCP client chaining (in theory the DHCPv6 client configures the IPv4-over-IPv6 tunnel and launches a DHCPv4 client and CRA pair, which configure the IPv4 part including the port range) - nor the ICMP 3/13 handling on the SD-B4 (renew the DHCPv4 lease). - nor a third WNDR3700v2 SD-B4 (should be the same than the WNDR3800 one, and we didn't ask visitors to provide extra clients) Regards Francis.Dupont@fdupont.fr From yu.guanghui@gmail.com Sun Mar 25 16:52:26 2012 Return-Path: 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 9C1D521E802D for ; Sun, 25 Mar 2012 16:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 PY1L1UBjSdxN for ; Sun, 25 Mar 2012 16:52:25 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D321F8447 for ; Sun, 25 Mar 2012 16:52:25 -0700 (PDT) Received: by bkuw5 with SMTP id w5so4134684bku.31 for ; Sun, 25 Mar 2012 16:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/gBvrRsYGhULzwufOttAjLUQ550qiEpZKAWq96TTTA=; b=bJecZCIb/uU8YF6zTKfXu27fo4BUc0e9jksWjrRZRyqZIMIUH9FSzlXE6qLJpr1X3A fL9gYBSSLu7fPdOTQhrqJfarGoAQ2/EYbwx7Uf5PhMt98yZrrr1AVNOJN59f95MFR1T7 oBCMxztJz8keN5SSzoP7Nz+/GEgBlRYKQRBIemHEKdNc92ZCqBXb/ZLXE4sK30hSfMp8 bEDj/XdMopy9u0IYM+LUHqoW2dKVx1+xOfUuWdQEjkKfQkPGxOKqusU2WEmC2HvfI0x0 8xr2SyamJABZx6SPEZjfN3CiO83i8zHDzK1tipMyL09gYvbITE4bpUgg8dQdfGJHgT1Y IaAg== MIME-Version: 1.0 Received: by 10.204.143.151 with SMTP id v23mr7873892bku.63.1332719544634; Sun, 25 Mar 2012 16:52:24 -0700 (PDT) Received: by 10.204.184.145 with HTTP; Sun, 25 Mar 2012 16:52:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 07:52:24 +0800 Message-ID: From: Guanghui Yu To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=0015175d06060b0f1e04bc19f361 Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 23:52:26 -0000 --0015175d06060b0f1e04bc19f361 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yiu According to our experimental data, it is very small . But Please note that the experimental data also shows that the ratio of packet labeled "DF=3D1 and MF=3D1=E2=80=9D among total packet is 1.1E-5. 4rd-U insists to = claim to have a better end-to-end behavior than MAP-T, but it just serves for a corner case. On Fri, Mar 23, 2012 at 10:24 PM, Lee, Yiu wrote= : > Hi Guanghui, > > Just curious, how common IPv4 option is used these days? I don't have any > data in-hand. > > Thanks, > Yiu > > From: Guanghui Yu > Date: Fri, 23 Mar 2012 13:43:07 +0800 > > To: "Yiu L. LEE" > Cc: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 > > it cannot support IPv4 option. > --=20 Yu Guanghui Network and Information Center Dalian University of Technology, China --0015175d06060b0f1e04bc19f361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yiu
=C2=A0=C2=A0 According to our experimental data, it is very small= . But Please note that the experimental data also shows that the ratio of = packet labeled "DF=3D1 and MF=3D1=E2=80=9D among total packet is 1.1E-= 5. 4rd-U insists to claim to have a better end-to-end behavior than MAP-T, = but it just serves for a corner case.

On Fri, Mar 23, 2012 at 10:24 PM, Lee, Yiu <= span dir=3D"ltr"><Yiu_Lee@c= able.comcast.com> wrote:
Hi Guanghui,

Just curious, how common = IPv4 option is used these days? I don't have any data in-hand.

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Fri, 23 Mar 2012 13:43:= 07 +0800

To: "Yiu L. LEE" <= ;yiu_lee@cab= le.comcast.com>
Cc: Soft= wires WG <softwi= res@ietf.org>
Subject: Re: [Softwires] Path to m= ove forward with 4rd=C5=A0

= it cannot support IPv4 optio= n.=C2=A0



--
Yu Guanghui <yg= h at dlut.edu.cn>
Network and Information Center
Dalian University of Tech= nology, China


--0015175d06060b0f1e04bc19f361-- From yu.guanghui@gmail.com Sun Mar 25 16:53:17 2012 Return-Path: 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 B292221F8496 for ; Sun, 25 Mar 2012 16:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 mygkSiRpXFe3 for ; Sun, 25 Mar 2012 16:53:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1714421F8447 for ; Sun, 25 Mar 2012 16:53:15 -0700 (PDT) Received: by bkuw5 with SMTP id w5so4134913bku.31 for ; Sun, 25 Mar 2012 16:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ja1Pdw/zO0Aw1KjKxqqRwoE18V73BetwZ4ClyTk+Jdk=; b=CLH4/mgGxSk3klAXQJd/LRzOlEhEFeg8yoC0yln+UHXZCLX33BEwLeadouQsOm0d4J frSUHK5C/Yr5ZP775RnYRQhfDnDV4fMA2Ep37Jh4PI1rfSfO1SYoOnHTBW1k0HrESqG0 UweTJubilee3YQfNFjyg3vwj2427NfCA9YqDLr6rlOTLHhblnwk/9mnCjOgaJCiRwbfu zW6cMGW0VbHbeJhI8+2sC75SDxFK+rAhdVBy7cUI64e6VMsxPDEETrXJMyWcCpQDsrCu aPPcOr9RgYvXnb/3CUsRuHlwcDryYnqoGjjvIfOICeFwHHXv1ycJsmG/uswyUqZM1oaD SZtQ== MIME-Version: 1.0 Received: by 10.204.149.204 with SMTP id u12mr2468065bkv.45.1332719595198; Sun, 25 Mar 2012 16:53:15 -0700 (PDT) Received: by 10.204.184.145 with HTTP; Sun, 25 Mar 2012 16:53:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 07:53:15 +0800 Message-ID: From: Guanghui Yu To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=0015175dd9440e98a604bc19f6f0 Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 23:53:17 -0000 --0015175dd9440e98a604bc19f6f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yiu Please read MAP-Thttp://tools.ietf.org/html/draft-mdt-softwire-map-translat= ion-01#section-8.3 On Fri, Mar 23, 2012 at 10:28 PM, Lee, Yiu wrote= : > Hi Guanghui, > > Is the original use case for MAP is to deliver v4 over v6 in a stateless > fashion in the network? This is stated in the stateless-requirements draf= t. > If we can get v4-v6 (single translation) for free, I am all for it. But > this isn't the original requirements we are trying to solve. Right? > > Thanks, > Yiu > > From: Guanghui Yu > Date: Fri, 23 Mar 2012 13:43:07 +0800 > > To: "Yiu L. LEE" > Cc: Softwires WG > Subject: Re: [Softwires] Path to move forward with 4rd=C5=A0 > > 4rd-U cannot replace MAP-T, since it cannot support single translation. > > > --=20 Yu Guanghui Network and Information Center Dalian University of Technology, China --0015175dd9440e98a604bc19f6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yiu
Please read MAP-T
http://tool=
s.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.3


On Fri, Mar 23, 2012 at 10:28 PM, = Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Hi Guanghui,

Is the original use case = for MAP is to deliver v4 over v6 in a stateless fashion in the network? Thi= s is stated in the stateless-requirements draft. If we can get v4-v6 (singl= e translation) for free, I am all for it. But this isn't the original r= equirements we are trying to solve. Right?

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Fri, 23 Mar 2012 13:43:= 07 +0800

To: "Yiu L. LEE" <= ;yiu_lee@cab= le.comcast.com>
Cc: Soft= wires WG <softwi= res@ietf.org>
Subject: Re: [Softwires] Path to m= ove forward with 4rd=C5=A0
=C2=A04rd-U cannot replac= e MAP-T, since it cannot support single translation.





--
Yu Guanghui <yg= h at dlut.edu.cn>
Network and Information Center
Dalian University of Tech= nology, China


--0015175dd9440e98a604bc19f6f0-- From cxc@xmu.edu.cn Sun Mar 25 19:17:42 2012 Return-Path: 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 D614B21E8056 for ; Sun, 25 Mar 2012 19:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.941 X-Spam-Level: *** X-Spam-Status: No, score=3.941 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6, J_CHICKENPOX_51=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 tA7rwEbAqZth for ; Sun, 25 Mar 2012 19:17:41 -0700 (PDT) Received: from xmu.edu.cn (unknown [IPv6:2001:da8:e800:0:e61f:13ff:fe38:8310]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43D21E8019 for ; Sun, 25 Mar 2012 19:17:39 -0700 (PDT) Received: from JustinChenPC (unknown [210.34.8.198]) by app (Coremail) with SMTP id 0iL_+5C7o51Xy29PgFzXBQ--.1267S2; Mon, 26 Mar 2012 09:50:15 +0800 (CST) From: "Justin Chen" To: Date: Mon, 26 Mar 2012 10:17:19 +0800 Message-ID: <000401cd0af6$92cb9320$b862b960$@xmu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0K9oRzbVIkz27YT8G0HO3w9zegpg== Content-Language: zh-cn X-CM-TRANSID: 0iL_+5C7o51Xy29PgFzXBQ--.1267S2 X-Coremail-Antispam: 1UD129KBjvAXoW3Aw1xCr4UZF45CF4UGw17KFg_yoW8CF4kKo WrZryxAw4xGr1UGF1vyayDJry5G3W3Kr1kJryUXw4UGanIqa47A3Wxua1DWFs8tr15Wr1D Jw1rXF4DZr4Iqryfn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjQmb7Iv0xC_Kw4lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx 0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMI8E67AF 67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IUemXd5UUUU U== X-CM-SenderInfo: hf0fq5lpxovvfxof0/ Subject: Re: [Softwires] Path to move forward with 4rd? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 02:17:43 -0000 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] =B4=FA=B1=ED softwires-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C225=C8=D5 1:47 =CA=D5=BC=FE=C8=CB: softwires@ietf.org =D6=F7=CC=E2: Softwires Digest, Vol 76, Issue 94 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/softwires Click the 'Unsubscribe or edit options' button, log in, and set "Get = MIME or Plain Text Digests?" to MIME. You can set this option globally for all = the list digests you receive at this point. Send Softwires mailing list submissions to softwires@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/softwires or, via email, send a message with subject or body 'help' to softwires-request@ietf.org You can reach the person managing the list at softwires-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Softwires digest..." Today's Topics: 1. Re: Path to move forward with 4rd? (Jan Zorz @ go6.si) 2. Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris (Alistair Woodman) 3. Re: Path to move forward with 4rd? (R?mi Despr?s) 4. Re: 4rd-u tunnels and stateful NAT64s (R?mi Despr?s) ---------------------------------------------------------------------- Message: 1 Date: Sat, 24 Mar 2012 17:29:43 +0100 From: "Jan Zorz @ go6.si" To: softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd? Message-ID: <4F6DF677.8080505@go6.si> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed On 3/23/12 4:04 AM, Guanghui Yu wrote: > Hi Yiu > > 4rd-u changes the IPv6 header architecture (redefine fragmentation = > header extension) and IPv6 address architecture (different meaning of=20 > u-bit when g-bit=3D1). These are the fundamental changes. If 4rd-u=20 > becomes the standard, then there will be new defined ?IPv6? > packets on the Internet, which are not compatible with existing IPv6=20 > packets and no existing devices can understand those packets. Exactly. +1 Cheers, Jan Zorz +1 Justin Chen ------------------------------ Message: 2 Date: Sat, 24 Mar 2012 09:37:53 -0700 From: "Alistair Woodman" To: Cc: fdupont@isc.org Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris Message-ID: <356701cd09dc$7872b190$695814b0$@org> Content-Type: text/plain; charset=3D"us-ascii" All, you are cordially invited. =20 Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of draft-penno-softwire-sdnat-02.=20 =20 The following will be shown: =20 1) Stateless DS-Lite 2) Stateless CPE B4 NAT 3) Anycast Failover 4) DHCPv4 proxy over v6 5) NAT Port range re-allocation via ICMP method. =20 When: Sunday the 25th from 15h30 to 17h00. Where: Room #201 (Front left of Hall Maillot when facing Porte Maillot), IETF 83, Paris -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Sat, 24 Mar 2012 17:58:25 +0100 From: R?mi Despr?s To: Jan Zorz @ go6.si Cc: softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd? Message-ID: <2C41A97B-38A7-4BED-9CA5-96E39FAD4EBB@laposte.net> Content-Type: text/plain; charset=3Dwindows-1252 Hi, Jan, Please see my answer to Guanghui. Thanks, RD Le 2012-03-24 ? 17:29, Jan Zorz @ go6.si a ?crit : > On 3/23/12 4:04 AM, Guanghui Yu wrote: >> Hi Yiu >>=20 >> 4rd-u changes the IPv6 header architecture (redefine fragmentation=20 >> header extension) and IPv6 address architecture (different meaning of = >> u-bit when g-bit=3D1). These are the fundamental changes. If 4rd-u=20 >> becomes the standard, then there will be new defined ?IPv6? >> packets on the Internet, which are not compatible with existing IPv6=20 >> packets and no existing devices can understand those packets. >=20 > Exactly. >=20 > +1 >=20 > Cheers, Jan Zorz >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires ------------------------------ Message: 4 Date: Fri, 23 Mar 2012 18:46:52 +0100 From: R?mi Despr?s To: Maoke Cc: Softwires WG Subject: Re: [Softwires] 4rd-u tunnels and stateful NAT64s Message-ID: <51BA7F56-7B83-4EF5-9223-7B21AB37BDE8@laposte.net> Content-Type: text/plain; charset=3D"iso-8859-1" Le 2012-03-19 ? 11:44, Maoke a ?crit : >=20 >=20 > 2012/3/19 R?mi Despr?s >=20 > Le 2012-03-19 ? 10:21, Maoke a ?crit : >=20 >>=20 >>=20 >> 2012/3/19 R?mi Despr?s >>=20 >> Le 2012-03-19 ? 09:16, Maoke a ?crit : >>=20 >>>=20 >>>=20 >>> 2012/3/16 R?mi Despr?s Maoke, >>>=20 >>> Let me try a more complete picture than before: >>>=20 >>>=20 >>> A1 -----. =20 >>> RFC6145-host| .-- 4rd BR --.=20 >>> | | | >>> A2 -----:--(v6net)--: :--(v4 Internet)--- B=20 >>> 4rd-CE | | | UDP Lite appli >>> (no IPv4 @) | '-- NAT64+ --'=20 >>> | =20 >>> A3 -----'=20 >>> 4rd-CE =20 >>> (IPv4 @, shared or not) >>>=20 >>>=20 >>> NAT64+ is supposed to have a bindings for UDP Lite, either only for=20 >>> NAT64+ 4rd IPv6 addresses (the minimum), or also for native IPv6=20 >>> NAT64+ addresses (the complete upgrade, with UDP-Lite checksum=20 >>> NAT64+ adjustment for these addresses) >>>=20 >>> Connectivities I get are:=20 >>> A2 =3D> B (via NAT64+) >>> A3 <=3D> B (via 4rd BR) >>> (There is no A1-B connectivity) >>>=20 >>> A2 is IPv6-only, right? >>=20 >> There seems to be a misunderstanding on what is IPv6-only. >> a) A2 is dual stack. Being a CE node, it supports IPv4 applications, = and typically includes a NAT44.=20 >> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it = has no assigned public IPv4 address (even shared). >> c) Because it has received a NAT64+ mapping rule, it knows it can = tunnel IPv4 packets to the NAT64+. >>=20 >>=20 >>> if so, let me go down.=20 >>=20 >> Not so =3D> doesn't apply.=20 >> (Yet some further comments below) >>=20 >> RD >>=20 >>=20 >>> =20 >>>=20 >>> Anything missed? >>>=20 >>>=20 >>> Other detailed comments follow. >>>=20 >>> Le 2012-03-16 ? 01:59, Maoke a ?crit : >>>=20 >>>>=20 >>>>=20 >>>> 2012/3/15 R?mi Despr?s >>>>=20 >>>> Le 2012-03-15 ? 14:47, Maoke a ?crit : >>>>=20 >>>>>=20 >>>>>=20 >>>>> 2012/3/15 R?mi Despr?s >>>>>=20 >>>>> Le 2012-03-15 ? 11:45, Maoke a ?crit : >>>>>=20 >>>>>> i understand NAT64 makes translation between arbitrary IPv6 = address to arbitrary IPv4 address. i don't understand how you make CNP in any = IPv6 address. >>>>>=20 >>>>>=20 >>>>>> in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. >>>>>=20 >>>>> That's no the case at all(!).=20 >>>>> A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged). >>>>>=20 >>>>> The draft says: >>>>> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support = 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format." >>>>> =20 >>>>> =20 >>>>> this phrase is not understood yet. do you mean using = 4rd-IPv6-address format for stateful translation service? >>>>=20 >>>> Yes (but, &s said, only for CE nodes that are 4rd capable (with the advantage of better IPv4 transparency between CEs and NAT64+ than = between RFC6145 and NAT64). >>>>=20 >>>>> please draw an example of A <---> B communication as i did for clarification. >>>>=20 >>>> Here is an example scenario: >>>>=20 >>>> v4appli-BIH ----. =3D> A>B NOK (because, according to RFC6535, BIH = uses RFC6145)=20 >>>> A1 | =20 >>>> :----(v6net)----- NAT64+ ---(IPv4 Internet)--- = Server >>>> | UDP-lite = UDP-lite >>>> v4Appli-4rdCE --' capable B >>>> A2 =3D> A-B OK >>>>=20 >>>>=20 >>>> yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, if the "not support" means passing-it-through without checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing with the L4, right? >>>=20 >>> A NAT64 that supports UDP Lite MUST update checksum for hosts that = have native IPv6 addresses. >>> That's why A1 =3D> B doesn't work unless the NAT64 recognizes which packets are those of IPv4 applications in DS hosts. >>>=20 >>> A1 -> B doesn't need stateful NAT64 but stateless service is enough. well, stateful is also ok. it is true NAT64 supporting UDP-Lite must = update checksum.=20 >>> =20 >>>=20 >>>> B --> A is a question mark, if we use the NAT64+ which does nothing with the L4 checksum, it is also not a problem. >>>=20 >>>=20 >>>> however, if we use, as you mentioned before, an UDP-Lite-aware = update of RFC6146, that may updates the checksum while the BIH doesn't know = that.=20 >>>=20 >>> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and = NAT64+) to support more protocols than the two required by the RFC. It is just an extension which cannot break anything (backward compatible). >>>=20 >>> confusing. upgrade vs. extension??=20 >>> =20 >>>=20 >>>=20 >>>>=20 >>>> my point here is: what is the use case with the details of = addressing? if and only if A1 or A2 is configured with an RFC6052 or a MAP or a = 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address to = serve B for the communications, A1 BIH or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't such a address pool for B, things will = fail because only one among src and dst is checksum-neutral.=20 >>>=20 >>> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address reaches the NAT64+ at this IPv6 address: >>>=20 >>> +-------------------------------+---+---+-------------+------+ >>> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >>> +-------------------------------+---+---+-------------+------+ >>> : 64 : 8 : 8 : 32 : 16 : >>>=20 >>> In the reverse direction, and for the same IPv4 address, it is the = same IPv6 address that must be synthesized by the NAT64+. >>>=20 >>> this address is used for A2 or used for B? if you mean B, then may i conclude that NAT64+ is serving between A2 (native IPv6 address with = 4rd-U CNP) and B (synthesized by NAT64+ into another IPv6-converted address = having CNP)? if i can, may i further conclude that NAT64+ serves only for the = case where A2 has the 4rd-U-style address?=20 >>=20 >> Let me repeat that: >> - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. >> - The only difference is that NAT64+ has a plus for addresses that = are those of 4RD-u CEs (better IPv4 transparency). >>=20 >> accepted. but i have pointed out the "better transparency" has some = cost and uncertaity up to now (see another thread).=20 >> =20 >>=20 >>=20 >>> if the A2 is configured with any IPv6 address, for example, address = with the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, = right?=20 >>>=20 >>> if so, i do really suggest you call it NAT64- instead of NAT64+ = because NAT64 can also serve hosts with any native IPv6 address to connect with = an IPv4 peer. >>>=20 >>> your answer below didn't respond my question, sorry. for example (in = >>> the use case of NAT64 instead of NAT64-), A2 has native IPv6 address = >>> 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the=20 >>> CE might synthesize an IPv6 address for B, with the NAT64+ prefix=20 >>> and the 0xc0204d32 and a CNP embedded, say B', and let A2 connect to = >>> B' through IPv6; however, when this packet goes through the NAT64+, >>=20 >>> because only B' is checksum-neutral while A2 is not, >>=20 >> If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, = >> per Fig 6, 2001:db8:1234:5678:3000:: It IS checksum neutral. >>=20 >> well, it is saying A2 must have the 4rd address in order to get the benefit of NAT64-, right? >=20 > (*) For native IPv6, it has whatever address applies (that of your = example is OK). > Its CE is reached with all destination addresses starting with the = site /64 followed by with the V octet. =20 >=20 >=20 >> i have typed "for example (in the use case of NAT64 instead of = NAT64-), ..." as the prerequisite of the above discussion. let me have the = following propositions:=20 >>=20 >> a. NAT64 suitable for any case no matter A2 is assigned with any kind = of address, but currently only works for TCP and UDP.=20 >=20 > Yes (but with the DF bit transparency limitation that is avoided in=20 > case of NAT64+) >=20 >> 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. >> =20 >> c. NAT64+ works like:=20 >> if A2 has a V-CNP-address, then it doesn't update the checksum for = any L4 protocols;=20 >> 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.=20 Seems right too. >>=20 >> i think we are common that a. is true, right? >=20 > Right, with the caveat above. >=20 >> do you mean c. instead of b. ? >=20 > 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.=20 >=20 > not yet cleared. "receives a NAT64+ mapping rule" for what? To know what to do with IPv4 packets if assigned no public IPv4 address. > is the NAT64+ mapping rule stateless or stateful? The rule 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=20 > is not applied, and you may have d.) If pressed to make a choice, c. seems closer to what I described. RD >=20 > thanks, > maoke > =20 >=20 > That's IMHO clear enough, especially with the (*) above which = clarifies AFAIK which native and 4rd IPv6 addresses are used by CEs. >=20 >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >>=20 >> thanks, >> maoke >>=20 >> =20 >>=20 >>> NAT64+ passing it without L4 checksum adjustment will make B receive = a packet with wrong checksum, for any L4 protocols.=20 >>>=20 >>> the above example works well for TCP and UDP with today's NAT64, = without limitations on A2's address.=20 >>>=20 >>> - maoke >>> =20 >>> This is I suppose implicit, but it can advantageously be made = explicit in the draft. >>> Thanks. >>>=20 >>>=20 >>>>> Because 4rd IPv6 addresses of CEs are distinguishable from all = other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY = for addresses that actually are 4rd CE addresses. >>>>> =20 >>>>> =20 >>>>> we need to make sure if the NAT64s make both src and dst addresses checksum-neutral. >>>>=20 >>>> Correct, iff the host address has the V octet. >>>>=20 >>>> 1. without the V-octet, CE and NAT64 can also distinguish the = 4rd-CE addresses from others.=20 >>>=20 >>> True, but while testing the V octet is sufficient in 4rd, the NAT64 = has in MAP to process mapping rules to find for null subnet IDs whose = lengths depend on which mapping rule applies. >>> That's IMHO one instance where the V-octet potential is clear. >>>=20 >>>=20 >>>> 2. even with the V-octet, do you mean B's IPv4 address also = translated (by the NAT64+) to a CNP-and-V-containing IPv6 address?=20 >>>=20 >>> Yes (see above). >>>=20 >>>> if 2 is true, why you use stateful NAT64+ here for B rather than a stateless one? >>>=20 >>> Because we consider hosts that are not assigned any public IPv4 = address, even shared. >>>=20 >>>> if 2 is not true, then the NAT64 can use any arbitrary IPv6 address = for B's communications, and such a case results only A's mapped address is checksum-neutral, and thus anyway L4 adjustment is needed.=20 >>>>=20 >>>> if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, = because NAT64 doesn't have the limitation on the IPv6 address pool in use.=20 >>>=20 >>> Suggestion not retained ;-). >>> What you call the IPv6 address pool isn't a reserved pool: as = explained above, NAT64+ synthesizes its IPv6 source addresses using its unchanged = /64 prefix.=20 >>>=20 >>>=20 >>>> 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is = NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit this = for the time being).=20 >>>=20 >>> Right. >>>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> - maoke >>>> =20 >>>>=20 >>>>> i cannot imagine what the use case is. please specify! >>>>=20 >>>> Hope the picture above helps. >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>> =20 >>>>> - maoke >>>>> =20 >>>>> =20 >>>>>=20 >>>>> RD >>>>>=20 >>>>>=20 >>>>>> - maoke >>>>>>=20 >>>>>> 2012/3/15 R?mi Despr?s >>>>>>=20 >>>>>> Le 2012-03-15 ? 10:59, R?mi Despr?s a ?crit : >>>>>>=20 >>>>>> > Maoke, >>>>>> > >>>>>> > Thanks for this question. >>>>>> > This subject being new, I take it on a new thread. >>>>>> > >>>>>> > 2012-03-15 10:38, Maoke: >>>>>> > ... >>>>>> >> i didn't understand the how the stateful NAT64 benefits from = CNP. >>>>>> > >>>>>> > The point is that if a NAT64 is upgraded to support 4rd-u = tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 = payloads. >>>>>> > Any protocol that this NAT64 supports is then supported e2e for = >>>>>> > 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. >>>>>> > >>>>>> > Note that the NAT64 doesn't need to have CNP code. It just=20 >>>>>> > happens that host IPv6 addresses it sees are checksum neutral.=20 >>>>>> > (Thus, IPv6 and IPv4 payloads are the same for all protocols=20 >>>>>> > that have ports at the same place as TCP/UDP/..., and the same=20 >>>>>> > checksum algorithm) >>>>>>=20 >>>>>> Oops. >>>>>> This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a = CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). >>>>>> Sorry for having hastily added this sentence. >>>>>>=20 >>>>>> RD >>>>>>=20 >>>>>> > >>>>>> > RD >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Softwires mailing list >>>>>> > Softwires@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires End of Softwires Digest, Vol 76, Issue 94 ***************************************** From msq@tju.edu.cn Sun Mar 25 20:52:10 2012 Return-Path: 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 492C521E8048 for ; Sun, 25 Mar 2012 20:52:10 -0700 (PDT) X-Quarantine-ID: <5r1ApJps2M14> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.683 X-Spam-Level: *** X-Spam-Status: No, score=3.683 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_RECV_IP_FROMIP1=1.666, SARE_SUB_ENC_UTF8=0.152] 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 5r1ApJps2M14 for ; Sun, 25 Mar 2012 20:52:09 -0700 (PDT) Received: from tju.edu.cn (smg.tju.edu.cn [202.113.15.18]) by ietfa.amsl.com (Postfix) with SMTP id 44DE621E8034 for ; Sun, 25 Mar 2012 20:52:06 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: X-EMDG-VER: 2009-11-28 Received: (eyou anti_spam gateway 3.0); Mon, 26 Mar 2012 11:34:27 +0800 Message-ID: <532732867.21392@tju.edu.cn> X-EYOUMAIL-SMTPAUTH: msq@tju.edu.cn Received: from 202.113.13.2 by 192.168.100.100 with SMTP; Mon, 26 Mar 2012 11:34:27 +0800 From: =?utf-8?B?5a2f5bCR5Y2/?= To: Date: Mon, 26 Mar 2012 11:52:00 +0800 Organization: =?utf-8?B?5aSp5rSl5aSn5a2m?= Message-ID: <004201cd0b03$ccad4f90$6607eeb0$@tju.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01CD0B46.DAD12BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0LA6YPAsMnQuHjSAikWiQt0OPr6Q== Content-Language: zh-cn Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: msq@tju.edu.cn List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 03:52:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0043_01CD0B46.DAD12BD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Exactly. +1 Shaoqing Meng Tianjin University Network Center > Hi Yiu > > 4rd-u changes the IPv6 header architecture (redefine fragmentation > header extension) and IPv6 address architecture (different meaning of > u-bit when g-bit=1). These are the fundamental changes. If 4rd-u > becomes the standard, then there will be new defined ?IPv6? > packets on the Internet, which are not compatible with existing IPv6 > packets and no existing devices can understand those packets. ------=_NextPart_000_0043_01CD0B46.DAD12BD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Exactly.

 

+1

 

 

Shaoqing Meng

Tianjin University Network = Center

 

> Hi = Yiu

> 

>     = 4rd-u changes the IPv6 header architecture (redefine fragmentation =

> = header extension) and IPv6 address architecture (different meaning of =

> = u-bit when g-bit=3D1). These are the fundamental changes. If 4rd-u =

> = becomes the standard, then there will be new defined = ?IPv6?

> packets on the Internet, which are not compatible with = existing IPv6

> packets and no existing devices can understand those = packets.

 

------=_NextPart_000_0043_01CD0B46.DAD12BD0-- From fibrib@gmail.com Sun Mar 25 21:35:12 2012 Return-Path: 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 1497E21E8064 for ; Sun, 25 Mar 2012 21:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 O0p7-TS2jWuc for ; Sun, 25 Mar 2012 21:35:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 153AA21F8458 for ; Sun, 25 Mar 2012 21:35:06 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3543661qcs.31 for ; Sun, 25 Mar 2012 21:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zPFqOUaFRUrWipaaf4L+JWB3OpoqpKMra77yGGc/xnw=; b=M0Y7dYaflzqNVWHvAzqVMgWo2TGxqdxUtYqRVAKR7W11m78VqObu9L/hWJIBmxKzTj kpUCGfr04+tE9YH3IfwAuOyAGmm4zEpVIa+WoEY7uaEJ2+VuEab9zfClhlOcFoYuwM+n qK9quxJ6Wup+Q7GCTvGF9pFtISAip0xzc5Xtc/ycOOa5dqgDd/RS9gvp5gVb46uVRFyp PCcCQ8U2QnXp2IObJ/ZO90H/Jceud3fleftXP9HQdsLgH1IHPSWcNlKKmSXoSfuYLScE rz4nQpV2/BEtw9HlcILuiRIsfbYrOVbDvqiwKeLSEFAfep52cC4HossHtnvFx8qQWrf3 b2zA== MIME-Version: 1.0 Received: by 10.229.77.141 with SMTP id g13mr7863363qck.11.1332736506185; Sun, 25 Mar 2012 21:35:06 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Sun, 25 Mar 2012 21:35:06 -0700 (PDT) In-Reply-To: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> Date: Mon, 26 Mar 2012 04:35:06 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235429cbe007caa004bc1de615 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 04:35:13 -0000 --00235429cbe007caa004bc1de615 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, let me remove those you have marked as "end". they are fine to me too. only one point: no implementation nor operation trouble !=3D it is safe to say i= t an architectural building block of tunnel. if we both say 4rd-u is an alternative for translation, it would be much clear. (i don't think it is a tunnel variant at all, due to not providing virtual links; while you insist it not a translation at all). 2012/3/25 R=E9mi Despr=E9s > > > c) MAP-A+P says "Each MAP node in the domain has the same set of rules" >>> while MAP-T says "if a CE knows only a subset of the mapping rules ..." >>> >>> >> >> first of all, they are not conflicting logically. >> >> >> ??? >> >> second, if you mean one doc is superior than multiple with better >> consistency in writing, i could agree. >> >> >> This is not the point. >> Separate documents can be consistent, but they aren't on this point. >> >> One of the two assertions must be changed. >> Remaining question: which one? >> >> > > well. this is why i said they are not conflict in logic. as a definition > of the MAP rule, right, each MAP node in the domain SHOULD have the same > set of rules. however, in practice of operation, it is possible that this > MAY not strictly achieved due to some information losses (which is often > happens in the Internet environment), MAP-T defines the CE working as it > were in hub&spokes mode for an unknown destination CE. > > > I am not aware that a CE might receive some of the MAP DHCPv6 parameters > but not all due to lost packets. > Clarification on this will be welcome. > my understanding is: DHCPv6 is not running on a reliable protocol, while MAP DHCPv6 does not yet determine if all FMR would be carried in a single or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has done with this, please teach me, thanks!) if you assume Internet is always reliable for everything, we must change our discussion on a lot of issues. > > if you mean the single mapping rule in IVI case, the answer is NONE, > surely. IVI uses RFC6052 address format rather than the MAP, without the > business of MAP. > > > OK > (In this respect at least, IVI significantly differs from a running > version of MAP-T). > well, here i don't know how "significantly" you mean. IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different in address mapping and operation. the context of "IVI" above mentioned the original IVI/dIVI that applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules. > > > if you mean using the MAP for the single translation as we did in IVI > (though actually we have IVI working for both single and double > translations simultaneously), MAP-T Sec 8.3 has answered your question. > > > Saying that there is no mapping rule in IVI is sufficient an answer. > then there is no more "not reaching collective understanding" for this point. End of this topic for me. > > None? >> If one, is it a DMR or a BMR? >> If two, what are they? >> ... >> OK, could have been clearer. >> Yet, I think you understand that with U, one has SIMULTANEOUSLY, >> transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that >> look at TCP ports. >> >> > > ok. then may i conclude, for the major part of U, that 1) U, as a > stated enhancement for double translation, gain the transparency for > DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); > > > 1) A statistic at a given time, and in a given place, isn't a proof that > the same ratio will be found later and somewhere else. > 2) Those that happen to be in the sacrificed minority, be it small, may > not like their situation. Solving the problem, be it only for them, is > progress. > 1) not only one statistics. i did it at Tsinghua University. prof. Bao and others did it at CERNET. other guys did it in Europe and published in IMC'07. and if you carefully read that paper, you may found that case was very abnormal. 2) well, it is good if we can take care of the minority without putting the majority into potential trouble and uncertainty. > > 2) with introducing #1. weird definition of the fragment header of IPv6; > #2 weird packet of IPv6 carrying ICMPv4 messages? > > > AFAIK, not weird to those who are open to accept that it is very simple. > AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2 well discussed with the ICMP designers before concluding they are "not weird"! i am not so open. to those who are open to accept this, i think they should be also open to the following propositions (that are wrong to me): *1. IPv6 option header, as long as there are reverved or not-yet-used or padding bits, could be redefined as we like. *2. it is a useless design that ICMP(v4 or v6) error message body contains part of the original IP(v4 or v6) packet, where the source address is identical to the destination of the IP(v4 or v6) header carrying the ICMP(v4 or v6) message. *3. it is a useless design that ICMPv6 header checksum contains pseudo-header of the IPv6 header carrying it. *4. IPv4 header checksum is actually useless. if the community would accept these *1 ~ *4 as true statements, i would be also open to accept the above 2). but don't conclude before we get the feedback from the community! ... > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are > major flaws (as we discussed so much, i was not convinced at all). i don'= t > think others who read the specification don't see them and other issues. > > > ICMPv4 payloads in IPv6 packets appear only during domain traversal, wher= e > they don't hurt anyone. > see above. > > If a host is IPv6 only, it isn't a 4rd-U host. > For communication between IPv4-only applications of DS hosts and IPv6-onl= y > hosts, there are already workable RFCs. > common understanding, including RFC6052/RFC6145/RFC6146 but surely not limited to these. > BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. > A new solution for this isn't needed. > BIH serves DS hosts connected to DS networks. the use case does not cover the all cases of IPv4-IPv6 mutual communciations. > > an operator definitely needs the encapsulation as a fully featured virtua= l > link (underlay infrastructure) in real O&A for IPv4 communications over > IPv6 infrastructure. U cannot replace E at all. > > > Different understanding. > An detailed E use case that cannot be supported by U (if it exists) would > give substance to this claim. > Open to look at it. > in my personal experience i could give you at least three quick examples of the use case for the building block of "virtual link": first example, if the IPv4 customer network plays BGP over IPv4 with the provider, through the BGP session between CE and BR, a virtual link is desired. (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) second example, there are dynamic routing protocols like RIP running in the following (multihoming) topology for IPv4 routing. the operator may want to treat the CE-BR as a single hop in order the virtual link is considered the distance vector calculation. (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) \ / \ / +------------ CE ----(Another, IPv4 domain)----------+ third example, same topology as above but OSPF are applied, and OSPF TTL-security check are enabled to ensure hop-passings less than a specified threshold. if the operator would like to treat CE---(IPv6-only domain)---BR as one hop because it is considered as virtual link, 4rd-u's rudiness in decreasing TTL will hurt. MAP-E (and other E) surely has no limitation in supporting any features of existing routing protocols. with at least the above three examples, i conclude "U cannot replace E at all"! (btw, surely the translation has the same limitation not to support the above features but, e.g., as you also said, it opens transport-layer stuff to the middle boxes). therefore i said operators may use either encapsulation or translation according to what they attach importance to.) > > but U needs still discussion > > > T too. > See, for example, (*) above. > you have ended that subject. fine to me. people have known the difference between the "needs discussions" for the both. > > and running code approval. it cannot replace T at least this moment. > > > Understanding how U's header mapping works doesn't need great expertise. > Co-autors readily understood it, with origins as varied as router-and-hos= t > vendor, software vendor, broadband operator, mobile operator. > well, it works just like another translator, surely it doesn't need great expertise. > > Running code as soon couldn't be done yet, but isn't a big deal at all > (see (**) below) > > ... > > MAP can work even without the V-octet and CNP, at least in significant > cases. > > > Not a valid reason to stop progress, especially if easy to understand. > At least Med suggested to look at V octet even in the context of MAP (if > chosen for standard track). > no problem if you keep debate in/with the MAP design team. just our current understanding is: it is not necessary. > > if we have the standard of MAP, we can immediately deploy it into > practice through applying MAP rules into the already well understood, wel= l > approved, well standardized encapsulation and translation modules, > without waiting for the approval of the new features in the address > format, and the approval of the reversible header mapping tightly coupled > with the address format. > > > (**) > When we discussed in Taipei, you first said you might code 4rd-U so that > it could be tested for real. You didn't do it for reasons that I perfectl= y > respect. > yes but i also mentioned the prerequisite: "when i fully understand it and see it qualified". i also talked with some others that i was interested in that and, if possible and necessary, i would try to code it out and test it, but again the prerequisite was attached. i have no reason to do a code for a stuff even suspected by myself. you should remember that, after a large amount of discussion, i told you i wouldn't code it when we reached the problem of IPv6 carrying ICMPv4. this made me re-think the issue in the aspect of architectural building block. sure the company's resource allocation was a reason but this reason was tightly correlated to my own academic judgement on the necessity. thanks, - maoke > Yet, modifying T code to support header mapping remains quite simple (you > even call it a translation variant). Starting from E code, it's simple to= o. > When this is done, all verifications can be easily done that what analysi= s > says is right is also right with running code. > > > Regards, > RD > --00235429cbe007caa004bc1de615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,=A0

let me remove those you have = marked as "end". they are fine to me too. only one point: no impl= ementation nor operation trouble !=3D it is safe to say it an architectural= building block of tunnel. if we both say 4rd-u is an alternative for trans= lation, it would be much clear. (i don't think it is a tunnel variant a= t all, due to not providing virtual links; while you insist it not a transl= ation at all).=A0

2012/3/25 R=E9mi Despr=E9s <despres.remi@la= poste.net>


c) MAP-A+P says "Each MAP node in the domain has the same set of = rules" while MAP-T says "if a CE knows only a subset of the mappi= ng rules ..." =A0
=A0
=A0=
first of all, they are not conflicting logically.

???

<= div class=3D"gmail_quote">
second, if you mean one doc is superior tha= n multiple with better consistency in writing, i could agree.

This is not the point.
Se= parate documents can be consistent, but they aren't on this point.

One of the two assertions must be changed.=A0
Remaining question: which one?
=A0
= =A0
well. this is why i said they are not conflict in logic. as a= definition of the MAP rule, right, each MAP node in the domain SHOULD have= the same set of rules. however, in practice of operation, it is possible t= hat this MAY not strictly achieved due to some information losses (which is= often happens in the Internet environment), MAP-T defines the CE working a= s it were in=A0hub&spokes mode for an unknown destination CE.

I am not aware that a CE might rece= ive some of the MAP DHCPv6 parameters but not all due to lost packets.
Clarification on this will be welcome.

my understanding is: DHCPv6 is not running on a reliable pro= tocol, while MAP DHCPv6 does not yet determine if all FMR would be carried = in a single or multiple DHCPv6 messages provided they are many. (if the MAP= -dhcp has done with this, please teach me, thanks!)

if you assume Internet is always reliable for everythin= g, we must change our discussion on a lot of issues.=A0
=A0
=

if you mean the single mapping rule in IVI case= , the answer is NONE, surely. IVI uses RFC6052 address format rather than t= he MAP, without the business of MAP.

OK
(In this res= pect at least, IVI significantly differs from a running version of MAP-T).<= /div>

well, here i don't kn= ow how "significantly" you mean. IVI/dIVI/MAP-T(or dIVI-pd) are s= ame in header processing but different in address mapping and operation. th= e context of "IVI" above mentioned the original IVI/dIVI that app= lies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules.=A0
=A0

=A0
if you mean using the MAP for the single translation as = we did in IVI (though actually we have IVI working for both single and doub= le translations simultaneously),=A0MAP-T Sec 8.3 has answered your question= .

Saying that there is no mapping rul= e in IVI is sufficient an answer.

then there is no more "not reaching collective understanding" = for this point. End of this topic for me.=A0
=A0

None?=A0
If one, is it a DMR or a BMR?
If two, wha= t are they?
...
OK, could have been= clearer.
Yet, I think you understand that with U, one=A0has=A0SI= MULTANEOUSLY, transparency to DF=3DMF=3D1 and applicability of IPv6-only mi= ddle boxes that look at TCP ports.
=A0
=A0
ok. then may i co= nclude, for the major part of U,=A0that 1) U, as a stated=A0enhancement for= =A0double translation,=A0gain the transparency for DF=3DMF=3D1 (the 10^-6 m= inor cases, commonly thought abnormal);

1) A statistic at a given time= , and in a given place, isn't a proof that the same ratio will be found= later and somewhere else.
2) Those that happen to be in the sacr= ificed minority, be it small, may not like their situation. Solving the pro= blem, be it only for them, is progress.

1) not only one statistics. i did it= at Tsinghua University. prof. Bao and others did it at CERNET. other guys = did it in Europe and published in IMC'07. and if you carefully read tha= t paper, you may found that case was very abnormal.=A0
2) well, it is good if we can take care of the minority without puttin= g the majority into potential trouble and uncertainty.=A0
=A0

<= blockquote type=3D"cite">
2) with introduci= ng #1. weird definition of the fragment header of IPv6; #2 weird packet of = IPv6 carrying ICMPv4 messages?

AFAIK, not weird to those who are o= pen to accept that it is very simple.

AFAIK, you'd better to have #1 accepted by the IPv6 protocol and= have #2 well discussed with the ICMP designers before concluding they are = "not weird"! i am not so open. to those who are open to accept th= is, i think they should be also open to the following propositions (that ar= e wrong to me):

*1. IPv6 option header, as long as there are reverved o= r not-yet-used or padding bits, could be redefined as we like.
*2= . it is a useless design that ICMP(v4 or v6) error message body contains pa= rt of the original IP(v4 or v6) packet, where the source address is identic= al to the destination of the IP(v4 or v6) header carrying the ICMP(v4 or v6= ) message.=A0
*3. it is a useless design that ICMPv6 header checksum contains pseudo= -header of the IPv6 header carrying it.=A0
*4. IPv4 header checks= um is actually useless.=A0

if the community would = accept these *1 ~ *4 as true statements, i would be also open to accept the= above 2). but don't conclude before we get the feedback from the commu= nity!

...=A0
well, i mostly argue that=A0the ICMPv4 being carried = by IPv6 and CNP are major flaws (as we discussed so much, i was not convinc= ed at all). i don't think others who read the specification don't s= ee them and other issues.

ICMPv4 payloads in IPv6 packet= s appear only during domain traversal, where they don't hurt anyone.

see above.=A0
=A0=

If a host is IPv6 only, it isn't a 4rd-U host.=A0
For communication between IPv4-only applications of DS hosts and IPv6-only = hosts,=A0there are already workable RFCs.=A0
=

common understanding, including RFC6052/RFC6145/RFC6146= but surely not limited to these.=A0
=A0
BIH in DS hosts is AFAIK particularly powerful, and IMHO su= fficient.=A0
A new solution for this isn't needed.=A0

BIH serves DS hosts connected to DS networks. the = use case does not cover the all cases of IPv4-IPv6 mutual communciations.= =A0
=A0

an operator definitely needs the encapsulation as a fully featured vir= tual link (underlay infrastructure)=A0in real O&A for IPv4 communicatio= ns over IPv6 infrastructure. U cannot replace E at all.

Different understanding.
An detailed E use c= ase that cannot be supported by U=A0(if it exists)=A0would give substance t= o this claim.
Open to look at it. =A0

in my personal experience i could give you at least three qu= ick examples of the use case for the building block of "virtual link&q= uot;:=A0

first example, if the IPv4 customer netwo= rk plays BGP over IPv4 with the provider, through the BGP session between C= E and BR, a virtual link is desired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
second = example, there are dynamic routing protocols like RIP running in the follow= ing (multihoming) topology for IPv4 routing. the operator may want to treat= the CE-BR as a single hop in order the virtual link is considered the dist= ance vector calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

third example, same topology a= s above but OSPF are applied, and OSPF TTL-security check are enabled to en= sure hop-passings less than a specified threshold. if the operator would li= ke to treat CE---(IPv6-only domain)---BR as one hop because it is considere= d as virtual link, 4rd-u's rudiness in decreasing TTL will hurt.=A0

MAP-E (and other E) surely has no limitation in support= ing any features of existing routing protocols. with at least the above thr= ee examples, i conclude "U cannot replace E at all"! (btw, surely= the translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the middle b= oxes). therefore i said operators may use either encapsulation or translati= on according to what they attach importance to.)=A0


=
but U needs still discussion
<= /blockquote>
T too.
See, for example, (*) abov= e.

you have ended t= hat subject. fine to me. people have known the difference between the "= ;needs discussions" for the both.=A0
=A0

and running code approval. it cannot replace T at least this moment. <= /div>

Understanding how U's= header mapping works doesn't need great expertise.
Co-autors= readily understood it, with origins as varied as router-and-host vendor, s= oftware vendor, broadband operator, mobile operator.

well, it works just like anoth= er translator, surely it doesn't need great expertise.=A0
=A0=

Running code a= s soon couldn't be done yet, but isn't a big deal at all (see (**) = below)

...=A0

MAP can work even without the V-octet and C= NP, at least in significant cases.

<= /div>Not a valid reason to stop progress, especially if easy to understand.=
At least Med suggested to look at V octet even in the context of MAP (= if chosen for standard track).

= no problem if you keep debate in/with the MAP design team. just our current= understanding is: it is not necessary.=A0
=A0

=A0if we have the standard of MAP, we=A0can immediately=A0deploy it in= to practice through applying MAP rules into the=A0already well understood, = well approved, well standardized=A0encapsulation and translation modules, = =A0without=A0waiting for the approval of the new features in the address fo= rmat, and the approval of the reversible header mapping tightly coupled wit= h the address format.

(**)
When we discuss= ed in Taipei, you first said you might code 4rd-U so that it could be teste= d for real. You didn't do it for reasons that I perfectly respect.

yes but i also mentioned the p= rerequisite: "when i fully understand it and see it qualified". i= also talked with some others that i was interested in that and, if possibl= e and necessary, i would try to code it out and test it, but again the prer= equisite was attached. i have no reason to do a code for a stuff even suspe= cted by myself. you should remember that, after a large amount of discussio= n, i told you i wouldn't code it when we reached the problem of IPv6 ca= rrying ICMPv4. this made me re-think the issue in the aspect of architectur= al building block. sure the company's resource allocation was a reason = but this reason was tightly correlated to my own academic judgement on the = necessity.=A0

thanks,
- maoke
=A0
Yet, mod= ifying T code to support header mapping remains quite simple (you even call= it a translation variant). Starting from E code, it's simple too.
When this is done, all verifications can be easily done that what anal= ysis says is right is also right with running code.


Regards,
RD

--00235429cbe007caa004bc1de615-- From clong_liu@hit.edu.cn Sun Mar 25 21:54:49 2012 Return-Path: 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 332EC21F84B8 for ; Sun, 25 Mar 2012 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.499 X-Spam-Level: *** X-Spam-Status: No, score=3.499 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] 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 MUkyE7zdj1dm for ; Sun, 25 Mar 2012 21:54:45 -0700 (PDT) Received: from hit.edu.cn (unknown [IPv6:2001:da8:ab:253::233]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3521F84AA for ; Sun, 25 Mar 2012 21:54:43 -0700 (PDT) Received: from clong_liu ( [202.118.243.16] ) by ajax-webmail-app3 (Coremail) ; Mon, 26 Mar 2012 12:54:47 +0800 (CST) Date: Mon, 26 Mar 2012 12:54:47 +0800 (CST) From: To: softwires@ietf.org Message-ID: <18b43d8.d3d5.1364d5b3eb7.Coremail.clong_liu@hit.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [202.118.243.16] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.0.4 build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn hit X-CM-TRANSID: qC2owJCrw0uX9m9PwPybAQ--.1823W X-CM-SenderInfo: xfor0wpbol3qxklwhvlgxou0/1tbiAQAWLkwrJkSiMQAMsj X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWUJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 04:54:49 -0000 +1 support From clong_liu@hit.edu.cn Sun Mar 25 21:59:55 2012 Return-Path: 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 CAE6021F84D2 for ; Sun, 25 Mar 2012 21:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.799 X-Spam-Level: *** X-Spam-Status: No, score=3.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] 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 eDvAkgI7Ounv for ; Sun, 25 Mar 2012 21:59:54 -0700 (PDT) Received: from hit.edu.cn (unknown [IPv6:2001:da8:ab:253::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB4021F84AA for ; Sun, 25 Mar 2012 21:59:52 -0700 (PDT) Received: from clong_liu ( [202.118.243.16] ) by ajax-webmail-app3 (Coremail) ; Mon, 26 Mar 2012 12:59:56 +0800 (CST) Date: Mon, 26 Mar 2012 12:59:56 +0800 (CST) From: To: softwires@ietf.org Message-ID: <1082910.d3d8.1364d5ff612.Coremail.clong_liu@hit.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [202.118.243.16] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.0.4 build 111111(15684.4153.3993) Copyright (c) 2002-2012 www.mailtech.cn hit X-CM-TRANSID: qC2owJCLHzDM929PwPybAQ--.2043W X-CM-SenderInfo: xfor0wpbol3qxklwhvlgxou0/1tbiAQAWLkwrJkSiMQANsi X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWUJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 04:59:55 -0000 +1 support Liu ChangLong Harbin Institute of Technology Network and Information Center,china From Francis.Dupont@fdupont.fr Sun Mar 25 23:42:49 2012 Return-Path: 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 6ABB821E8082 for ; Sun, 25 Mar 2012 23:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] 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 tp8+TeVUQh+4 for ; Sun, 25 Mar 2012 23:42:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2E021F8496 for ; Sun, 25 Mar 2012 23:42:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q6g2Ix005775; Mon, 26 Mar 2012 08:42:02 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260642.q2Q6g2Ix005775@givry.fdupont.fr> From: Francis Dupont To: "sunqi.csnet.thu" In-reply-to: Your message of Mon, 26 Mar 2012 11:42:51 +0800. <2012032611425130665213@gmail.com> Date: Mon, 26 Mar 2012 08:42:02 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:42:49 -0000 The principle is good, details are not: - only switched (giga) Ethernets were used (no wireless) - the PCP should get double arrow - all SD-B4s run a PCP/NAT-PMP/UPnP-GID-v1+v2 server (in fact they have the same kind of softwares, the laptop just offers more tools, 10000 times larger stable storage, a screen where wireshark can show packets, etc) - the port range (never a set for the SD-CPE) was configured by DHCPv4 over IPv6 too (ideally, we had time only for the static setup) Thanks Francis.Dupont@fdupont.fr PS: we have a picture too but I prefer to finish the demo setup than to fix the picture (same effort, better result :-). From wdec.ietf@gmail.com Mon Mar 26 02:08:52 2012 Return-Path: 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 A4D9121F8468 for ; Mon, 26 Mar 2012 02:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ebbSd6JzKcB3 for ; Mon, 26 Mar 2012 02:08:51 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0777421F84F6 for ; Mon, 26 Mar 2012 02:08:49 -0700 (PDT) Received: by qadc14 with SMTP id c14so2051203qad.10 for ; Mon, 26 Mar 2012 02:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=biwL2ynlwmkutfgfhcus/MHqPKWN1GejuKMFLXg5GZk=; b=fk65Q5GYiiu149w/6xPQ6eeDC73WGu/BIQa2mQcEPy9zG1Ywo5j8LOXMmk9/owmz7n 7TOcqT6dCrhSmN01ABQbHnVNuusQUzk8xnmRyJbA/lEbSXWCZiVKWqTu29pKoNHQ0K6z YI/so11r6ptgY1t7hxqg9YgKJyud665D1xmeO3KGrpb+9RSbSoZy+dOrpXKEnVN82lFJ 5526dl69mPnaf6dBarWeF18rempeuNJ0BCHwt7nTNocBWphyR+Kp0a2z8zkWLLg4czz+ 9nNs6BABBkPl3iU7TryHSuEs8yM39bsrxmsmtVHhHiVrFfKnsCRw3HrGaZAMuxDqamnH wdyg== MIME-Version: 1.0 Received: by 10.224.59.7 with SMTP id j7mr26849881qah.38.1332752929511; Mon, 26 Mar 2012 02:08:49 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Mon, 26 Mar 2012 02:08:49 -0700 (PDT) In-Reply-To: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> Date: Mon, 26 Mar 2012 11:08:49 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f74deefd9e604bc21b8f1 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:08:52 -0000 --20cf306f74deefd9e604bc21b8f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With the checksum re-computed, as per the rfc6145 option, translated IPv6 packets would get the right checksum. With 4rd-u so far I see no such option. -Woj. On 23 March 2012 14:55, R=E9mi Despr=E9s wrote: > Hi, Wojciech, > > Are you suggesting that T would work with IPv4 packets having UDP checksu= m > =3D 0? > > RFC6145 says that IPv4 packets with UDP checksum =3D 0 are either always > discarded, or optionally discarded if not fragmented (with checksum > recomputed if not discarded). > I don't see: > - how this would work with double translation > - why anything should be added to U for checksum-less UDP (IPv6-only > hosts don't support it anyway). > > Cheers, > RD > > > > Le 2012-03-23 =E0 13:46, Wojciech Dec a =E9crit : > > > > On 19 March 2012 14:22, R=E9mi Despr=E9s wrote= : > >> Hi, Xing, >> >> I look forward to face to face discussions in Paris if we don't clarify >> everything before that (I will be busy on something else in the next 3 >> days). >> >> >> Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : >> ... >> >> >> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE >> node, when it receives no 4rd mapping rule, to exercise single translati= on. >> Actually, I believe that using for this the BIH of RFC6535 is both >> sufficient and recommendable. >> Translated IPv4 packets, because they are sent from CE nodes to DNS64 >> synthesized addresses, are appropriately routed to their destinations. (= It >> can be via the NAT64-CGN if needed, or via more direct paths if possible= .) >> Anything missed? >> >> >> Sorry, this is a misunderstanding. >> Hint: Single translation and double translation are based on the same >> mapping rule in the CERNET2 deployment. >> >> >> I am well aware of this, but this doesn't explain why 4rd mapping rules >> similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 >> communication (single translation) supported". >> >> As said in RFC6219, CERNET hosts have their IPv6 addresses configured >> "via manual configuration or stateful autoconfiguration via DHCPv6". >> Hosts can therefore be assigned Interface IDs that have the 4rd-u format >> (with V octet and CNP). >> >> Now, when both addresses happen to be checksum neutral, RFC6145 >> translation doesn't modify L4 data, so that it doesn't matter whether th= e >> DS node has used 4rd-u header mapping or single translation. >> Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd >> CE nodes. >> > > If those packets are UDP checksum 0, the IPv6 host would either need to b= e > customized, or something else would need to changed/configured on the 4rd= -u > CE specifically to get that to work for specific IPv6 destinations, while > with MAP-t this would be transparent (and not require specific forwarding > rules). > > -Woj. > > >> >> Regards, >> RD >> >> >> >> >> >> >> >> Regards, >> >> xing >> >> >> >> Regards, >> RD >> >> >> >> >> >> Regards, >> >> xing >> >> >> >> Regards, >> RD >> >> >> >> >> >> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >> ... | | | | | >> >> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N = | >> | | packets | | | | | >> >> suggest you rename to "IPv4 to IPv6 communication (single translation) = supported" >> >> >> >> (2) More clarification should be added here. I am not sure 4rd-H can >> support single translation. >> >> (a) According to (1), 4rd-H does not perform header translation defined >> by RFC6145. >> >> (b) In the softwire mailing list, it seems that 4rd-H cannot support >> single translation. See the thread containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and >> other posts. >> >> (c) If 4rd-H cannot support single translation, then "IPv6 web caches >> work for IPv4 packets" requires special configurations, it cannot do IPv= 6 >> web caches for non 4rd-H packets. >> >> >> ... >> >> (5) I would like to see the details of how 4rd-H handles ICMP and ICMP >> error messages. In the softwire mailing list there were some discussions= . See >> the thread containing >> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and >> other posts. Please add >> >> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >> >> ... >> >> >> >> >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > > --20cf306f74deefd9e604bc21b8f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With the checksum re-computed, as per the rfc6145 option, translated IPv6 p= ackets would get the right checksum. With 4rd-u so far I see no such option= .

-Woj.

On 23 March 2012 14:55, R= =C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:
Hi, Wojc= iech,

Are you suggesting that T would work with IPv4 pac= kets having UDP checksum =3D 0?

RFC6145 says that IPv4 packets with UDP checksum = =3D 0 are either always discarded, or optionally discarded if not fragmente= d (with checksum recomputed if not discarded).=C2=A0
I don't = see:
- how this would work with double translation
- why anything= should be added to U for checksum-less UDP =C2=A0(IPv6-only hosts don'= t support it anyway).

Cheers,
RD



Le 2012-03-23 =C3=A0 13:4= 6, Wojciech Dec a =C3=A9crit :



On 19 March 2012 14:22, R= =C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrot= e:
Hi, Xing,

I look for= ward to face to face discussions in Paris if we don't clarify everythin= g before that (I will be busy on something else in the next 3 days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a =C3= =A9crit :
...

=C2=A0A key point is that 4rd doesn't prevent a=C2=A04rd-c= apable dual-stack CE node,=C2=A0when it receives no 4rd mapping rule, to exercise single translation.=C2=A0
=C2=A0Actually, I believe that using for this the BIH of RFC65= 35 is both sufficient and recommendable.
=C2=A0Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

I am well aware of this, but this=C2=A0doesn't explain= why 4rd mapping rules similar to those of CERNET2 wouldn't have, like = MAP-T, "IPv4 to IPv6 communication (= single translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 addresses config= ured "via manual configuration or stateful autoconfiguration via DHCPv= 6".
Hosts can therefore=C2=A0be assigned Interface IDs that have the 4rd-u format (w= ith V octet and CNP).
Now, when both addresses happen to b= e checksum neutral, RFC6145 translation doesn't modify L4 data, so that= it doesn't matter whether the DS node has used 4rd-u header mapping=C2= =A0or single translation.=C2=A0
Thus,=C2=A0IPv6-only hosts can exchange=C2=A0packets with IPv4 applications of 4rd CE nodes.=C2=A0

If those packets are UDP checksum 0, the IPv6 host wo= uld either need to be customized, or something else would need to changed/c= onfigured on the 4rd-u CE specifically to get that to work for specific IPv= 6 destinations, while with MAP-t this would be transparent (and not require= specific forwarding rules).

-Woj.
=C2=A0

Regards,
RD

=






=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
=C2=A0




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :=
... | | | | |
  |  5 | IPv6 web caches work for IPv4    =
    |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 com=
munication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.=C2= =A0 See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configuration= s, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail= -archive/web/softwires/current/msg03324.html and other posts. Plea= se add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ?=
 |
...







______________________________= _________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires




--20cf306f74deefd9e604bc21b8f1-- From despres.remi@laposte.net Mon Mar 26 04:35:28 2012 Return-Path: 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 7E79721F85AF for ; Mon, 26 Mar 2012 04:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 6mObBSLxPz9S for ; Mon, 26 Mar 2012 04:34:51 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id E561E21F85AA for ; Mon, 26 Mar 2012 04:34:50 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8501-out with ME id qBak1i00C5M8erm03Balfg; Mon, 26 Mar 2012 13:34:48 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-119680899 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 26 Mar 2012 13:34:42 +0200 Message-Id: <2BF534DB-3665-4FB4-B7AC-335B9FCA92EB@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:35:28 -0000 --Apple-Mail-1-119680899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-26 =E0 11:08, Wojciech Dec a =E9crit : > With the checksum re-computed, as per the rfc6145 option, translated = IPv6 packets would get the right checksum. With 4rd-u so far I see no = such option. Are you saying that, when original IPv4 packets have null UDP checksums, = MAP-T would REQUIRE CEs and BRs to recompute UDP checksums of complete = packets?=20 This would certainly prevent packets containing fragments to be = forwarded on the fly, and would therefore have performance implication. In any case, this is not specified yet (one more open issue of the MAP = set of documents). RD >=20 > -Woj. >=20 > On 23 March 2012 14:55, R=E9mi Despr=E9s = wrote: > Hi, Wojciech, >=20 > Are you suggesting that T would work with IPv4 packets having UDP = checksum =3D 0? >=20 > RFC6145 says that IPv4 packets with UDP checksum =3D 0 are either = always discarded, or optionally discarded if not fragmented (with = checksum recomputed if not discarded).=20 > I don't see: > - how this would work with double translation > - why anything should be added to U for checksum-less UDP (IPv6-only = hosts don't support it anyway). >=20 > Cheers, > RD >=20 >=20 >=20 > Le 2012-03-23 =E0 13:46, Wojciech Dec a =E9crit : >=20 >>=20 >>=20 >> On 19 March 2012 14:22, R=E9mi Despr=E9s = wrote: >> Hi, Xing, >>=20 >> I look forward to face to face discussions in Paris if we don't = clarify everything before that (I will be busy on something else in the = next 3 days). >>=20 >>=20 >> Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : >> ... >>>>=20 >>>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack = CE node, when it receives no 4rd mapping rule, to exercise single = translation.=20 >>>> Actually, I believe that using for this the BIH of RFC6535 is both = sufficient and recommendable. >>>> Translated IPv4 packets, because they are sent from CE nodes to = DNS64 synthesized addresses, are appropriately routed to their = destinations. (It can be via the NAT64-CGN if needed, or via more direct = paths if possible.) >>>> Anything missed? >>>=20 >>> Sorry, this is a misunderstanding.=20 >>> Hint: Single translation and double translation are based on the = same mapping rule in the CERNET2 deployment. >>=20 >> I am well aware of this, but this doesn't explain why 4rd mapping = rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to = IPv6 communication (single translation) supported". >>=20 >> As said in RFC6219, CERNET hosts have their IPv6 addresses configured = "via manual configuration or stateful autoconfiguration via DHCPv6". >> Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with V octet and CNP). >>=20 >> Now, when both addresses happen to be checksum neutral, RFC6145 = translation doesn't modify L4 data, so that it doesn't matter whether = the DS node has used 4rd-u header mapping or single translation.=20 >> Thus, IPv6-only hosts can exchange packets with IPv4 applications of = 4rd CE nodes.=20 >>=20 >> If those packets are UDP checksum 0, the IPv6 host would either need = to be customized, or something else would need to changed/configured on = the 4rd-u CE specifically to get that to work for specific IPv6 = destinations, while with MAP-t this would be transparent (and not = require specific forwarding rules).=20 >>=20 >> -Woj. >> =20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Regards, >>>=20 >>> xing >>>=20 >>>=20 >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Regards, >>>>>=20 >>>>> xing >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> RD >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >>>>>> ... | | | | | >>>>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y = | N | >>>>>>>>> | | packets | | | = | | >>>>>>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>>>>>=20 >>>>>>>=20 >>>>>>> (2) More clarification should be added here. I am not sure 4rd-H = can support single translation. >>>>>>>=20 >>>>>>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>>>>>=20 >>>>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot = support single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. >>>>>>>=20 >>>>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>>> (5) I would like to see the details of how 4rd-H handles ICMP = and ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>>>>>=20 >>>>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>>>> ... >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 >=20 --Apple-Mail-1-119680899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
With the checksum re-computed, as per the rfc6145 option, = translated IPv6 packets would get the right checksum. With 4rd-u so far = I see no such option.

Are you saying = that, when original IPv4 packets have null UDP = checksums, MAP-T would REQUIRE CEs and BRs to recompute UDP = checksums of complete packets? 
This would certainly = prevent packets containing fragments to be forwarded on the fly, and = would therefore have performance = implication.

In any case, this is not specified = yet (one more open issue of the MAP set of = documents).

RD



-Woj.

On 23 = March 2012 14:55, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span> wrote:
Hi, Wojciech,

Are you = suggesting that T would work with IPv4 packets having UDP checksum =3D = 0?

RFC6145 says that IPv4 packets with UDP = checksum =3D 0 are either always discarded, or optionally discarded if = not fragmented (with checksum recomputed if not = discarded). 
I don't see:
- how this would work with double translation
- why = anything should be added to U for checksum-less UDP  (IPv6-only = hosts don't support it = anyway).

Cheers,
RD



Le 2012-03-23 =C3=A0 = 13:46, Wojciech Dec a =C3=A9crit :



On 19 March 2012 14:22, R=C3=A9mi Despr=C3=A9s = <despres.remi@laposte.net> wrote:
Hi, Xing,

I look = forward to face to face discussions in Paris if we don't clarify = everything before that (I will be busy on something else in the next 3 = days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a = =C3=A9crit :
...

 A key point is that 4rd doesn't prevent = a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, = to exercise single translation. 
 Actually, I believe that using for this the BIH of = RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from = CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 = deployment.

I am well aware = of this, but this doesn't explain why 4rd mapping rules similar to = those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication (single = translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 = addresses configured "via manual configuration or stateful = autoconfiguration via DHCPv6".
Hosts can therefore be assigned Interface IDs that have = the 4rd-u format (with V octet and CNP).

Now, when both addresses happen = to be checksum neutral, RFC6145 translation doesn't modify L4 data, so = that it doesn't matter whether the DS node has used 4rd-u header = mapping or single = translation. 
Thus, IPv6-only hosts can = exchange packets with IPv4 = applications of 4rd CE nodes. 

If those packets are UDP checksum 0, the IPv6 host = would either need to be customized, or something else would need to = changed/configured on the 4rd-u CE specifically to get that to work for = specific IPv6 destinations, while with MAP-t this would be transparent = (and not require specific forwarding rules).

-Woj.
 

=
Regards,
RD







=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit = :
... | | | | = |
  |  5 | IPv6 web caches work for IPv4  =
      |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 =
communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single = translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

= (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts. = Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? =
| ? |
...





=


_____________________________= __________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires





= --Apple-Mail-1-119680899-- From despres.remi@laposte.net Mon Mar 26 04:49:16 2012 Return-Path: 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 0743421F868C for ; Mon, 26 Mar 2012 04:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 aVGC2wvwMygX for ; Mon, 26 Mar 2012 04:49:14 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D321F866C for ; Mon, 26 Mar 2012 04:49:12 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8503-out with ME id qBpA1i0025M8erm03BpAVM; Mon, 26 Mar 2012 13:49:11 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-120545508 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 26 Mar 2012 13:49:07 +0200 Message-Id: <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> To: Maoke Chen , Tomasz Mrugalski X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:49:16 -0000 --Apple-Mail-2-120545508 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, More comments in line. Tomek, could you please tell your view on (*) below. Le 2012-03-26 =E0 06:35, Maoke a =E9crit : > hi Remi,=20 >=20 > let me remove those you have marked as "end". they are fine to me too. = only one point: no implementation nor operation trouble !=3D it is safe = to say it an architectural building block of tunnel. if we both say = 4rd-u is an alternative for translation, it would be much clear. (i = don't think it is a tunnel variant at all, As already answered, "tunnel" is taken to mean a local setup such that = you cannot detect, e2e, that packets weren't natively routed all the = way. This is a AFAIK reasonable use of the word. Some words to clarify this in the draft could be added if found = desirable.=20 > due to not providing virtual links; while you insist it not a = translation at all).=20 No objection to use Reversible header "translation" instead of = Reversible header "mapping". The important points are: (1) reversibility = of header mapping/translation; (2) payload preservation. (No religion = against the word translation!).=20 What MUST be avoided is only confusion with RFC6145 translation, because = it is different.=20 (*) > I am not aware that a CE might receive some of the MAP DHCPv6 = parameters but not all due to lost packets. > Clarification on this will be welcome. >=20 > my understanding is: DHCPv6 is not running on a reliable protocol, = while MAP DHCPv6 does not yet determine if all FMR would be carried in a = single or multiple DHCPv6 messages provided they are many. (if the = MAP-dhcp has done with this, please teach me, thanks!) Copy to Tomek Mrugalski is added, in order to have his expertise on this = subject. > if you assume Internet is always reliable for everything, we must = change our discussion on a lot of issues.=20 > =20 >=20 >> if you mean the single mapping rule in IVI case, the answer is NONE, = surely. IVI uses RFC6052 address format rather than the MAP, without the = business of MAP. >=20 > OK > (In this respect at least, IVI significantly differs from a running = version of MAP-T). >=20 > well, here i don't know how "significantly" you mean. = IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different = in address mapping and operation. the context of "IVI" above mentioned = the original IVI/dIVI that applies RFC6052 mapping, while MAP-T = (dIVI-pd) applies MAP mapping rules.=20 No problem here. End of this for me. >> if you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your question. >=20 > Saying that there is no mapping rule in IVI is sufficient an answer. >=20 > then there is no more "not reaching collective understanding" for this = point. End of this topic for me.=20 > =20 >=20 >> None?=20 >> If one, is it a DMR or a BMR? >> If two, what are they? >> ... >> OK, could have been clearer. >> Yet, I think you understand that with U, one has SIMULTANEOUSLY, = transparency to DF=3DMF=3D1 and applicability of IPv6-only middle boxes = that look at TCP ports. >> =20 >> =20 >> ok. then may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the transparency for = DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought abnormal); >=20 > 1) A statistic at a given time, and in a given place, isn't a proof = that the same ratio will be found later and somewhere else. > 2) Those that happen to be in the sacrificed minority, be it small, = may not like their situation. Solving the problem, be it only for them, = is progress. >=20 > 1) not only one statistics. i did it at Tsinghua University. prof. Bao = and others did it at CERNET. other guys did it in Europe and published = in IMC'07. and if you carefully read that paper, you may found that case = was very abnormal.=20 What you call "abnormal" is a packet that is fragmented by its source = and not to be fragmented in the network.=20 note however that this is the choice that has become standard in IPv6 = (fragmentation only by sources). > 2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and uncertainty.=20 Agreed. That's precisely what U has been designed to achieve, successfully = AFAIK.=20 >> 2) with introducing #1. weird definition of the fragment header of = IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? >=20 > AFAIK, not weird to those who are open to accept that it is very = simple. >=20 > AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have = #2 well discussed with the ICMP designers before concluding they are = "not weird"! i am not so open. to those who are open to accept this, i = think they should be also open to the following propositions (that are = wrong to me): >=20 > *1. IPv6 option header, as long as there are reverved or not-yet-used = or padding bits, could be redefined as we like. > *2. it is a useless design that ICMP(v4 or v6) error message body = contains part of the original IP(v4 or v6) packet, where the source = address is identical to the destination of the IP(v4 or v6) header = carrying the ICMP(v4 or v6) message.=20 > *3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it.=20 > *4. IPv4 header checksum is actually useless.=20 None of these statements have ever been made before AFAIK. They seem to = be your own construction. If you could point to text in the U draft that justifies your concern, = and explain what might go wrong, that would permit to understand what = you mean. > if the community would accept these *1 ~ *4 as true statements, i = would be also open to accept the above 2). but don't conclude before we = get the feedback from the community! >=20 >> ...=20 >> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP = are major flaws (as we discussed so much, i was not convinced at all). i = don't think others who read the specification don't see them and other = issues. >=20 > ICMPv4 payloads in IPv6 packets appear only during domain traversal, = where they don't hurt anyone. >=20 > see above.=20 > =20 >=20 > If a host is IPv6 only, it isn't a 4rd-U host.=20 > For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable RFCs.=20 >=20 > common understanding, including RFC6052/RFC6145/RFC6146 but surely not = limited to these.=20 > =20 > BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.=20= > A new solution for this isn't needed.=20 >=20 > BIH serves DS hosts connected to DS networks. the use case does not = cover the all cases of IPv4-IPv6 mutual communciations.=20 The subject at hand is CE node having 4rd-U (for IPv4 across IPv6), and = BIH (for IPv4 applications communicating with IPv6-only peers). Thanks = to 4rd-U, BIH-capable nodes can be used on IPv6-only networks. >> an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. >=20 > Different understanding. > An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. > Open to look at it. =20 >=20 > in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >=20 > first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >=20 > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U. =20 > second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >=20 > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 > \ = / > \ = / > +------------ CE ----(Another, IPv4 = domain)----------+ Same comment. > third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 Same comment. > MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. Why U would be less transparent between CEs and BRs than E for any L4 = protocol remains unexplained. =20 > with at least the above three examples, i conclude "U cannot replace E = at all"! See above. > (btw, surely the translation has the same limitation not to support = the above features but, e.g., as you also said, it opens transport-layer = stuff to the middle boxes). therefore i said operators may use either = encapsulation or translation according to what they attach importance = to.)=20 >=20 >=20 >=20 >> but U needs still discussion >=20 > T too. > See, for example, (*) above. >=20 > you have ended that subject. fine to me. > people have known the difference between the "needs discussions" for = the both. ??? - What about a domain parameter being needed or not in MAP for = hub&spoke? - Wojciech just suggested that, for MAP-T, CEs and BRs would compute UDP = checksums of full IUDP packets received with null checksums. Is it = something you would also recommend? I don't see any substantial point about U that hasn't been answered. >> and running code approval. it cannot replace T at least this moment. >=20 > Understanding how U's header mapping works doesn't need great = expertise. > Co-autors readily understood it, with origins as varied as = router-and-host vendor, software vendor, broadband operator, mobile = operator. >=20 > well, it works just like another translator, surely it doesn't need = great expertise.=20 > =20 >=20 > Running code as soon couldn't be done yet, but isn't a big deal at all = (see (**) below) >=20 > ...=20 >=20 >> MAP can work even without the V-octet and CNP, at least in = significant cases. >=20 > Not a valid reason to stop progress, especially if easy to understand. > At least Med suggested to look at V octet even in the context of MAP = (if chosen for standard track). >=20 > no problem if you keep debate in/with the MAP design team. Please note that several MAP team members are co-authors of the U = proposal. I never refused discussion (as you well know), and prefer to do it in = the open. Discussion is now on the WG ML. > just our current understanding is: it is not necessary. - Understanding of whom? - If some others find it IS necessary, why not accepting to satisfy them = too (that's what standardization is about)? =20 >> if we have the standard of MAP, we can immediately deploy it into = practice through applying MAP rules into the already well understood, = well approved, well standardized encapsulation and translation modules, = without waiting for the approval of the new features in the address = format, and the approval of the reversible header mapping tightly = coupled with the address format. >=20 > (**) > When we discussed in Taipei, you first said you might code 4rd-U so = that it could be tested for real. You didn't do it for reasons that I = perfectly respect. >=20 > yes but i also mentioned the prerequisite: "when i fully understand it = and see it qualified". i also talked with some others that i was = interested in that and, if possible and necessary, i would try to code = it out and test it, but again the prerequisite was attached. i have no = reason to do a code for a stuff even suspected by myself. you should = remember that, after a large amount of discussion, i told you i wouldn't = code it when we reached the problem of IPv6 carrying ICMPv4. this made = me re-think the issue in the aspect of architectural building block. = sure the company's resource allocation was a reason but this reason was = tightly correlated to my own academic judgement on the necessity.=20 No disagreement on any of this. Cheers, RD >=20 > thanks, > - maoke > =20 > Yet, modifying T code to support header mapping remains quite simple = (you even call it a translation variant). Starting from E code, it's = simple too. > When this is done, all verifications can be easily done that what = analysis says is right is also right with running code. >=20 >=20 > Regards, > RD >=20 --Apple-Mail-2-120545508 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi Remi, 

let me = remove those you have marked as "end". they are fine to me too. only one = point: no implementation nor operation trouble !=3D it is safe to say it = an architectural building block of tunnel. if we both say 4rd-u is an = alternative for translation, it would be much clear. (i don't think it = is a tunnel variant at = all,

As already answered, = "tunnel" is taken to mean a local setup such that you cannot = detect, e2e, that packets weren't natively routed all the way. This is = a AFAIK reasonable use of the word.
Some words to = clarify this in the draft could be added if found = desirable. 

due to = not providing virtual links; while you insist it not a translation at = all). 

No objection to use = Reversible header "translation" instead of Reversible header = "mapping". The important points are: (1) reversibility of header = mapping/translation; (2) payload preservation. (No religion against the = word translation!). 

What MUST be avoided = is only confusion with RFC6145 translation, because it is = different. 


(*)
I am not aware that a CE might receive some of = the MAP DHCPv6 parameters but not all due to lost = packets.
Clarification on this will be = welcome.

my understanding is: DHCPv6 is not running on a reliable = protocol, while MAP DHCPv6 does not yet determine if all FMR would be = carried in a single or multiple DHCPv6 messages provided they are many. = (if the MAP-dhcp has done with this, please teach me, = thanks!)

Copy to Tomek Mrugalski = is added, in order to have his expertise on this = subject.



if you assume Internet is always reliable for everything, we must = change our discussion on a lot of = issues. 
 

if you mean the single = mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 = address format rather than the MAP, without the business of MAP.

OK
(In this = respect at least, IVI significantly differs from a running version of = MAP-T).

well, here i = don't know how "significantly" you mean. IVI/dIVI/MAP-T(or dIVI-pd) are = same in header processing but different in address mapping and = operation. the context of "IVI" above mentioned the original IVI/dIVI = that applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping = rules. 

No problem = here.
End of this for = me.


if = you mean using the MAP for the single translation as we did in IVI = (though actually we have IVI working for both single and double = translations simultaneously), MAP-T Sec 8.3 has answered your = question.

Saying that there is no mapping = rule in IVI is sufficient an = answer.

then there is no = more "not reaching collective understanding" for this point. End of this = topic for me. 
 

None? 
If one, is it a DMR or a BMR?
If = two, what are they?
...
OK, = could have been clearer.
Yet, I think you understand that with = U, one has SIMULTANEOUSLY, transparency to DF=3DMF=3D1 and = applicability of IPv6-only middle boxes that look at TCP ports.
 
 
ok. then = may i conclude, for the major part of U, that 1) U, as a = stated enhancement for double translation, gain the = transparency for DF=3DMF=3D1 (the 10^-6 minor cases, commonly thought = abnormal);

1) A statistic at a given = time, and in a given place, isn't a proof that the same ratio will be = found later and somewhere else.
2) Those that happen to be in = the sacrificed minority, be it small, may not like their situation. = Solving the problem, be it only for them, is progress.

1) not only one statistics. i did = it at Tsinghua University. prof. Bao and others did it at CERNET. other = guys did it in Europe and published in IMC'07. and if you carefully read = that paper, you may found that case was very = abnormal. 

What you call = "abnormal" is a packet that is fragmented by its source and not to be = fragmented in the network. 
note however that this is the = choice that has become standard in IPv6 (fragmentation only by = sources).

2) well, it is good if we can take care of the minority without = putting the majority into potential trouble and = uncertainty. 

Agreed.
That's precisely what U has been designed to achieve, successfully = AFAIK. 


= 2) with introducing #1. weird definition of the fragment header of IPv6; = #2 weird packet of IPv6 carrying ICMPv4 messages?

AFAIK, not weird to those who = are open to accept that it is very = simple.

AFAIK, you'd better = to have #1 accepted by the IPv6 protocol and have #2 well discussed with = the ICMP designers before concluding they are "not weird"! i am not so = open. to those who are open to accept this, i think they should be also = open to the following propositions (that are wrong to me):

*1. IPv6 option header, as long as there are = reverved or not-yet-used or padding bits, could be redefined as we = like.
*2. it is a useless design that ICMP(v4 or v6) error = message body contains part of the original IP(v4 or v6) packet, where = the source address is identical to the destination of the IP(v4 or v6) = header carrying the ICMP(v4 or v6) message. 
*3. it is a useless design that ICMPv6 header checksum contains = pseudo-header of the IPv6 header carrying it. 
*4. IPv4 = header checksum is actually = useless. 

None of these = statements have ever been made before AFAIK. They seem to be your own = construction.

If you could point to text in the = U draft that justifies your concern, and explain what might go wrong, = that would permit to understand what you = mean.


if the community would accept these *1 ~ *4 = as true statements, i would be also open to accept the above 2). but = don't conclude before we get the feedback from the community!

... 
well, i mostly argue that the ICMPv4 being = carried by IPv6 and CNP are major flaws (as we discussed so much, i was = not convinced at all). i don't think others who read the specification = don't see them and other issues.

ICMPv4 payloads in IPv6 = packets appear only during domain traversal, where they don't hurt = anyone.

see = above. 
 

If a host is = IPv6 only, it isn't a 4rd-U host. 
For communication between IPv4-only applications of DS hosts and = IPv6-only hosts, there are already workable = RFCs. 

common = understanding, including RFC6052/RFC6145/RFC6146 but surely not limited = to these. 
 
BIH in DS hosts is AFAIK = particularly powerful, and IMHO sufficient. 
A new solution for this isn't = needed. 

BIH = serves DS hosts connected to DS networks. the use case does not cover = the all cases of IPv4-IPv6 mutual = communciations. 

The subject = at hand is CE node having 4rd-U (for IPv4 across IPv6), and BIH (for = IPv4 applications communicating with IPv6-only peers). Thanks to 4rd-U, = BIH-capable nodes can be used on IPv6-only = networks.


an operator definitely needs the encapsulation as a fully featured = virtual link (underlay infrastructure) in real O&A for IPv4 = communications over IPv6 infrastructure. U cannot replace E at all. =

Different understanding.
An detailed E = use case that cannot be supported by U (if it exists) would = give substance to this claim.
Open to look at it. =  

in my personal experience i could give you at least three = quick examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 = customer network plays BGP over IPv4 with the provider, through the BGP = session between CE and BR, a virtual link is desired. 

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 = world) 

I = don't see in this scenario why anything that works with E (i.e. between = CEs and BRs) wouldn't also work with U.
     =                     =           =   

second example, there are dynamic routing = protocols like RIP running in the following (multihoming) topology for = IPv4 routing. the operator may want to treat the CE-BR as a single hop = in order the virtual link is considered the distance vector = calculation.

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 world) 
  =              \       =                     =                     =          /
      =           \           =                     =                     =    /
                =  +------------ CE ----(Another, IPv4 = domain)----------+

Same = comment.


third example, same topology as above = but OSPF are applied, and OSPF TTL-security check are enabled to ensure = hop-passings less than a specified threshold. if the operator would like = to treat CE---(IPv6-only domain)---BR as one hop because it is = considered as virtual link, 4rd-u's rudiness in decreasing TTL will = hurt. 

Same = comment.

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing = protocols.

Why U would = be less transparent between CEs and BRs than E for any L4 protocol = remains unexplained.
 
with at least the above three examples, = i conclude "U cannot replace E at all"! =

See = above.

(btw, surely the translation has the = same limitation not to support the above features but, e.g., as you also = said, it opens transport-layer stuff to the middle boxes). therefore i = said operators may use either encapsulation or translation according to = what they attach importance to.) 



but U needs still discussion =

T too.
See, for = example, (*) = above.

you have = ended that subject. fine to me.

people have known the = difference between the "needs discussions" for the = both.

???

- = What about a domain parameter being needed or not in MAP for = hub&spoke?
- Wojciech just suggested that, for MAP-T, CEs = and BRs would compute UDP checksums of full IUDP packets received with = null checksums. Is it something you would also = recommend?

I don't see any substantial = point about U that hasn't been = answered.


and running code approval. it cannot replace T at least this = moment.

Understanding = how U's header mapping works doesn't need great = expertise.
Co-autors readily understood it, with origins as = varied as router-and-host vendor, software vendor, broadband operator, = mobile operator.

well, it works just like = another translator, surely it doesn't need great = expertise. 
 

Running = code as soon couldn't be done yet, but isn't a big deal at all (see (**) = below)

... 

MAP can work even without the V-octet = and CNP, at least in significant = cases.

Not a valid reason = to stop progress, especially if easy to understand.
At least Med suggested to look at V octet even in the context of = MAP (if chosen for standard = track).

no problem if you = keep debate in/with the MAP design team. =


Please = note that several MAP team members are co-authors of the U = proposal.
I never refused discussion (as you well know), and = prefer to do it in the open.
Discussion is now on the WG = ML.

just our current understanding is: it is not = necessary.

- = Understanding of whom?
- If some others find it IS necessary, = why not accepting to satisfy them too (that's what standardization is = about)?
  

 if we have the standard of MAP, we can = immediately deploy it into practice through applying MAP rules into = the already well understood, well approved, well = standardized encapsulation and translation modules, =  without waiting for the approval of the new features in the = address format, and the approval of the reversible header mapping = tightly coupled with the address format.

(**)
When we = discussed in Taipei, you first said you might code 4rd-U so that it = could be tested for real. You didn't do it for reasons that I perfectly = respect.

yes but i also mentioned = the prerequisite: "when i fully understand it and see it qualified". i = also talked with some others that i was interested in that and, if = possible and necessary, i would try to code it out and test it, but = again the prerequisite was attached. i have no reason to do a code for a = stuff even suspected by myself. you should remember that, after a large = amount of discussion, i told you i wouldn't code it when we reached the = problem of IPv6 carrying ICMPv4. this made me re-think the issue in the = aspect of architectural building block. sure the company's resource = allocation was a reason but this reason was tightly correlated to my own = academic judgement on the = necessity. 

No disagreement = on any of = this.


Cheers,
RD



thanks,
- = maoke
 
Yet, modifying T code to = support header mapping remains quite simple (you even call it a = translation variant). Starting from E code, it's simple too.
When this is done, all verifications can be easily done that what = analysis says is right is also right with running = code.


Regards,
RD
<= /div>


= --Apple-Mail-2-120545508-- From jiangdong345@gmail.com Mon Mar 26 06:32:52 2012 Return-Path: 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 C900B21F85B1 for ; Mon, 26 Mar 2012 06:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 mkT88WbdGQvG for ; Mon, 26 Mar 2012 06:32:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14D4121F8598 for ; Mon, 26 Mar 2012 06:32:52 -0700 (PDT) Received: by iazz13 with SMTP id z13so9779106iaz.31 for ; Mon, 26 Mar 2012 06:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=OK0dtIQ2AO8wikNPs8GEBueG8W3DpiIVlVqpheT2V2g=; b=E3UaBZEhgD6o4A9rXAxsbPa/4nvOj2MUH6+dWpNUed7rc2we5Wp9Uvi+sc5ncQ5fDU K8ZIQR4I1f8Wov8kkI+xBbSXBYq0a5972gDU+FIrlVq8LeC5A3JMA+tj+cONqVsLWGwc 221MCahJcNN7hMq7NpPGYeq7eAvbhuVDCQP3FtU1DjkG3Qb2Sls5e6JNXlJgLyf2+Cu0 bhqhHoR3oFrl/ONdkMp7P1D7Mxiifbm9zlBE6QTj1OjF0fMC/DRx2Ik5Z9U0Cxo/7nvh 86m+cBkKOfAqfGYdMXc05ccivoIMckJsD6nI01JN0JyBK4fPpMI+oKAhgGPDg5xxds3t qdrg== Received: by 10.50.77.166 with SMTP id t6mr5499745igw.61.1332768771773; Mon, 26 Mar 2012 06:32:51 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id ut8sm14698830igc.11.2012.03.26.06.32.47 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 06:32:51 -0700 (PDT) Date: Mon, 26 Mar 2012 21:32:49 +0800 From: "Jiang Dong" To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> X-Priority: 3 X-GUID: 384E3739-252A-4ACB-9828-047C55E246D9 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012032621324442247767@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart788602822065_=----" Cc: Softwires WG Subject: [Softwires] questions about 4rd-u X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:32:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart788602822065_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFJlbWksDQoNCkkgZ2V0IHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSA0cmQtdSBkcmFmdC4N Cg0KMSkgVGhlICJ0dW5uZWwgcGFja2V0IiBkZWZpbmVkIGluIHlvdXIgZHJhZnQgaW5jbHVkZXMg YW4gSVB2NiBoZWFkZXIgZm9sbG93ZWQgYnkgYSBJUHY2IGZyYWdtZW50YXRpb24uIENhbiB0aGlz IHBhY2tldCBiZSBkZWZpbmVkIGFzIGEgdHVubmVsIHBhY2tldCBvciBhIHRyYW5zbGF0aW9uIHBh Y2tldCBvciBuZWl0aGVyIG9yIGJvdGg/IFNpbmNlIHRoaXMgaXMgbm90IHRoZSB0cmFkaXRpb25h bCB0dW5uZWxpbmcgcGFja2V0IGZvcm1hdCwgSSdtIG5vdCBzdXJlIHN0aWxsIHVzaW5nICJ0dW5u ZWwgcGFja2V0IiBpcyBhIGdvb2QgaWRlYS4NCg0KMikgWW91IG1lbnRpb25lZCBOQVQ2NCsgd2hp Y2ggaXMgdXBncmFkZWQgdG8gc3VwcG9ydCBib3RoIDRyZC11IGFuZCBOQVQ2NC4gV2hlbiBhIEJS IHJlY2VpdmVzIGEgdHVubmVsIHBhY2tldCwgaG93IGNhbiBpdCBkaXN0aW5ndWlzaCB0aGUgcGFj a2V0IGlzIGEgNHJkIHBhY2tldCBzbyB0aGF0IGl0IGNhbiBwZXJmb3JtIHRoZSA0cmQgcHJvY2Vk dXJlLCBvciBhIE5BVDY0IHBhY2tldCBzbyB0aGF0IGl0IGNhbiBwZXJmb3JtIHRoZSBOQVQ2NCBw cm9jZWR1cmU/IEFuZCBkb2VzIHRoZSBOQVQ2NCBwcm9jZWR1cmUgc3RpbGwgdGhlIHRyYWRpdGlv bmFsIG9uZT8NCg0KMykgSXMgdGhlcmUgYW55IHBvc3NpYmlsaXR5IHRoYXQgYSBDRSBjb250YWlu cyBib3RoIEJSIG1hcHBpbmcgcnVsZSBhbmQgTkFUNjQrIG1hcHBpbmcgcnVsZT8NCg0KNCkgWW91 IG1lbnRpb25lZCB0aGUgcHJvY2VzcyB0byBkZWFsIHdpdGggYSAgdW5zcGVjaWZpZWQgSVB2NCBh ZGRyZXNzIGZvcm1hdCBpbiBTZWN0aW9uIDQuNC4gSG93IHRoZSBCUihOQVQ2NCspIGRlYWwgd2l0 aCBzdWNoIGEgcGFja2V0Pw0KDQpBbm90aGVyIGNvbW1lbnQ6IGl0IHdvdWxkIGJlIGJldHRlciB0 byB1bmRlcnN0YW5kIHRoZSBkcmFmdCBpZiB5b3UgY2FuIHB1dCBzb21lIGNvbXBsZXRlIGRhdGEg cGxhbiBwcm9jZWR1cmVzIGluIHRoZSBleGFtcGxlIHNlY3Rpb24uDQoNClJlZ2FyZHMhDQoNCg0K DQoNCkppYW5nIERvbmcNClRzaW5naHVhIFVuaXZlcnNpdHk= ------=_001_NextPart788602822065_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi, Remi,
 
I get some questions about the 4rd-u draft.
 
1) The "tunnel packet" defined in your draft includes an IP= v6=20 header followed by a IPv6 fragmentation. Can this packet be defined as a t= unnel=20 packet or a translation packet or neither or both? Since this is not the=20 traditional tunneling packet format, I'm not sure still using "tunnel pack= et" is=20 a good idea.
 
2) You mentioned NAT64+ which is upgraded to support both 4rd-u and N= AT64.=20 When a BR receives a tunnel packet, how can it distinguish the packet is a= 4rd=20 packet so that it can perform the 4rd procedure, or a NAT64 packet so that= it=20 can perform the NAT64 procedure? And does the NAT64 procedure still the=20 traditional one?
 
3) Is there any possibility that a CE contains both BR mapping rule a= nd=20 NAT64+ mapping rule?
 
4) You mentioned the process to deal with a  unspecified IPv4 ad= dress=20 format in Section 4.4. How the BR(NAT64+) deal with such a packet?
 
Another comment: it would be better to understand the draft if you ca= n=20 put some complete data plan procedures in the example section.
 
Regards!
 
Jiang Dong
Tsinghua University
 
------=_001_NextPart788602822065_=------ From fibrib@gmail.com Mon Mar 26 06:48:40 2012 Return-Path: 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 DEE4C21E8013 for ; Mon, 26 Mar 2012 06:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 3L+64rP6PvTc for ; Mon, 26 Mar 2012 06:48:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B622521E809B for ; Mon, 26 Mar 2012 06:48:39 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3818434qcs.31 for ; Mon, 26 Mar 2012 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dc6o3NH43HqjYTgOwMUyGeFj3c83QKOCLsS1/zUwo80=; b=oC8NbayMSyKLFHzMwn35BRKdok9B+dMDyDdmo2E8yCDG3k3f3qUPALVAin4BpXIa1I swIG7jHQxqms5N5dSnMfeFbQNMmL/nntgeT5Ez6pJ51W2XQGzH+NInP7Uu/m+jLpIvWn iTj0oYFDCamPxixdU8JdUn8hK48k0+g4FASEUjS9I3ow9F00NQMHpwqw6/FRkeDmFkor lmMFZPYvq25jEKZgVHbT9ojXK6RoJGPGa4sMVot3L7AtNP74hYHJBhnb+6w2jFb3x752 dNJQoGBat5Eziusv0ophYQU2hwb5aGRaGmMAU+SJFeNQK5vq1VSp/t0qf1iockcsYP1p Mf3g== MIME-Version: 1.0 Received: by 10.224.111.19 with SMTP id q19mr11751744qap.24.1332769719212; Mon, 26 Mar 2012 06:48:39 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 26 Mar 2012 06:48:39 -0700 (PDT) Date: Mon, 26 Mar 2012 22:48:39 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074d218ae5a0e04bc25a196 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:48:41 -0000 --20cf3074d218ae5a0e04bc25a196 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, i think you won't be against if i change the subject of this specific discussion, focusing on the routing issues regarding virtual link. 2012/3/26 R=E9mi Despr=E9s > Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) woul= d >> give substance to this claim. >> Open to look at it. >> > > in my personal experience i could give you at least three quick examples > of the use case for the building block of "virtual link": > > first example, if the IPv4 customer network plays BGP over IPv4 with the > provider, through the BGP session between CE and BR, a virtual link is > desired. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv= 4 > world) > > > I don't see in this scenario why anything that works with E (i.e. between > CEs and BRs) wouldn't also work with U. > > by default, ebgp requires direct link (some implementations specify TTL =3D= 1 to achieve this). U decreases TTL when packet goes through IPv6 cloud, and therefore CE---BR ebgp session cannot be established with regular BGP configurations. > second example, there are dynamic routing protocols like RIP running in > the following (multihoming) topology for IPv4 routing. the operator may > want to treat the CE-BR as a single hop in order the virtual link is > considered the distance vector calculation. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv= 4 > world) > \ / > \ / > +------------ CE ----(Another, IPv4 domain)----------+ > > > Same comment. > > similar misunderstanding. RIP distance vectors are delivered to neighbors but the operators are easy to be confused by the fact that CE---BR are shown as multihop with tools like traceroute. > > > third example, same topology as above but OSPF are applied, and OSPF > TTL-security check are enabled to ensure hop-passings less than a specifi= ed > threshold. if the operator would like to treat CE---(IPv6-only domain)---= BR > as one hop because it is considered as virtual link, 4rd-u's rudiness in > decreasing TTL will hurt. > > > Same comment. > > same misunderstanding. without knowing the details of the IPv6 domain backbone, it is difficult for the operator to set up a proper value of the TTL-security parameter for the OSPF regarding the CE---BR section. virtual link (full encapsulation) eliminates this trouble. > > > MAP-E (and other E) surely has no limitation in supporting any features o= f > existing routing protocols. > > > Why U would be less transparent between CEs and BRs than E for any L4 > protocol remains unexplained. > > hope the above helps. it is not about the transparency but about the behavior of virtual link. it is not about any L4 protocol but about routing protocols. > > > > with at least the above three examples, i conclude "U cannot replace E at > all"! > > > See above. > > see above. - maoke > > > (btw, surely the translation has the same limitation not to support the > above features but, e.g., as you also said, it opens transport-layer stuf= f > to the middle boxes). therefore i said operators may use either > encapsulation or translation according to what they attach importance to.= ) > > --20cf3074d218ae5a0e04bc25a196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
dear Remi,
=A0
i think you won't= be against if i change the subject of this specific discussion, focusing o= n the routing issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>
Different understanding.
An detailed E use case that cannot be supported by U=A0(if it exists)=A0wo= uld give substance to this claim.
Open to look at it. =A0

in my personal experience i could give you at least three qu= ick examples of the use case for the building block of "virtual link&q= uot;:=A0

first example, if the IPv4 customer netwo= rk plays BGP over IPv4 with the provider, through the BGP session between C= E and BR, a virtual link is desired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
<= br>
I don't see in this scenario why anything tha= t works with E (i.e. between CEs and BRs) wouldn't also work with U.
=A0
=A0
by default, ebgp = requires direct link (some implementations specify TTL =3D 1 to achieve thi= s). U decreases TTL when packet goes through IPv6 cloud,=A0and therefore CE= ---BR ebgp=A0session cannot be established=A0with=A0regular=A0BGP configura= tions.
second example, t= here are dynamic routing protocols like RIP running in the following (multi= homing) topology for IPv4 routing. the operator may want to treat the CE-BR= as a single hop in order the virtual link is considered the distance vecto= r calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

Same= comment.
=A0
=A0
si= milar misunderstanding. RIP distance vectors are delivered to neighbors=A0b= ut the operators are easy to be confused by the fact that CE---BR are shown= as=A0multihop with tools like traceroute.
=A0
=A0
third example, same topology as above but OSPF are applied, and = OSPF TTL-security check are enabled to ensure hop-passings less than a spec= ified threshold. if the operator would like to treat CE---(IPv6-only domain= )---BR as one hop because it is considered as virtual link, 4rd-u's rud= iness in decreasing TTL will hurt.=A0

Same comment.
=A0
=A0
same misunderstanding. with= out knowing the details of the IPv6 domain backbone, it is difficult for th= e operator to set up a proper value of the TTL-security parameter for the O= SPF regarding the CE---BR section. virtual link (full encapsulation) elimin= ates this trouble.
=A0
=A0

MAP-E (and other E) surely has no limitation in supporting any feature= s of existing routing protocols.

Why U would be less transparent between CEs and BRs than E fo= r any L4 protocol remains unexplained.
=A0
=A0
hope the ab= ove helps. it is not about the transparency but about the behavior of virtu= al link. it is not about any L4 protocol but about routing protocols.
=A0
=A0
=A0
with at least the above three examples, i con= clude "U cannot replace E at all"!

See above.
=A0
=A0
see above.
=A0
- maoke
=A0
=A0

(btw,= surely the translation has the same limitation not to support the above fe= atures but, e.g., as you also said, it opens transport-layer stuff to the m= iddle boxes). therefore i said operators may use either encapsulation or tr= anslation according to what they attach importance to.)=A0
--20cf3074d218ae5a0e04bc25a196-- From sunqi.csnet.thu@gmail.com Mon Mar 26 06:51:50 2012 Return-Path: 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 6B2CD21E809A for ; Mon, 26 Mar 2012 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 KTlywNfdFiKc for ; Mon, 26 Mar 2012 06:51:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B52D21E8013 for ; Mon, 26 Mar 2012 06:51:48 -0700 (PDT) Received: by yhkk25 with SMTP id k25so4178165yhk.31 for ; Mon, 26 Mar 2012 06:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=STAHQRQ9mz39lwHNH8AcNzsncMTYTcRcsx9hUzacnoo=; b=ihVzjrBlj6uO1XFKcN/woiVZcMHgbl1vwignJfbqYxZ3oDev/d85dkumtG8KDMYtRl 8Q8xjXxPG+nuBlRVueeYt29/w/JIhZCfjHrB5Q2h34LxcjGicYEBnWqDIePat5tu0f5B pgkHX/wXR46cCKNdknDRDueUPIlMDoVXUpMVPl2l3nzYOgy3/0QFKcIi45YP195+4lH0 QhsxI9IBDZf8eYSAsLkPY608Zq7UWzCaXr3ndB2Vwb25RUcbr6pxDVLZzpTBNIsChIs2 1+PGKjlk7myHEjqk/u1HkveZ+IqS4MaqqNU6FHO86RByCH5AEuUIfHq//E7ds0nq781b BeKQ== Received: by 10.50.189.129 with SMTP id gi1mr5609721igc.16.1332769907668; Mon, 26 Mar 2012 06:51:47 -0700 (PDT) Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id vr4sm23307851igb.1.2012.03.26.06.51.42 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 06:51:46 -0700 (PDT) Date: Mon, 26 Mar 2012 21:51:37 +0800 From: "Qi Sun" To: "Francis Dupont" , "Yong Cui" References: <201203252144.q2PLibT4072543@givry.fdupont.fr> X-Priority: 3 X-GUID: 09AE89EA-C057-4E38-ABFA-2FFB7B4B43FC X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012032621513703068417@gmail.com> Content-Type: multipart/mixed; boundary="----=_001_NextPart810142667706_=----" Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:51:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart810142667706_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart524477317670_=----" ------=_002_NextPart524477317670_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmNpcywNCiAgICAgIGkgd29yayBvdXQgYSB0b3BvbG9neSBvZiB5b3VyIHN5c3RlbSBh Y2NvcmRpbmcgdG8geW91ciBkZXNjcmlwdGlvbiwgYW5kIGhvcGVzIHRvIGhlbHAgdGhvc2Ugd2hv IGNhbid0IG1ha2UgaXQgdG8geW91ciBkZW1vIHdpdGggYSBxdWljayB1bmRlcnN0YW5kaW5nIG9m IHRoZSBzeXN0ZW0uDQogICAgICBQbGVhc2UgY29ycmVjdCBtZSBpZiBpJ20gbWlzc2luZyBhbnl0 aGluZyBvciBtaXN1bmRlcnN0YW5kaW5nIHlvdXIgcG9pbnRzLg0KICAgICBUaGUgYXR0YWNobWVu dCBpcyB0aGUgdHh0IHZlcnNpb24gb2YgdGhlIHRvcG9sb2d5LCBlZGl0aW5nIHdpdGggVWx0cmFF ZGl0Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQpMb29raW5nIGZvcndhcmQgdG8geW91ciByZXBseX4NCg0KUFM6IFZlcnkgc29ycnkgZm9y IGZhaWxpbmcgdG8gc2VuZCBvdXQgb2YgdGhlIGVhcmx5IGVtYWlsIGJlY2F1c2Ugb2YgIG1pcy1v cGVyYXRpb24uICANCg0KQmVzdCBSZWdhcmRzIQ0KDQoNCg0KDQpRaSBTdW4NCg0KRnJvbTogRnJh bmNpcyBEdXBvbnQNCkRhdGU6IDIwMTItMDMtMjYgMDU6NDQNClRvOiBZb25nIEN1aQ0KQ0M6IHNv ZnR3aXJlczsgZmR1cG9udA0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIERlbW8gb2YgZHJhZnQt cGVubm8tc29mdHdpcmUtc2RuYXQtMDIgLS0gU3VuZGF5IDI1dGggZnJvbSAxNWgzMCB0byAxN2gw MCByb29tICMyMDEgYXQgSUVURiBpbiBQYXJpcw0KIEluIHlvdXIgcHJldmlvdXMgbWFpbCB5b3Ug d3JvdGU6DQoNCj4gIFRoYW5rcyBmb3IgdGhlIGRlbW8uDQo+ICBXb3VsZCB5b3UgcGxlYXNlIGFs c28gZ2l2ZSBhIHN1bW1hcnkgdG8gdGhlIG1haWxpbmcgbGlzdCwgZXNwZWNpYWxseSBmb3INCj4g IHNvbWVvbmUgd2hvIGNhbm5vdCBqb2luIHRoZSBkZW1vLg0KDQo9PiB3ZSBzZXR1cCBhIFNELUFG VFIgYW5kIGEgcGFpciBvZiBTRC1CNHMgKG9uZSBOZXRnZWFyIFdORFIzODAwDQphbmQgb25lIGxh cHRvcCkgYW5kIGEgY2xpZW50IGF0dGFjaGVkIHRvIG9uZSBvZiB0aGUgU0QtQjRzIHdpdGg6DQog LSBjb25uZWN0aW9uIGZyb20gdGhlIGNsaWVudCB0byB0aGUgSW50ZXJuZXQNCiAtIGNvbm5lY3Rp b24gZnJvbSB0aGUgSW50ZXJuZXQgdG8gdGhlIGNsaWVudCB1c2luZyBhIHBvcnQgcmV0dXJuZWQN CiAgYnkgUENQIChzZXJ2ZXIgcnVubmluZyBvbiBhIFNELUI0KQ0KIC0gcmVwbGFjZW1lbnQgb2Yg YSBTRC1BRlRSIGJ5IGEgc3BhcmUgU0QtQUZUUiB3aXRoIHRoZSBzYW1lIGNvbmZpZw0KICAoYnV0 IHdpdGhvdXQgZHluYW1pYyBzdGF0ZSBzaGFyaW5nKTogY29ubmVjdGlvbnMgc3RpbGwgYWxpdmUs IGluDQogIGZhY3QgaWYgeW91IGRvbid0IHRha2UgY2FyZSBvZiB0aGUgcGFja2V0cyBsb3N0IGR1 cmluZyB0aGUgbWFudWFsDQogIG9wZXJhdGlvbiBpdCBpcyByZWFsbHkgdHJhbnNwYXJlbnQNCiAt IHdlIGhhZCBub3QgZW5vdWdoIHRpbWUgdG8gZmluaXNoIHRoZSBESENQIGNsaWVudCBjaGFpbmlu Zw0KICAoaW4gdGhlb3J5IHRoZSBESENQdjYgY2xpZW50IGNvbmZpZ3VyZXMgdGhlIElQdjQtb3Zl ci1JUHY2IHR1bm5lbA0KICAgYW5kIGxhdW5jaGVzICBhIERIQ1B2NCBjbGllbnQgICBhbmQgQ1JB IHBhaXIsIHdoaWNoIGNvbmZpZ3VyZQ0KICAgdGhlIElQdjQgcGFydCBpbmNsdWRpbmcgdGhlIHBv cnQgcmFuZ2UpDQogLSBub3IgdGhlIElDTVAgMy8xMyBoYW5kbGluZyBvbiB0aGUgU0QtQjQgKHJl bmV3IHRoZSBESENQdjQgbGVhc2UpLg0KIC0gbm9yIGEgdGhpcmQgV05EUjM3MDB2MiBTRC1CNCAo c2hvdWxkIGJlIHRoZSBzYW1lIHRoYW4gdGhlIFdORFIzODAwDQogIG9uZSwgYW5kIHdlIGRpZG4n dCBhc2sgdmlzaXRvcnMgdG8gcHJvdmlkZSBleHRyYSBjbGllbnRzKQ0KDQpSZWdhcmRzDQoNCkZy YW5jaXMuRHVwb250QGZkdXBvbnQuZnINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_002_NextPart524477317670_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Francis,
      i work out a topology of your system=20 according to your description, and hopes to help those who can't make it t= o your=20 demo with a quick understanding of the system.
      Please correct me if i'm missing anyth= ing or=20 misunderstanding your points.
     The attachment is the txt version of the top= ology,=20 editing with UltraEdit.
           &nb= sp;            = ;            &= nbsp;           &nb= sp;     
Looking forward to your reply~
 
PS: Very sorry for failing to se= nd out=20 of the early email because of  mis-operation. 
 
Best Regards!
 
Qi Sun
 
Date: 2012-03-26 05:44
CC: softwires; = fdupont
Subject: Re: [Softwires] Demo of draft-penno-softwire-sdn= at-02=20 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris
<= /DIV>
 In your previous mail you wrote:
 
>  Thanks for the demo.
>  Would you please also give a=  summary to the mailing list, especially&nbs= p;for
>  someone who cannot join the = demo.
 
=3D> we setup a SD-AFTR and a p= air of SD-B4s (one Netgear WNDR3800
and one laptop) and a client attached&n= bsp;to one of the SD-B4s with:
 - connection from the client to t= he Internet
 - connection from the Internet to = ;the client using a port returned
  by PCP (server running on a = ;SD-B4)
 - replacement of a SD-AFTR by a&n= bsp;spare SD-AFTR with the same config
  (but without dynamic state sharing):&= nbsp;connections still alive, in
  fact if you don't take care = ;of the packets lost during the manual
  operation it is really transparent
 - we had not enough time to = finish the DHCP client chaining
  (in theory the DHCPv6 client con= figures the IPv4-over-IPv6 tunnel
   and launches  a DHCPv4 client=20   and CRA pair, which configure
   the IPv4 part including the&nbs= p;port range)
 - nor the ICMP 3/13 handling on&n= bsp;the SD-B4 (renew the DHCPv4 lease).
 - nor a third WNDR3700v2 SD-B4 (s= hould be the same than the WNDR3800
  one, and we didn't ask visitors&= nbsp;to provide extra clients)
 
Regards
 
Francis.Dupont@fdupont.fr
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_002_NextPart524477317670_=------ ------=_001_NextPart810142667706_=---- Content-Type: application/octet-stream; name="Topology.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Topology.txt" DQoNClRvcG9sb2d5DQoNCiAgICAgICAgICAJCQkJCQkJCQkJCQkJCQkJCQkJCQkJIA0KICAgICAg ICAgICAgIFBDUCBQb3J0ICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgIA0KICstLS0t LS0tLSsgICAgYWxsb2MuICB8ICAgICAgICAgICAgICB8CQkJCQkJCQkgDQogfCBDbGllbnQgfDwt LS0tLS0tLS0tLXwgICBTRC1CNCAgICAgIHwgICBUdW5uZWxpbmcgICAgCQkrLS0tLS0tLS0tLS0t LS0tLS0tKw0KIHwgICAgICAgIHwtLS0tLS0tLS0tLS18ICYgUENQIHNlcnZlciB8LS0tLS0tLS0t LS0tLS0tLS0tLXwJCSAgICAJCQkJCSB8DQogKy0tLS0tLS0tKyAgV2lyZWxlc3MgIHwgIChXTkRS MzgwMCkgIHwgICAgICAgICAgICAgICAgCQl8ICAgICBTRC1BRlRSICAgICAgfCAgICAgKy0tLS0t LS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCBESENQdjQg b3ZlciB2NiAJCXwgICZESENQdjQgc2VydmVyICB8ICAgICB8ICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rPD09PT09PT09PT09PT09PT09PnwgIAkJ CQkJCQkgICB8ICAgICB8ICAgIElQdjQgICAgfA0KCQkJCQkJCQkJCQkJCQkJCQkJCSA8PT09PT09 PT09PT09PT09PT0+fCcnJycnJycnJycnJycnJycnJ3wtLS0tLXwgIEludGVybmV0ICB8DQogICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgSUNNUCBmb3IgcG9ydCBzZXQgfCAg U3BhcmUgU0QtQUZUUiAgIHwgICAgIHwgICAgICAgICAgICB8DQoJCQkJCQkJCQkJCSB8ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIAkJfCAgKFNhbWUgY29uZmlnLCAgIHwgICAgIHwgICAg ICAgICAgICB8DQoJCQkJCQkJCQkJCSB8ICAgIFNELUI0ICAgICB8LS0tLS0tLS0tLS0tLS0tLS0t LXwgIE1hbnVhbGx5IHNoaWZ0KSB8ICAgICArLS0tLS0tLS0tLS0tKw0KCQkJCQkJCQkJCQkgfCAg IChsYXB0b3ApICAgfAkJVHVubmVsaW5nICAgIAkJfCAgICAgICAgICAgICAgICAgIHwNCgkJCQkJ CQkJCQkJIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLSsNCgkJCQkJCQkJCQkJICstLS0tLS0tLS0tLS0tLSsJCQkJCQkJCQkJDQoNCg0KDQoNCg== ------=_001_NextPart810142667706_=------ From jiangdong345@gmail.com Mon Mar 26 06:59:31 2012 Return-Path: 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 0C63921F8606 for ; Mon, 26 Mar 2012 06:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 apBT892sR2mb for ; Mon, 26 Mar 2012 06:59:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2A21E8013 for ; Mon, 26 Mar 2012 06:59:26 -0700 (PDT) Received: by ggmi1 with SMTP id i1so4223380ggm.31 for ; Mon, 26 Mar 2012 06:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=5cgMovcSP0nrz55vF4nAtri3bMOPJMUSI/ofmnYu0Iw=; b=dnzpxFZX8ft+aL4Qn1fBcIX5QrzpIca1kwVjwENiqajCyAAX1ZAwElO7P0UNszX2Ti E1TNr2nuyCXdExzBJ0dZeTvVca7lz977jVyhImPvRLSvGHHH/xotYRB9Qhd8V1JtCiqo V4JwUh/LscBY46autS0nL40Xr4ymUGhgGGuSxJCEroccxJzZUpGkUjz+/MAlwjPk0sQ8 XNXU93QRV9FlTgl2AP8L1xyZgPM6EDJtKFPhe8F/bDnWDWIf/SCepIa2UvgP7qnx1Taw yAXMTILoX+KRRTfgI46uqafycsPGOW3LgAp7n2DTiA0d1rYx2u9cN5p2rB7PksP5IeTF qYtw== Received: by 10.50.219.194 with SMTP id pq2mr5785961igc.18.1332770364591; Mon, 26 Mar 2012 06:59:24 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id i6sm14777091igq.3.2012.03.26.06.59.19 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 06:59:24 -0700 (PDT) Date: Mon, 26 Mar 2012 21:59:21 +0800 From: "Jiang Dong" To: cai.lei3 , jacni , shtsuchi References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> X-Priority: 3 X-GUID: F232EEC0-A5F5-4C2A-82ED-C16C3FF5572F X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012032621591809758988@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart164288665453_=----" Cc: Softwires WG , Cui Yong Subject: [Softwires] Comments about 6rd MIB X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:59:31 -0000 This is a multi-part message in MIME format. ------=_001_NextPart164288665453_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIGF1dGhvcnMgb2YgNnJkIE1JQiwNCg0KSSBnZXQgc29tZSBjb21tZW50cyBhYm91dCA2cmQg TUlCIGRyYWZ0Lg0KDQoxKSBZb3UgbWVudGlvbmVkIHRoZSAidHVubmVsSWZYVGFibGUiIGluIHNl Y3Rpb24gNS4yLiBJIHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGV4dGVuZCB0aGUgdHVubmVs IE1JQiwgc29tZSBzY2VuYXJpbyBjYW5ub3QgYmUgaW5jbHVkZWQgaW4gUkZDNDA4Nywgc3VjaCBh cyBwb2ludCB0byBtdWx0aS1wb2ludCB0dW5uZWwgbGlrZSBzb2Z0d2lyZSBtZXNoLg0KDQoyKSBJ dCBzZWVtcyB5b3UgbWlzcyB0aGUgY29uZm9ybWFuY2UgcGFydCBpbiB0aGUgZGVmaW5pdGlvbi4N Cg0KMykgSSdtIG5vdCBxdWl0ZSBzdXJlIHdoYXQncyB0aGUgInNpeFJkSXB2NE1hc2tMZW4gIiB1 c2VkIGZvciwgY2FuIHlvdSBleHBsYWluIGl0Pw0KDQpSZWdhcmRzIQ0KDQoNCg0KSmlhbmcgRG9u Zw0KVHNpbmdodWEgVW5pdmVyc2l0eQ== ------=_001_NextPart164288665453_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, authors of 6= rd=20 MIB,
 
I get s= ome=20 comments about 6rd MIB draft.
 
1) You=20 mentioned the "tunnelIfXTable" in section 5.2. I think it is a good idea t= o=20 extend the tunnel MIB, some scenario cannot be included in RFC4087, such a= s=20 point to multi-point tunnel like softwire mesh.
 
2) It s= eems you=20 miss the conformance part in the definition.
 
3) I'm = not=20 quite sure what's the "sixRdIpv4MaskLen " used for, can you explain=20 it?
 
Regards!
Jiang Dong
Tsinghua=20 University

------=_001_NextPart164288665453_=------ From shtsuchi@cisco.com Mon Mar 26 07:19:17 2012 Return-Path: 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 0B3EB21E8096 for ; Mon, 26 Mar 2012 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 0MAcJSAt8JGp for ; Mon, 26 Mar 2012 07:19:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B421E8013 for ; Mon, 26 Mar 2012 07:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2697; q=dns/txt; s=iport; t=1332771555; x=1333981155; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0eGJjMYwmGq8U22WjURX8N+iKZDq5j8fL/0GHUG4XaQ=; b=Vu4+rrOxzJegitbBG9HOdgn2+nlDtdZbqJhqcmGpVr5DawwwDhGnTgFd G44hD/uqP4tgkoh1qHxYcqDdzit01Pe4cbhtEq+rJsXrBEw1Hh84kwvzg wAbfa8rtWCgft8V6XSU6uqB7qguulpXT4N+8bf8sMEPI5/HOQbAsZoqvn U=; X-IronPort-AV: E=Sophos;i="4.73,650,1325462400"; d="scan'208";a="133373011" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2012 14:19:14 +0000 Received: from [10.55.81.69] (dhcp-10-55-81-69.cisco.com [10.55.81.69]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2QEJDjQ007612; Mon, 26 Mar 2012 14:19:14 GMT Message-ID: <4F707AE1.2000802@cisco.com> Date: Mon, 26 Mar 2012 16:19:13 +0200 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: jiangdong345@gmail.com References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> <2012032621591809758988@gmail.com> In-Reply-To: <2012032621591809758988@gmail.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: cai.lei3@zte.com.cn, softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: Re: [Softwires] Comments about 6rd MIB X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:19:17 -0000 Jiang Thanks for comments. I will do presentation this draft at Friday,and I will ask which idea is better to the audience and chairs. If IP tunnel MIB extended is better than 6rdMIB,so we would update and define extension of IP tunnel MIB. 6rd MIB is completely reflecting to 6rd configuration. http://tools.ietf.org/html/rfc5969#section-7 "sixRdIpv4MaskLen " is same function as IPv4MaskLen. IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits, IPv4MaskLen is 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (e.g., the Private IPv4 address range 10.0.0.0/8 is being used), IPv4MaskLen is equal to 8 and IPv4MaskLen high-order bits are stripped from the IPv4 address before constructing the corresponding 6rd delegated prefix. Regards, -Shishio (2012/03/26 15:59), Jiang Dong wrote: > Hi,authors of 6rd MIB, > I get some comments about 6rd MIB draft. > 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is a good idea to extend the tunnel MIB, some scenario cannot be included in RFC4087, such as point to multi-point tunnel like softwire mesh. > 2) It seems you miss the conformance part in the definition. > 3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can you explain it? > Regards! > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Jiang Dong > Tsinghua University > From sarikaya2012@gmail.com Mon Mar 26 08:30:41 2012 Return-Path: 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 81F5C21E80BB for ; Mon, 26 Mar 2012 08:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ngbpjKVRk8BM for ; Mon, 26 Mar 2012 08:30:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC821E80C2 for ; Mon, 26 Mar 2012 08:30:39 -0700 (PDT) Received: by iazz13 with SMTP id z13so9927775iaz.31 for ; Mon, 26 Mar 2012 08:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=gE7ygqDR71jIemwXtJyDaSesFLxWDbezrtBZknCxcZM=; b=Uv0nRAPznivu997eVucMwCGnGshqT69YnCbxgpA8O24O2u+5++MHP3Wn32noiKZOAr t+NKjn9zaQW5kMy9OK+GcECZtsl/jxWrZSWFW23L9xU9kL12MHMDwxxYTczkvMy6/z72 ckbeX7GmR0xOlTgLWny7AXLzFXVyaRr3rgGHgBdBFPg1zo6SJEMoZdHOLVtFHA/kEzBj U+6T4jGCcwf7PAYGSIarYnc6+WIlx7Yoyu80b1LUY7KeZau5MIIQ+zeOrxM6xEAuPcfY mCsfOqpF85HF5g3zf6iBx+Zyeg2EQBAnYIi1nLGjWtAKYJBSVNvUYS/zScstGyj5Ww+G H+0A== MIME-Version: 1.0 Received: by 10.43.52.74 with SMTP id vl10mr12976162icb.55.1332775834278; Mon, 26 Mar 2012 08:30:34 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Mon, 26 Mar 2012 08:30:34 -0700 (PDT) In-Reply-To: <20120326131032.32303.84986.idtracker@ietfa.amsl.com> References: <20120326131032.32303.84986.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 10:30:34 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] Fwd: New Version Notification for draft-sarikaya-softwire-6rdmulticast-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:30:41 -0000 A new version of I-D, draft-sarikaya-softwire-6rdmulticast-03.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. This version covers both AMT and translation based multicast for 6rd. Filename: =A0 =A0 =A0 =A0draft-sarikaya-softwire-6rdmulticast Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 Multicast Support for 6rd Creation date: =A0 2012-03-25 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 16 Abstract: =A0 This memo specifies 6rd's multicast component so that IPv6 hosts ca= n =A0 receive multicast data from IPv6 servers. =A0In AMT based encapsulation =A0 solution, AMT Gateway at the 6rd Customer Edge router uses AMT =A0 protocol to establish a tunnel interface with AMT Relay at the 6rd =A0 Border Relay and this tunnel is used to exchange MLD messages to =A0 establish multicast state at AMT Relay so that AMT Relay can tunnel =A0 IPv6 multicast data to IPv6 hosts connected to AMT Gateway. =A0In 6rd =A0 Translation Multicast based solution, the protocol is based on =A0 proxying MLD at the 6rd Customer Edge router and then translating MLD =A0 messages to IGMP messages and sending them upstream to a network =A0 which supports IPv4 multicast. 6rd Border Relay is multicast router =A0 and IGMP-MLD translator. =A0It translates IGMP join back to MLD join =A0 message and sends it to multicast source. =A0IPv6 Multicast data =A0 received at 6rd Border Relay is translated into IPv4 multicast data =A0 and then sent to IPv4 multicast tree downstream to 6rd Customer Edge =A0 which translates back to IPv6 multicast data then delivers to the =A0 hosts. The IETF Secretariat From wdec.ietf@gmail.com Mon Mar 26 09:42:52 2012 Return-Path: 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 99B8021E80CF for ; Mon, 26 Mar 2012 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 pQE9r5gaMk9h for ; Mon, 26 Mar 2012 09:42:50 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7C21E80BE for ; Mon, 26 Mar 2012 09:42:47 -0700 (PDT) Received: by qadc14 with SMTP id c14so2322708qad.10 for ; Mon, 26 Mar 2012 09:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GynvDEjMmxy2efl7hghVzXmB8ZudwokAbR7o6DWnQTw=; b=B/bl46s13V1NHnTXfvNp4vBzK8Ana6u6s9sfaRxtmxq7hPF5H/JKxmWl9kPB++m8VU H5YUdGF8gfK67voXlantaH+waHKYizUGc6/qSeSpYl3XaS4EuWBjFLTwL3RYRK0tMy0S ++VeOKGNGOybOw+HyGA0QlV5OOsxWc8wg55TpX0+KW87Y8o4fj8PGaigi3+79AbW3CdH fiq+mRUGFlj6EBIP5DXNottPzg/wDDLWKL3aju0j26t9xlCJbS7sVoshLJsLbWD0sh1L EpszpxD1lXt854mQXYW3yyp8xKKvfWsLs+PX7j6qbucrfxvn29iXsUkq+tC0/uwifvTC 8IMQ== MIME-Version: 1.0 Received: by 10.224.213.7 with SMTP id gu7mr2725255qab.25.1332780166904; Mon, 26 Mar 2012 09:42:46 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Mon, 26 Mar 2012 09:42:46 -0700 (PDT) In-Reply-To: <2BF534DB-3665-4FB4-B7AC-335B9FCA92EB@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> <2BF534DB-3665-4FB4-B7AC-335B9FCA92EB@laposte.net> Date: Mon, 26 Mar 2012 18:42:46 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300fb109697c7b04bc281034 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:42:52 -0000 --20cf300fb109697c7b04bc281034 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 March 2012 13:34, R=E9mi Despr=E9s wrote: > > Le 2012-03-26 =E0 11:08, Wojciech Dec a =E9crit : > > With the checksum re-computed, as per the rfc6145 option, translated IPv6 > packets would get the right checksum. With 4rd-u so far I see no such > option. > > > Are you saying that, when original IPv4 packets have null UDP > checksums, MAP-T would REQUIRE CEs and BRs to recompute UDP checksums of > complete packets? > This would certainly prevent packets containing fragments to be forwarded > on the fly, and would therefore have performance implication. > The fragmented packet case is not what I'm referring to, but rather, the case where regular unfragmented IPv4 UDP checksum 0 packets are sent. As per rfc6145, the checksum recalculation of such packets is allowed. > > In any case, this is not specified yet (one more open issue of the MAP se= t > of documents). > There doesn't seem to be a need to do that as it's already specified in rfc6145. -Woj. > > RD > > > > -Woj. > > On 23 March 2012 14:55, R=E9mi Despr=E9s wrote= : > >> Hi, Wojciech, >> >> Are you suggesting that T would work with IPv4 packets having UDP >> checksum =3D 0? >> >> RFC6145 says that IPv4 packets with UDP checksum =3D 0 are either always >> discarded, or optionally discarded if not fragmented (with checksum >> recomputed if not discarded). >> I don't see: >> - how this would work with double translation >> - why anything should be added to U for checksum-less UDP (IPv6-only >> hosts don't support it anyway). >> >> Cheers, >> RD >> >> >> >> Le 2012-03-23 =E0 13:46, Wojciech Dec a =E9crit : >> >> >> >> On 19 March 2012 14:22, R=E9mi Despr=E9s wrot= e: >> >>> Hi, Xing, >>> >>> I look forward to face to face discussions in Paris if we don't clarify >>> everything before that (I will be busy on something else in the next 3 >>> days). >>> >>> >>> Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : >>> ... >>> >>> >>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE >>> node, when it receives no 4rd mapping rule, to exercise single translat= ion. >>> Actually, I believe that using for this the BIH of RFC6535 is both >>> sufficient and recommendable. >>> Translated IPv4 packets, because they are sent from CE nodes to DNS64 >>> synthesized addresses, are appropriately routed to their destinations. = (It >>> can be via the NAT64-CGN if needed, or via more direct paths if possibl= e.) >>> Anything missed? >>> >>> >>> Sorry, this is a misunderstanding. >>> Hint: Single translation and double translation are based on the same >>> mapping rule in the CERNET2 deployment. >>> >>> >>> I am well aware of this, but this doesn't explain why 4rd mapping rules >>> similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 >>> communication (single translation) supported". >>> >>> As said in RFC6219, CERNET hosts have their IPv6 addresses configured >>> "via manual configuration or stateful autoconfiguration via DHCPv6". >>> Hosts can therefore be assigned Interface IDs that have the 4rd-u >>> format (with V octet and CNP). >>> >>> Now, when both addresses happen to be checksum neutral, RFC6145 >>> translation doesn't modify L4 data, so that it doesn't matter whether t= he >>> DS node has used 4rd-u header mapping or single translation. >>> Thus, IPv6-only hosts can exchange packets with IPv4 applications of >>> 4rd CE nodes. >>> >> >> If those packets are UDP checksum 0, the IPv6 host would either need to >> be customized, or something else would need to changed/configured on the >> 4rd-u CE specifically to get that to work for specific IPv6 destinations= , >> while with MAP-t this would be transparent (and not require specific >> forwarding rules). >> >> -Woj. >> >> >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> >>> >>> >>> Regards, >>> >>> xing >>> >>> >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> >>> Regards, >>> >>> xing >>> >>> >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> >>> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >>> ... | | | | | >>> >>> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N = | >>> | | packets | | | | | >>> >>> suggest you rename to "IPv4 to IPv6 communication (single translation)= supported" >>> >>> >>> >>> (2) More clarification should be added here. I am not sure 4rd-H can >>> support single translation. >>> >>> (a) According to (1), 4rd-H does not perform header translation defined >>> by RFC6145. >>> >>> (b) In the softwire mailing list, it seems that 4rd-H cannot support >>> single translation. See the thread containing >>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.htmland= other posts. >>> >>> (c) If 4rd-H cannot support single translation, then "IPv6 web caches >>> work for IPv4 packets" requires special configurations, it cannot do IP= v6 >>> web caches for non 4rd-H packets. >>> >>> >>> ... >>> >>> (5) I would like to see the details of how 4rd-H handles ICMP and ICMP >>> error messages. In the softwire mailing list there were some discussion= s. See >>> the thread containing >>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.htmland= other posts.Please add >>> >>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>> >>> ... >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >> > > --20cf300fb109697c7b04bc281034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 26 March 2012 13:34, R=C3=A9mi Despr= =C3=A9s <d= espres.remi@laposte.net> wrote:

Le 2012-03-26 =C3=A0 11:0= 8, Wojciech Dec a =C3=A9crit :

With the checksum re-computed, as per the rfc6145 option, transla= ted IPv6 packets would get the right checksum. With 4rd-u so far I see no s= uch option.

Are you saying that,=C2=A0when original I= Pv4 packets have null UDP checksums,=C2=A0MAP-T would REQUIRE CEs and BRs t= o recompute UDP checksums of complete packets?=C2=A0
This would c= ertainly prevent packets containing fragments to be forwarded on the fly, a= nd would therefore have performance implication.

The fragmented packet case is not what I'm = referring to, but rather, the case where regular unfragmented IPv4 UDP chec= ksum 0 packets are sent. As per rfc6145, the checksum recalculation of such= packets is allowed.

In any case, this is not specified yet= (one more open issue of the MAP set of documents).

There doesn't seem to be a need to do that = as it's already specified in rfc6145.

-Woj.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

RD



-Woj.

On 23= March 2012 14:55, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net= > wrote:
Hi, Wojc= iech,

Are you suggesting that T would work with IPv4 pac= kets having UDP checksum =3D 0?

RFC6145 says that IPv4 packets with UDP checksum = =3D 0 are either always discarded, or optionally discarded if not fragmente= d (with checksum recomputed if not discarded).=C2=A0
I don't = see:
- how this would work with double translation
- why anything= should be added to U for checksum-less UDP =C2=A0(IPv6-only hosts don'= t support it anyway).

Cheers,
RD



Le 2012-03-23 =C3=A0 13:4= 6, Wojciech Dec a =C3=A9crit :



On 19 March 2012 14:22, R=C3=A9mi Despr= =C3=A9s <despres.remi@laposte.net> wrote:
Hi, Xing,

I look for= ward to face to face discussions in Paris if we don't clarify everythin= g before that (I will be busy on something else in the next 3 days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a =C3= =A9crit :
...

=C2=A0A key point is that 4rd doesn't prevent a=C2=A04rd-c= apable dual-stack CE node,=C2=A0when it receives no 4rd mapping rule, to exercise single translation.=C2=A0
=C2=A0Actually, I believe that using for this the BIH of RFC65= 35 is both sufficient and recommendable.
=C2=A0Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment.

I am well aware of this, but this=C2=A0doesn't explain= why 4rd mapping rules similar to those of CERNET2 wouldn't have, like = MAP-T, "IPv4 to IPv6 communication (= single translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 addresses config= ured "via manual configuration or stateful autoconfiguration via DHCPv= 6".
Hosts can therefore=C2=A0be assigned Interface IDs that have the 4rd-u format (w= ith V octet and CNP).
Now, when both addresses happen to b= e checksum neutral, RFC6145 translation doesn't modify L4 data, so that= it doesn't matter whether the DS node has used 4rd-u header mapping=C2= =A0or single translation.=C2=A0
Thus,=C2=A0IPv6-only hosts can exchange=C2=A0packets with IPv4 applications of 4rd CE nodes.=C2=A0

If those packets are UDP checksum 0, the IPv6 host wo= uld either need to be customized, or something else would need to changed/c= onfigured on the 4rd-u CE specifically to get that to work for specific IPv= 6 destinations, while with MAP-t this would be transparent (and not require= specific forwarding rules).

-Woj.
=C2=A0

Regards,
RD

=






=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
=C2=A0




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :=
... | | | | |
  |  5 | IPv6 web caches work for IPv4    =
    |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 com=
munication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.=C2= =A0 See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configuration= s, it cannot do IPv6 web caches for non 4rd-H packets.

...

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail= -archive/web/softwires/current/msg03324.html and other posts. Plea= se add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ?=
 |
...







______________________________= _________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires






--20cf300fb109697c7b04bc281034-- From Francis.Dupont@fdupont.fr Mon Mar 26 09:57:41 2012 Return-Path: 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 8310A21E8109 for ; Mon, 26 Mar 2012 09:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 Cs0tRf7KUK6q for ; Mon, 26 Mar 2012 09:57:40 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 984D821E80BE for ; Mon, 26 Mar 2012 09:57:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2QGvTDe046320; Mon, 26 Mar 2012 18:57:29 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203261657.q2QGvTDe046320@givry.fdupont.fr> From: Francis Dupont To: "Lee, Yiu" In-reply-to: Your message of Tue, 20 Mar 2012 15:39:29 GMT. Date: Mon, 26 Mar 2012 18:57:29 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:57:41 -0000 In your previous mail you wrote: > Today, if a user generates a packet using an illegal IPv4 source address, > what would we do? We could drop the packet silently by doing > source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should > drop the packet silently. => it is a bit different in this case because it is not an illegal port but a misconfigured port. I agree to drop junk packets but for misconfed it is better to send an ICMP 3/13 (unreachable / admin prohibited) by default with a knob to silently drop (in the case you believe there should not be misconfed, for instance because you froze the config 6 month ago). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 26 10:00:30 2012 Return-Path: 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 80ADC21E8110 for ; Mon, 26 Mar 2012 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] 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 G7OEkN0I4WEE for ; Mon, 26 Mar 2012 10:00:29 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 3222D21E80BE for ; Mon, 26 Mar 2012 10:00:29 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2QH0P5T046561; Mon, 26 Mar 2012 19:00:25 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203261700.q2QH0P5T046561@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Tue, 20 Mar 2012 17:05:41 +0100. <94C682931C08B048B7A8645303FDC9F36E285583EB@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 26 Mar 2012 19:00:25 +0200 Sender: Francis.Dupont@fdupont.fr Cc: draft-cui-softwire-b4-translated-ds-lite , Softwires WG , "draft-penno-softwire-sdnat@tools.ietf.org" Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:00:30 -0000 In your previous mail you wrote: > Sending back an ICMP message when receiving a port out of range > should be configurable IMHO. > > When receiving a port out of range, the behaviour of REQ#12 (A, B > and C) of > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3 > can be followed by the AFTR. > > No need to define a new ICMP message for this; ICMP message Type 3 > Code 13 is fine for this. +1 (and not only I agree but I implemented this in the ISC AFTR) Regards Francis.Dupont@fdupont.fr From despres.remi@laposte.net Mon Mar 26 10:16:12 2012 Return-Path: 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 A21A421E810B for ; Mon, 26 Mar 2012 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 6AnzBlVAB+ij for ; Mon, 26 Mar 2012 10:16:11 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id B158C21E810A for ; Mon, 26 Mar 2012 10:16:10 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id qHG51i00337Y3f403HG5ud; Mon, 26 Mar 2012 19:16:08 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-140163100 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 26 Mar 2012 19:16:04 +0200 Message-Id: <06DC52C6-2591-43BD-81EF-2141D5524B9B@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn> <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net> <4F59AE74.4090204@cernet.edu.cn> <5AAB9CD9-4C3E-469E-B5C5-64E4C9C3E82F@laposte.net> <4F666409.9050800@cernet.edu.cn> <8B228A6B-4D3C-4E39-BE94-E1B4773649E0@laposte.net> <2BF534DB-3665-4FB4-B7AC-335B9FCA92EB@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:16:12 -0000 --Apple-Mail-1-140163100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-26 =E0 18:42, Wojciech Dec a =E9crit : >=20 >=20 > On 26 March 2012 13:34, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-03-26 =E0 11:08, Wojciech Dec a =E9crit : >=20 >> With the checksum re-computed, as per the rfc6145 option, translated = IPv6 packets would get the right checksum. With 4rd-u so far I see no = such option. >=20 > Are you saying that, when original IPv4 packets have null UDP = checksums, MAP-T would REQUIRE CEs and BRs to recompute UDP checksums of = complete packets?=20 > This would certainly prevent packets containing fragments to be = forwarded on the fly, and would therefore have performance implication. >=20 > The fragmented packet case is not what I'm referring to, I didn't write "fragmented" packet, just "complete" packet. CE or BR, to compute a checksum has to process the "complete"contents of = the packet. This is by reference to what RFC6145 says, namely: "For UDP packets that do not contain a UDP checksum (i.e., the UDP = checksum field is zero), the translator SHOULD provide a configuration = function to allow: 1. Dropping the packet and generating a system management event that = specifies at least the IP addresses and port numbers of the packet. 2. Calculating an IPv6 checksum and forwarding the packet (which has = performance implications)." As regards, fragmented packets, RFC 6145 says: "Fragmented IPv4 UDP = packets that do not contain a UDP checksum (i.e., the UDP checksum field = is zero) are not of significant use in the Internet, and in general will = not be translated by the IP/ICMP translator. However, when the = translator is configured to forward the packet without a UDP checksum, = the fragmented IPv4 UDP packets will be translated." =3D> two questions: a) How do you see this to be configured if a particular configuration = isn't imposed by the MAP-T specification? b) If fragmented packets are translated, isn't this as I said = incompatible with packet forwarding on the fly (fragment per fragment)? > but rather, the case where regular unfragmented IPv4 UDP checksum 0 = packets are sent. As per rfc6145, the checksum recalculation of such = packets is allowed. Allowed, and therefore not mandatory. That's fuzziness in the specification. > In any case, this is not specified yet (one more open issue of the MAP = set of documents). >=20 > There doesn't seem to be a need to do that as it's already specified = in rfc6145. See above. With E or U, none of this is a concern. RD =20 >=20 > -Woj. > =20 >=20 > RD >=20 >=20 >>=20 >> -Woj. >>=20 >> On 23 March 2012 14:55, R=E9mi Despr=E9s = wrote: >> Hi, Wojciech, >>=20 >> Are you suggesting that T would work with IPv4 packets having UDP = checksum =3D 0? >>=20 >> RFC6145 says that IPv4 packets with UDP checksum =3D 0 are either = always discarded, or optionally discarded if not fragmented (with = checksum recomputed if not discarded).=20 >> I don't see: >> - how this would work with double translation >> - why anything should be added to U for checksum-less UDP (IPv6-only = hosts don't support it anyway). >>=20 >> Cheers, >> RD >>=20 >>=20 >>=20 >> Le 2012-03-23 =E0 13:46, Wojciech Dec a =E9crit : >>=20 >>>=20 >>>=20 >>> On 19 March 2012 14:22, R=E9mi Despr=E9s = wrote: >>> Hi, Xing, >>>=20 >>> I look forward to face to face discussions in Paris if we don't = clarify everything before that (I will be busy on something else in the = next 3 days). >>>=20 >>>=20 >>> Le 2012-03-18 =E0 23:39, Xing Li a =E9crit : >>> ... >>>>>=20 >>>>> A key point is that 4rd doesn't prevent a 4rd-capable dual-stack = CE node, when it receives no 4rd mapping rule, to exercise single = translation.=20 >>>>> Actually, I believe that using for this the BIH of RFC6535 is = both sufficient and recommendable. >>>>> Translated IPv4 packets, because they are sent from CE nodes to = DNS64 synthesized addresses, are appropriately routed to their = destinations. (It can be via the NAT64-CGN if needed, or via more direct = paths if possible.) >>>>> Anything missed? >>>>=20 >>>> Sorry, this is a misunderstanding.=20 >>>> Hint: Single translation and double translation are based on the = same mapping rule in the CERNET2 deployment. >>>=20 >>> I am well aware of this, but this doesn't explain why 4rd mapping = rules similar to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to = IPv6 communication (single translation) supported". >>>=20 >>> As said in RFC6219, CERNET hosts have their IPv6 addresses = configured "via manual configuration or stateful autoconfiguration via = DHCPv6". >>> Hosts can therefore be assigned Interface IDs that have the 4rd-u = format (with V octet and CNP). >>>=20 >>> Now, when both addresses happen to be checksum neutral, RFC6145 = translation doesn't modify L4 data, so that it doesn't matter whether = the DS node has used 4rd-u header mapping or single translation.=20 >>> Thus, IPv6-only hosts can exchange packets with IPv4 applications of = 4rd CE nodes.=20 >>>=20 >>> If those packets are UDP checksum 0, the IPv6 host would either need = to be customized, or something else would need to changed/configured on = the 4rd-u CE specifically to get that to work for specific IPv6 = destinations, while with MAP-t this would be transparent (and not = require specific forwarding rules).=20 >>>=20 >>> -Woj. >>> =20 >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Regards, >>>>=20 >>>> xing >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> RD >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> xing >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> RD >>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Le 2012-02-10 =E0 04:28, Xing Li a =E9crit : >>>>>>> ... | | | | | >>>>>>>>>> | 5 | IPv6 web caches work for IPv4 | Y | N | = Y | N | >>>>>>>>>> | | packets | | | = | | >>>>>>>>> suggest you rename to "IPv4 to IPv6 communication (single = translation) supported" >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> (2) More clarification should be added here. I am not sure = 4rd-H can support single translation. >>>>>>>>=20 >>>>>>>> (a) According to (1), 4rd-H does not perform header translation = defined by RFC6145.=20 >>>>>>>>=20 >>>>>>>> (b) In the softwire mailing list, it seems that 4rd-H cannot = support single translation. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. >>>>>>>>=20 >>>>>>>> (c) If 4rd-H cannot support single translation, then "IPv6 web = caches work for IPv4 packets" requires special configurations, it cannot = do IPv6 web caches for non 4rd-H packets. >>>>>>>=20 >>>>>>> ... >>>>>>>=20 >>>>>>>> (5) I would like to see the details of how 4rd-H handles ICMP = and ICMP error messages. In the softwire mailing list there were some = discussions. See the thread containing = http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and = other posts. Please add >>>>>>>>=20 >>>>>>>> | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | >>>>>>> ... >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-1-140163100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On 26 March 2012 13:34, = R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net><= /span> wrote:

Le 2012-03-26 =C3=A0 = 11:08, Wojciech Dec a =C3=A9crit :

With the checksum re-computed, as per the rfc6145 option, = translated IPv6 packets would get the right checksum. With 4rd-u so far = I see no such option.

Are you saying that, when = original IPv4 packets have null UDP checksums, MAP-T would REQUIRE = CEs and BRs to recompute UDP checksums of complete = packets? 
This would certainly prevent packets containing = fragments to be forwarded on the fly, and would therefore have = performance implication.

The fragmented packet case is not what I'm = referring to,

I didn't write = "fragmented" packet, just "complete" packet.
CE or BR, to = compute a checksum has to process the "complete"contents of the = packet.
This is by reference to what RFC6145 says, = namely:
"For UDP packets that do not contain a UDP = checksum (i.e., the UDP checksum field is zero), the translator SHOULD = provide a configuration function to allow:
1. Dropping the = packet and generating a system management event that specifies at least = the IP addresses and port numbers of the packet.
2. = Calculating an IPv6 checksum and forwarding the packet (which has = performance implications)."

As regards, = fragmented packets, RFC 6145 says: "Fragmented IPv4 UDP packets that do = not contain a UDP checksum (i.e., the UDP checksum field is zero) are = not of significant use in the Internet, and in general will not be = translated by the IP/ICMP translator. However, when the translator = is configured to forward the packet without a UDP checksum, the = fragmented IPv4 UDP packets will be = translated."

=3D> two = questions:
a) How do you see this to be configured if a = particular configuration isn't imposed by the MAP-T = specification?
b) If fragmented packets are translated, isn't = this as I said incompatible with packet forwarding on the fly (fragment = per fragment)?


but rather, the case = where regular unfragmented IPv4 UDP checksum 0 packets are sent. As per = rfc6145, the checksum recalculation of such packets is = allowed.

Allowed, and = therefore not mandatory.
That's fuzziness in the = specification.


In any case, this is not = specified yet (one more open issue of the MAP set of documents).

There doesn't seem to be a need to do that = as it's already specified in = rfc6145.

See = above.

With E or U, none of this is a = concern.

RD

 

-Woj.
 

RD



-Woj.

On = 23 March 2012 14:55, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:
Hi, Wojciech,

Are you = suggesting that T would work with IPv4 packets having UDP checksum =3D = 0?

RFC6145 says that IPv4 packets with UDP = checksum =3D 0 are either always discarded, or optionally discarded if = not fragmented (with checksum recomputed if not = discarded). 
I don't see:
- how this would work with double translation
- why = anything should be added to U for checksum-less UDP  (IPv6-only = hosts don't support it = anyway).

Cheers,
RD



Le 2012-03-23 =C3=A0 = 13:46, Wojciech Dec a =C3=A9crit :



On 19 March 2012 14:22, = R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:
Hi, Xing,

I look = forward to face to face discussions in Paris if we don't clarify = everything before that (I will be busy on something else in the next 3 = days).


Le 2012-03-18 =C3=A0 23:39, Xing Li a = =C3=A9crit :
...

 A key point is that 4rd doesn't prevent = a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, = to exercise single translation. 
 Actually, I believe that using for this the BIH of = RFC6535 is both sufficient and recommendable.
 Translated IPv4 packets, because they are sent from = CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.)
Anything missed?

Sorry, this is a misunderstanding.
Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 = deployment.

I am well aware = of this, but this doesn't explain why 4rd mapping rules similar to = those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication (single = translation) supported".

As said in RFC6219, CERNET hosts have their IPv6 = addresses configured "via manual configuration or stateful = autoconfiguration via DHCPv6".
Hosts can therefore be assigned Interface IDs that have = the 4rd-u format (with V octet and CNP).

Now, when both addresses happen = to be checksum neutral, RFC6145 translation doesn't modify L4 data, so = that it doesn't matter whether the DS node has used 4rd-u header = mapping or single = translation. 
Thus, IPv6-only hosts can = exchange packets with IPv4 = applications of 4rd CE nodes. 

If those packets are UDP checksum 0, the IPv6 host = would either need to be customized, or something else would need to = changed/configured on the 4rd-u CE specifically to get that to work for = specific IPv6 destinations, while with MAP-t this would be transparent = (and not require specific forwarding rules).

-Woj.
 

=
Regards,
RD







=20 Regards,

xing



Regards,
RD





Regards,

xing



Regards,
RD
 




Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit = :
... | | | | = |
  |  5 | IPv6 web caches work for IPv4  =
      |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |

suggest you rename to "IPv4 to IPv6 =
communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can support single translation.

(a) According to (1), 4rd-H does not perform header translation defined by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support single = translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

= (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/m= sg03324.html and other posts. = Please add

 
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? =
| ? |
...





=


_____________________________= __________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires







= --Apple-Mail-1-140163100-- From despres.remi@laposte.net Mon Mar 26 11:57:52 2012 Return-Path: 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 93D4921E80BD for ; Mon, 26 Mar 2012 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 ubZhP0SGTBXR for ; Mon, 26 Mar 2012 11:57:52 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0E15B21E80CC for ; Mon, 26 Mar 2012 11:57:50 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id ECF849400B2 for ; Mon, 26 Mar 2012 20:57:42 +0200 (CEST) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 20:57:41 +0200 Message-Id: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:57:52 -0000 Hi, all, With some co-authors of the 4rd-U proposal, we will hold an informal = meeting about it. - subject: Clarification on what 4rd-U is designed to do, and how it = does it. - Participants: whoever is interested in a good understanding of the = 4rd-U proposal.=20 - place: room 204 - time : Tuesday 15:15 (duration depending on questions, maximum till = 16:30). The meeting can be seen as a bar BOF... without drinks in the room. See you there if interested, RD" From kyking6@gmail.com Mon Mar 26 14:30:25 2012 Return-Path: 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 76B4921E8094 for ; Mon, 26 Mar 2012 14:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 1O8rws0LPeKI for ; Mon, 26 Mar 2012 14:30:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E722A21E802A for ; Mon, 26 Mar 2012 14:30:23 -0700 (PDT) Received: by lbol12 with SMTP id l12so4749669lbo.31 for ; Mon, 26 Mar 2012 14:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ozxvan/nbcoC+I5Bj/hK3NhfnkpNlaKmV6m1HFun/5c=; b=k9ZWoVG9fu14088M6yPRxqjkss9ADHPVHZk0UT0JvgSL8IPzKZo05HR558Zss77jif YyVH3eyw8hLlwAGbL/MhcmBPw/aJKEVV+OeilpQY34vLWIM5i0hvY+dq/nsX7/GQV0/d fpooA439xYXQMf8IZo+YTAQ7ITLrCk+1dRzBZeSjIyVoaqhjfeNPTKcqxpWOwcK2xPBK hj4z8/BYF5inN4MM/ZuKtgUs2k8C3Jvw/n837/tPmh4GaaGVO+E82T9siSRNgpPR12Tw VcK7RMWp5xN6DB7VMhk7AoE+8BLG1XGBg0KAOFd10+3qnd6vLBC2cTaFP7ao7ZqU1/fK iKUQ== MIME-Version: 1.0 Received: by 10.152.130.167 with SMTP id of7mr16803977lab.36.1332797422672; Mon, 26 Mar 2012 14:30:22 -0700 (PDT) Received: by 10.112.29.234 with HTTP; Mon, 26 Mar 2012 14:30:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 16:30:22 -0500 Message-ID: From: Kevin Y To: Alain Durand Content-Type: multipart/alternative; boundary=f46d042c6c3fef9b2604bc2c14b1 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:30:25 -0000 --f46d042c6c3fef9b2604bc2c14b1 Content-Type: text/plain; charset=ISO-8859-1 Dear WG Co-Chairs, I looked at your arguments in this email here and Softwaire WG agenda you proposed on Wed and Fri, I am kind of confusing, hope you can clarify: There are several drafts discussed in Wed agenda which basically solved same problem as we discussed in Friday and they are all variant solution of encapsulations in stateless mode for 464 user case. how do you deal with all those proposals, should we put all of those along with MAP, 4rd-u as part of selecting decision from WG on Friday all together ? It will be unfair to treat those differently on Wed vs those on Friday ! If we are facing the problem for too many standard proposals from softwire WG, they occured in situations we had too many variant of encapsulations, so far, from what I can see, MAP represents the best efforts from WG to unify encapsulation and translation solutions from softwire. I agreed with many in this mailing-list said before, respect the collaborating efforts in past 6 month and select MAP as standard track,rather other individual variant such as 4rd-U, stateless DS-lite, etc. let us be more productive through collaboration than count-productive through more individual drafts. Best Regards, Kevin Yin On Mon, Mar 19, 2012 at 6:38 PM, Alain Durand wrote: > Dear wg, > > After a number of discussions with my co-chair, our AD and various > authors, here is how we would like to move forward wrt 4rd. > > 1) There is an observation that all the solutions on the table E, T & U > actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are > really significant. E and T are the original Encapsulation and Translation > proposals, U is an hybrid unifying solution. > > 2) We have already agreed back in Beijing that we would publish all > necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as > Experimental, Informational or Standard Track. > > We are at the point now where we need to make progress. In Paris, we would > like to ask for presentations from the proponents of each candidate > solution (E, T & U). > Each presentation should cover an overview of the proposed solution, > explain how it compares to the others and make a case as why it should be > the one on the Standard Track. We will allocate 20 minutes for each > presentation. > > Then, we, chairs, would like to ask a series of questions to the working > group. In order to make this process transparent, here is the list of > questions we want to ask > and their sequence. > > Q1: Without pre-supposing which one will be selected, do you agree to > publish 1 of the 3 proposals on the Standard Track and publish the other(s) > as Informational if still asked to? > > If the answer is NO, then the process stops and we will publish everything > as Experimental and come back in 12-24 months to see what gets adopted by > the market. > If the answer is YES, we move to the next question. > > > Q2: Do you believe that the WG should publish U as the one Standards Track > document? > > If the answer is YES, the process stop, we put U on the Standard Track and > publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned or > published as Historical/Informational) > > > Q3: Which of E and T do you want to see moving on the standard track (you > can only express support for one)? > > If there is a clear outcome from this question, we would publish that > proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both E & > T as Experimental. > > In the meantime, we would like to encourage discussion on the mailing list > to foster our common understanding of the various technologies and how they > relate to each other. > > Alain & Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d042c6c3fef9b2604bc2c14b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear WG Co-Chairs,
=A0
I looked at your arguments = in this email=A0here and Softwaire WG agenda you proposed on Wed and Fri, I= am kind of confusing, hope you can clarify:
=A0
There = are several drafts discussed in Wed agenda which basically solved same prob= lem as we discussed in Friday and=A0they are all variant=A0solution of enca= psulations=A0in stateless mode for 464 user case.=A0how do you deal with=A0= all those proposals, should we put=A0all=A0of those=A0along with MAP,=A04rd= -u as part of selecting decision=A0from WG on
Friday all together ?=A0 It will be unfair to=A0treat those differentl= y on Wed vs those on Friday !=A0
=A0
If we=A0are facing= =A0the problem for too many standard proposals from softwire WG, =A0they oc= cured in situations we had too many=A0variant of=A0encapsulations,=A0 so fa= r, from what I can see,=A0MAP represents the best efforts from WG to unify = encapsulation and translation solutions from=A0softwire.=A0=A0I agreed with= many in this mailing-list=A0said before,=A0 respect the collaborating effo= rts=A0in past 6 month and select=A0MAP as standard track,rather other=A0ind= ividual variant such as 4rd-U, stateless DS-lite,=A0etc. let us be more pro= ductive through collaboration than=A0count-productive through more individu= al drafts.=A0=A0=A0
=A0
Best Regards,
=A0
Kevin Yin
On Mon, Mar 19, 2012 at 6:38 PM, Alain Durand <= span dir=3D"ltr"><adurand@juniper= .net> wrote:
Dear wg,

After a number of discussions with my co-chair, our AD and various authors,= here is how we would like to move forward wrt 4rd.

1) There =A0is an observation that all the solutions on the table E, T &= ; U actually solve the stateless =A0problem we started with.
=A0 =A0There are differences, but it is unclear if those differences are r= eally significant. E and T are the original Encapsulation and Translation =A0 =A0proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessa= ry documents. The issue here is the 'label' or 'status' tho= se
=A0 =A0documents have at IETF. In particular, do we want to publish them a= s Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would = like to ask for presentations from the proponents of each candidate solutio= n (E, T & U).
Each presentation should cover an overview of the proposed solution, explai= n how it compares to the others and make a case as why it should be the one= on the Standard Track. We will allocate 20 minutes for each presentation.<= br>
Then, we, chairs, would like to ask a series of questions to the working gr= oup. In order to make this process transparent, here is the list of questio= ns we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publi= sh 1 of the 3 proposals on the Standard Track and publish the other(s) as I= nformational if still asked to?

If the answer is NO, then the process stops and we will publish everything = as Experimental and come back in 12-24 months to see what gets adopted by t= he market.
If the answer is YES, we move to the next question.


Q2: Do you believe that the WG should publish U as the one Standards Track = document?

If the answer is YES, the process stop, we put U on the Standard Track and = publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational)


Q3: Which of E and T do you want to see moving on the standard track (you c= an only express support for one)?

If there is a clear outcome from this question, we would publish that propo= sal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E &am= p; T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list = to foster our common understanding of the various technologies and how they= relate to each other.

=A0Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d042c6c3fef9b2604bc2c14b1-- From kyking6@gmail.com Mon Mar 26 14:41:33 2012 Return-Path: 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 6B83321F85FD for ; Mon, 26 Mar 2012 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 pSG6FqNFY-51 for ; Mon, 26 Mar 2012 14:41:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 484FD21F85D7 for ; Mon, 26 Mar 2012 14:41:32 -0700 (PDT) Received: by lagj5 with SMTP id j5so4758515lag.31 for ; Mon, 26 Mar 2012 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xva2fVmFU92ADCBVpZgcBNxiK41BwNpXMjlfExuN7f4=; b=WsBoXXWNb8vf048FzZKG92ygnpcXwbeY26O9RCT/UEmzCc/9iLN7QxCmglKGhBqbsc tZHffO1pLQoa/kGZqNi4+1LskaIKUEQeil5folHXqtlSuyJva4x16Pyr+OVfF4rjtUPC oc/WShGEC8PL6Q63XWEQZyCzgeMTlo3YdPtzn6V7LiL4CVBtg+YNli3cSGG/3gGy8/Y2 wRpz2RegvIeVTC3tZ/9WmLVr+P/58zwgUVbx+oV3BhEI5x7RQNDu1trGIXGyhLj4baAc 6Ysi3CYF53Volz2f3n1mfamWtmC+MYbRQG/O7gveNg4XPNg/Lnb8OmYw4avGxRx/HSax 0/jA== MIME-Version: 1.0 Received: by 10.152.133.9 with SMTP id oy9mr16912796lab.43.1332798091181; Mon, 26 Mar 2012 14:41:31 -0700 (PDT) Received: by 10.112.29.234 with HTTP; Mon, 26 Mar 2012 14:41:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 16:41:31 -0500 Message-ID: From: Kevin Y To: Maoke Content-Type: multipart/alternative; boundary=f46d044284f6c83fd904bc2c3cd9 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:41:33 -0000 --f46d044284f6c83fd904bc2c3cd9 Content-Type: text/plain; charset=ISO-8859-1 Maoke, I like your analog of horse, donkey, and donkorse! and fully agree with you. People know what kind of situation horse and donkey can help to solve the problem. People do not want unknown donkorse because it creates more problem rather than solving specific problem. Kevin Yin > >> > > well, this is what i mean the uncertainty of 4rd-U in the architecture to > the common understanding. as a analogy, one of Mr. E and Mr. T said, "i > give you a horse", while the other said "i give you a donkey". then people > well understand when they need acwhen they need a donkey. now Mr. U said > "wow, i give you a fantastic donkorse!". there would be 2 possible results, > not certain right now: > A. donkorse is just another sort of donkey, somehow good but somehow > flawed. > B. donkorse is just donkorse, and people, taking a long time to understand > it, and finally find it either a flawed or a quite good hybrid, like mule, > useful in some cases. > > no matter if the future result is A or B, now Mr. O understand what he > needs for his business is either a horse and a donkey, with their > well-known characteristics. Mr. MAP provides a wheeled car as the common > instrument, while Mr. O needs a standard suite for the wheeled-car, the > horse-driving and donkey-driving methods and the way of feeding the horse > and donkey. this is the task of our wg, right now. > > Mr. U said you must have another type of wheel and drive it with my > donkorse --- and when Mr. O asked him, what your donkorse is, he answered: > you will know it is donkorse, having both the advantages of the horse and > the advantages of the donkey. however, Mr. O doubts donkorse hasn't also > the disadvantages of horse and the disadvantages of donkey and some flaws > not yet documented. why not? > > --f46d044284f6c83fd904bc2c3cd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maoke,
=A0
I like your = analog of horse, donkey, and donkorse! and fully agree with you.
= =A0
People know what kind of=A0situation horse and donkey can hel= p to solve the problem.=A0 People do not want unknown donkorse=A0because it= creates more problem rather than solving specific problem.
=A0
Kevin Yin
=A0
=A0
=A0
=A0
well, this is=A0= what i=A0mean the uncertainty of 4rd-U in the architecture to the common un= derstanding. as a analogy, one of Mr.=A0E and Mr. T said, "i give you = a horse", while=A0the other=A0said "i give you a donkey". th= en people well understand when they need acwhen they need a donkey. now Mr.= U said "wow, i give you a fantastic donkorse!". there would be= =A02 possible results, not certain right now:
A. donkorse is just another sort of donkey, somehow good but somehow f= lawed.
B. donkorse is just donkorse, and people, taking a long t= ime to understand it, and finally find it either a flawed or a quite good h= ybrid, like mule, useful in some cases.
=A0
no matter if the future result is A or B, now Mr. O unde= rstand what he needs for his business is either a horse and a donkey, with = their well-known characteristics. Mr. MAP provides a wheeled car as=A0the c= ommon instrument, while Mr. O needs a standard suite for the wheeled-car, t= he horse-driving and donkey-driving methods and the way of feeding the hors= e and donkey.=A0this is the=A0task of our wg, right now. =A0
=A0
Mr. U said you must have another type of wheel and drive= it with my donkorse --- and when Mr. O asked him, what your donkorse is, h= e answered: you will know it is donkorse, having both the advantages of the= horse and the advantages of the donkey. however, Mr. O doubts donkorse has= n't also the disadvantages of horse and the disadvantages of donkey and= some flaws not yet documented. why not?
=A0
--f46d044284f6c83fd904bc2c3cd9-- From kyking6@gmail.com Mon Mar 26 14:51:00 2012 Return-Path: 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 4679921E8085 for ; Mon, 26 Mar 2012 14:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 X8iFHOKt93J0 for ; Mon, 26 Mar 2012 14:50:59 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF61521E8083 for ; Mon, 26 Mar 2012 14:50:58 -0700 (PDT) Received: by lagj5 with SMTP id j5so4763702lag.31 for ; Mon, 26 Mar 2012 14:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nhNxKP3glU4P8iKsdlOz7kSSASH2y2dtcRbfWhx58Io=; b=uMVVx2T1r/xjYAH0UIAYHkWaykepX5Ib9fzF2f4Nanf8nSwkqPgLCPvLGBt4ucc2gE ZWVm/h83y3vaeXgcdcFN3wijnFqZnqH7Q0r0VHXNvM0q/0Rix/H978o++CZ9DnRR7wSe d3DKn8H9ThiRTQe0HP1cUPp86fC/WMQvInfPT90xD/cbF9PD+lvkyGJdp/WmdqU0Kx9q TbncAKg6pveEyQlbMLk9JNIMNn0d7n6ei2oa39WUg/vroVNZ7zIbM3RLRvgQv6ueqXAR hnYyn/hHo+8+Jw7AR7i5Dz374STRIft0dqm1yVq4P6o8CIRxtgj8LvVgFsQgw29B9asw q3pQ== MIME-Version: 1.0 Received: by 10.152.108.171 with SMTP id hl11mr16984078lab.29.1332798657830; Mon, 26 Mar 2012 14:50:57 -0700 (PDT) Received: by 10.112.29.234 with HTTP; Mon, 26 Mar 2012 14:50:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 16:50:57 -0500 Message-ID: From: Kevin Y To: Guanghui Yu Content-Type: multipart/alternative; boundary=bcaec54fbd3c8e9db204bc2c5e2f Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:51:00 -0000 --bcaec54fbd3c8e9db204bc2c5e2f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Remi, This is beyond the charter of softwire WG, changing IPv6 address format needs much broad discussion in IETF community to understand its impact first, before we should even discuss if it is valid to design something like this in softwire. Have you done that ? Best Regards, Kevin Yin On Thu, Mar 22, 2012 at 10:04 PM, Guanghui Yu wrote= : > Hi Yiu > > 4rd-u changes the IPv6 header architecture (redefine > fragmentation header extension) and IPv6 address architecture (different > meaning of u-bit when g-bit=3D1). These are the fundamental changes. If 4= rd-u > becomes the standard, then there will be new defined =93IPv6=94 packets o= n > the Internet, which are not compatible with existing IPv6 packets and > no existing devices can understand those packets. > > > Yu Guanghui > Network and Information Center > Dalian University of Technology, China > > > On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu wro= te: > >> Hi Guanghui, >> >> I agree that both MAP and 4rd-u are similar technology and solving the >> same problem. From technical perspective, can you elaborate this a lithe >> bit? >> >> Thanks, >> Yiu >> >> From: Guanghui Yu >> Date: Thu, 22 Mar 2012 20:26:40 +0800 >> To: Softwires WG >> Subject: Re: [Softwires] Path to move forward with 4rd=85 >> >> I read 4rd-u draft and found it is flawed. >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --bcaec54fbd3c8e9db204bc2c5e2f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi, Remi,
=A0
This is beyond the charter of so= ftwire WG, changing IPv6 address format needs much broad discussion in IETF= =A0community to understand its impact first,=A0before we=A0should even=A0di= scuss=A0if it is=A0valid to design something like this in=A0softwire.=A0=A0= Have you done that ?
=A0
Best Regards,
=A0
Kevin Yin
=A0
On Thu, Mar 22, 2012 at 10:04 PM,= Guanghui Yu <yu.guanghui@gmail.com> wrote:
Hi Yiu

=A0 =A04rd-u changes = the IPv6 header architecture (redefine fragmentation=A0header extension) an= d IPv6 address architecture (different meaning of=A0u-bit when g-bit=3D1). = These are the fundamental changes. If 4rd-u becomes=A0the standard, then th= ere will be new defined =93IPv6=94 packets on the=A0Internet, which are not= compatible with existing IPv6 packets and no=A0existing devices can unders= tand those packets.
=A0 =A0

Yu Guanghui <ygh at dlut.edu.cn>
Network and Info= rmation Center
Dalian University of Technology, China
<= div class=3D"h5">


On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <Yiu_Lee@cable.comcast.= com> wrote:
Hi Guanghui,

I agree that both MAP and= 4rd-u are similar technology and solving the same problem.=A0From technica= l perspective, can you elaborate this a lithe bit?=A0

Thanks,
Yiu

From: Guanghui Yu <yu.guanghui@gmail.com>= ;
Date: Thu, 22 Mar 2012 20:26:= 40 +0800
To: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to mov= e forward with 4rd=85

Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--bcaec54fbd3c8e9db204bc2c5e2f-- From fibrib@gmail.com Mon Mar 26 17:38:23 2012 Return-Path: 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 F247A21E8045 for ; Mon, 26 Mar 2012 17:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 LnYyI6XlVkO0 for ; Mon, 26 Mar 2012 17:38:22 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E115C21E802D for ; Mon, 26 Mar 2012 17:38:21 -0700 (PDT) Received: by qadc14 with SMTP id c14so2572583qad.10 for ; Mon, 26 Mar 2012 17:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+erQ2rjSoxbs0MEVn1sLfRcr1y7DJuSTIRnNKW3fSpg=; b=tm2mdRlSB4nto0hROsqXoUn/N+R+55ErRPqR6I7d5dCYu0F4o7ggo6rjTRMgs+lOrU sQOWn8PIWZzOhNZQq3Zc26ojS+RjtrvXlNKwjAbKfMeb01R1e+rUodPiJWZ2/We4+1AN l7yX2Li7VEeQ+LPvWoP57NOMTO8xY00MaJbpryu9hGP+HK8Z8NikYRe/gqpUOSTOdtVO HjheBE0hqQCFDsCfC9XCR52diH8P257fSDs3TKG/cavhECK75dNeCVZzOXsI1NXOFoar kG9FITRvAES4VXaCbF+XTu+MVdon50y+evyXbyaQPrJz8tC9pAX0e0KlJI9B3EFUFFq9 bSiw== MIME-Version: 1.0 Received: by 10.229.135.207 with SMTP id o15mr9149634qct.51.1332808701411; Mon, 26 Mar 2012 17:38:21 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 26 Mar 2012 17:38:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 00:38:21 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c7690fe3382ad04bc2eb57c Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 00:38:23 -0000 --00248c7690fe3382ad04bc2eb57c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, i know you are very busy in Paris, but please respond to this thread. again, if i made anything wrong, please don't hesitate to point out. thanks! best, maoke 2012/3/26 Maoke > > dear Remi, > > i think you won't be against if i change the subject of this specific > discussion, focusing on the routing issues regarding virtual link. > 2012/3/26 R=E9mi Despr=E9s > >> Different understanding. >>> An detailed E use case that cannot be supported by U (if it >>> exists) would give substance to this claim. >>> Open to look at it. >>> >> >> in my personal experience i could give you at least three quick examples >> of the use case for the building block of "virtual link": >> >> first example, if the IPv4 customer network plays BGP over IPv4 with the >> provider, through the BGP session between CE and BR, a virtual link is >> desired. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> >> >> I don't see in this scenario why anything that works with E (i.e. betwee= n >> CEs and BRs) wouldn't also work with U. >> >> > > by default, ebgp requires direct link (some implementations specify TTL = =3D > 1 to achieve this). U decreases TTL when packet goes through IPv6 > cloud, and therefore CE---BR ebgp session cannot be > established with regular BGP configurations. > >> second example, there are dynamic routing protocols like RIP running in >> the following (multihoming) topology for IPv4 routing. the operator may >> want to treat the CE-BR as a single hop in order the virtual link is >> considered the distance vector calculation. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> \ = / >> \ / >> +------------ CE ----(Another, IPv4 domain)----------+ >> >> >> Same comment. >> >> > > similar misunderstanding. RIP distance vectors are delivered to > neighbors but the operators are easy to be confused by the fact that > CE---BR are shown as multihop with tools like traceroute. > > >> >> >> third example, same topology as above but OSPF are applied, and OSPF >> TTL-security check are enabled to ensure hop-passings less than a specif= ied >> threshold. if the operator would like to treat CE---(IPv6-only domain)--= -BR >> as one hop because it is considered as virtual link, 4rd-u's rudiness in >> decreasing TTL will hurt. >> >> >> Same comment. >> >> > > same misunderstanding. without knowing the details of the IPv6 domain > backbone, it is difficult for the operator to set up a proper value of th= e > TTL-security parameter for the OSPF regarding the CE---BR section. virtua= l > link (full encapsulation) eliminates this trouble. > > >> >> >> MAP-E (and other E) surely has no limitation in supporting any features >> of existing routing protocols. >> >> >> Why U would be less transparent between CEs and BRs than E for any L4 >> protocol remains unexplained. >> >> > > hope the above helps. it is not about the transparency but about the > behavior of virtual link. it is not about any L4 protocol but about routi= ng > protocols. > > >> >> >> >> with at least the above three examples, i conclude "U cannot replace E a= t >> all"! >> >> >> See above. >> >> > > see above. > > - maoke > > >> >> >> (btw, surely the translation has the same limitation not to support the >> above features but, e.g., as you also said, it opens transport-layer stu= ff >> to the middle boxes). therefore i said operators may use either >> encapsulation or translation according to what they attach importance to= .) >> >> --00248c7690fe3382ad04bc2eb57c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,=A0

i know you are very busy in= Paris, but please respond to this thread. again, if i made anything wrong,= please don't hesitate to point out. thanks!=A0

best,
maoke

2012/3/26 Maoke <= span dir=3D"ltr"><fibrib@gmail.com>
=A0
dear Remi,
=A0
i think you won't= be against if i change the subject of this specific discussion, focusing o= n the routing issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>=
Different understanding.
An detailed E use case that cannot be supported by U=A0(if it exists)=A0wo= uld give substance to this claim.
Open to look at it. =A0

in my personal experience i could give you at least three qu= ick examples of the use case for the building block of "virtual link&q= uot;:=A0

first example, if the IPv4 customer netwo= rk plays BGP over IPv4 with the provider, through the BGP session between C= E and BR, a virtual link is desired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
<= br>
I don't see in this scenario why anything tha= t works with E (i.e. between CEs and BRs) wouldn't also work with U.
=A0
=A0
by default, ebgp = requires direct link (some implementations specify TTL =3D 1 to achieve thi= s). U decreases TTL when packet goes through IPv6 cloud,=A0and therefore CE= ---BR ebgp=A0session cannot be established=A0with=A0regular=A0BGP configura= tions.
second example, t= here are dynamic routing protocols like RIP running in the following (multi= homing) topology for IPv4 routing. the operator may want to treat the CE-BR= as a single hop in order the virtual link is considered the distance vecto= r calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

Same= comment.
=A0
=A0
si= milar misunderstanding. RIP distance vectors are delivered to neighbors=A0b= ut the operators are easy to be confused by the fact that CE---BR are shown= as=A0multihop with tools like traceroute.
=A0
=A0
th= ird example, same topology as above but OSPF are applied, and OSPF TTL-secu= rity check are enabled to ensure hop-passings less than a specified thresho= ld. if the operator would like to treat CE---(IPv6-only domain)---BR as one= hop because it is considered as virtual link, 4rd-u's rudiness in decr= easing TTL will hurt.=A0

Same comment.
=A0
=A0
same misunderstanding. with= out knowing the details of the IPv6 domain backbone, it is difficult for th= e operator to set up a proper value of the TTL-security parameter for the O= SPF regarding the CE---BR section. virtual link (full encapsulation) elimin= ates this trouble.
=A0
=A0

MAP-E (and other E) surely has no limitation in supporting any feature= s of existing routing protocols.

Why U would be less transparent between CEs and BRs than E fo= r any L4 protocol remains unexplained.
=A0
=A0
hope the ab= ove helps. it is not about the transparency but about the behavior of virtu= al link. it is not about any L4 protocol but about routing protocols.
=A0
=A0
=A0
with at least the above three examples, i conclude "U= cannot replace E at all"!

See above.
=A0
=A0
see above.
=A0
- maoke
=A0
=A0

(btw, surely the t= ranslation has the same limitation not to support the above features but, e= .g., as you also said, it opens transport-layer stuff to the middle boxes).= therefore i said operators may use either encapsulation or translation acc= ording to what they attach importance to.)=A0

--00248c7690fe3382ad04bc2eb57c-- From fibrib@gmail.com Mon Mar 26 18:39:45 2012 Return-Path: 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 E1EEB21E8045 for ; Mon, 26 Mar 2012 18:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 FZ3z3e8Wr2Sj for ; Mon, 26 Mar 2012 18:39:45 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04121E8043 for ; Mon, 26 Mar 2012 18:39:45 -0700 (PDT) Received: by qadc14 with SMTP id c14so2594771qad.10 for ; Mon, 26 Mar 2012 18:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liQncW65Pazkc6PPkgrmyxCHQRt3G+1puCWzHgp8z1o=; b=LrW1BwfFunBT9SSGLRVXVDEPUzyj8vIWMe+DObNEOCaIdhnpegHarS4hZl280MwtF6 pxo5YNDB2cshKdFmPjyFwfN92msi5FHxg8zJbMJf3SHWvfqTIaUCw8WbzKhK2WSsUNZm ZORBZl0glQ64vTadb9V5ROLUXxT0MiVTPkrbyHEM0vmWMoUKnmXbwGOJrchiarQV24Ja rNX9d4Q+5kn8x1JeEnJa3pdYIVJbe0CTKCXGS5ZXJbLNDI+ByVI9z/Z3nC75ALpQwobn PgKv78wrFcZleB0bOqOfrT1liegSyRthyVkYROIlG3tZtv2ODKs77FPmqYn3Y/ANPIDN U9wg== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr9263526qct.71.1332812384743; Mon, 26 Mar 2012 18:39:44 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 26 Mar 2012 18:39:44 -0700 (PDT) In-Reply-To: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> Date: Tue, 27 Mar 2012 01:39:44 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235452e750beb2eb04bc2f9021 Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 01:39:46 -0000 --00235452e750beb2eb04bc2f9021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i wonder if remote participation (skype, jabber room, etc.) is available or not. - maoke 2012/3/26 R=E9mi Despr=E9s > Hi, all, > > With some co-authors of the 4rd-U proposal, we will hold an informal > meeting about it. > - subject: Clarification on what 4rd-U is designed to do, and how it does > it. > - Participants: whoever is interested in a good understanding of the 4rd-= U > proposal. > - place: room 204 > - time : Tuesday 15:15 (duration depending on questions, maximum till > 16:30). > > The meeting can be seen as a bar BOF... without drinks in the room. > > See you there if interested, > RD" > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00235452e750beb2eb04bc2f9021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i wonder if remote participation (skype, jabber room, etc.) is available or= not. - maoke=A0

2012/3/26 R=E9mi Despr= =E9s <desp= res.remi@laposte.net>
Hi, all,

With some co-authors of the 4rd-U proposal, we will hold an informal meetin= g about it.
- subject: Clarification on what 4rd-U is designed to do, and how it does i= t.
- Participants: whoever is interested in a good understanding of the 4rd-U = proposal.
- place: =A0room 204
- time : =A0Tuesday 15:15 (duration depending on questions, maximum till 16= :30).

The meeting can be seen as a bar BOF... without drinks in the room.

See you there if interested,
RD"

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00235452e750beb2eb04bc2f9021-- From jiangdong345@gmail.com Mon Mar 26 20:37:01 2012 Return-Path: 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 AD96321E8045 for ; Mon, 26 Mar 2012 20:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-1.705, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 Tni+aF-RGo7A for ; Mon, 26 Mar 2012 20:37:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D036321E8019 for ; Mon, 26 Mar 2012 20:37:00 -0700 (PDT) Received: by iazz13 with SMTP id z13so10810879iaz.31 for ; Mon, 26 Mar 2012 20:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=Ut17Y2vH/wZO0wtfs5XmRkpEdtTT4BjI/V/3ib1XLeY=; b=s+TxZeSJVgoGr/8Izo0og49WiOPBWIdhI1apCKYo0xJVbPH65D/pbDCCRyc3eNF1wk ZqO63TMOOrtp9vrSfkBcfWCfD0gYdUGhgWTUxy7vPZCMDb6/khfuxTwo9rHUns7a8kVY IzuCBzrIxgF/6Zkt9w8QK+lSXn02+44BSzmefeA/T3iqR4q9QfUUW/0diW39NYl+ew5u RB5eKqAtraVb0ts/a+yG4SNibfA6v9IsFzxP7/orxirVeYQxCQUYaWnuMueMMXQj58W6 HfSbc3fTmBvwbOJPOesXeGk+FMw0QZm0fgi5VcouabhHEn/FkPSW4Z54OKwlZ+TZmTDu ZTKQ== Received: by 10.42.169.132 with SMTP id b4mr14528135icz.5.1332819420388; Mon, 26 Mar 2012 20:37:00 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id md6sm16636143igc.0.2012.03.26.20.36.57 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 20:37:00 -0700 (PDT) Date: Tue, 27 Mar 2012 11:36:57 +0800 From: "Jiang Dong" To: shtsuchi References: <4E3C088A-CBB6-4E9A-AC78-2E821BC349F1@laposte.net> , <72352FAC-8EBA-4611-8019-BDE519D87A2F@laposte.net> <2012032621591809758988@gmail.com>, <4F707AE1.2000802@cisco.com> X-Priority: 3 X-GUID: D3DB83B1-4CBE-4D3E-B7CD-C4FF0A569D45 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012032711365431182175@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart530880628381_=----" Cc: "cai.lei3" , Softwires WG , Cui Yong Subject: Re: [Softwires] Comments about 6rd MIB X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 03:37:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart530880628381_=---- Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 SGksIFNoaXNoaW8sDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSBhbmQgY2xhcmlmaWNhdGlvbi4N Cg0KQmVzdCBSZWdhcmRzIQ0KDQoNCg0KSmlhbmcgRG9uZw0KVHNpbmdodWEgVW5pdmVyc2l0eQ0K MjAxMi0wMy0yNw0KDQpGcm9tOiBTaGlzaGlvIFRzdWNoaXlhDQpEYXRlOiAyMDEyLTAzLTI2IDIy OjE5DQpUbzogamlhbmdkb25nMzQ1DQpDQzogY2FpLmxlaTM7IGphY25pOyBzb2Z0d2lyZXM7IGN1 aXlvbmcNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXUNvbW1lbnRzIGFib3V0IDZyZCBNSUINCkpp YW5nDQpUaGFua3MgZm9yIGNvbW1lbnRzLg0KSSB3aWxsIGRvIHByZXNlbnRhdGlvbiB0aGlzIGRy YWZ0IGF0IEZyaWRheSxhbmQgSSB3aWxsIGFzayB3aGljaCBpZGVhIGlzIGJldHRlciB0byB0aGUg YXVkaWVuY2UgYW5kIGNoYWlycy4NCklmIElQIHR1bm5lbCBNSUIgZXh0ZW5kZWQgaXMgYmV0dGVy IHRoYW4gNnJkTUlCLHNvIHdlIHdvdWxkIHVwZGF0ZSBhbmQgZGVmaW5lIGV4dGVuc2lvbiBvZiBJ UCB0dW5uZWwgTUlCLg0KDQpbREpdIEkgdGhpbmsgUkZDNDA4NyBpcyBkZXNpZ25lZCBmb3IgY29t bW9uIGluZm9ybWF0aW9uIGFib3V0IHR1bm5lbHMuIFNvIGV4dHJhIGluZm9ybWF0aW9uIHRoYXQg Y2FuIG5vdCBiZSBpbmNsdWRlZCBpbiBSRkM0MDg3IG5lZWQgdG8gYmUgY29udGFpbmVkIGluIHNw ZWNpYWxpemVkIE1JQiBzdWNoIGFzIDZyZCwgc29mdHdpcmUgbWVzaC4gDQpCVFcsIHNpbmNlIDZy ZCBjYW4gcGVyZm9ybSBlbmNhcHN1bGF0aW9uIGluIGEgc3RhdGVsZXNzIHdheSwgdGhlcmUgaXMg bm8gbmVlZCB0byBtYWludGFpbiBhbiBlbmNhcHN1bGF0aW9uIHRhYmxlLiBBRkJScyBpbiBzb2Z0 d2lyZSBtZXNoIHNjZW5hcmlvIG5lZWQgdG8gcGVyZm9ybSBJLUlQIGVuY2Fwc3VsYXRpb24gd2l0 aCBFLUlQIHByZWZpeCBpbmZvcm1hdGlvbiwgYSB3ZSBkZWZpbmVkIGFuIEVuY2Fwc3VsYXRpb24g VGFibGUgaW4gdGhlIHNvZnR3aXJlIG1lc2ggTUlCLiBDb21tZW50cyBhcmUgd2VsY29tZSA6ICkN Cg0KNnJkIE1JQiBpcyBjb21wbGV0ZWx5IHJlZmxlY3RpbmcgdG8gNnJkIGNvbmZpZ3VyYXRpb24u DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTY5I3NlY3Rpb24tNw0KInNpeFJkSXB2 NE1hc2tMZW4gIiAgaXMgc2FtZSBmdW5jdGlvbiBhcyBJUHY0TWFza0xlbi4NCg0KSVB2NE1hc2tM ZW4gICAgICAgICBUaGUgbnVtYmVyIG9mIGhpZ2gtb3JkZXIgYml0cyB0aGF0IGFyZSBpZGVudGlj YWwNCiAgICAgICAgICAgICAgICAgICAgICAgYWNyb3NzIGFsbCBDRSBJUHY0IGFkZHJlc3NlcyB3 aXRoaW4gYSBnaXZlbiA2cmQNCiAgICAgICAgICAgICAgICAgICAgICAgZG9tYWluLiAgRm9yIGV4 YW1wbGUsIGlmIHRoZXJlIGFyZSBubyBpZGVudGljYWwNCiAgICAgICAgICAgICAgICAgICAgICAg Yml0cywgSVB2NE1hc2tMZW4gaXMgMCBhbmQgdGhlIGVudGlyZSBDRSBJUHY0DQogICAgICAgICAg ICAgICAgICAgICAgIGFkZHJlc3MgaXMgdXNlZCB0byBjcmVhdGUgdGhlIDZyZCBkZWxlZ2F0ZWQN CiAgICAgICAgICAgICAgICAgICAgICAgcHJlZml4LiAgSWYgdGhlcmUgYXJlIDggaWRlbnRpY2Fs IGJpdHMgKGUuZy4sIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICBQcml2YXRlIElQdjQgYWRk cmVzcyByYW5nZSAxMC4wLjAuMC84IGlzIGJlaW5nDQogICAgICAgICAgICAgICAgICAgICAgIHVz ZWQpLCBJUHY0TWFza0xlbiBpcyBlcXVhbCB0byA4IGFuZCBJUHY0TWFza0xlbg0KICAgICAgICAg ICAgICAgICAgICAgICBoaWdoLW9yZGVyIGJpdHMgYXJlIHN0cmlwcGVkIGZyb20gdGhlIElQdjQN CiAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzcyBiZWZvcmUgY29uc3RydWN0aW5nIHRoZSBj b3JyZXNwb25kaW5nIDZyZA0KICAgICAgICAgICAgICAgICAgICAgICBkZWxlZ2F0ZWQgcHJlZml4 Lg0KDQpSZWdhcmRzLA0KLVNoaXNoaW8NCg0KKDIwMTIvMDMvMjYgMTU6NTkpLCBKaWFuZyBEb25n IHdyb3RlOg0KPiBIaSxhdXRob3JzIG9mIDZyZCBNSUIsDQo+IEkgZ2V0IHNvbWUgY29tbWVudHMg YWJvdXQgNnJkIE1JQiBkcmFmdC4NCj4gMSkgWW91IG1lbnRpb25lZCB0aGUgInR1bm5lbElmWFRh YmxlIiBpbiBzZWN0aW9uIDUuMi4gSSB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBleHRlbmQg dGhlIHR1bm5lbCBNSUIsIHNvbWUgc2NlbmFyaW8gY2Fubm90IGJlIGluY2x1ZGVkIGluIFJGQzQw ODcsIHN1Y2ggYXMgcG9pbnQgdG8gbXVsdGktcG9pbnQgdHVubmVsIGxpa2Ugc29mdHdpcmUgbWVz aC4NCj4gMikgSXQgc2VlbXMgeW91IG1pc3MgdGhlIGNvbmZvcm1hbmNlIHBhcnQgaW4gdGhlIGRl ZmluaXRpb24uDQo+IDMpIEknbSBub3QgcXVpdGUgc3VyZSB3aGF0J3MgdGhlICJzaXhSZElwdjRN YXNrTGVuICIgdXNlZCBmb3IsIGNhbiB5b3UgZXhwbGFpbiBpdD8NCj4gUmVnYXJkcyENCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IEppYW5nIERvbmcNCj4gVHNpbmdodWEgVW5pdmVyc2l0eQ0K PiA= ------=_001_NextPart530880628381_=---- Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi, Shishio,
 
Thanks for your reply and=20 clarification.
 
Best Regards!
Jiang Dong
Tsinghua University
2012-03-27
 
Date: 2012-03-26 22:19
To: jiangdong345
CC: cai.lei3; = jacni; softwires; cuiyong
Subject: Re: [Softwires]Comments about 6rd=20 MIB
Jiang
Thanks for comments.
I will do presentation this draft at&nb= sp;Friday,and I will ask which idea is = better to the audience and chairs.
If IP tunnel MIB extended is better&nbs= p;than 6rdMIB,so we would update and define&= nbsp;extension of IP tunnel MIB.
 
[DJ] I think RFC4087 is designed for common information about tunnels= . So=20 extra information that can not be included in RFC4087 need to be contained= in=20 specialized MIB such as 6rd, softwire mesh.
BTW, since 6rd can perform encapsulation in a stateless way, there is= no=20 need to maintain an encapsulation table. AFBRs in softwire mesh scenario n= eed to=20 perform I-IP encapsulation with E-IP prefix information, a we defined an=20 Encapsulation Table in the softwire mesh MIB. Comments are welcome : )
 
6rd MIB is completely reflecting to 6rd=  configuration.
http://tools.ietf.org/html/rfc5969#section-7
"sixRdIpv4MaskLen "  is same function a= s IPv4MaskLen.
 
IPv4MaskLen         The&= nbsp;number of high-order bits that are iden= tical
           &nb= sp;           acros= s all CE IPv4 addresses within a given&= nbsp;6rd
           &nb= sp;           domai= n.  For example, if there are no i= dentical
           &nb= sp;           bits,=  IPv4MaskLen is 0 and the entire CE&nbs= p;IPv4
           &nb= sp;           addre= ss is used to create the 6rd delegated<= /DIV>
           &nb= sp;           prefi= x.  If there are 8 identical bits = (e.g., the
           &nb= sp;           Priva= te IPv4 address range 10.0.0.0/8 is being
           &nb= sp;           used)= , IPv4MaskLen is equal to 8 and IPv4Mas= kLen
           &nb= sp;           high-= order bits are stripped from the IPv4
           &nb= sp;           addre= ss before constructing the corresponding 6rd
           &nb= sp;           deleg= ated prefix.
 
Regards,
-Shishio
 
(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> I get some comments about 6rd = ;MIB draft.
> 1) You mentioned the "tunnelIfXTable"&n= bsp;in section 5.2. I think it is a&nbs= p;good idea to extend the tunnel MIB, s= ome scenario cannot be included in RFC4087,&= nbsp;such as point to multi-point tunnel lik= e softwire mesh.
> 2) It seems you miss the conf= ormance part in the definition.
> 3) I'm not quite sure what's = the "sixRdIpv4MaskLen " used for, can you&nb= sp;explain it?
> Regards!
> -----------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= -------------------------------------------
> Jiang Dong
> Tsinghua University
> 
 
 
------=_001_NextPart530880628381_=------ From satoru.matsushima@gmail.com Mon Mar 26 20:54:30 2012 Return-Path: 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 D8D9321E8037 for ; Mon, 26 Mar 2012 20:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] 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 eyOROL9hh23B for ; Mon, 26 Mar 2012 20:54:30 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A485121E8019 for ; Mon, 26 Mar 2012 20:54:29 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4022764wib.13 for ; Mon, 26 Mar 2012 20:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+VZf+FDQyFpA7m6oQ8TGUiXMxZtqJNBDgyBmSlkNJcY=; b=wiZhq/MneToid6xVNoS5YIDF9uPr1rRfqJCA9g/OJryI1Xtp2IYsihE6O70FlOt5kK 1ExWyHNHkFBSvOsBM6XqX5XpCZAa0fxcyttEM5/ccEBSyqb5Erh5d6j2Tdlk87yKaPw4 BD1V7QKgi0yXddrm276UBor4yfUzeF6wIPhPqluEvrrRxRr2KE1Ixu0tM3EZEGFqHGon r7I82+aCAPDEaeDG3dM/SlKMvJBhoJLGPHz+u2vBYEki7QBIOcjDK6lkoSX2vRVi9DuW yAOEOtWRUSwxR9KFYNiWlR98RMH8mMFRjXsLJkfNt/bjdneiNKFSDLS1a/aaD9Mqhd15 RpUQ== Received: by 10.180.85.70 with SMTP id f6mr24067968wiz.5.1332820468852; Mon, 26 Mar 2012 20:54:28 -0700 (PDT) Received: from dhcp-453f.meeting.ietf.org (dhcp-453f.meeting.ietf.org. [130.129.69.63]) by mx.google.com with ESMTPS id gg2sm75670372wib.7.2012.03.26.20.54.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 20:54:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <15D8606F-0EB6-4A6B-927D-B5B2C861B285@employees.org> Date: Tue, 27 Mar 2012 05:54:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <240B8C21-D3A7-4E2B-B1FE-0520FCC8A9DD@gmail.com> References: <15D8606F-0EB6-4A6B-927D-B5B2C861B285@employees.org> To: Alain Durand , Softwires WG , Yong Cui , Ralph Droms X-Mailer: Apple Mail (2.1257) Subject: Re: [Softwires] =?iso-2022-jp?b?UGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0?= =?iso-2022-jp?b?cmQbJEIhRBsoQg==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 03:54:31 -0000 As a member of the MAT DT, I am naturally biased in favor of what Xing, = Maoke and Ole said. I also think that the chair's questions are not adequate. I don't think = that the questions should be which of document the wg choose, make = documents to be unified or not. I think that it should be what 'solution = space' has been clarified beyond the MAP suite. Let me try to figure = these out. 1. Reduce the number of parameters for MAP configuration The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', = 'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It = would be more convenient when one or some of them can be reduced or = omitted. 2. Trying to keep more header transparency=20 When operators think that it would be nice if the MAP-T can keep header = transparency, which includes checksum neutrality, beyond the current = header translation specification, the wg should be work on that, or ask = other wg to do that. 3. Truly 'Unified' operation=20 Since encapsulation and translation are completely separated operation = in operator's network (I mean 'polarized' on Jan's comment) but the = implementation of both is possible into one box. Beyond just 'unified = document', does operators think it would be more attractive with = 'unified' operation for which both encapsulation and translation = co-exist in same time, on same network, for same service. Above three are my thought of what 4rd-u proposed to the wg. Discussions = and more suggestions are welcome. Best regards, --satoru On 2012/03/23, at 10:46, Ole Tr=C3=B8an wrote: > Alain, et al, >=20 > we have been at an impasse, so thank you very much for proposing a = path forward. >=20 >> After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >> 1) There is an observation that all the solutions on the table E, T = & U actually solve the stateless problem we started with. >> There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation >> proposals, U is an hybrid unifying solution. >=20 > I do agree with that. the Venn diagram for the three solutions would = look awfully similar to a single circle. ;-) > there are some use cases though, that can only be fulfilled with one = mode of transport versus the other. > I left the interim meeting in Beijing having been convinced that there = are use cases requiring both encapsulation and requiring translation. if = we for a moment accept that, I would suggest that we treat MAP as one = single solution. it will have two options/flavours of transport. >=20 >> 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those >> documents have at IETF. In particular, do we want to publish them = as Experimental, Informational or Standard Track. >>=20 >> We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). >> Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >> Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask >> and their sequence. >>=20 >> Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? >>=20 >> If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. >> If the answer is YES, we move to the next question. >>=20 >>=20 >> Q2: Do you believe that the WG should publish U as the one Standards = Track document? >>=20 >> If the answer is YES, the process stop, we put U on the Standard = Track and publish E & T as Informational. >> If the answer is NO, we are left with E & T (U then might be = abandoned or published as Historical/Informational) >>=20 >>=20 >> Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >>=20 >> If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. >> If there is no clear consensus on this question, we will publish both = E & T as Experimental. >=20 > with the above proposal, we can drop question 3. >=20 >> In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. >=20 > can ask the chairs to take a hum of how many would want t-shirts for = the meeting with: "Just pick one for F's sake and stop arguing". ;-) >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Mon Mar 26 22:16:51 2012 Return-Path: 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 711AF21F8764 for ; Mon, 26 Mar 2012 22:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 W3Gv7at1YOWj for ; Mon, 26 Mar 2012 22:16:50 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1A21F84EA for ; Mon, 26 Mar 2012 22:16:50 -0700 (PDT) Received: by ggmi1 with SMTP id i1so4865847ggm.31 for ; Mon, 26 Mar 2012 22:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pWSIjvgdkiCbuhpJ37MEkMPCrVhbDFk1Sw7cX8QPETM=; b=OLH9iHedk+zURGpTFpl1iR8I90tdW7zAAiDMvk7nzpLk7P2DJ/2yv27oq8/Pkfu+/o bV3hW4tV/y3pgfkNKND3dnd5USMg2m0V3hPEY1dApJwAQWeN+vGCWb9kekFtQ6HydY/R f9DHB7ShN42CknQczRxtGXxHmEOqTIkL0lh+fWhQ8yNwyln6ImI/Oypxiifcm6H+WqjZ T9Lqy/qDPExqC6zUVxS+1YnPyPMRZfm1jGXq8YM3t9daLtUG1DnvNuazSaXomFZe5k2g jg5/2yzkHz+SsTSOWqkfRBOodi0GT+nnnqgC3K0LTr2tzhH9uzTm0ViSb+eoP2VCuOfZ 8WNQ== MIME-Version: 1.0 Received: by 10.68.193.231 with SMTP id hr7mr38342933pbc.44.1332825409657; Mon, 26 Mar 2012 22:16:49 -0700 (PDT) Received: by 10.143.63.10 with HTTP; Mon, 26 Mar 2012 22:16:49 -0700 (PDT) In-Reply-To: <201203260642.q2Q6g2Ix005775@givry.fdupont.fr> References: <2012032611425130665213@gmail.com> <201203260642.q2Q6g2Ix005775@givry.fdupont.fr> Date: Tue, 27 Mar 2012 13:16:49 +0800 Message-ID: From: Qi Sun To: Francis Dupont Content-Type: multipart/alternative; boundary=047d7b15a905171b9804bc3299ea Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:16:51 -0000 --047d7b15a905171b9804bc3299ea Content-Type: text/plain; charset=ISO-8859-1 Hi Francis, Thank you for your correction~ Here are some questions about the demo and SD-NAT. 1. As I see, the bindings of v6 and v4+ports are deterministic and pre-configured on the AFTR. Will it be of great cost if they are installed using NETCONF which is mentioned in one of Alain's emails? 2.About the DHCPv4 over IPv6 server, how do you deal with the Server ID option issue? 3.Does SD-NAT mechanism support the allocation of non-continuous port set (e.g. using GMA stated in MAP draft)? Thank you again! Qi Sun PS: If possible, will you post your picture? That would be great for me~ 2012/3/26 Francis Dupont > The principle is good, details are not: > - only switched (giga) Ethernets were used (no wireless) > - the PCP should get double arrow > - all SD-B4s run a PCP/NAT-PMP/UPnP-GID-v1+v2 server > (in fact they have the same kind of softwares, the laptop just offers > more tools, 10000 times larger stable storage, a screen where wireshark > can show packets, etc) > - the port range (never a set for the SD-CPE) was configured by > DHCPv4 over IPv6 too (ideally, we had time only for the static setup) > > Thanks > > Francis.Dupont@fdupont.fr > > PS: we have a picture too but I prefer to finish the demo setup than > to fix the picture (same effort, better result :-). > --047d7b15a905171b9804bc3299ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francis,

=A0 =A0 =A0 Thank you for your correction~
=A0 =A0 =A0 =A0Here are some questions about the demo and SD-NAT.
<= div>=A0 =A0 =A0=A0
=A0 =A0 =A0 1. As I see, the bindings of v6 an= d v4+ports are deterministic and pre-configured on the AFTR. Will it be of = great cost if they are installed using NETCONF which is mentioned in one of= Alain's emails?=A0
=A0 =A0 =A0 2.About the DHCPv4 over IPv6 server, how do you deal with = the Server ID option issue?
=A0 =A0 =A0 3.Does SD-NAT mechanism s= upport the allocation of non-continuous port set (e.g. using GMA stated in = MAP draft)?=A0

=A0 =A0 =A0 Thank you again!

Q= i Sun

PS: If possible, will you post your picture?= That would be great for me~

2012/3/26 Fr= ancis Dupont <Francis.Dupont@fdupont.fr>
The principle is good, details are not:
=A0- only switched (giga) Ethernets were used (no wireless)
=A0- the PCP should get double arrow
=A0- all SD-B4s run a PCP/NAT-PMP/UPnP-GID-v1+v2 server
=A0(in fact they have the same kind of softwares, the laptop just offers =A0 more tools, 10000 times larger stable storage, a screen where wireshar= k
=A0 can show packets, etc)
=A0- the port range (never a set for the SD-CPE) was configured by
=A0DHCPv4 over IPv6 too (ideally, we had time only for the static setup)
Thanks

Francis.Dupont@fdupont.fr<= br>
PS: we have a picture too but I prefer to finish the demo setup than
to fix the picture (same effort, better result :-).

--047d7b15a905171b9804bc3299ea-- From despres.remi@laposte.net Mon Mar 26 22:43:49 2012 Return-Path: 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 D1F3821F8769 for ; Mon, 26 Mar 2012 22:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.442, 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 NrNcJf3h-I-S for ; Mon, 26 Mar 2012 22:43:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6994C21F86FC for ; Mon, 26 Mar 2012 22:43:47 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id qVjk1i00737Y3f403VjkxR; Tue, 27 Mar 2012 07:43:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-185022496 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 07:43:44 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:43:50 -0000 --Apple-Mail-4-185022496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-27 =E0 02:38, Maoke a =E9crit : > dear Remi,=20 >=20 > i know you are very busy in Paris, Indeed. > but please respond to this thread. Response coming. Could you be less impatient? (There is also a night here, which is time = to rest!) RD > again, if i made anything wrong, please don't hesitate to point out. = thanks!=20 >=20 > best, > maoke >=20 > 2012/3/26 Maoke > =20 > dear Remi, > =20 > i think you won't be against if i change the subject of this specific = discussion, focusing on the routing issues regarding virtual link.=20 > 2012/3/26 R=E9mi Despr=E9s >> Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. >> Open to look at it. =20 >>=20 >> in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >>=20 >> first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >=20 > I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U. > =20 > =20 > by default, ebgp requires direct link (some implementations specify = TTL =3D 1 to achieve this). U decreases TTL when packet goes through = IPv6 cloud, and therefore CE---BR ebgp session cannot be established = with regular BGP configurations. >> second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >> \ = / >> \ = / >> +------------ CE ----(Another, IPv4 = domain)----------+ >=20 > Same comment. > =20 > =20 > similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact that = CE---BR are shown as multihop with tools like traceroute. > =20 > =20 >> third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >=20 > Same comment. > =20 > =20 > same misunderstanding. without knowing the details of the IPv6 domain = backbone, it is difficult for the operator to set up a proper value of = the TTL-security parameter for the OSPF regarding the CE---BR section. = virtual link (full encapsulation) eliminates this trouble. > =20 > =20 >=20 >> MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. >=20 > Why U would be less transparent between CEs and BRs than E for any L4 = protocol remains unexplained. > =20 > =20 > hope the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols. > =20 > =20 > =20 >> with at least the above three examples, i conclude "U cannot replace = E at all"! >=20 > See above. > =20 > =20 > see above. > =20 > - maoke > =20 > =20 >=20 >> (btw, surely the translation has the same limitation not to support = the above features but, e.g., as you also said, it opens transport-layer = stuff to the middle boxes). therefore i said operators may use either = encapsulation or translation according to what they attach importance = to.)=20 >=20 --Apple-Mail-4-185022496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
dear = Remi, 

i know you are very busy in = Paris, =

Indeed.

but please respond to this thread. =

Response coming.
Could you = be less impatient? (There is also a night here, which is time to = rest!)

RD

again, if i made anything wrong, please don't = hesitate to point out. thanks! 

best,
maoke

2012/3/26 = Maoke <fibrib@gmail.com>
 
dear Remi,
 
i think you = won't be against if i change the subject of this specific discussion, = focusing on the routing issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>
Different = understanding.
An detailed E use case that cannot be supported = by U (if it exists) would give substance to this = claim.
Open to look at it.  

in my personal experience i could give you at least three = quick examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 = customer network plays BGP over IPv4 with the provider, through the BGP = session between CE and BR, a virtual link is desired. 

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 = world) 

I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U.
 
 
by = default, ebgp requires direct link (some implementations specify TTL =3D = 1 to achieve this). U decreases TTL when packet goes through IPv6 = cloud, and therefore CE---BR ebgp session cannot be = established with regular BGP configurations.
second = example, there are dynamic routing protocols like RIP running in the = following (multihoming) topology for IPv4 routing. the operator may want = to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation.

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 world) 
  =              \       =                     =                     =          /
      =           \           =                     =                     =    /
                =  +------------ CE ----(Another, IPv4 = domain)----------+

Same= = comment.
 
 
<= div>similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact = that CE---BR are shown as multihop with tools like traceroute. =
 
 
third example, same topology as above = but OSPF are applied, and OSPF TTL-security check are enabled to ensure = hop-passings less than a specified threshold. if the operator would like = to treat CE---(IPv6-only domain)---BR as one hop because it is = considered as virtual link, 4rd-u's rudiness in decreasing TTL will = hurt. 

Same = comment.
 
 
<= div>same misunderstanding. without knowing the details of the IPv6 = domain backbone, it is difficult for the operator to set up a proper = value of the TTL-security parameter for the OSPF regarding the CE---BR = section. virtual link (full encapsulation) eliminates this trouble. =
 
 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing = protocols.

Why U = would be less transparent between CEs and BRs than E for any L4 protocol = remains unexplained.
=
 
 
hope= the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols.
 
 
 
with at least the above three examples, = i conclude "U cannot replace E at all"! =

See = above.
 
 
see above.
 
- maoke =
 
 

(btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.) 


= --Apple-Mail-4-185022496-- From despres.remi@laposte.net Mon Mar 26 22:44:07 2012 Return-Path: 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 BA4DD21F8781 for ; Mon, 26 Mar 2012 22:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 VDfBuu-sXHAJ for ; Mon, 26 Mar 2012 22:44:06 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6871621F86FC for ; Mon, 26 Mar 2012 22:44:04 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7C49C940051; Tue, 27 Mar 2012 07:43:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-185028403 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 07:43:50 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:44:07 -0000 --Apple-Mail-5-185028403 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Maoke, Thanks for clarifying what you meant. I now understand that you were referring to applications that might = require IPv4 dialogue between one link apart nodes. Whether this is a real use case in the MAP-4rd context remains however = to be seen. Here are my immediate comments: a) This wasn't mentioned as one of the desirable features of stateless = solutions. b) Since MAP-T can't satisfy such a requirement, and there has been = promoters of MAP-T as a sufficient standard, this casts some doubt or = reality of this requirement. c) If the requirement is nevertheless confirmed, it can be satisfied = AFAIK by an ad hoc complement to 4rd-U. (At least one one approach I see = consists in using the 7 remaining bits of IPv6 packet IDs for this). I = would be glad to share w details with you, but only after the WG would = confirm that there is a real need. (Let's not say that because there is = a solution there is a need.) d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do = you know a better reference than this RFC? Regards, RD Le 2012-03-26 =E0 15:48, Maoke a =E9crit : > =20 > dear Remi, > =20 > i think you won't be against if i change the subject of this specific = discussion, focusing on the routing issues regarding virtual link.=20 > 2012/3/26 R=E9mi Despr=E9s >> Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. >> Open to look at it. =20 >>=20 >> in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >>=20 >> first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >=20 > I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U. > =20 > =20 > by default, ebgp requires direct link (some implementations specify = TTL =3D 1 to achieve this). U decreases TTL when packet goes through = IPv6 cloud, and therefore CE---BR ebgp session cannot be established = with regular BGP configurations. >> second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >>=20 >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >> \ = / >> \ = / >> +------------ CE ----(Another, IPv4 = domain)----------+ >=20 > Same comment. > =20 > =20 > similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact that = CE---BR are shown as multihop with tools like traceroute. > =20 > =20 >> third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >=20 > Same comment. > =20 > =20 > same misunderstanding. without knowing the details of the IPv6 domain = backbone, it is difficult for the operator to set up a proper value of = the TTL-security parameter for the OSPF regarding the CE---BR section. = virtual link (full encapsulation) eliminates this trouble. > =20 > =20 >=20 >> MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. >=20 > Why U would be less transparent between CEs and BRs than E for any L4 = protocol remains unexplained. > =20 > =20 > hope the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols. > =20 > =20 > =20 >> with at least the above three examples, i conclude "U cannot replace = E at all"! >=20 > See above. > =20 > =20 > see above. > =20 > - maoke > =20 > =20 >=20 >> (btw, surely the translation has the same limitation not to support = the above features but, e.g., as you also said, it opens transport-layer = stuff to the middle boxes). therefore i said operators may use either = encapsulation or translation according to what they attach importance = to.)=20 --Apple-Mail-5-185028403 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = Maoke,

Thanks for clarifying what you = meant.
I now understand that you were referring to = applications that might require IPv4 dialogue between one link apart = nodes.

Whether this is a real use case in the = MAP-4rd context remains however to be seen.
Here are my = immediate comments:
a) This wasn't mentioned as one of the = desirable features of stateless solutions.
b) Since MAP-T = can't satisfy such a requirement, and there has been promoters of MAP-T = as a sufficient standard, this casts some doubt or reality of this = requirement.
c) If the requirement is nevertheless confirmed, = it can be satisfied AFAIK by an ad hoc complement to 4rd-U. (At least = one one approach I see consists in using the 7 remaining bits of IPv6 = packet IDs for this). I would be glad to share w details with you, but = only after the WG would confirm that there is a real need. (Let's not = say that because there is a solution there is a need.)
d) I = didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do you = know a better reference than this = RFC?

Regards,
RD


Le 2012-03-26 =E0 15:48, Maoke a =E9crit :

 
dear = Remi,
 
i think you won't be against if i = change the subject of this specific discussion, focusing on the routing = issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Different = understanding.
An detailed E use case that cannot be supported = by U (if it exists) would give substance to this = claim.
Open to look at it.  

in my personal experience i could give you at least three = quick examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 = customer network plays BGP over IPv4 with the provider, through the BGP = session between CE and BR, a virtual link is desired. 

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 = world) 

I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U.
 
 
by = default, ebgp requires direct link (some implementations specify TTL =3D = 1 to achieve this). U decreases TTL when packet goes through IPv6 = cloud, and therefore CE---BR ebgp session cannot be = established with regular BGP configurations.
second = example, there are dynamic routing protocols like RIP running in the = following (multihoming) topology for IPv4 routing. the operator may want = to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation.

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 world) 
  =              \       =                     =                     =          /
      =           \           =                     =                     =    /
                =  +------------ CE ----(Another, IPv4 = domain)----------+

Same= = comment.
 
 
<= div>similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact = that CE---BR are shown as multihop with tools like traceroute. =
 
 
third example, same topology as above = but OSPF are applied, and OSPF TTL-security check are enabled to ensure = hop-passings less than a specified threshold. if the operator would like = to treat CE---(IPv6-only domain)---BR as one hop because it is = considered as virtual link, 4rd-u's rudiness in decreasing TTL will = hurt. 

Same = comment.
 
 
<= div>same misunderstanding. without knowing the details of the IPv6 = domain backbone, it is difficult for the operator to set up a proper = value of the TTL-security parameter for the OSPF regarding the CE---BR = section. virtual link (full encapsulation) eliminates this trouble. =
 
 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing = protocols.

Why U = would be less transparent between CEs and BRs than E for any L4 protocol = remains unexplained.
=
 
 
hope= the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols.
 
 
 
with at least the = above three examples, i conclude "U cannot replace E at all"! =

See = above.
 
 
see above.
 
- maoke =
 
 

(btw, surely the translation has the = same limitation not to support the above features but, e.g., as you also = said, it opens transport-layer stuff to the middle boxes). therefore i = said operators may use either encapsulation or translation according to = what they attach importance to.) 

= --Apple-Mail-5-185028403-- From fibrib@gmail.com Mon Mar 26 23:41:48 2012 Return-Path: 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 053C121F8775 for ; Mon, 26 Mar 2012 23:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 2Y7ngyXLk7yB for ; Mon, 26 Mar 2012 23:41:46 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5440121F8771 for ; Mon, 26 Mar 2012 23:41:46 -0700 (PDT) Received: by qaea16 with SMTP id a16so2660078qae.10 for ; Mon, 26 Mar 2012 23:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yKiQGs3q9g3l9Kl0Fry5EXjMS+U925PtvUoMHonsTO4=; b=ZXw7t3HYmKwtWp1bFFsRRqQU3EoyBWlVdiN9Pw1EZySfxjkitXgzYMB0h4ymqxoe34 D8fDQVjUZopaW1ryOpaBDdqfFgkbiOb2OAIZ23S8jAnKG1f/eUzVJMJEbfe0CsB99j9y T9scUcuzk9diLhO9B3d9cNHVnCb4hBjF+oeFmG/zUOjv25jCKoqB5XP8HYwrqEDy7BUO 3j0gc7k+xL7W4S3Qd6/xgOqDrBqIztvmo70y1/alo3TMDnd8cLT13YD6stb+zpbGXcrB bC74RIZv1p+4ctpIpSnnQo0hQFh1Lta4d7yfVWGLEgNZxp+LosCgYXFI+bYk397peDkp IkFQ== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr31331858qab.11.1332830505797; Mon, 26 Mar 2012 23:41:45 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 26 Mar 2012 23:41:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 06:41:45 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b4b8d8089204bc33c827 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 06:41:48 -0000 --20cf3074b4b8d8089204bc33c827 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, sorry but i forgot the time difference this morning. thanks for the quick response! 2012/3/27 R=E9mi Despr=E9s > Dear Maoke, > > Thanks for clarifying what you meant. > I now understand that you were referring to applications that might > require IPv4 dialogue between one link apart nodes. > > Whether this is a real use case in the MAP-4rd context remains however to > be seen. > if 4rd-u is limited to a very constrained scope, it is no problem. but people surely want to have a scalable solution. i listed issues of both inter-domain and intra-domain routing and i believe supporting some dynamic routing in the MAP domain is a natural requirement. > Here are my immediate comments: > a) This wasn't mentioned as one of the desirable features of stateless > solutions. > any encapsulation is commonly, well understood to have such a feature without need of further explanation, without need of adding any elements in standard. we are now seldom discussing about the routing issue in the stateless solutions but we cannot block up the road to the real operation. > b) Since MAP-T can't satisfy such a requirement, and there has been > promoters of MAP-T as a sufficient standard, this casts some doubt or > reality of this requirement. > well, my predicted response from you. :) please NOTE: MAP-T has never said it can "replace E". this thread is about the importance of virtual link as an architectural building block that 4rd-u cannot offer. MAP-T has none of business with this topic, because it is never considered virtual link. what i am arguing against, in this thread, is that "once operator has U it doesn't need either E or T". my point here is: 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is a unified solution" is NOT qualified. it is not the topic of this thread if 4rd-u can replace MAP-T or not. i will go deep in that later, in another thread. > c) If the requirement is nevertheless confirmed, it can be satisfied AFAI= K > by an ad hoc complement to 4rd-U. (At least one one approach I see consis= ts > in using the 7 remaining bits of IPv6 packet IDs for this). I would be gl= ad > to share w details with you, but only after the WG would confirm that the= re > is a real need. (Let's not say that because there is a solution there is = a > need.) > another predicted patch idea. but i doubt 7 bit can represent TTL =3D 255 correctly. > d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do you > know a better reference than this RFC? > RFC2260 is informational rather than standard. BGP4 specification is RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i mentioned, is not a standard feature, but used in some implementations (including Cisco IOS and Juniper JUNOS and the open-source routing tool Quagga, to my best knowledge) in order to ensure the standard feature that defaultly EBGP is established over an immediate link. as a quick evidence of the implementation, in bgpd.c of quagga suite we may read the piece of source code: peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); it is saying, if the peer is IBGP, the TTL of IP header carrying it should be set to 255; while if it is EBGP, TTL should be 1. regards, maoke > > Regards, > RD > > > Le 2012-03-26 =E0 15:48, Maoke a =E9crit : > > > dear Remi, > > i think you won't be against if i change the subject of this specific > discussion, focusing on the routing issues regarding virtual link. > 2012/3/26 R=E9mi Despr=E9s > >> Different understanding. >>> An detailed E use case that cannot be supported by U (if it >>> exists) would give substance to this claim. >>> Open to look at it. >>> >> >> in my personal experience i could give you at least three quick examples >> of the use case for the building block of "virtual link": >> >> first example, if the IPv4 customer network plays BGP over IPv4 with the >> provider, through the BGP session between CE and BR, a virtual link is >> desired. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> >> >> I don't see in this scenario why anything that works with E (i.e. betwee= n >> CEs and BRs) wouldn't also work with U. >> >> > > by default, ebgp requires direct link (some implementations specify TTL = =3D > 1 to achieve this). U decreases TTL when packet goes through IPv6 > cloud, and therefore CE---BR ebgp session cannot be > established with regular BGP configurations. > >> second example, there are dynamic routing protocols like RIP running in >> the following (multihoming) topology for IPv4 routing. the operator may >> want to treat the CE-BR as a single hop in order the virtual link is >> considered the distance vector calculation. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> \ = / >> \ / >> +------------ CE ----(Another, IPv4 domain)----------+ >> >> >> Same comment. >> >> > > similar misunderstanding. RIP distance vectors are delivered to > neighbors but the operators are easy to be confused by the fact that > CE---BR are shown as multihop with tools like traceroute. > > >> >> >> third example, same topology as above but OSPF are applied, and OSPF >> TTL-security check are enabled to ensure hop-passings less than a specif= ied >> threshold. if the operator would like to treat CE---(IPv6-only domain)--= -BR >> as one hop because it is considered as virtual link, 4rd-u's rudiness in >> decreasing TTL will hurt. >> >> >> Same comment. >> >> > > same misunderstanding. without knowing the details of the IPv6 domain > backbone, it is difficult for the operator to set up a proper value of th= e > TTL-security parameter for the OSPF regarding the CE---BR section. virtua= l > link (full encapsulation) eliminates this trouble. > > >> >> >> MAP-E (and other E) surely has no limitation in supporting any features >> of existing routing protocols. >> >> >> Why U would be less transparent between CEs and BRs than E for any L4 >> protocol remains unexplained. >> >> > > hope the above helps. it is not about the transparency but about the > behavior of virtual link. it is not about any L4 protocol but about routi= ng > protocols. > > >> >> >> >> with at least the above three examples, i conclude "U cannot replace E a= t >> all"! >> >> >> See above. >> >> > > see above. > > - maoke > > >> >> >> (btw, surely the translation has the same limitation not to support the >> above features but, e.g., as you also said, it opens transport-layer stu= ff >> to the middle boxes). therefore i said operators may use either >> encapsulation or translation according to what they attach importance to= .) >> >> > --20cf3074b4b8d8089204bc33c827 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,=A0

sorry but i forgot the time= difference this morning. thanks for the quick response!

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
Dear Mao= ke,

Thanks for clarifying what you meant.
I no= w understand that you were referring to applications that might require IPv= 4 dialogue between one link apart nodes.

Whether this is a real use case in the MAP-4rd context = remains however to be seen.

if = 4rd-u is limited to a very constrained scope, it is no problem. but people = surely want to have a scalable solution. i listed issues of both inter-doma= in and intra-domain routing and i believe supporting some dynamic routing i= n the MAP domain is a natural requirement.=A0
=A0
Here are my immediate comments:
a) This wasn't men= tioned as one of the desirable features of stateless solutions.

any encapsulation is commonly, well = understood to have such a feature without need of further explanation, with= out need of adding any elements in standard. we are now seldom discussing a= bout the routing issue in the stateless solutions but we cannot block up th= e road to the real operation.=A0
=A0
b) Since MAP-T can't satisfy such a requirement, and there h= as been promoters of MAP-T as a sufficient standard, this casts some doubt = or reality of this requirement.

well, my predicted response from you= . :) please NOTE: MAP-T has never said it can "replace E". this t= hread is about the importance of virtual link as an architectural building = block that 4rd-u cannot offer. MAP-T has none of business with this topic, = because it is never considered virtual link. what i am arguing against, in = this thread, is that "once operator has U it doesn't need either E= or T". my point here is: 4rd-u cannot replace MAP-E, and accordingly = the statement "4rd-u is a unified solution" is NOT qualified.=A0<= /div>

it is not the topic of this thread if 4rd-u can replace= MAP-T or not. i will go deep in that later, in another thread.=A0
=A0
c) If the requirement is neverthel= ess confirmed, it can be satisfied AFAIK by an ad hoc complement to 4rd-U. = (At least one one approach I see consists in using the 7 remaining bits of = IPv6 packet IDs for this). I would be glad to share w details with you, but= only after the WG would confirm that there is a real need. (Let's not = say that because there is a solution there is a need.)

another predicted patch idea. but i = doubt 7 bit can represent TTL =3D 255 correctly.=A0
=A0
d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than th= is RFC?

RFC2260 is informationa= l rather than standard. BGP4 specification is RFC4271 and you may be intere= sted in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i mentioned, is not a = standard feature, but used in some implementations (including Cisco IOS and= Juniper JUNOS and the open-source routing tool Quagga, to my best knowledg= e) in order to ensure the standard feature that defaultly EBGP is establish= ed over an immediate link. as a quick evidence of the implementation, in bg= pd.c of quagga suite we may read the piece of source code:=A0

=A0 =A0peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PE= ER_IBGP ? 255 : 1);

it is saying, if the peer is I= BGP, the TTL of IP header carrying it should be set to 255; while if it is = EBGP, TTL should be 1.=A0

regards,
maoke
=A0

Regards,
RD


Le 2012-03-26 =E0 15:48, Mao= ke a =E9crit :

=A0
dear Remi,
=A0
i think you won't b= e against if i change the subject of this specific discussion, focusing on = the routing issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>=
Different understanding.
An detailed E use case that cannot be supported by U=A0(if it exists)=A0wo= uld give substance to this claim.
Open to look at it. =A0

in my personal experience i could give you at least three qu= ick examples of the use case for the building block of "virtual link&q= uot;:=A0

first example, if the IPv4 customer netwo= rk plays BGP over IPv4 with the provider, through the BGP session between C= E and BR, a virtual link is desired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
<= br>
I don't see in this scenario why anything tha= t works with E (i.e. between CEs and BRs) wouldn't also work with U.
=A0
=A0
by default, ebgp = requires direct link (some implementations specify TTL =3D 1 to achieve thi= s). U decreases TTL when packet goes through IPv6 cloud,=A0and therefore CE= ---BR ebgp=A0session cannot be established=A0with=A0regular=A0BGP configura= tions.
second example, t= here are dynamic routing protocols like RIP running in the following (multi= homing) topology for IPv4 routing. the operator may want to treat the CE-BR= as a single hop in order the virtual link is considered the distance vecto= r calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

Same= comment.
=A0
=A0
si= milar misunderstanding. RIP distance vectors are delivered to neighbors=A0b= ut the operators are easy to be confused by the fact that CE---BR are shown= as=A0multihop with tools like traceroute.
=A0
=A0
th= ird example, same topology as above but OSPF are applied, and OSPF TTL-secu= rity check are enabled to ensure hop-passings less than a specified thresho= ld. if the operator would like to treat CE---(IPv6-only domain)---BR as one= hop because it is considered as virtual link, 4rd-u's rudiness in decr= easing TTL will hurt.=A0

Same comment.
=A0
=A0
same misunderstanding. with= out knowing the details of the IPv6 domain backbone, it is difficult for th= e operator to set up a proper value of the TTL-security parameter for the O= SPF regarding the CE---BR section. virtual link (full encapsulation) elimin= ates this trouble.
=A0
=A0

MAP-E (and other E) surely has no limitation in supporting any feature= s of existing routing protocols.

Why U would be less transparent between CEs and BRs than E fo= r any L4 protocol remains unexplained.
=A0
=A0
hope the ab= ove helps. it is not about the transparency but about the behavior of virtu= al link. it is not about any L4 protocol but about routing protocols.
=A0
=A0
=A0
with at least the above three examples, i conclude "U= cannot replace E at all"!

See above.
=A0
=A0
see above.
=A0
- maoke
=A0
=A0

(btw, surely the t= ranslation has the same limitation not to support the above features but, e= .g., as you also said, it opens transport-layer stuff to the middle boxes).= therefore i said operators may use either encapsulation or translation acc= ording to what they attach importance to.)=A0


--20cf3074b4b8d8089204bc33c827-- From fibrib@gmail.com Mon Mar 26 23:56:32 2012 Return-Path: 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 5A25C21F85A5 for ; Mon, 26 Mar 2012 23:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 td5btETcGY67 for ; Mon, 26 Mar 2012 23:56:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B221F859B for ; Mon, 26 Mar 2012 23:56:31 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4409313qcs.31 for ; Mon, 26 Mar 2012 23:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pSQLWlFB8Fipl9Apa78IdPPSV/vU7KgC6rqkUb8HzWk=; b=OJT1Pxvhh1vzh/uf6fvHNj2f3EmMA4n1hyONayMy5qdvY7MU3HU4UZtWLoAc2A07/F HDuwnlJEqbNfyoH2qY1d2GrMtYjwjrQHI/HvfisogwlN/JNcu4dw9YW77yw1uzLW4qbc 9uGOJ2HTh6LzhU+9FRufRDLE4IjcxOt/raz+yB665zC9MMLpNDi3II4ylrPsCMmHLBDl 5rGPyhEGBYbG6nZKYepQcQKw+sd8/6xO+ipfc77SB/nBfYDpGc8ZkNDUBMNtVgIMLu4P /Y93c28kDsWsfVwLFNtv4UZLqutwqEJj5c+CFCEju5RiLfPW93Qks2mHQZnZa9o8lTPr AGew== MIME-Version: 1.0 Received: by 10.229.135.207 with SMTP id o15mr9441479qct.51.1332831390640; Mon, 26 Mar 2012 23:56:30 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Mon, 26 Mar 2012 23:56:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 06:56:30 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c7690fe95ad0504bc33fd34 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 06:56:32 -0000 --00248c7690fe95ad0504bc33fd34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/27 R=E9mi Despr=E9s > Dear Maoke, > > Thanks for clarifying what you meant. > I now understand that you were referring to applications that might > require IPv4 dialogue between one link apart nodes. > btw, conceptually i don't suggest to call them "applications". actually BGP is running over TCP but OSPF is over IP directly. they are of the components of Internet infrastructure. the same understanding applies to ICMP as well. - maoke > > Whether this is a real use case in the MAP-4rd context remains however to > be seen. > Here are my immediate comments: > a) This wasn't mentioned as one of the desirable features of stateless > solutions. > b) Since MAP-T can't satisfy such a requirement, and there has been > promoters of MAP-T as a sufficient standard, this casts some doubt or > reality of this requirement. > c) If the requirement is nevertheless confirmed, it can be satisfied AFAI= K > by an ad hoc complement to 4rd-U. (At least one one approach I see consis= ts > in using the 7 remaining bits of IPv6 packet IDs for this). I would be gl= ad > to share w details with you, but only after the WG would confirm that the= re > is a real need. (Let's not say that because there is a solution there is = a > need.) > d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do you > know a better reference than this RFC? > > Regards, > RD > > > Le 2012-03-26 =E0 15:48, Maoke a =E9crit : > > > dear Remi, > > i think you won't be against if i change the subject of this specific > discussion, focusing on the routing issues regarding virtual link. > 2012/3/26 R=E9mi Despr=E9s > >> Different understanding. >>> An detailed E use case that cannot be supported by U (if it >>> exists) would give substance to this claim. >>> Open to look at it. >>> >> >> in my personal experience i could give you at least three quick examples >> of the use case for the building block of "virtual link": >> >> first example, if the IPv4 customer network plays BGP over IPv4 with the >> provider, through the BGP session between CE and BR, a virtual link is >> desired. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> >> >> I don't see in this scenario why anything that works with E (i.e. betwee= n >> CEs and BRs) wouldn't also work with U. >> >> > > by default, ebgp requires direct link (some implementations specify TTL = =3D > 1 to achieve this). U decreases TTL when packet goes through IPv6 > cloud, and therefore CE---BR ebgp session cannot be > established with regular BGP configurations. > >> second example, there are dynamic routing protocols like RIP running in >> the following (multihoming) topology for IPv4 routing. the operator may >> want to treat the CE-BR as a single hop in order the virtual link is >> considered the distance vector calculation. >> >> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR >> ----(IPv4 world) >> \ = / >> \ / >> +------------ CE ----(Another, IPv4 domain)----------+ >> >> >> Same comment. >> >> > > similar misunderstanding. RIP distance vectors are delivered to > neighbors but the operators are easy to be confused by the fact that > CE---BR are shown as multihop with tools like traceroute. > > >> >> >> third example, same topology as above but OSPF are applied, and OSPF >> TTL-security check are enabled to ensure hop-passings less than a specif= ied >> threshold. if the operator would like to treat CE---(IPv6-only domain)--= -BR >> as one hop because it is considered as virtual link, 4rd-u's rudiness in >> decreasing TTL will hurt. >> >> >> Same comment. >> >> > > same misunderstanding. without knowing the details of the IPv6 domain > backbone, it is difficult for the operator to set up a proper value of th= e > TTL-security parameter for the OSPF regarding the CE---BR section. virtua= l > link (full encapsulation) eliminates this trouble. > > >> >> >> MAP-E (and other E) surely has no limitation in supporting any features >> of existing routing protocols. >> >> >> Why U would be less transparent between CEs and BRs than E for any L4 >> protocol remains unexplained. >> >> > > hope the above helps. it is not about the transparency but about the > behavior of virtual link. it is not about any L4 protocol but about routi= ng > protocols. > > >> >> >> >> with at least the above three examples, i conclude "U cannot replace E a= t >> all"! >> >> >> See above. >> >> > > see above. > > - maoke > > >> >> >> (btw, surely the translation has the same limitation not to support the >> above features but, e.g., as you also said, it opens transport-layer stu= ff >> to the middle boxes). therefore i said operators may use either >> encapsulation or translation according to what they attach importance to= .) >> >> > --00248c7690fe95ad0504bc33fd34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.n= et>
Dear Maoke,

Thanks f= or clarifying what you meant.
I now understand that you were refe= rring to applications that might require IPv4 dialogue between one link apa= rt nodes.

btw, conceptually i don't sugges= t to call them "applications". actually BGP is running over TCP b= ut OSPF is over IP directly. they are of the components of Internet infrast= ructure. the same understanding applies to ICMP as well. - maoke
=A0

Whether this is a real use case in the MAP-4rd co= ntext remains however to be seen.
Here are my immediate comments:
a) This wasn't mentioned= as one of the desirable features of stateless solutions.
b) Sinc= e MAP-T can't satisfy such a requirement, and there has been promoters = of MAP-T as a sufficient standard, this casts some doubt or reality of this= requirement.
c) If the requirement is nevertheless confirmed, it can be satisfied A= FAIK by an ad hoc complement to 4rd-U. (At least one one approach I see con= sists in using the 7 remaining bits of IPv6 packet IDs for this). I would b= e glad to share w details with you, but only after the WG would confirm tha= t there is a real need. (Let's not say that because there is a solution= there is a need.)
d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260.= Do you know a better reference than this RFC?

Reg= ards,
RD


Le 2012-03-26 =E0= 15:48, Maoke a =E9crit :

=A0
dea= r Remi,
=A0
i think you won't be against if i chang= e the subject of this specific discussion, focusing on the routing issues r= egarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>=
Different understanding.
An detailed E use case that cannot be supported by U=A0(if it exists)=A0wo= uld give substance to this claim.
Open to look at it. =A0

in my personal experience i could give you at least three qu= ick examples of the use case for the building block of "virtual link&q= uot;:=A0

first example, if the IPv4 customer netwo= rk plays BGP over IPv4 with the provider, through the BGP session between C= E and BR, a virtual link is desired.=A0

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
<= br>
I don't see in this scenario why anything tha= t works with E (i.e. between CEs and BRs) wouldn't also work with U.
=A0
=A0
by default, ebgp = requires direct link (some implementations specify TTL =3D 1 to achieve thi= s). U decreases TTL when packet goes through IPv6 cloud,=A0and therefore CE= ---BR ebgp=A0session cannot be established=A0with=A0regular=A0BGP configura= tions.
second example, t= here are dynamic routing protocols like RIP running in the following (multi= homing) topology for IPv4 routing. the operator may want to treat the CE-BR= as a single hop in order the virtual link is considered the distance vecto= r calculation.

=A0 =A0 (IPv4 customer network)--- CE ----(IPv6-on= ly domain)----- BR ----(IPv4 world)=A0
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+------------ CE ----(Another, IPv4= domain)----------+

Same= comment.
=A0
=A0
si= milar misunderstanding. RIP distance vectors are delivered to neighbors=A0b= ut the operators are easy to be confused by the fact that CE---BR are shown= as=A0multihop with tools like traceroute.
=A0
=A0
th= ird example, same topology as above but OSPF are applied, and OSPF TTL-secu= rity check are enabled to ensure hop-passings less than a specified thresho= ld. if the operator would like to treat CE---(IPv6-only domain)---BR as one= hop because it is considered as virtual link, 4rd-u's rudiness in decr= easing TTL will hurt.=A0

Same comment.
=A0
=A0
same misunderstanding. with= out knowing the details of the IPv6 domain backbone, it is difficult for th= e operator to set up a proper value of the TTL-security parameter for the O= SPF regarding the CE---BR section. virtual link (full encapsulation) elimin= ates this trouble.
=A0
=A0

MAP-E (and other E) surely has no limitation in supporting any feature= s of existing routing protocols.

Why U would be less transparent between CEs and BRs than E fo= r any L4 protocol remains unexplained.
=A0
=A0
hope the ab= ove helps. it is not about the transparency but about the behavior of virtu= al link. it is not about any L4 protocol but about routing protocols.
=A0
=A0
=A0
with at least the above three examples, i conclude "U= cannot replace E at all"!

See above.
=A0
=A0
see above.
=A0
- maoke
=A0
=A0

(btw, surely the t= ranslation has the same limitation not to support the above features but, e= .g., as you also said, it opens transport-layer stuff to the middle boxes).= therefore i said operators may use either encapsulation or translation acc= ording to what they attach importance to.)=A0


--00248c7690fe95ad0504bc33fd34-- From Francis.Dupont@fdupont.fr Tue Mar 27 00:48:17 2012 Return-Path: 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 9FBDE21F8754 for ; Tue, 27 Mar 2012 00:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] 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 sPYOirOdxfLJ for ; Tue, 27 Mar 2012 00:48:15 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7F21F84FA for ; Tue, 27 Mar 2012 00:48:14 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2R7lLdd001070; Tue, 27 Mar 2012 09:47:21 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203270747.q2R7lLdd001070@givry.fdupont.fr> From: Francis Dupont To: Qi Sun In-reply-to: Your message of Tue, 27 Mar 2012 13:16:49 +0800. Date: Tue, 27 Mar 2012 09:47:21 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:48:18 -0000 In your previous mail you wrote: > Here are some questions about the demo and SD-NAT. > > 1. As I see, the bindings of v6 and v4+ports are deterministic and > pre-configured on the AFTR. Will it be of great cost if they are installed > using NETCONF which is mentioned in one of Alain's emails? => it seems the question is about the ISC AFTR and not AFTR in general: the ISC AFTR uses a configuration file (ASCII text), you can change it and push it to the running daemon using a (smooth) reload or a (hard) reboot command (there is no dynamic NAT entries to lose so it doesn't matter :-). Now the provisioning system can use what it wants, we even provide some XML tools to manage and push the config... BTW for the demo I wrote some python scripts and use the built-in A+P/PRR support (I am more concerned about this as the full NAT code is more than over engineered for its use in a SD-AFTR :-). > 2.About the DHCPv4 over IPv6 server, how do you deal with the Server > ID option issue? => I didn't configure the server to send one (it is possible but I believe it is not in the spirit of the I-D). Fortunately the ISC DHCPv4 client doesn't require a server ID option so it works without hacks. Note this behavior is compliant but the opposite one (require a server ID option and drop all DHCPOFFER without one) is compliant too. > 3.Does SD-NAT mechanism support the allocation of non-continuous port > set (e.g. using GMA stated in MAP draft)? => SD-NAT is ambiguous: - I think the SD-CPE / SD-B4 should only support a range (i.e., continuous set) because as far as I know it is already supported by all SD-CPEs without changing a line of code (i.e., to transform a CPE / B4 into a SD-CPE / SD-B4 you need to change some (one for a CPE using Linux) lines in the config. So even there are any reasons this point is critical for the deployment. - the SD-CGN / SD-AFTR is different. I believe it should propose a GMA stateless/deterministic/algorithmic translation. So I wrote to a python script generating an ISC AFTR config with static NAT entries but for the demo I started with no translation aka A+P aka PRR config because it was simpler, suitable for a demo, etc, and I had the good surprise to discover it is compatible too with the new version of the SD-NAT document (even I disagree about this change :-). Regards Francis.Dupont@fdupont.fr From phdgang@gmail.com Tue Mar 27 00:53:31 2012 Return-Path: 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 CA38221F87D6 for ; Tue, 27 Mar 2012 00:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 b64eXPHcaj9J for ; Tue, 27 Mar 2012 00:53:30 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6121F87D3 for ; Tue, 27 Mar 2012 00:53:30 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4140568wib.13 for ; Tue, 27 Mar 2012 00:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZdaYeFzV6JEs9hzVBoEoeQeFvmKlgxseb0kJONnZGmQ=; b=bGj517JHplmuQZ32xJeRkhwl2FDJNuHkGftW/dC92AICuAqtMxw7oXitJB40TSyb5G dt4k44FDavX9D9D3D5ltFm+OD/yaxmzwlO8n5WhigcYaNSsV7TdmKmolkKak2POT5HYd 17srY96D46FVff63NwFQ+EgLXI9pf7v2I82jPDxWoPrHMqYi0arNdRf8FxC22gt+kFOt NnDjgjKFSs5dFyw7aR5qCbo7c4+pGzxU07GhMHqWMY2Lw1IdxaCI8bhMm5/vBWJDW512 +NwDod9eNkesvjowYhqXYPS2vpMZAgk54+MQnkdE/fjkMQ13r8z01NXnVQ9aT8/WRp3/ miEg== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr29418901wib.3.1332834809474; Tue, 27 Mar 2012 00:53:29 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 27 Mar 2012 00:53:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 15:53:29 +0800 Message-ID: From: GangChen To: Kevin Y Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:53:31 -0000 Hello Kevin and all, I actually see current multiple solution proposal from different angle. Regarding the changes you mentioned, MAP-T/E is also doing that, e.g. added fragmentation header to survive DF bit; change ICMP ID filed to carry the port information. 4rd-U doesn't beat MAP-series. I prefer to understand the situation is 4rd-U raised some points(e.g. CNP, Fully IPv4 transparency) which is desirable heading to a perfect protocol design. BRs Gang 2012/3/27, Kevin Y : > Hi, Remi, > > This is beyond the charter of softwire WG, changing IPv6 address format > needs much broad discussion in IETF community to understand its impact > first, before we should even discuss if it is valid to design something > like this in softwire. Have you done that ? > > Best Regards, > > Kevin Yin > > On Thu, Mar 22, 2012 at 10:04 PM, Guanghui Yu wro= te: > >> Hi Yiu >> >> 4rd-u changes the IPv6 header architecture (redefine >> fragmentation header extension) and IPv6 address architecture (different >> meaning of u-bit when g-bit=3D1). These are the fundamental changes. If >> 4rd-u >> becomes the standard, then there will be new defined =93IPv6=94 packets = on >> the Internet, which are not compatible with existing IPv6 packets and >> no existing devices can understand those packets. >> >> >> Yu Guanghui >> Network and Information Center >> Dalian University of Technology, China >> >> >> On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu >> wrote: >> >>> Hi Guanghui, >>> >>> I agree that both MAP and 4rd-u are similar technology and solving the >>> same problem. From technical perspective, can you elaborate this a lith= e >>> bit? >>> >>> Thanks, >>> Yiu >>> >>> From: Guanghui Yu >>> Date: Thu, 22 Mar 2012 20:26:40 +0800 >>> To: Softwires WG >>> Subject: Re: [Softwires] Path to move forward with 4rd=85 >>> >>> I read 4rd-u draft and found it is flawed. >>> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > From Francis.Dupont@fdupont.fr Tue Mar 27 01:58:12 2012 Return-Path: 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 135FC21F892B for ; Tue, 27 Mar 2012 01:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 ZdE01A4mRVD1 for ; Tue, 27 Mar 2012 01:58:11 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCB621F892A for ; Tue, 27 Mar 2012 01:58:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2R8w9R9006394; Tue, 27 Mar 2012 10:58:09 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203270858.q2R8w9R9006394@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Wed, 21 Mar 2012 11:24:48 +0100. <94C682931C08B048B7A8645303FDC9F36E285585DC@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 27 Mar 2012 10:58:09 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:58:12 -0000 In your previous mail you wrote: > This is an issue common to all stateless solutions, including deterministic > NAT with (anaycast) IPv4 address pool. => +1! In fact, it is an issue common to all solutions implying mandatory filtering on transport fields (aka layer 4) including ports. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Mar 27 02:05:50 2012 Return-Path: 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 8B6F121F88FC for ; Tue, 27 Mar 2012 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, 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 7Y-Hjz6h-Y2x for ; Tue, 27 Mar 2012 02:05:50 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id CD45B21F88F0 for ; Tue, 27 Mar 2012 02:05:49 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2R95m7u007028; Tue, 27 Mar 2012 11:05:48 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203270905.q2R95m7u007028@givry.fdupont.fr> From: Francis Dupont To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-reply-to: Your message of Fri, 23 Mar 2012 11:01:40 +0100. <461847BF-3941-4990-A462-0A0E5E01A74C@laposte.net> Date: Tue, 27 Mar 2012 11:05:48 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Softwires Subject: Re: [Softwires] Fragmentation in sdnat-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:05:50 -0000 In your previous mail you wrote: > In this context, the important consideration is AFAIK that it is > completely acceptable to lose fragmented packets that, with bad > luck, happen to be routed via distinct BRs when there is a route > change. Frequent route changes would have many more severe > consequences than this one if considered normal. > Do we agree on this? => I agree (BTW in my comments about SD-NAT I warned than even with the no-translation on the SD-CGN variant there is still a mandatory reassembly which means incomplete fragmented packets are dropped). Regards Francis.Dupont@fdupont.fr PS: I don't believe which should say more. From jiangdong345@gmail.com Tue Mar 27 02:19:33 2012 Return-Path: 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 09E6A21F8946 for ; Tue, 27 Mar 2012 02:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 diwyehEieHtO for ; Tue, 27 Mar 2012 02:19:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0521F894F for ; Tue, 27 Mar 2012 02:19:31 -0700 (PDT) Received: by iazz13 with SMTP id z13so11294574iaz.31 for ; Tue, 27 Mar 2012 02:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=Vp+HHcn3oRQKGCtNVCIbPxYdVVBuf3hRUcvzGIbpBEQ=; b=fNCAAomad1dLPhpJofxpJ6zt3ANkHT9EnjbjpMi2xqybrCQRCMG4vbHxG1+SojhmMq FeqXYw/K5GelcM4iLqomwUIbg3cJoP1PxTtHIjM0BBeLG6FQimq2XjcUZuyhafgJKPmY d+LZhASqaYkmyB+BRAZpPzsSev5W4dVzz6yUTJg9DP9oa1fjKvh1uTwhwFefuf6ugFnD F5nvoe/0ZFenGg2+x0Iceup8hPh6NxsGodzRW3jnx8J0Pvc8LE67v7bPP8/bzmcf3NyS Id04zRdxx2GNHYJTmBbio8okMgGzyAWjuY72Uyerlhp7uGMMA6lZHPXYbizi21rthm5B srlQ== Received: by 10.50.160.131 with SMTP id xk3mr8011594igb.19.1332839970898; Tue, 27 Mar 2012 02:19:30 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id nq4sm403644igc.5.2012.03.27.02.19.28 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 02:19:30 -0700 (PDT) Date: Tue, 27 Mar 2012 17:19:28 +0800 From: "Jiang Dong" To: GangChen , "Kevin Y" References: , X-Priority: 3 X-GUID: 2941DB9E-F870-4137-AA90-F4E3988682D3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <20120327171926187501149@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart033486586837_=----" Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:19:33 -0000 This is a multi-part message in MIME format. ------=_001_NextPart033486586837_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2FuZyBhbmQgYWxsLA0KDQpJIHRoaW5rIHRoZXJlIGFyZSBzb21lIHBvaW50cyBuZWVkIHRv IGJlIGNvbnNpZGVyZWQgYmV0d2VlbiBNQVAgc2VyaWVzIGFuZCA0cmQtVS4NCg0KNHJkLVUgc2Fp ZHMgIklQdjQgaGVhZGVycyBjYW4gYmUgcmV2ZXJzaWJseSBtYXBwZWQgaW50byBJUHY2IGhlYWRl cnMgc28gdGhhdCA0cmQgdHVubmVsIHBhY2tldHMgY2FuIGJlIGRlc2lnbmVkIHRvIGJlIHZhbGlk IElQdjYgcGFja2V0cyIgaW4gU2VjdGlvbiBJLiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIDRyZC11IGFuZCBNQVAtRSBpcyAiSVB2NiBmcmFnbWVudCBoZWFkZXIg dnMgSVB2NCBoZWFkZXIiLiBCb3RoIDRyZC1VIGFuZCBNQVAtRSBjYW4ga2VlcCB0aGUgdHJhbnNw YXJlbmN5LCB3aGlsZSA0cmQtVSByZXNlcnZlcyAxMiBieXRlcyB0byBpbXByb3ZlIHRoZSBlZmZp Y2llbmN5IGFuZCBNQVQtRSBoYXMgc29tZSBJUHY0IHJlZHVuZGFuY3kgb2N0ZXRzIGJ1dCBrZWVw IHRoZSBvcmlnaW5hbCBJUC1JUCBlbmNhcHN1bGF0aW9uIHdoaWNoIGlzIGVhc3kgdG8gYmUgb3Bl cmF0ZWQuDQoNCkNvbXBhcmluZyB3aXRoIE1BUC1FLCA0cmQtVSBrZWVwcyB0aGUgREYgYml0LCBU T1MgYW5kIHNvIG9uIHdpdGggYW4gYWRkaXRpb25hbCBJUHY2IGZyYWdtZW50IGhlYWRlciwgd2hp Y2ggaW5jdXJzIHJldXNpbmcgSVB2NiBvcHRpb24gNDQuDQoNCklmIDRyZC1VIGNhbiBiZSBjb25z aWRlcmVkIGFzIGEgdHVubmVsaW5nIHRlY2huaXF1ZSwgdGhlIHF1ZXN0aW9uIGlzOiBkb2VzIGl0 IGRlc2VydmUgYWRkaW5nIHRoZSBJUHY2IGZyYWdtZW50IGhlYWRlciBpbiBvcmRlciB0byBzYXZl IDEyIGJ5dGVzIGVmZmljaWVuY3kgZWFjaCBwYWNrZXQ/DQoNCklmIDRyZC1VIGNhbiBiZSBjb25z aWRlcmVkIGFzIGEgdHJhbnNsYXRpb24gdGVjaG5pcXVlLCB0aGUgcXVlc3Rpb24gaXM6IGRvZXMg aXQgZGVzZXJ2ZSBhZGRpbmcgdGhlIElQdjYgZnJhZ21lbnQgaGVhZGVyIGluIG9yZGVyIHRvIGtl ZXAgdHJhbnNwYXJlbmN5Pw0KDQpSZWdhcmRzIQ0KSmlhbmcgRG9uZw0KVHNpbmdodWEgVW5pdmVy c2l0eQ0KMjAxMi0wMy0yNw0KDQpGcm9tOiBHYW5nQ2hlbg0KRGF0ZTogMjAxMi0wMy0yNyAxNTo1 Mw0KVG86IEtldmluIFkNCkNDOiBTb2Z0d2lyZXMgV0cNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVz XVBhdGggdG8gbW92ZSBmb3J3YXJkIHdpdGggNHJkxaANCkhlbGxvIEtldmluIGFuZCBhbGwsDQoN CkkgYWN0dWFsbHkgc2VlIGN1cnJlbnQgbXVsdGlwbGUgc29sdXRpb24gcHJvcG9zYWwgZnJvbSBk aWZmZXJlbnQNCmFuZ2xlLiBSZWdhcmRpbmcgdGhlIGNoYW5nZXMgeW91IG1lbnRpb25lZCwgTUFQ LVQvRSBpcyBhbHNvIGRvaW5nDQp0aGF0LCBlLmcuIGFkZGVkIGZyYWdtZW50YXRpb24gaGVhZGVy IHRvIHN1cnZpdmUgREYgYml0OyBjaGFuZ2UgSUNNUA0KSUQgZmlsZWQgdG8gY2FycnkgdGhlIHBv cnQgaW5mb3JtYXRpb24uDQoNCjRyZC1VIGRvZXNuJ3QgYmVhdCBNQVAtc2VyaWVzLiBJIHByZWZl ciB0byB1bmRlcnN0YW5kIHRoZSBzaXR1YXRpb24gaXMNCjRyZC1VIHJhaXNlZCBzb21lIHBvaW50 cyhlLmcuIENOUCwgRnVsbHkgSVB2NCB0cmFuc3BhcmVuY3kpIHdoaWNoIGlzDQpkZXNpcmFibGUg aGVhZGluZyB0byBhIHBlcmZlY3QgcHJvdG9jb2wgZGVzaWduLg0KDQpCUnMNCg0KR2FuZw0KDQoy MDEyLzMvMjcsIEtldmluIFkgPGt5a2luZzZAZ21haWwuY29tPjoNCj4gSGksIFJlbWksDQo+DQo+ IFRoaXMgaXMgYmV5b25kIHRoZSBjaGFydGVyIG9mIHNvZnR3aXJlIFdHLCBjaGFuZ2luZyBJUHY2 IGFkZHJlc3MgZm9ybWF0DQo+IG5lZWRzIG11Y2ggYnJvYWQgZGlzY3Vzc2lvbiBpbiBJRVRGIGNv bW11bml0eSB0byB1bmRlcnN0YW5kIGl0cyBpbXBhY3QNCj4gZmlyc3QsIGJlZm9yZSB3ZSBzaG91 bGQgZXZlbiBkaXNjdXNzIGlmIGl0IGlzIHZhbGlkIHRvIGRlc2lnbiBzb21ldGhpbmcNCj4gbGlr ZSB0aGlzIGluIHNvZnR3aXJlLiAgIEhhdmUgeW91IGRvbmUgdGhhdCA/DQo+DQo+IEJlc3QgUmVn YXJkcywNCj4NCj4gS2V2aW4gWWluDQo+DQo+IE9uIFRodSwgTWFyIDIyLCAyMDEyIGF0IDEwOjA0 IFBNLCBHdWFuZ2h1aSBZdSA8eXUuZ3VhbmdodWlAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+IEhp IFlpdQ0KPj4NCj4+ICAgIDRyZC11IGNoYW5nZXMgdGhlIElQdjYgaGVhZGVyIGFyY2hpdGVjdHVy ZSAocmVkZWZpbmUNCj4+IGZyYWdtZW50YXRpb24gaGVhZGVyIGV4dGVuc2lvbikgYW5kIElQdjYg YWRkcmVzcyBhcmNoaXRlY3R1cmUgKGRpZmZlcmVudA0KPj4gbWVhbmluZyBvZiB1LWJpdCB3aGVu IGctYml0PTEpLiBUaGVzZSBhcmUgdGhlIGZ1bmRhbWVudGFsIGNoYW5nZXMuIElmDQo+PiA0cmQt dQ0KPj4gYmVjb21lcyB0aGUgc3RhbmRhcmQsIHRoZW4gdGhlcmUgd2lsbCBiZSBuZXcgZGVmaW5l ZCDmj5FQdjY/cGFja2V0cyBvbg0KPj4gdGhlIEludGVybmV0LCB3aGljaCBhcmUgbm90IGNvbXBh dGlibGUgd2l0aCBleGlzdGluZyBJUHY2IHBhY2tldHMgYW5kDQo+PiBubyBleGlzdGluZyBkZXZp Y2VzIGNhbiB1bmRlcnN0YW5kIHRob3NlIHBhY2tldHMuDQo+Pg0KPj4NCj4+IFl1IEd1YW5naHVp IDx5Z2ggYXQgZGx1dC5lZHUuY24+DQo+PiBOZXR3b3JrIGFuZCBJbmZvcm1hdGlvbiBDZW50ZXIN Cj4+IERhbGlhbiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3ksIENoaW5hDQo+Pg0KPj4NCj4+IE9u IEZyaSwgTWFyIDIzLCAyMDEyIGF0IDEwOjEwIEFNLCBMZWUsIFlpdQ0KPj4gPFlpdV9MZWVAY2Fi bGUuY29tY2FzdC5jb20+d3JvdGU6DQo+Pg0KPj4+IEhpIEd1YW5naHVpLA0KPj4+DQo+Pj4gSSBh Z3JlZSB0aGF0IGJvdGggTUFQIGFuZCA0cmQtdSBhcmUgc2ltaWxhciB0ZWNobm9sb2d5IGFuZCBz b2x2aW5nIHRoZQ0KPj4+IHNhbWUgcHJvYmxlbS4gRnJvbSB0ZWNobmljYWwgcGVyc3BlY3RpdmUs IGNhbiB5b3UgZWxhYm9yYXRlIHRoaXMgYSBsaXRoZQ0KPj4+IGJpdD8NCj4+Pg0KPj4+IFRoYW5r cywNCj4+PiBZaXUNCj4+Pg0KPj4+IEZyb206IEd1YW5naHVpIFl1IDx5dS5ndWFuZ2h1aUBnbWFp bC5jb20+DQo+Pj4gRGF0ZTogVGh1LCAyMiBNYXIgMjAxMiAyMDoyNjo0MCArMDgwMA0KPj4+IFRv OiBTb2Z0d2lyZXMgV0cgPHNvZnR3aXJlc0BpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW1Nv ZnR3aXJlc10gUGF0aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmQ/DQo+Pj4NCj4+PiBJIHJlYWQg NHJkLXUgZHJhZnQgYW5kIGZvdW5kIGl0IGlzIGZsYXdlZC4NCj4+Pg0KPj4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gU29mdHdpcmVz IG1haWxpbmcgbGlzdA0KPj4gU29mdHdpcmVzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPj4NCj4+DQo+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlz dA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcw== ------=_001_NextPart033486586837_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Gang and all,
 
I think there are som= e points=20 need to be considered between MAP series and 4rd-U.
 
4rd-U saids "IPv4 hea= ders can=20 be reversibly mapped into IPv6 headers so that 4rd tunnel packets can be=20 designed to be valid IPv6 packets" in Section I. In my understanding, the=20 difference between 4rd-u and MAP-E is "IPv6 fragment header vs IPv4 header= ".=20 Both 4rd-U and MAP-E can keep the transparency, while 4rd-U reserves 12 by= tes to=20 improve the efficiency and MAT-E has some IPv4 redundancy octets but keep = the=20 original IP-IP encapsulation which is easy to be operated.
 
Comparing with MAP-E,= 4rd-U=20 keeps the DF bit, TOS and so on with an additional IPv6 fragment= header, which incurs reusing IPv6 option 44.
 
If 4rd-U can be consi= dered as=20 a tunneling technique, the question is: does it deserve adding the=20 IPv6 fragment header in order to save 12 bytes efficiency e= ach=20 packet?
 
If 4rd-U can be consi= dered as=20 a translation technique, the question is: does it deserve adding the=20 IPv6 fragment header in order to keep transparency?
 
Regards!
Jiang Dong
Tsinghua University 2012-03-27
 
Hello Kevin and all,
 
I actually see current multiple solution&nbs= p;proposal from different
angle. Regarding the changes you mentioned,&= nbsp;MAP-T/E is also doing
that, e.g. added fragmentation header to&nbs= p;survive DF bit; change ICMP
ID filed to carry the port information.=
 
4rd-U doesn't beat MAP-series. I prefer = ;to understand the situation is
4rd-U raised some points(e.g. CNP, Fully&nbs= p;IPv4 transparency) which is
desirable heading to a perfect protocol = ;design.
 
BRs
 
Gang
 
2012/3/27, Kevin Y <kyking6@gmail.com>:
> Hi, Remi,
>
> This is beyond the charter of = ;softwire WG, changing IPv6 address format
> needs much broad discussion in IET= F community to understand its impact
> first, before we should even discu= ss if it is valid to design something
> like this in softwire.   Have=  you done that ?
>
> Best Regards,
>
> Kevin Yin
>
> On Thu, Mar 22, 2012 at 10:04=  PM, Guanghui Yu <yu.guanghui@gmail.com> wr= ote:
>
>> Hi Yiu
>>
>>    4rd-u changes the IPv6=  header architecture (redefine
>> fragmentation header extension) and = ;IPv6 address architecture (different
>> meaning of u-bit when g-bit=3D1).&n= bsp;These are the fundamental changes. If
>> 4rd-u
>> becomes the standard, then there&nb= sp;will be new defined =E6=8F=91Pv6?packets on
>> the Internet, which are not co= mpatible with existing IPv6 packets and
>> no existing devices can understand&= nbsp;those packets.
>>
>>
>> Yu Guanghui <ygh at dlut.edu.cn&= gt;
>> Network and Information Center
>> Dalian University of Technology, Ch= ina
>>
>>
>> On Fri, Mar 23, 2012 at 1= 0:10 AM, Lee, Yiu
>> <Yiu_Lee@cable.comcast.com>wrote:
>>
>>> Hi Guanghui,
>>>
>>> I agree that both MAP and&= nbsp;4rd-u are similar technology and solving&nbs= p;the
>>> same problem. From technical pe= rspective, can you elaborate this a lithe
>>> bit?
>>>
>>> Thanks,
>>> Yiu
>>>
>>> From: Guanghui Yu <yu.guanghui@gm= ail.com>
>>> Date: Thu, 22 Mar 2012 20:= 26:40 +0800
>>> To: Softwires WG <softwires@ietf.= org>
>>> Subject: Re: [Softwires] Path t= o move forward with 4rd?
>>>
>>> I read 4rd-u draft and fou= nd it is flawed.
>>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart033486586837_=------ From repenno@cisco.com Tue Mar 27 02:26:02 2012 Return-Path: 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 1FA9021F897C for ; Tue, 27 Mar 2012 02:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 43q-Tw+aXNOU for ; Tue, 27 Mar 2012 02:26:01 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE621F896E for ; Tue, 27 Mar 2012 02:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=253; q=dns/txt; s=iport; t=1332840361; x=1334049961; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=lGsXGPkImzL/gURfu/OipVkTBkN1fGseN4aJAtdaTKA=; b=ipuMv0qPY9qvUesNwugEayaMcb/JrwtZmpg5bvu6kQWjCV1DPBAYKilR KfV1TpOwbURa7vZga2Iivqcn3fIk7dR6yxwb5vHBXcS9h5NQgiJbkZTt/ nb6F/32CERFn9mLCRk71+R2zN+hwIU0NIvTMX/K5IoekGL6KTgmjPy1A3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugGABCHcU+rRDoH/2dsb2JhbABFgw61OoEHghASAScCATwTCBArYgYBDQUih2eaTI1RkTuRDwSIWI0JhW+IVoFogwc X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="37825169" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Mar 2012 09:26:01 +0000 Received: from [10.21.114.2] (sjc-vpn2-514.cisco.com [10.21.114.2]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2R9Pfx7012686; Tue, 27 Mar 2012 09:25:51 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 02:25:40 -0700 From: Reinaldo Penno To: Francis Dupont , Qi Sun Message-ID: Thread-Topic: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris In-Reply-To: <201203270747.q2R7lLdd001070@givry.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:26:02 -0000 What was the use case for non-contigous port sets? On 3/27/12 12:47 AM, "Francis Dupont" wrote: >>3.Does SD-NAT mechanism support the allocation of non-continuous port >> set (e.g. using GMA stated in MAP draft)? > From despres.remi@laposte.net Tue Mar 27 02:26:45 2012 Return-Path: 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 2ED3021F8974 for ; Tue, 27 Mar 2012 02:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.225, 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 Ggr5tMcZTc1X for ; Tue, 27 Mar 2012 02:26:44 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2955A21F896E for ; Tue, 27 Mar 2012 02:26:42 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8506-out with ME id qZSe1i0055M8erm03ZSelQ; Tue, 27 Mar 2012 11:26:41 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-198396728 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 11:26:38 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:26:45 -0000 --Apple-Mail-8-198396728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-27 =E0 08:41, Maoke a =E9crit : > dear Remi,=20 >=20 > sorry but i forgot the time difference this morning. thanks for the = quick response! >=20 > 2012/3/27 R=E9mi Despr=E9s > Dear Maoke, >=20 > Thanks for clarifying what you meant. > I now understand that you were referring to applications that might = require IPv4 dialogue between one link apart nodes. >=20 > Whether this is a real use case in the MAP-4rd context remains however = to be seen. >=20 > if 4rd-u is limited to a very constrained scope, it is no problem. but = people surely want to have a scalable solution. i listed issues of both = inter-domain and intra-domain routing and i believe supporting some = dynamic routing in the MAP domain is a natural requirement.=20 > =20 > Here are my immediate comments: > a) This wasn't mentioned as one of the desirable features of stateless = solutions. >=20 > any encapsulation is commonly, well understood to have such a feature = without need of further explanation, without need of adding any elements = in standard. we are now seldom discussing about the routing issue in the = stateless solutions but we cannot block up the road to the real = operation.=20 Having a feature has never been expression of a requirement. > b) Since MAP-T can't satisfy such a requirement, and there has been = promoters of MAP-T as a sufficient standard, this casts some doubt or = reality of this requirement. >=20 > well, my predicted response from you. :) please NOTE: MAP-T has never = said it can "replace E". In my recollection, double translation it has been proposed as a = possibly unique standard but, OK, the MAP proposal is to have both MAP-T = AND MAP-E as standards. > this thread is about the importance of virtual link as an = architectural building block that 4rd-u cannot offer. See (*) below. > MAP-T has none of business with this topic, because it is never = considered virtual link. what i am arguing against, in this thread, is = that "once operator has U it doesn't need either E or T". my point here = is: 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is = a unified solution" is NOT qualified.=20 >=20 > it is not the topic of this thread if 4rd-u can replace MAP-T or not. = i will go deep in that later, in another thread. Then please leave me time to answer new discussion items you will = introduce (may answers may be after the end of this week.) >=20 > c) If the requirement is nevertheless confirmed, it can be satisfied = AFAIK by an ad hoc complement to 4rd-U. (At least one one approach I see = consists in using the 7 remaining bits of IPv6 packet IDs for this). I = would be glad to share w details with you, but only after the WG would = confirm that there is a real need. (Let's not say that because there is = a solution there is a need.) >=20 > another predicted patch idea. (*) "Another" patch?? Just a solution to a feature you personally see add as a requirement. It happens that I already thought about it, but didn't propose to = include it because I had never saw a WG requirement for it. > but i doubt 7 bit can represent TTL =3D 255 correctly.=20 Did I suggest that? (I hope you will someday have more respect for my design ability!) > d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do = you know a better reference than this RFC? >=20 > RFC2260 is informational rather than standard. BGP4 specification is = RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = =3D 1, as i mentioned, is not a standard feature, but used in some = implementations (including Cisco IOS and Juniper JUNOS and the = open-source routing tool Quagga, to my best knowledge) in order to = ensure the standard feature that defaultly EBGP is established over an = immediate link. as a quick evidence of the implementation, in bgpd.c of = quagga suite we may read the piece of source code:=20 >=20 > peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >=20 > it is saying, if the peer is IBGP, the TTL of IP header carrying it = should be set to 255; while if it is EBGP, TTL should be 1.=20 Not familiar enough with the subject to know whether these = implementations cannot be configured so that they don't care. I noted that RFC4271 doesn't have the word virtual link, and that = RFC2328 only mentions "configured" virtual links (=3D> out of scope). =20= If, despite this, you get WG support for a requirement of "1hop-only = tunnels", the best answer is IMHO to include its support in 4rd-U. This AFAIK will close this issue. Thanks for this clarification, RD >=20 > regards, > maoke > =20 >=20 > Regards, > RD >=20 >=20 > Le 2012-03-26 =E0 15:48, Maoke a =E9crit : >=20 >> =20 >> dear Remi, >> =20 >> i think you won't be against if i change the subject of this specific = discussion, focusing on the routing issues regarding virtual link.=20 >> 2012/3/26 R=E9mi Despr=E9s >>> Different understanding. >>> An detailed E use case that cannot be supported by U (if it exists) = would give substance to this claim. >>> Open to look at it. =20 >>>=20 >>> in my personal experience i could give you at least three quick = examples of the use case for the building block of "virtual link":=20 >>>=20 >>> first example, if the IPv4 customer network plays BGP over IPv4 with = the provider, through the BGP session between CE and BR, a virtual link = is desired.=20 >>>=20 >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >>=20 >> I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U. >> =20 >> =20 >> by default, ebgp requires direct link (some implementations specify = TTL =3D 1 to achieve this). U decreases TTL when packet goes through = IPv6 cloud, and therefore CE---BR ebgp session cannot be established = with regular BGP configurations. >>> second example, there are dynamic routing protocols like RIP running = in the following (multihoming) topology for IPv4 routing. the operator = may want to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation. >>>=20 >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR = ----(IPv4 world)=20 >>> \ = / >>> \ = / >>> +------------ CE ----(Another, IPv4 = domain)----------+ >>=20 >> Same comment. >> =20 >> =20 >> similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact that = CE---BR are shown as multihop with tools like traceroute. >> =20 >> =20 >>> third example, same topology as above but OSPF are applied, and OSPF = TTL-security check are enabled to ensure hop-passings less than a = specified threshold. if the operator would like to treat CE---(IPv6-only = domain)---BR as one hop because it is considered as virtual link, = 4rd-u's rudiness in decreasing TTL will hurt.=20 >>=20 >> Same comment. >> =20 >> =20 >> same misunderstanding. without knowing the details of the IPv6 domain = backbone, it is difficult for the operator to set up a proper value of = the TTL-security parameter for the OSPF regarding the CE---BR section. = virtual link (full encapsulation) eliminates this trouble. >> =20 >> =20 >>=20 >>> MAP-E (and other E) surely has no limitation in supporting any = features of existing routing protocols. >>=20 >> Why U would be less transparent between CEs and BRs than E for any L4 = protocol remains unexplained. >> =20 >> =20 >> hope the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols. >> =20 >> =20 >> =20 >>> with at least the above three examples, i conclude "U cannot replace = E at all"! >>=20 >> See above. >> =20 >> =20 >> see above. >> =20 >> - maoke >> =20 >> =20 >>=20 >>> (btw, surely the translation has the same limitation not to support = the above features but, e.g., as you also said, it opens transport-layer = stuff to the middle boxes). therefore i said operators may use either = encapsulation or translation according to what they attach importance = to.)=20 >=20 >=20 --Apple-Mail-8-198396728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
dear = Remi, 

sorry but i forgot the time = difference this morning. thanks for the quick response!

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Dear Maoke,

Thanks for = clarifying what you meant.
I now understand that you were = referring to applications that might require IPv4 dialogue between one = link apart nodes.

Whether this is a real use case in the MAP-4rd = context remains however to be = seen.

if 4rd-u is limited to = a very constrained scope, it is no problem. but people surely want to = have a scalable solution. i listed issues of both inter-domain and = intra-domain routing and i believe supporting some dynamic routing in = the MAP domain is a natural requirement. 
 
Here are my immediate = comments:
a) This wasn't mentioned as one of the desirable = features of stateless solutions.

any encapsulation is commonly, = well understood to have such a feature without need of further = explanation, without need of adding any elements in standard. we are now = seldom discussing about the routing issue in the stateless solutions but = we cannot block up the road to the real = operation. 

Having a feature = has never been expression of a = requirement.


b) Since MAP-T can't = satisfy such a requirement, and there has been promoters of MAP-T as a = sufficient standard, this casts some doubt or reality of this = requirement.

well, my predicted response from = you. :) please NOTE: MAP-T has never said it can "replace E". =

In my recollection, double = translation it has been proposed as a possibly unique standard but, = OK, the MAP proposal is to have both MAP-T AND MAP-E as = standards.

this thread is about the importance of = virtual link as an architectural building block that 4rd-u cannot offer. =

See (*) = below.

MAP-T has none of business with this topic, = because it is never considered virtual link. what i am arguing against, = in this thread, is that "once operator has U it doesn't need either E or = T". my point here is: 4rd-u cannot replace MAP-E, and accordingly the = statement "4rd-u is a unified solution" is NOT qualified. 

it is not the topic of this thread if 4rd-u can = replace MAP-T or not. i will go deep in that later, in another = thread.

Then please leave me time = to answer new discussion items you will introduce (may answers may be = after the end of this week.)


c) If the requirement is = nevertheless confirmed, it can be satisfied AFAIK by an ad hoc = complement to 4rd-U. (At least one one approach I see consists in using = the 7 remaining bits of IPv6 packet IDs for this). I would be glad to = share w details with you, but only after the WG would confirm that there = is a real need. (Let's not say that because there is a solution there is = a need.)

another predicted patch = idea.

(*)
"Another" = patch??
Just a solution to a feature you personally see add as = a requirement.
It happens that I already thought about it, but = didn't propose to include it because I had never saw a WG requirement = for it.


but i doubt 7 bit can represent TTL =3D 255 = correctly. 

Did I suggest = that?
(I hope you will someday have more respect for my design = ability!)


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than = this RFC?

RFC2260 is = informational rather than standard. BGP4 specification is RFC4271 and = you may be interested in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i = mentioned, is not a standard feature, but used in some implementations = (including Cisco IOS and Juniper JUNOS and the open-source routing tool = Quagga, to my best knowledge) in order to ensure the standard feature = that defaultly EBGP is established over an immediate link. as a quick = evidence of the implementation, in bgpd.c of quagga suite we may read = the piece of source code: 

   peer->ttl =3D (peer_sort (peer) =3D=3D= BGP_PEER_IBGP ? 255 : 1);

it is saying, if the = peer is IBGP, the TTL of IP header carrying it should be set to 255; = while if it is EBGP, TTL should be = 1. 

Not familiar = enough with the subject to know whether these implementations cannot be = configured so that they don't care.
I noted that RFC4271 = doesn't have the word virtual link, and that RFC2328 only mentions = "configured" virtual links (=3D> out of scope). =  

If, despite this, you get WG support for = a requirement of "1hop-only tunnels", the best answer is IMHO to include = its support in 4rd-U.
This AFAIK will close this = issue.

Thanks for this = clarification,
RD


=

regards,
maoke
 

Regards,
RD


Le 2012-03-26 =E0 15:48, = Maoke a =E9crit :

 
dear = Remi,
 
i think you won't be against if i = change the subject of this specific discussion, focusing on the routing = issues regarding virtual link.
2012/3/26 R=E9mi Despr=E9s <despres.remi@laposte.net>
Different = understanding.
An detailed E use case that cannot be supported = by U (if it exists) would give substance to this = claim.
Open to look at it.  

in my personal experience i could give you at least three = quick examples of the use case for the building block of "virtual = link": 

first example, if the IPv4 = customer network plays BGP over IPv4 with the provider, through the BGP = session between CE and BR, a virtual link is desired. 

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 = world) 

I don't see in this scenario why anything that works with E (i.e. = between CEs and BRs) wouldn't also work with U.
 
 
by = default, ebgp requires direct link (some implementations specify TTL =3D = 1 to achieve this). U decreases TTL when packet goes through IPv6 = cloud, and therefore CE---BR ebgp session cannot be = established with regular BGP configurations.
second = example, there are dynamic routing protocols like RIP running in the = following (multihoming) topology for IPv4 routing. the operator may want = to treat the CE-BR as a single hop in order the virtual link is = considered the distance vector calculation.

    (IPv4 customer network)--- CE = ----(IPv6-only domain)----- BR ----(IPv4 world) 
  =              \       =                     =                     =          /
      =           \           =                     =                     =    /
                =  +------------ CE ----(Another, IPv4 = domain)----------+

Same= = comment.
 
 
<= div>similar misunderstanding. RIP distance vectors are delivered to = neighbors but the operators are easy to be confused by the fact = that CE---BR are shown as multihop with tools like traceroute. =
 
 
third example, same topology as above = but OSPF are applied, and OSPF TTL-security check are enabled to ensure = hop-passings less than a specified threshold. if the operator would like = to treat CE---(IPv6-only domain)---BR as one hop because it is = considered as virtual link, 4rd-u's rudiness in decreasing TTL will = hurt. 

Same = comment.
 
 
<= div>same misunderstanding. without knowing the details of the IPv6 = domain backbone, it is difficult for the operator to set up a proper = value of the TTL-security parameter for the OSPF regarding the CE---BR = section. virtual link (full encapsulation) eliminates this trouble. =
 
 

MAP-E (and other E) surely has no limitation in supporting any = features of existing routing = protocols.

Why U = would be less transparent between CEs and BRs than E for any L4 protocol = remains unexplained.
=
 
 
hope= the above helps. it is not about the transparency but about the = behavior of virtual link. it is not about any L4 protocol but about = routing protocols.
 
 
 
with at least the above three examples, = i conclude "U cannot replace E at all"! =

See = above.
 
 
see above.
 
- maoke =
 
 

(btw, surely the = translation has the same limitation not to support the above features = but, e.g., as you also said, it opens transport-layer stuff to the = middle boxes). therefore i said operators may use either encapsulation = or translation according to what they attach importance to.) 



= --Apple-Mail-8-198396728-- From fibrib@gmail.com Tue Mar 27 03:16:05 2012 Return-Path: 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 9A9A821F89A5 for ; Tue, 27 Mar 2012 03:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 34xQs0uoQk6y for ; Tue, 27 Mar 2012 03:16:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43A5021F89A2 for ; Tue, 27 Mar 2012 03:15:55 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3201842wgb.13 for ; Tue, 27 Mar 2012 03:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H6EhP1JzdAMA+vS0z/DdMVM5pQRDNbHS8iKree+xtqU=; b=hXkGfJj1R2TnerhhStZ1K26iZEynllUha08Hrjw9lubNzf71TDi3SrTyqi3NR9cGT4 wjU5uK20LQ0jCWzJdsXVkdXIiOdLa2HwzAoSUL7UE1RGO7wfha7rLK+CZCYqi0qhXNvg FU19yI4ubUS8pliw/tsY2nhjap4VmjJw4R8x8IUV2NMc79u4fNRPbyXVGLpczkSdcssi BnWiAUyCcy8IBGke0AHAogG4fyiXRLAnMw+Hp5ACsYO0QCpoBdIy2rIexaSKrJXP3Bae PGw1KserFFhLcoP7whbFHj+a13kX8wQXMXhQ6w4URFyRAo5+S12CjFxVb+B25CurThbP b3Eg== MIME-Version: 1.0 Received: by 10.180.81.37 with SMTP id w5mr26172240wix.16.1332843354383; Tue, 27 Mar 2012 03:15:54 -0700 (PDT) Received: by 10.216.188.204 with HTTP; Tue, 27 Mar 2012 03:15:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 10:15:54 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04428dc0ade5b904bc36c6bd Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:16:05 -0000 --f46d04428dc0ade5b904bc36c6bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/27 R=E9mi Despr=E9s > > Le 2012-03-27 =E0 08:41, Maoke a =E9crit : > > dear Remi, > > sorry but i forgot the time difference this morning. thanks for the quick > response! > > 2012/3/27 R=E9mi Despr=E9s > >> Dear Maoke, >> >> Thanks for clarifying what you meant. >> I now understand that you were referring to applications that might >> require IPv4 dialogue between one link apart nodes. >> >> Whether this is a real use case in the MAP-4rd context remains however t= o >> be seen. >> > > if 4rd-u is limited to a very constrained scope, it is no problem. but > people surely want to have a scalable solution. i listed issues of both > inter-domain and intra-domain routing and i believe supporting some dynam= ic > routing in the MAP domain is a natural requirement. > > >> Here are my immediate comments: >> a) This wasn't mentioned as one of the desirable features of stateless >> solutions. >> > > any encapsulation is commonly, well understood to have such a feature > without need of further explanation, without need of adding any elements = in > standard. we are now seldom discussing about the routing issue in the > stateless solutions but we cannot block up the road to the real operation= . > > > Having a feature has never been expression of a requirement. > > > b) Since MAP-T can't satisfy such a requirement, and there has been >> promoters of MAP-T as a sufficient standard, this casts some doubt or >> reality of this requirement. >> > > well, my predicted response from you. :) please NOTE: MAP-T has never sai= d > it can "replace E". > > > In my recollection, double translation it has been proposed as a possibly > unique standard but, OK, the MAP proposal is to have both MAP-T AND MAP-E > as standards. > we think MAP as a suite and -T and -E are to be used in different circumstances where operators attach importance to different considerations. > > this thread is about the importance of virtual link as an architectural > building block that 4rd-u cannot offer. > > > See (*) below. > > MAP-T has none of business with this topic, because it is never considere= d > virtual link. what i am arguing against, in this thread, is that "once > operator has U it doesn't need either E or T". my point here is: 4rd-u > cannot replace MAP-E, and accordingly the statement "4rd-u is a unified > solution" is NOT qualified. > > it is not the topic of this thread if 4rd-u can replace MAP-T or not. i > will go deep in that later, in another thread. > > > Then please leave me time to answer new discussion items you will > introduce (may answers may be after the end of this week.) > fully understood. but i won't stop in order to contribute my understandings to the community stopping 4rd-u misleading the progress of standardization. > > > c) If the requirement is nevertheless confirmed, it can be satisfied AFAI= K >> by an ad hoc complement to 4rd-U. (At least one one approach I see consi= sts >> in using the 7 remaining bits of IPv6 packet IDs for this). I would be g= lad >> to share w details with you, but only after the WG would confirm that th= ere >> is a real need. (Let's not say that because there is a solution there is= a >> need.) >> > > another predicted patch idea. > > > (*) > "Another" patch?? > Just a solution to a feature you personally see add as a requirement. > It happens that I already thought about it, but didn't propose to include > it because I had never saw a WG requirement for it. > well, really never a WG requirement. some dialogues have been there: http://www.ietf.org/mail-archive/web/softwires/current/msg03106.html -- the requirement http://www.ietf.org/mail-archive/web/softwires/current/msg03109.html -- a possible solution http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html -- the concern on the possible solution and its little necessity > > > but i doubt 7 bit can represent TTL =3D 255 correctly. > > > Did I suggest that? > (I hope you will someday have more respect for my design ability!) > "using the 7 remaining bits of IPv6 packet IDs for this" was not your writing? i never doubt your design ability but i also hope we (you and me), when designing anything, will someday have more respect for all other designers and implementors, being a little conservative on what we will generate to the Internet. very sincerely hope so! this thread could be closed now. i have expressed my consideration. i also have prepared some further clarification for OSPF and RIP but it looks you are not interested in it. it is fine to me because operators and implementors know very clearly about what i am concerning. just one comment on BGP4 "doesn't have a word virtual link" --- all 6bone players may remember that, at that time, we establish most of IPv6 BGP peers through virtual links (tunnels), without the standard explicitly saying virtual link. conclusion has been cleared: 4rd-u cannot offer all that MAP-E (as encapsulation supporting virtual link building block) can. 4rd-u is not a tunnel at all. so long, - maoke > > > d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do you >> know a better reference than this RFC? >> > > RFC2260 is informational rather than standard. BGP4 specification is > RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = =3D > 1, as i mentioned, is not a standard feature, but used in some > implementations (including Cisco IOS and Juniper JUNOS and the open-sourc= e > routing tool Quagga, to my best knowledge) in order to ensure the standar= d > feature that defaultly EBGP is established over an immediate link. as a > quick evidence of the implementation, in bgpd.c of quagga suite we may re= ad > the piece of source code: > > peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); > > it is saying, if the peer is IBGP, the TTL of IP header carrying it shoul= d > be set to 255; while if it is EBGP, TTL should be 1. > > > Not familiar enough with the subject to know whether these implementation= s > cannot be configured so that they don't care. > I noted that RFC4271 doesn't have the word virtual link, and that RFC2328 > only mentions "configured" virtual links (=3D> out of scope). > > If, despite this, you get WG support for a requirement of "1hop-only > tunnels", the best answer is IMHO to include its support in 4rd-U. > This AFAIK will close this issue. > > Thanks for this clarification, > RD > > > --f46d04428dc0ade5b904bc36c6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-27 =E0 08:41, = Maoke a =E9crit :

dear Remi,=A0
=

sorry but i forgot the time dif= ference this morning. thanks for the quick response!

2012/3/27 R=E9mi Despr=E9s <despres.= remi@laposte.net>
Dear Mao= ke,

Thanks for clarifying what you meant.
I no= w understand that you were referring to applications that might require IPv= 4 dialogue between one link apart nodes.

Whether this is a real use case in the MAP-4rd context = remains however to be seen.

if = 4rd-u is limited to a very constrained scope, it is no problem. but people = surely want to have a scalable solution. i listed issues of both inter-doma= in and intra-domain routing and i believe supporting some dynamic routing i= n the MAP domain is a natural requirement.=A0
=A0
Here are my immediate comments:
a) This wasn't men= tioned as one of the desirable features of stateless solutions.

any encapsulation is commonly, well = understood to have such a feature without need of further explanation, with= out need of adding any elements in standard. we are now seldom discussing a= bout the routing issue in the stateless solutions but we cannot block up th= e road to the real operation.=A0

Having a feature has never been exp= ression of a requirement.


b) Since MAP-T can't satisfy such a requirement, and there has bee= n promoters of MAP-T as a sufficient standard, this casts some doubt or rea= lity of this requirement.

well, my predicted response from you= . :) please NOTE: MAP-T has never said it can "replace E".
=

In my recollection, double translat= ion=A0it has been proposed as a possibly unique standard but, OK, the MAP p= roposal is to have both MAP-T AND MAP-E as standards.

we think MAP as a suite and -T and -= E are to be used in different circumstances where operators attach importan= ce to different considerations.=A0
=A0

this thread is about the impo= rtance of virtual link as an architectural building block that 4rd-u cannot= offer.

See (*) below.

MAP-T= has none of business with this topic, because it is never considered virtu= al link. what i am arguing against, in this thread, is that "once oper= ator has U it doesn't need either E or T". my point here is: 4rd-u= cannot replace MAP-E, and accordingly the statement "4rd-u is a unifi= ed solution" is NOT qualified.=A0

it is not the topic of this thread if 4rd-u can replace= MAP-T or not. i will go deep in that later, in another thread.
=

Then please leave me time to answer new d= iscussion items you will introduce (may answers may be after the end of thi= s week.)

fully understood. but i won't st= op in order to contribute my understandings to the community stopping 4rd-u= misleading the progress of standardization.=A0
=A0


c) If the requirement is neverthel= ess confirmed, it can be satisfied AFAIK by an ad hoc complement to 4rd-U. = (At least one one approach I see consists in using the 7 remaining bits of = IPv6 packet IDs for this). I would be glad to share w details with you, but= only after the WG would confirm that there is a real need. (Let's not = say that because there is a solution there is a need.)

another predicted patch idea.
<= /div>

(*)
"Another" pa= tch??
Just a solution to a feature you personally see add as a re= quirement.
It happens that I already thought about it, but didn't propose to = include it because I had never saw a WG requirement for it.

well, really never a WG requirement. some dial= ogues have been there:

http://www.ietf.org/mail-archive/web/softwires/current/msg03110.= html -- the concern on the possible solution and its little necessity
=A0


<= div class=3D"gmail_quote">
but i doubt 7 bit can represent TTL =3D 255 correctly.=A0
=

Did I suggest that?
(I hope you= will someday have more respect for my design ability!)

"using the 7 remaining bits of IPv6 packet IDs for= this" was not your writing? i never doubt your design ability but i a= lso hope we (you and me), when designing anything, will someday have more r= espect for all other designers and implementors, being a little conservativ= e on what we will generate to the Internet. very sincerely hope so!

this thread could be closed now. i have expressed my co= nsideration. i also have prepared some further clarification for OSPF and R= IP but it looks you are not interested in it. it is fine to me because oper= ators and implementors know very clearly about what i am concerning. just o= ne comment on BGP4 "doesn't have a word virtual link" --- all= 6bone players may remember that, at that time, we establish most of IPv6 B= GP peers through virtual links (tunnels), without the standard explicitly s= aying virtual link.=A0

conclusion has been cleared: 4rd-u cannot offer all tha= t MAP-E (as encapsulation supporting virtual link building block) can. 4rd-= u is not a tunnel at all.=A0

so long,
- maoke

=A0

d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than th= is RFC?

RFC2260 is informationa= l rather than standard. BGP4 specification is RFC4271 and you may be intere= sted in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i mentioned, is not a = standard feature, but used in some implementations (including Cisco IOS and= Juniper JUNOS and the open-source routing tool Quagga, to my best knowledg= e) in order to ensure the standard feature that defaultly EBGP is establish= ed over an immediate link. as a quick evidence of the implementation, in bg= pd.c of quagga suite we may read the piece of source code:=A0

=A0 =A0peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PE= ER_IBGP ? 255 : 1);

it is saying, if the peer is I= BGP, the TTL of IP header carrying it should be set to 255; while if it is = EBGP, TTL should be 1.=A0

Not familiar enough with= the subject to know whether these implementations cannot be configured so = that they don't care.
I noted that RFC4271 doesn't have t= he word virtual link, and that=A0RFC2328 only mentions "configured&quo= t; virtual links (=3D> out of scope). =A0

If, despite this, you get WG support for a requirement = of "1hop-only tunnels", the best answer is IMHO to include its su= pport in 4rd-U.
This AFAIK will close this issue.

Thanks for this clarification,
RD



--f46d04428dc0ade5b904bc36c6bd-- From despres.remi@laposte.net Tue Mar 27 03:42:52 2012 Return-Path: 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 B533821F8867 for ; Tue, 27 Mar 2012 03:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.217, 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 rbr9uBOwh4+y for ; Tue, 27 Mar 2012 03:42:51 -0700 (PDT) Received: from smtpout.laposte.net (smtpout7.laposte.net [193.253.67.232]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7221F85AF for ; Tue, 27 Mar 2012 03:42:50 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8514-out with ME id qaim1i0095M8erm03aimr9; Tue, 27 Mar 2012 12:42:48 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-202964481 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 12:42:46 +0200 Message-Id: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:42:52 -0000 --Apple-Mail-11-202964481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-27 =E0 12:15, Maoke a =E9crit : >=20 >=20 > 2012/3/27 R=E9mi Despr=E9s >=20 > Le 2012-03-27 =E0 08:41, Maoke a =E9crit : >=20 >> dear Remi,=20 >>=20 >> sorry but i forgot the time difference this morning. thanks for the = quick response! >>=20 >> 2012/3/27 R=E9mi Despr=E9s >> Dear Maoke, >>=20 >> Thanks for clarifying what you meant. >> I now understand that you were referring to applications that might = require IPv4 dialogue between one link apart nodes. >>=20 >> Whether this is a real use case in the MAP-4rd context remains = however to be seen. >>=20 >> if 4rd-u is limited to a very constrained scope, it is no problem. = but people surely want to have a scalable solution. i listed issues of = both inter-domain and intra-domain routing and i believe supporting some = dynamic routing in the MAP domain is a natural requirement.=20 >> =20 >> Here are my immediate comments: >> a) This wasn't mentioned as one of the desirable features of = stateless solutions. >>=20 >> any encapsulation is commonly, well understood to have such a feature = without need of further explanation, without need of adding any elements = in standard. we are now seldom discussing about the routing issue in the = stateless solutions but we cannot block up the road to the real = operation.=20 >=20 > Having a feature has never been expression of a requirement. >=20 >=20 >> b) Since MAP-T can't satisfy such a requirement, and there has been = promoters of MAP-T as a sufficient standard, this casts some doubt or = reality of this requirement. >>=20 >> well, my predicted response from you. :) please NOTE: MAP-T has never = said it can "replace E". >=20 > In my recollection, double translation it has been proposed as a = possibly unique standard but, OK, the MAP proposal is to have both MAP-T = AND MAP-E as standards. >=20 > we think MAP as a suite and -T and -E are to be used in different = circumstances where operators attach importance to different = considerations.=20 > =20 >=20 >> this thread is about the importance of virtual link as an = architectural building block that 4rd-u cannot offer. >=20 > See (*) below. >=20 >> MAP-T has none of business with this topic, because it is never = considered virtual link. what i am arguing against, in this thread, is = that "once operator has U it doesn't need either E or T". my point here = is: 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is = a unified solution" is NOT qualified.=20 >>=20 >> it is not the topic of this thread if 4rd-u can replace MAP-T or not. = i will go deep in that later, in another thread. >=20 > Then please leave me time to answer new discussion items you will = introduce (may answers may be after the end of this week.) >=20 > fully understood. but i won't stop in order to contribute my = understandings to the community Sure, and I appreciate your technical inputs. > stopping 4rd-u misleading the progress of standardization.=20 Different view on this. >> c) If the requirement is nevertheless confirmed, it can be satisfied = AFAIK by an ad hoc complement to 4rd-U. (At least one one approach I see = consists in using the 7 remaining bits of IPv6 packet IDs for this). I = would be glad to share w details with you, but only after the WG would = confirm that there is a real need. (Let's not say that because there is = a solution there is a need.) >>=20 >> another predicted patch idea. >=20 > (*) > "Another" patch?? > Just a solution to a feature you personally see add as a requirement. > It happens that I already thought about it, but didn't propose to = include it because I had never saw a WG requirement for it. >=20 > well, really never a WG requirement. some dialogues have been there: I have to face that I didn't understand well enough the discussion = thread below. Thanks for the reminder.=20 This is enough to convince me that, despite its not being recorded as a = MAP requirement, TTL preservation is a real requirement for some ISPs. Satoru-san wrote "what i would like to have is a consistent header = processing for single/double translations and encapsulation", and I = thought 4rd-U did achieve it. It will when we add TTL transparency.=20 > http://www.ietf.org/mail-archive/web/softwires/current/msg03106.html = -- the requirement=20 > http://www.ietf.org/mail-archive/web/softwires/current/msg03109.html = -- a possible solution > http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html = -- the concern on the possible solution and its little necessity > =20 >=20 >=20 >> but i doubt 7 bit can represent TTL =3D 255 correctly.=20 >=20 > Did I suggest that? > (I hope you will someday have more respect for my design ability!) >=20 > "using the 7 remaining bits of IPv6 packet IDs for this" was not your = writing? i never doubt your design ability but i also hope we (you and = me), when designing anything, will someday have more respect for all = other designers and implementors, being a little conservative on what we = will generate to the Internet. very sincerely hope so! Implementors I have met (a number of them) don't find 4rd-U complicated. For them, this is just a legend. > this thread could be closed now. i have expressed my consideration. i = also have prepared some further clarification for OSPF and RIP but it = looks you are not interested in it. Where did you see this? My answer above testifies of my interest for having this solved in = 4rd-U. > it is fine to me because operators and implementors know very clearly = about what i am concerning. just one comment on BGP4 "doesn't have a = word virtual link" --- all 6bone players may remember that, at that = time, we establish most of IPv6 BGP peers through virtual links = (tunnels), without the standard explicitly saying virtual link.=20 >=20 > conclusion has been cleared: 4rd-u cannot offer all that MAP-E (as = encapsulation supporting virtual link building block) can. Different view, and not alone in that. > 4rd-u is not a tunnel at all. With TTL transparency added, I don't see what would be missing, even = with all requirements you expressed. Regards, RD > =20 >=20 > so long, > - maoke >=20 > =20 >=20 >=20 >> d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do = you know a better reference than this RFC? >>=20 >> RFC2260 is informational rather than standard. BGP4 specification is = RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = =3D 1, as i mentioned, is not a standard feature, but used in some = implementations (including Cisco IOS and Juniper JUNOS and the = open-source routing tool Quagga, to my best knowledge) in order to = ensure the standard feature that defaultly EBGP is established over an = immediate link. as a quick evidence of the implementation, in bgpd.c of = quagga suite we may read the piece of source code:=20 >>=20 >> peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >>=20 >> it is saying, if the peer is IBGP, the TTL of IP header carrying it = should be set to 255; while if it is EBGP, TTL should be 1.=20 >=20 > Not familiar enough with the subject to know whether these = implementations cannot be configured so that they don't care. > I noted that RFC4271 doesn't have the word virtual link, and that = RFC2328 only mentions "configured" virtual links (=3D> out of scope). =20= >=20 > If, despite this, you get WG support for a requirement of "1hop-only = tunnels", the best answer is IMHO to include its support in 4rd-U. > This AFAIK will close this issue. >=20 > Thanks for this clarification, > RD >=20 >=20 >>=20 >=20 --Apple-Mail-11-202964481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-27 =E0 = 08:41, Maoke a =E9crit :

dear = Remi, 

sorry but i = forgot the time difference this morning. thanks for the quick = response!

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
Dear Maoke,

Thanks for = clarifying what you meant.
I now understand that you were = referring to applications that might require IPv4 dialogue between one = link apart nodes.

Whether this is a real use case in the MAP-4rd = context remains however to be = seen.

if 4rd-u is limited to = a very constrained scope, it is no problem. but people surely want to = have a scalable solution. i listed issues of both inter-domain and = intra-domain routing and i believe supporting some dynamic routing in = the MAP domain is a natural requirement. 
 
Here are my immediate = comments:
a) This wasn't mentioned as one of the desirable = features of stateless solutions.

any encapsulation is commonly, = well understood to have such a feature without need of further = explanation, without need of adding any elements in standard. we are now = seldom discussing about the routing issue in the stateless solutions but = we cannot block up the road to the real operation. 

Having a feature has never been = expression of a requirement.


b) Since MAP-T can't satisfy such a requirement, and there has been = promoters of MAP-T as a sufficient standard, this casts some doubt or = reality of this requirement.

well, my predicted response from = you. :) please NOTE: MAP-T has never said it can "replace E". =

In my recollection, double = translation it has been proposed as a possibly unique standard but, = OK, the MAP proposal is to have both MAP-T AND MAP-E as standards.

we think MAP as a suite and -T = and -E are to be used in different circumstances where operators attach = importance to different = considerations. 
 

this thread is about the = importance of virtual link as an architectural building block that 4rd-u = cannot offer.

See (*) below.

MAP-T has none of business with this topic, = because it is never considered virtual link. what i am arguing against, = in this thread, is that "once operator has U it doesn't need either E or = T". my point here is: 4rd-u cannot replace MAP-E, and accordingly the = statement "4rd-u is a unified solution" is NOT qualified. 

it is not the topic of this thread if 4rd-u can = replace MAP-T or not. i will go deep in that later, in another = thread.

Then please leave = me time to answer new discussion items you will introduce (may answers = may be after the end of this week.)

fully understood. but i won't = stop in order to contribute my understandings to the community =

Sure, and I appreciate your = technical inputs.

stopping 4rd-u misleading the progress of = standardization. 

Different = view on this.


c) If the requirement is = nevertheless confirmed, it can be satisfied AFAIK by an ad hoc = complement to 4rd-U. (At least one one approach I see consists in using = the 7 remaining bits of IPv6 packet IDs for this). I would be glad to = share w details with you, but only after the WG would confirm that there = is a real need. (Let's not say that because there is a solution there is = a need.)

another predicted patch = idea.

(*)
"Another"= patch??
Just a solution to a feature you personally see add = as a requirement.
It happens that I already thought about it, but didn't propose to = include it because I had never saw a WG requirement for = it.

well, really never a WG = requirement. some dialogues have been = there:



I have to face that I didn't understand well enough the discussion = thread below.
Thanks for the reminder. 
This is = enough to convince me that, despite its not being recorded as a MAP = requirement, TTL preservation is a real requirement for some = ISPs.
Satoru-san wrote "what i would like = to have is a consistent header processing for single/double translations = and encapsulation", and I thought 4rd-U did achieve = it.
It will when we add = TTL transparency.


 


but i doubt 7 bit can represent TTL =3D 255 = correctly. 

Did I = suggest that?
(I hope you will someday have more respect for = my design ability!)

"using the 7 remaining bits of IPv6 packet IDs for = this" was not your writing? i never doubt your design ability but i also = hope we (you and me), when designing anything, will someday have more = respect for all other designers and implementors, being a little = conservative on what we will generate to the Internet. very sincerely = hope so!

Implementors I have met = (a number of them) don't find 4rd-U complicated.




 

so = long,
- maoke

 


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than = this RFC?

RFC2260 is = informational rather than standard. BGP4 specification is RFC4271 and = you may be interested in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i = mentioned, is not a standard feature, but used in some implementations = (including Cisco IOS and Juniper JUNOS and the open-source routing tool = Quagga, to my best knowledge) in order to ensure the standard feature = that defaultly EBGP is established over an immediate link. as a quick = evidence of the implementation, in bgpd.c of quagga suite we may read = the piece of source code: 

   peer->ttl =3D (peer_sort (peer) =3D=3D= BGP_PEER_IBGP ? 255 : 1);

it is saying, if the = peer is IBGP, the TTL of IP header carrying it should be set to 255; = while if it is EBGP, TTL should be 1. 

Not familiar enough = with the subject to know whether these implementations cannot be = configured so that they don't care.
I noted that RFC4271 = doesn't have the word virtual link, and that RFC2328 only mentions = "configured" virtual links (=3D> out of scope).  

If, despite this, you get WG support for a = requirement of "1hop-only tunnels", the best answer is IMHO to include = its support in 4rd-U.
This AFAIK will close this = issue.

Thanks for this clarification,
RD




= --Apple-Mail-11-202964481-- From Francis.Dupont@fdupont.fr Tue Mar 27 04:02:20 2012 Return-Path: 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 B8DF821F887D for ; Tue, 27 Mar 2012 04:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] 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 PqVyaBOU98fa for ; Tue, 27 Mar 2012 04:02:20 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1D21F87FA for ; Tue, 27 Mar 2012 04:02:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2RB2FWQ014508; Tue, 27 Mar 2012 13:02:15 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203271102.q2RB2FWQ014508@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Tue, 27 Mar 2012 02:25:40 PDT. Date: Tue, 27 Mar 2012 13:02:15 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:02:20 -0000 In your previous mail you wrote: > What was the use case for non-contigous port sets? => cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt A good port set definition algorithm must be reversible, easy to implement, and should be able to define non-continuous or random port sets for better security, be able to exclude the well known ports, 0 ~ 1023 or 0 ~ 4095, etc. obviously pure port range aka contigous port set is not "good". Regards Francis.Dupont@fdupont.fr From repenno@cisco.com Tue Mar 27 04:10:24 2012 Return-Path: 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 A070821F884C for ; Tue, 27 Mar 2012 04:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 a5jRzUOcnxsr for ; Tue, 27 Mar 2012 04:10:22 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF16F21F85F6 for ; Tue, 27 Mar 2012 04:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=908; q=dns/txt; s=iport; t=1332846622; x=1334056222; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=MYAujpKCl9p56vuBHmZBS5x8CDEhX6z3rPsI6L8PTr4=; b=OfIbTQbChZkO5xwlssIhhAmHSsWL+Op08JHn7KD4ETBj6ItCHSNABX6M /J2PTQ469ALeuxl4/Y8Fqvm7zKF7zDe9CDW/HZMB8K0Ek1O00d9Uvp+D4 ozspIL8hulIXrGyUrqmBk+53ansJjgY6FkgBYwp7wej3zVH0A/SPpW6q2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQHAOuecU+rRDoJ/2dsb2JhbABDgxe1LYEHggkBAQEDARIBJwIBPBMIEAgjYgYOBSKHYwSedI1RiV6KZ4YoBIhYjQmFb4hWgWiDB4E8 X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="34717681" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 27 Mar 2012 11:10:22 +0000 Received: from [10.21.96.72] (sjc-vpn1-72.cisco.com [10.21.96.72]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2RBA8fi002075; Tue, 27 Mar 2012 11:10:17 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 04:10:06 -0700 From: Reinaldo Penno To: Francis Dupont Message-ID: Thread-Topic: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris In-Reply-To: <201203271102.q2RB2FWQ014508@givry.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:10:24 -0000 On 3/27/12 4:02 AM, "Francis Dupont" wrote: > > In your previous mail you wrote: > >> What was the use case for non-contigous port sets? > >=> cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt > > A good port set definition algorithm must be reversible, easy to > implement, A contiguous, direct mapping is the easiest to implement. >and should be able to define non-continuous or random port > sets for better security, If the ports are random at every new allocation then you need to store state, right? Or do you mean they are randomize at initiation, what I would call 'port shuffle'. >be able to exclude the well known ports, 0 > ~ 1023 or 0 ~ 4095, etc. I can understand excluding 0-1024 ports. > >obviously pure port range aka contigous port set is not "good". > >Regards > >Francis.Dupont@fdupont.fr From fibrib@gmail.com Tue Mar 27 04:12:15 2012 Return-Path: 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 3548721F899C for ; Tue, 27 Mar 2012 04:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 g0kUfZvTnea3 for ; Tue, 27 Mar 2012 04:12:13 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2D21F899A for ; Tue, 27 Mar 2012 04:12:13 -0700 (PDT) Received: by qadb15 with SMTP id b15so3753194qad.16 for ; Tue, 27 Mar 2012 04:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0i/C1EkohUeeOySgfKpxDHZqPx1DjnxlDh7pKtntqk=; b=ip2VYpyZhgMjtm6kL+Um2mGFPj10GUqL8CxxqOF0I1Jv3vWMbdzKJ+TfX4D4bFyrBt th0gXIn3xh362pfLQrHIi3gqaWDghoMJWtaXIT1Z0g0UdvEaqMUtqT2nWWXUXl7dzkJs 6M09br3i4sRQC6FcW0xSNkw94ltHOjpXuR3yBxknXMO1b/tqjJYBm/e5AGLal5rh7t/2 +MXmO4vqv8DVFW1qNpPUfY+q1NGhV66pByZhEc1Z6t/5y25FXBGqLepdbtaucq6HaiEt 3uz2UgpTgnEkubYzc0FbKnZYZtpLrRSa2HzJgJkoZdgI93vFGtFMqbItQ43Zm5BCTSKG OFcQ== MIME-Version: 1.0 Received: by 10.229.135.207 with SMTP id o15mr9691607qct.51.1332846732675; Tue, 27 Mar 2012 04:12:12 -0700 (PDT) Received: by 10.229.98.21 with HTTP; Tue, 27 Mar 2012 04:12:12 -0700 (PDT) In-Reply-To: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> Date: Tue, 27 Mar 2012 11:12:12 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c7690fe0a8cda04bc379032 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:12:15 -0000 --00248c7690fe0a8cda04bc379032 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/27 R=E9mi Despr=E9s > > Le 2012-03-27 =E0 12:15, Maoke a =E9crit : > > > > 2012/3/27 R=E9mi Despr=E9s > >> >> Le 2012-03-27 =E0 08:41, Maoke a =E9crit : >> >> dear Remi, >> >> sorry but i forgot the time difference this morning. thanks for the quic= k >> response! >> >> 2012/3/27 R=E9mi Despr=E9s >> >>> Dear Maoke, >>> >>> Thanks for clarifying what you meant. >>> I now understand that you were referring to applications that might >>> require IPv4 dialogue between one link apart nodes. >>> >>> Whether this is a real use case in the MAP-4rd context remains however >>> to be seen. >>> >> >> if 4rd-u is limited to a very constrained scope, it is no problem. but >> people surely want to have a scalable solution. i listed issues of both >> inter-domain and intra-domain routing and i believe supporting some dyna= mic >> routing in the MAP domain is a natural requirement. >> >> >>> Here are my immediate comments: >>> a) This wasn't mentioned as one of the desirable features of stateless >>> solutions. >>> >> >> any encapsulation is commonly, well understood to have such a feature >> without need of further explanation, without need of adding any elements= in >> standard. we are now seldom discussing about the routing issue in the >> stateless solutions but we cannot block up the road to the real operatio= n. >> >> >> Having a feature has never been expression of a requirement. >> >> >> b) Since MAP-T can't satisfy such a requirement, and there has been >>> promoters of MAP-T as a sufficient standard, this casts some doubt or >>> reality of this requirement. >>> >> >> well, my predicted response from you. :) please NOTE: MAP-T has never >> said it can "replace E". >> >> >> In my recollection, double translation it has been proposed as a possibl= y >> unique standard but, OK, the MAP proposal is to have both MAP-T AND MAP-= E >> as standards. >> > > we think MAP as a suite and -T and -E are to be used in different > circumstances where operators attach importance to different > considerations. > > >> >> this thread is about the importance of virtual link as an architectural >> building block that 4rd-u cannot offer. >> >> >> See (*) below. >> >> MAP-T has none of business with this topic, because it is never >> considered virtual link. what i am arguing against, in this thread, is t= hat >> "once operator has U it doesn't need either E or T". my point here is: >> 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is a >> unified solution" is NOT qualified. >> >> it is not the topic of this thread if 4rd-u can replace MAP-T or not. i >> will go deep in that later, in another thread. >> >> >> Then please leave me time to answer new discussion items you will >> introduce (may answers may be after the end of this week.) >> > > fully understood. but i won't stop in order to contribute my > understandings to the community > > > Sure, and I appreciate your technical inputs. > > stopping 4rd-u misleading the progress of standardization. > > > Different view on this. > > > c) If the requirement is nevertheless confirmed, it can be satisfied AFAI= K >>> by an ad hoc complement to 4rd-U. (At least one one approach I see cons= ists >>> in using the 7 remaining bits of IPv6 packet IDs for this). I would be = glad >>> to share w details with you, but only after the WG would confirm that t= here >>> is a real need. (Let's not say that because there is a solution there i= s a >>> need.) >>> >> >> another predicted patch idea. >> >> >> (*) >> "Another" patch?? >> Just a solution to a feature you personally see add as a requirement. >> It happens that I already thought about it, but didn't propose to includ= e >> it because I had never saw a WG requirement for it. >> > > well, really never a WG requirement. some dialogues have been there: > > > > > I have to face that I didn't understand well enough the discussion thread > below. > Thanks for the reminder. > This is enough to convince me that, despite its not being recorded as a > MAP requirement, TTL preservation is a real requirement for some ISPs. > Satoru-san wrote "what i would like to have is a consistent header > processing for single/double translations and encapsulation", and I thoug= ht > 4rd-U did achieve it. > It will when we add TTL transparency. > > > http://www.ietf.org/mail-archive/web/softwires/current/msg03106.html -- > the requirement > http://www.ietf.org/mail-archive/web/softwires/current/msg03109.html -- a > possible solution > http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html -- > the concern on the possible solution and its little necessity > > >> >> >> but i doubt 7 bit can represent TTL =3D 255 correctly. >> >> >> Did I suggest that? >> (I hope you will someday have more respect for my design ability!) >> > > "using the 7 remaining bits of IPv6 packet IDs for this" was not your > writing? i never doubt your design ability but i also hope we (you and me= ), > when designing anything, will someday have more respect for all other > designers and implementors, being a little conservative on what we will > generate to the Internet. very sincerely hope so! > > > Implementors I have met (a number of them) don't find 4rd-U complicated. > For them, this is just a legend. > > > this thread could be closed now. i have expressed my consideration. i als= o > have prepared some further clarification for OSPF and RIP but it looks yo= u > are not interested in it. > > > Where did you see this? > My answer above testifies of my interest for having this solved in 4rd-U. > it looks i misunderstood. i thought you were hurry to close this issue. > > it is fine to me because operators and implementors know very clearly > about what i am concerning. just one comment on BGP4 "doesn't have a word > virtual link" --- all 6bone players may remember that, at that time, we > establish most of IPv6 BGP peers through virtual links (tunnels), without > the standard explicitly saying virtual link. > > conclusion has been cleared: 4rd-u cannot offer all that MAP-E (as > encapsulation supporting virtual link building block) can. > > > Different view, and not alone in that. > > 4rd-u is not a tunnel at all. > > > With TTL transparency added, I don't see what would be missing, even with > all requirements you expressed. > well, it is still uncertain how 4rd-u will do this. it is uncertain if the new ad hoc complement doesn't introduce new problems. could we see it by the end of IETF83? thanks, maoke > > Regards, > RD > > > > > so long, > - maoke > > > >> >> >> d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do y= ou >>> know a better reference than this RFC? >>> >> >> RFC2260 is informational rather than standard. BGP4 specification is >> RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = =3D >> 1, as i mentioned, is not a standard feature, but used in some >> implementations (including Cisco IOS and Juniper JUNOS and the open-sour= ce >> routing tool Quagga, to my best knowledge) in order to ensure the standa= rd >> feature that defaultly EBGP is established over an immediate link. as a >> quick evidence of the implementation, in bgpd.c of quagga suite we may r= ead >> the piece of source code: >> >> peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >> >> it is saying, if the peer is IBGP, the TTL of IP header carrying it >> should be set to 255; while if it is EBGP, TTL should be 1. >> >> >> Not familiar enough with the subject to know whether these >> implementations cannot be configured so that they don't care. >> I noted that RFC4271 doesn't have the word virtual link, and that RFC232= 8 >> only mentions "configured" virtual links (=3D> out of scope). >> >> If, despite this, you get WG support for a requirement of "1hop-only >> tunnels", the best answer is IMHO to include its support in 4rd-U. >> This AFAIK will close this issue. >> >> Thanks for this clarification, >> RD >> >> >> > > --00248c7690fe0a8cda04bc379032 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-27 =E0 12:15, = Maoke a =E9crit :


=
2012/3/27 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-27 =E0 08:41, = Maoke a =E9crit :

dear Remi,=A0
=

sorry but i forgot the time difference this = morning. thanks for the quick response!

2012/3/27 R=E9mi Despr=E9s <despres.= remi@laposte.net>
Dear Mao= ke,

Thanks for clarifying what you meant.
I no= w understand that you were referring to applications that might require IPv= 4 dialogue between one link apart nodes.

Whether this is a real use case in the MAP-4rd context = remains however to be seen.

if = 4rd-u is limited to a very constrained scope, it is no problem. but people = surely want to have a scalable solution. i listed issues of both inter-doma= in and intra-domain routing and i believe supporting some dynamic routing i= n the MAP domain is a natural requirement.=A0
=A0
Here are my immediate comments:
a) This wasn't men= tioned as one of the desirable features of stateless solutions.

any encapsulation is commonly, well = understood to have such a feature without need of further explanation, with= out need of adding any elements in standard. we are now seldom discussing a= bout the routing issue in the stateless solutions but we cannot block up th= e road to the real operation.=A0

Having a feature has never been exp= ression of a requirement.


b) Since MAP-T can't satisfy such a requirement, and there has bee= n promoters of MAP-T as a sufficient standard, this casts some doubt or rea= lity of this requirement.

well, my predicted response from you= . :) please NOTE: MAP-T has never said it can "replace E".
=

In my recollection, double translat= ion=A0it has been proposed as a possibly unique standard but, OK, the MAP p= roposal is to have both MAP-T AND MAP-E as standards.

we think MAP as a suite and -T and -= E are to be used in different circumstances where operators attach importan= ce to different considerations.=A0
=A0

this thread is about the importance of vir= tual link as an architectural building block that 4rd-u cannot offer.

See (*) below.

<= blockquote type=3D"cite">
MAP-T has none of = business with this topic, because it is never considered virtual link. what= i am arguing against, in this thread, is that "once operator has U it= doesn't need either E or T". my point here is: 4rd-u cannot repla= ce MAP-E, and accordingly the statement "4rd-u is a unified solution&q= uot; is NOT qualified.=A0

it is not the topic of this thread if 4rd-u can replace= MAP-T or not. i will go deep in that later, in another thread.
=

Then please leave me time to answer new d= iscussion items you will introduce (may answers may be after the end of thi= s week.)

fully understood. but i won't st= op in order to contribute my understandings to the community

Sure, and I appreciate your technical input= s.

stopping 4rd-u misleading the progress of standardization.=A0

Different view on this.


c) If the requirement is neverthel= ess confirmed, it can be satisfied AFAIK by an ad hoc complement to 4rd-U. = (At least one one approach I see consists in using the 7 remaining bits of = IPv6 packet IDs for this). I would be glad to share w details with you, but= only after the WG would confirm that there is a real need. (Let's not = say that because there is a solution there is a need.)

another predicted patch idea.
<= /div>

(*)
"Another" pa= tch??
Just a solution to a feature you personally see add as a re= quirement.
It happens that I already thought about it, but didn't propose to = include it because I had never saw a WG requirement for it.

well, really never a WG requirement. some dial= ogues have been there:



I hav= e to face that I didn't understand well enough the discussion thread be= low.
Thanks for the reminder.=A0
This is enough to conv= ince me that, despite its not being recorded as a MAP requirement, TTL pres= ervation is a real requirement for some ISPs.
Satoru-san wrote "what i would like to have is a consistent header processing for= single/double translations and encapsulation", and I thought 4rd-U di= d achieve it.
It will whe= n we add TTL transparency.


http://www.ietf.org/mail-archive/web/softwires= /current/msg03110.html -- the concern on the possible solution and its = little necessity
=A0


but i doubt 7 bit can represent TTL =3D 255 correctly.=A0
=

Did I suggest that?
(I hope you= will someday have more respect for my design ability!)

"using the 7 remaining bits of IPv6 packet IDs for= this" was not your writing? i never doubt your design ability but i a= lso hope we (you and me), when designing anything, will someday have more r= espect for all other designers and implementors, being a little conservativ= e on what we will generate to the Internet. very sincerely hope so!

Implementors I have met (a number o= f them) don't find 4rd-U complicated.
For them, this is just = a legend.


this thread could be closed now. i have expressed my consideration. i = also have prepared some further clarification for OSPF and RIP but it looks= you are not interested in it.

Where did you see this?
My answer above testifies of my int= erest for having this solved in 4rd-U.

it looks i misunderstood. i thought you were hurry to close this is= sue.=A0
=A0

it is fine to me because operators and implementors know very clearly = about what i am concerning. just one comment on BGP4 "doesn't have= a word virtual link" --- all 6bone players may remember that, at that= time, we establish most of IPv6 BGP peers through virtual links (tunnels),= without the standard explicitly saying virtual link.=A0

conclusion has been cleared: 4rd-u cannot offer all tha= t MAP-E (as encapsulation supporting virtual link building block) can.

Different view, and not alone in = that.

4rd-u is not a tunnel at all.

With TTL transparency added, I don't see what would be missin= g, even with all requirements you expressed.

well, it is still uncertain how 4rd-= u will do this. it is uncertain if the new ad hoc complement doesn't in= troduce new problems. could we see it by the end of IETF83?=A0

thanks,
maoke=A0
=A0

R= egards,
RD


=A0

so long,=
- maoke

=A0


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than th= is RFC?

RFC2260 is informationa= l rather than standard. BGP4 specification is RFC4271 and you may be intere= sted in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i mentioned, is not a = standard feature, but used in some implementations (including Cisco IOS and= Juniper JUNOS and the open-source routing tool Quagga, to my best knowledg= e) in order to ensure the standard feature that defaultly EBGP is establish= ed over an immediate link. as a quick evidence of the implementation, in bg= pd.c of quagga suite we may read the piece of source code:=A0

=A0 =A0peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PE= ER_IBGP ? 255 : 1);

it is saying, if the peer is I= BGP, the TTL of IP header carrying it should be set to 255; while if it is = EBGP, TTL should be 1.=A0

Not familiar enough with= the subject to know whether these implementations cannot be configured so = that they don't care.
I noted that RFC4271 doesn't have t= he word virtual link, and that=A0RFC2328 only mentions "configured&quo= t; virtual links (=3D> out of scope). =A0

If, despite this, you get WG support for a requirement = of "1hop-only tunnels", the best answer is IMHO to include its su= pport in 4rd-U.
This AFAIK will close this issue.

Thanks for this clarification,
RD
=




--00248c7690fe0a8cda04bc379032-- From Francis.Dupont@fdupont.fr Tue Mar 27 04:45:17 2012 Return-Path: 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 7A84921E8197 for ; Tue, 27 Mar 2012 04:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 GooR5G77TAfy for ; Tue, 27 Mar 2012 04:45:17 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A6ED321E8192 for ; Tue, 27 Mar 2012 04:45:16 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2RBjCBp017309; Tue, 27 Mar 2012 13:45:13 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203271145.q2RBjCBp017309@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Tue, 27 Mar 2012 04:10:06 PDT. Date: Tue, 27 Mar 2012 13:45:12 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:45:17 -0000 In your previous mail you wrote: > >> What was the use case for non-contigous port sets? > > > >=> cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt > > > > A good port set definition algorithm must be reversible, easy to > > implement, > > > A contiguous, direct mapping is the easiest to implement. => I can't say no as I use it for the DS-Lite SD-NAT demo for exactly this reason. > >and should be able to define non-continuous or random port > > sets for better security, > > If the ports are random at every new allocation then you need to store > state, right? Or do you mean they are randomize at initiation, what I > would call 'port shuffle'. => the second (the SD-CGN uses an algorithm which can be slightly more complex than the identity :-). Regards Francis.Dupont@fdupont.fr PS: BTW if you want to discuss Tsou's I-D IMHO you should change the subject. From despres.remi@laposte.net Tue Mar 27 05:02:15 2012 Return-Path: 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 0DCF021F88E7 for ; Tue, 27 Mar 2012 05:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.209, 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 sxflonUjAYfK for ; Tue, 27 Mar 2012 05:02:14 -0700 (PDT) Received: from smtpout.laposte.net (smtpout6.laposte.net [193.253.67.231]) by ietfa.amsl.com (Postfix) with ESMTP id E361C21F88CD for ; Tue, 27 Mar 2012 05:02:13 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8511-out with ME id qc291i0015M8erm03c29Gk; Tue, 27 Mar 2012 14:02:12 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-207727691 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 14:02:09 +0200 Message-Id: <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:02:15 -0000 --Apple-Mail-12-207727691 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-27 =E0 13:12, Maoke a =E9crit : > 2012/3/27 R=E9mi Despr=E9s > With TTL transparency added, I don't see what would be missing, even = with all requirements you expressed. >=20 > well, it is still uncertain how 4rd-u will do this. it is uncertain if = the new ad hoc complement doesn't introduce new problems. could we see = it by the end of IETF83?=20 Sure. basic ID:=20 - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, = and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in = bits 1-7 of the hop count. - A exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID.=20 The only constraint it introduces is that the longest IPv6 path within = the domain must not exceed 127 (something that AFAIK shouldn't be a = problem) OK? RD >=20 > thanks, > maoke=20 > =20 >=20 > Regards, > RD >=20 >=20 >> =20 >>=20 >> so long, >> - maoke >>=20 >> =20 >>=20 >>=20 >>> d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. = Do you know a better reference than this RFC? >>>=20 >>> RFC2260 is informational rather than standard. BGP4 specification is = RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = =3D 1, as i mentioned, is not a standard feature, but used in some = implementations (including Cisco IOS and Juniper JUNOS and the = open-source routing tool Quagga, to my best knowledge) in order to = ensure the standard feature that defaultly EBGP is established over an = immediate link. as a quick evidence of the implementation, in bgpd.c of = quagga suite we may read the piece of source code:=20 >>>=20 >>> peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >>>=20 >>> it is saying, if the peer is IBGP, the TTL of IP header carrying it = should be set to 255; while if it is EBGP, TTL should be 1.=20 >>=20 >> Not familiar enough with the subject to know whether these = implementations cannot be configured so that they don't care. >> I noted that RFC4271 doesn't have the word virtual link, and that = RFC2328 only mentions "configured" virtual links (=3D> out of scope). =20= >>=20 >> If, despite this, you get WG support for a requirement of "1hop-only = tunnels", the best answer is IMHO to include its support in 4rd-U. >> This AFAIK will close this issue. >>=20 >> Thanks for this clarification, >> RD >>=20 >>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail-12-207727691 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/3/27 = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
With TTL transparency = added, I don't see what would be missing, even with all requirements you = expressed.

well, it is still uncertain how = 4rd-u will do this. it is uncertain if the new ad hoc complement doesn't = introduce new problems. could we see it by the end of = IETF83? 

Sure.
basic= ID: 
- At domain entry, put TTL bit 0 as leftmost bit of = the IPv6 hop count, and bits 1-7 in the remaining space of the IPv6 = packet ID. Put 127 in bits 1-7 of the hop count.
- A = exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID. 

The only constraint it introduces is = that the longest IPv6 path within the domain must not exceed 127 = (something that AFAIK shouldn't be a = problem)
OK?

RD


thanks, =
maoke 
 

Regards,
RD


 

so = long,
- maoke

 


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than = this RFC?

RFC2260 is = informational rather than standard. BGP4 specification is RFC4271 and = you may be interested in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i = mentioned, is not a standard feature, but used in some implementations = (including Cisco IOS and Juniper JUNOS and the open-source routing tool = Quagga, to my best knowledge) in order to ensure the standard feature = that defaultly EBGP is established over an immediate link. as a quick = evidence of the implementation, in bgpd.c of quagga suite we may read = the piece of source code: 

   peer->ttl =3D (peer_sort (peer) =3D=3D= BGP_PEER_IBGP ? 255 : 1);

it is saying, if the = peer is IBGP, the TTL of IP header carrying it should be set to 255; = while if it is EBGP, TTL should be 1. 

Not familiar enough = with the subject to know whether these implementations cannot be = configured so that they don't care.
I noted that RFC4271 = doesn't have the word virtual link, and that RFC2328 only mentions = "configured" virtual links (=3D> out of scope).  

If, despite this, you get WG support for a = requirement of "1hop-only tunnels", the best answer is IMHO to include = its support in 4rd-U.
This AFAIK will close this = issue.

Thanks for this = clarification,
RD






= --Apple-Mail-12-207727691-- From sunqi.csnet.thu@gmail.com Tue Mar 27 05:11:57 2012 Return-Path: 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 B305221F8A4E for ; Tue, 27 Mar 2012 05:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 5LBNBfeztuYP for ; Tue, 27 Mar 2012 05:11:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC821F8A48 for ; Tue, 27 Mar 2012 05:11:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5036560ghb.31 for ; Tue, 27 Mar 2012 05:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7CVzBlmrzym0RccvEPKlTY8u0tiUaYyc3Zq7mQuR49c=; b=pjppSpfhxYVhF/4e3JMvJOV2gjdlm9Gp6Gst8ghlt3AAg8SP7VehVhW/4wYLQvEwBH 6wB2uwB176QWvRDARk/zTJuiFTV+RTFOtVa9AjD0g96tipDwzApqs80l3hFiRQ09JKc0 4fB/kR4Jd9XgriGcgU5b7srfj0FZxbADoYUZzk96+P62s/8auyeFZoKLMp8yE0D3LDWw bfv7QYgPBRcDtOV9swye7xfEVSMytu42QMa0rW6VlnV5OWkr3JGPB4wQwvPWjbQxNYS3 5fhzELJZFZLZoxd1e+B9pO/JKN0Cr/whrHBN+nCHsnbm4qZ1hMmsWw1HUNSIskxGegpr 2ssw== MIME-Version: 1.0 Received: by 10.68.197.65 with SMTP id is1mr9005600pbc.70.1332850315576; Tue, 27 Mar 2012 05:11:55 -0700 (PDT) Received: by 10.143.63.10 with HTTP; Tue, 27 Mar 2012 05:11:55 -0700 (PDT) In-Reply-To: <201203271145.q2RBjCBp017309@givry.fdupont.fr> References: <201203271145.q2RBjCBp017309@givry.fdupont.fr> Date: Tue, 27 Mar 2012 20:11:55 +0800 Message-ID: From: Qi Sun To: Francis Dupont Content-Type: multipart/alternative; boundary=e89a8ff1c9a499446e04bc38658d Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:11:57 -0000 --e89a8ff1c9a499446e04bc38658d Content-Type: text/plain; charset=ISO-8859-1 Hi Francis, A quick question: why is there a SD-CGN? Do you mean the second NAT at AFTR used to reshape the out-of-range source port into the restricted port range? If so, IMHO it is stateful, not using an algorithm. And I think it still doesn't solve the security issue. Please correct me if there is any mistake~ Thank you Qi Sun 2012/3/27 Francis Dupont > In your previous mail you wrote: > > > >> What was the use case for non-contigous port sets? > > > > > >=> cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt > > > > > > A good port set definition algorithm must be reversible, easy to > > > implement, > > > > > > A contiguous, direct mapping is the easiest to implement. > > => I can't say no as I use it for the DS-Lite SD-NAT demo for > exactly this reason. > > > >and should be able to define non-continuous or random port > > > sets for better security, > > > > If the ports are random at every new allocation then you need to store > > state, right? Or do you mean they are randomize at initiation, what I > > would call 'port shuffle'. > > => the second (the SD-CGN uses an algorithm which can be slightly more > complex than the identity :-). > > Regards > > Francis.Dupont@fdupont.fr > > PS: BTW if you want to discuss Tsou's I-D IMHO you should change the > subject. > --e89a8ff1c9a499446e04bc38658d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francis,

=A0 =A0 =A0A quick question: why is there a = SD-CGN? Do you mean the second NAT at AFTR used to reshape the out-of-range= source port into the restricted port range?=A0
=A0 =A0 =A0 If so= , IMHO it is stateful, not using an=A0algorithm. And I think it still doesn= 't solve the security issue.=A0

=A0 =A0 =A0 Please correct me if there is any mistake~<= /div>

=A0 =A0 =A0Thank you

Qi S= un

2012/3/27 Francis Dupont <Francis.Dupont= @fdupont.fr>
=A0In your previous mail y= ou wrote:

> =A0>> =A0What was the use case for non-contigous port sets?
> =A0>
> =A0>=3D> cf draft-tsou-softwire-port-set-algorithms-analysis-01.= txt
> =A0>
> =A0> =A0 A good port set definition algorithm must be reversible, e= asy to
> =A0> =A0 implement,
>
>
> =A0A contiguous, direct mapping is the easiest to implement.

=3D> I can't say no as I use it for the DS-Lite SD-NAT demo fo= r
exactly this reason.

> =A0>and should be able to define non-continuous or random port
> =A0> =A0 sets for better security,
>
> =A0If the ports are random at every new allocation then you need to st= ore
> =A0state, right? Or do you mean they are randomize at initiation, what= I
> =A0would call 'port shuffle'.

=3D> the second (the SD-CGN uses an algorithm which can be slightl= y more
complex than the identity :-).

Regards

Francis.Dupont@fdupont.fr<= br>
PS: BTW if you want to discuss Tsou's I-D IMHO you should change the su= bject.

--e89a8ff1c9a499446e04bc38658d-- From Francis.Dupont@fdupont.fr Tue Mar 27 05:33:04 2012 Return-Path: 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 E763221F89B0 for ; Tue, 27 Mar 2012 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 6cc+JqsXJ25v for ; Tue, 27 Mar 2012 05:33:04 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2B40921F89B3 for ; Tue, 27 Mar 2012 05:33:03 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2RCX032020403; Tue, 27 Mar 2012 14:33:00 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203271233.q2RCX032020403@givry.fdupont.fr> From: Francis Dupont To: Qi Sun In-reply-to: Your message of Tue, 27 Mar 2012 20:11:55 +0800. Date: Tue, 27 Mar 2012 14:33:00 +0200 Sender: Francis.Dupont@fdupont.fr Cc: softwires WG , fdupont Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:33:05 -0000 In your previous mail you wrote: > A quick question: why is there a SD-CGN? Do you mean the second NAT at > AFTR used to reshape the out-of-range source port into the restricted port > range? => there must be a SD-CGN which: - filter from SD-CPE to the Internet packets checking the SD-CPE uses the right IP address and ports in its assigned port range - route on address + port packets from the Internet to the right SD-CPE optionally it can "suffle" the port bits but there is no agreement about this (so it is *optionally*). > If so, IMHO it is stateful, not using an algorithm. And I think it > still doesn't solve the security issue. => no, the second NAT is no way stateful. Only the SD-CPE is stateful (and port range restricted). Regards Francis.Dupont@fdupont.fr From phdgang@gmail.com Tue Mar 27 09:30:51 2012 Return-Path: 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 84BE621E8136 for ; Tue, 27 Mar 2012 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 oeUCjd8-ITTT for ; Tue, 27 Mar 2012 09:30:50 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4950421E8123 for ; Tue, 27 Mar 2012 09:30:50 -0700 (PDT) Received: by werb10 with SMTP id b10so63576wer.31 for ; Tue, 27 Mar 2012 09:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wHGsZzvcLbvoD3VAVl0dL+Lh9YMYHCbfNbEQvKzhLvg=; b=zPgW1y00vjQuATGgeHNVLXOI0V2haIcTw3c7Znh8YRAdE+xNLCTQ39XXsu5WXkMBZ8 56S8NflXN7nBNSrMGl1lgO+1rfZwL/c4HYbRTdyf4jFJNgve5ThpDwqQ3IUrJ5vCOPh9 k0uJbZW3SfQPlbn3CgZnyfk3G14PMBrvFnSCdEJkMTqeNfsygzA783eh8UHlHmShRTm+ Yaf55pAg3PL2/T8K73eUE/wPW9BPPu3aL3NIAE5iSH/a1Dxv1Ojbxh8JNuA9EvwEyZV1 qaBgqSMA8nRhPY2JvyByE97aQOUEBAv76il5buZYEHQIDTIZ/9HLJh2E6J6YQF+eU0XK trZQ== MIME-Version: 1.0 Received: by 10.216.131.212 with SMTP id m62mr15374887wei.20.1332865849320; Tue, 27 Mar 2012 09:30:49 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 27 Mar 2012 09:30:49 -0700 (PDT) In-Reply-To: <20120327171926187501149@gmail.com> References: <20120327171926187501149@gmail.com> Date: Wed, 28 Mar 2012 00:30:49 +0800 Message-ID: From: GangChen To: jiangdong345 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:30:51 -0000 2012/3/27, Jiang Dong : > Hi Gang and all, > > I think there are some points need to be considered between MAP series an= d > 4rd-U. > > 4rd-U saids "IPv4 headers can be reversibly mapped into IPv6 headers so t= hat > 4rd tunnel packets can be designed to be valid IPv6 packets" in Section I= . > In my understanding, the difference between 4rd-u and MAP-E is "IPv6 > fragment header vs IPv4 header". Both 4rd-U and MAP-E can keep the > transparency, while 4rd-U reserves 12 bytes to improve the efficiency and > MAT-E has some IPv4 redundancy octets but keep the original IP-IP > encapsulation which is easy to be operated. > > Comparing with MAP-E, 4rd-U keeps the DF bit, TOS and so on with an > additional IPv6 fragment header, which incurs reusing IPv6 option 44. > > If 4rd-U can be considered as a tunneling technique, the question is: doe= s > it deserve adding the IPv6 fragment header in order to save 12 bytes > efficiency each packet? Not just bits saving, but also capable of indentification with IPv6 address. Please see more detailed at draft-despres-softwire-stateless-analysis-tool-01 > If 4rd-U can be considered as a translation technique, the question is: d= oes > it deserve adding the IPv6 fragment header in order to keep transparency? See above draft to get more information on comparision. BTW, fragmentation header is in common for MAP-T and 4rd-U. BRs Gang > > From: GangChen > Date: 2012-03-27 15:53 > To: Kevin Y > CC: Softwires WG > Subject: Re: [Softwires]Path to move forward with 4rd=C5=A0 > Hello Kevin and all, > > I actually see current multiple solution proposal from different > angle. Regarding the changes you mentioned, MAP-T/E is also doing > that, e.g. added fragmentation header to survive DF bit; change ICMP > ID filed to carry the port information. > > 4rd-U doesn't beat MAP-series. I prefer to understand the situation is > 4rd-U raised some points(e.g. CNP, Fully IPv4 transparency) which is > desirable heading to a perfect protocol design. > > BRs > > Gang > > 2012/3/27, Kevin Y : >> Hi, Remi, >> >> This is beyond the charter of softwire WG, changing IPv6 address format >> needs much broad discussion in IETF community to understand its impact >> first, before we should even discuss if it is valid to design something >> like this in softwire. Have you done that ? >> >> Best Regards, >> >> Kevin Yin >> >> On Thu, Mar 22, 2012 at 10:04 PM, Guanghui Yu >> wrote: >> >>> Hi Yiu >>> >>> 4rd-u changes the IPv6 header architecture (redefine >>> fragmentation header extension) and IPv6 address architecture (differen= t >>> meaning of u-bit when g-bit=3D1). These are the fundamental changes. If >>> 4rd-u >>> becomes the standard, then there will be new defined =E6=8F=91Pv6?packe= ts on >>> the Internet, which are not compatible with existing IPv6 packets and >>> no existing devices can understand those packets. >>> >>> >>> Yu Guanghui >>> Network and Information Center >>> Dalian University of Technology, China >>> >>> >>> On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu >>> wrote: >>> >>>> Hi Guanghui, >>>> >>>> I agree that both MAP and 4rd-u are similar technology and solving the >>>> same problem. From technical perspective, can you elaborate this a >>>> lithe >>>> bit? >>>> >>>> Thanks, >>>> Yiu >>>> >>>> From: Guanghui Yu >>>> Date: Thu, 22 Mar 2012 20:26:40 +0800 >>>> To: Softwires WG >>>> Subject: Re: [Softwires] Path to move forward with 4rd? >>>> >>>> I read 4rd-u draft and found it is flawed. >>>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From repenno@cisco.com Tue Mar 27 14:19:50 2012 Return-Path: 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 D0C7521E8113 for ; Tue, 27 Mar 2012 14:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 pdcq6LdEJVUb for ; Tue, 27 Mar 2012 14:19:50 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 097A221E810D for ; Tue, 27 Mar 2012 14:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=6158; q=dns/txt; s=iport; t=1332883190; x=1334092790; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=vwBYIqlFK0F00/u9+CA+TuFw8M2HFZMEx2kbj/2zFhE=; b=Av7bXEJK01wcVCpJe5saW+q3gro0l2WB8eXU089sDFFTM2sciDJZn37Z MROHc1HSc0FhUdwSV1T9yHK5YDOHlQKbAoiqiBJgHZ+WdXxMLbeK+CRxi rYtzBfA1p+PMYTx6mTDx/yObwu+e1Zvs0hOuRUQiwbVMmVqOzYGy+10bb s=; X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="37831246" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 27 Mar 2012 21:19:50 +0000 Received: from [10.21.81.114] (sjc-vpn4-370.cisco.com [10.21.81.114]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2RLJlFA024962; Tue, 27 Mar 2012 21:19:49 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 14:19:45 -0700 From: Reinaldo Penno To: Satoru Matsushima , Alain Durand , Softwires WG , Yong Cui , Ralph Droms Message-ID: Thread-Topic: [Softwires] Path to move forward with =?ISO-8859-1?B?NHJkig==?= In-Reply-To: <240B8C21-D3A7-4E2B-B1FE-0520FCC8A9DD@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [Softwires] =?iso-8859-1?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:19:50 -0000 On 3/26/12 8:54 PM, "Satoru Matsushima" wrote: >As a member of the MAT DT, I am naturally biased in favor of what Xing, >Maoke and Ole said. > >I also think that the chair's questions are not adequate. I don't think >that the questions should be which of document the wg choose, make >documents to be unified or not. I think that it should be what 'solution >space' has been clarified beyond the MAP suite. Let me try to figure >these out. > >1. Reduce the number of parameters for MAP configuration > The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', >'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It >would be more convenient when one or some of them can be reduced or >omitted. [Reinaldo] Good point. Irrespective of MAP/4rd-U it would be good to have a=20 simplified model for ease of deployment. Usually when implementing such standards things get very complicated for both development and ISP due to - Consistency checks across all parameters - Consistency checks within a parameter - Debugging, operational commands, testing, - Interop testing, naming conventions - Network planning and staff training. Thanks, Reinaldo=20 > >2. Trying to keep more header transparency > When operators think that it would be nice if the MAP-T can keep header >transparency, which includes checksum neutrality, beyond the current >header translation specification, the wg should be work on that, or ask >other wg to do that. > >3. Truly 'Unified' operation > Since encapsulation and translation are completely separated operation >in operator's network (I mean 'polarized' on Jan's comment) but the >implementation of both is possible into one box. Beyond just 'unified >document', does operators think it would be more attractive with >'unified' operation for which both encapsulation and translation co-exist >in same time, on same network, for same service. > >Above three are my thought of what 4rd-u proposed to the wg. Discussions >and more suggestions are welcome. > >Best regards, >--satoru > > > >On 2012/03/23, at 10:46, Ole Tr=F8an wrote: > >> Alain, et al, >>=20 >> we have been at an impasse, so thank you very much for proposing a path >>forward. >>=20 >>> After a number of discussions with my co-chair, our AD and various >>>authors, here is how we would like to move forward wrt 4rd. >>> 1) There is an observation that all the solutions on the table E, T & >>>U actually solve the stateless problem we started with. >>> There are differences, but it is unclear if those differences are >>>really significant. E and T are the original Encapsulation and >>>Translation >>> proposals, U is an hybrid unifying solution. >>=20 >> I do agree with that. the Venn diagram for the three solutions would >>look awfully similar to a single circle. ;-) >> there are some use cases though, that can only be fulfilled with one >>mode of transport versus the other. >> I left the interim meeting in Beijing having been convinced that there >>are use cases requiring both encapsulation and requiring translation. if >>we for a moment accept that, I would suggest that we treat MAP as one >>single solution. it will have two options/flavours of transport. >>=20 >>> 2) We have already agreed back in Beijing that we would publish all >>>necessary documents. The issue here is the 'label' or 'status' those >>> documents have at IETF. In particular, do we want to publish them as >>>Experimental, Informational or Standard Track. >>>=20 >>> We are at the point now where we need to make progress. In Paris, we >>>would like to ask for presentations from the proponents of each >>>candidate solution (E, T & U). >>> Each presentation should cover an overview of the proposed solution, >>>explain how it compares to the others and make a case as why it should >>>be the one on the Standard Track. We will allocate 20 minutes for each >>>presentation. >>> Then, we, chairs, would like to ask a series of questions to the >>>working group. In order to make this process transparent, here is the >>>list of questions we want to ask >>> and their sequence. >>>=20 >>> Q1: Without pre-supposing which one will be selected, do you agree to >>>publish 1 of the 3 proposals on the Standard Track and publish the >>>other(s) as Informational if still asked to? >>>=20 >>> If the answer is NO, then the process stops and we will publish >>>everything as Experimental and come back in 12-24 months to see what >>>gets adopted by the market. >>> If the answer is YES, we move to the next question. >>>=20 >>>=20 >>> Q2: Do you believe that the WG should publish U as the one Standards >>>Track document? >>>=20 >>> If the answer is YES, the process stop, we put U on the Standard Track >>>and publish E & T as Informational. >>> If the answer is NO, we are left with E & T (U then might be abandoned >>>or published as Historical/Informational) >>>=20 >>>=20 >>> Q3: Which of E and T do you want to see moving on the standard track >>>(you can only express support for one)? >>>=20 >>> If there is a clear outcome from this question, we would publish that >>>proposal on the Standard Track and the other one as Informational. >>> If there is no clear consensus on this question, we will publish both >>>E & T as Experimental. >>=20 >> with the above proposal, we can drop question 3. >>=20 >>> In the meantime, we would like to encourage discussion on the mailing >>>list to foster our common understanding of the various technologies and >>>how they relate to each other. >>=20 >> can ask the chairs to take a hum of how many would want t-shirts for >>the meeting with: "Just pick one for F's sake and stop arguing". ;-) >>=20 >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From tetsuya@ipinfusion.com Tue Mar 27 15:43:40 2012 Return-Path: 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 7689C21E814C for ; Tue, 27 Mar 2012 15:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 dQg-nsgliclq for ; Tue, 27 Mar 2012 15:43:39 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id EBC7021E8024 for ; Tue, 27 Mar 2012 15:43:13 -0700 (PDT) Received: from mail39-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Mar 2012 22:42:59 +0000 Received: from mail39-tx2 (localhost [127.0.0.1]) by mail39-tx2-R.bigfish.com (Postfix) with ESMTP id 629E83E015E; Tue, 27 Mar 2012 22:42:59 +0000 (UTC) X-SpamScore: -31 X-BigFish: PS-31(zzbb2dIc89bh1432N98dK4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail39-tx2: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=tetsuya@ipinfusion.com; helo=CH1PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail39-tx2 (localhost.localdomain [127.0.0.1]) by mail39-tx2 (MessageSwitch) id 1332888176958661_14006; Tue, 27 Mar 2012 22:42:56 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.239]) by mail39-tx2.bigfish.com (Postfix) with ESMTP id E3A0D8007A; Tue, 27 Mar 2012 22:42:56 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Mar 2012 22:42:55 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.139]) by CH1PRD0510HT005.namprd05.prod.outlook.com ([10.255.150.40]) with mapi id 14.16.0135.002; Tue, 27 Mar 2012 22:42:56 +0000 From: Tetsuya Murakami To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= Thread-Topic: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 Thread-Index: AQHNDGrz1y5CRYYmgkeLsKJryXrvGw== Date: Tue, 27 Mar 2012 22:42:55 +0000 Message-ID: <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> In-Reply-To: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT005.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT005.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:43:40 -0000 SGkgUmVtaSwNCg0KVGhhbmsgeW91IGZvciBoYXZpbmcgdGhlIGluZm9ybWF0aW9uYWwgbWVldGlu ZyBvZiA0cmQtdS4gSSBjYW4gdW5kZXJzdGFuZCA0cmQtdSB2ZXJ5IG11Y2guIA0KDQpBcyB5b3Ug bWVudGlvbmVkIGR1cmluZyB0aGUgaW5mb3JtYXRpb25hbCBtZWV0aW5nLCA0cmQtdSBkZWZpbmVz IHRoZSBuZXcgdHlwZSBvZiB0aGUgdHJhbnNsYXRpb24gYmV0d2VlbiBJUHY0IGFuZCBJUHY2IGlu c3RlYWQgb2YgTUFQLUUvTUFQLVQuIEFsc28sIHRoaXMgbmV3IHR5cGUgb2YgdGhlIHRyYW5zbGF0 aW9uIGhhcyBubyByZWxhdGlvbnNoaXAgd2l0aCB0aGUgbWFwcGluZyBydWxlLiBIZW5jZSwgSSB0 aGluayA0cmQtdSBkcmFmdCBjYW4gYmUgY2hhbmdlZCBvbmx5IHRvIGRlZmluZSB0aGUgbmV3IHR5 cGUgb2YgdGhlIHRyYW5zbGF0aW9uIHNpbWlsYXIgdG8gTUFQLUUvTUFQLVQgYnkgcmVtb3Zpbmcg YW55IHRleHQgcmVsYXRlZCB0byBtYXBwaW5nIHJ1bGUgYW5kIHJlZmVyIHRvIE1BUCBmb3IgdGhl IG1hcHBpbmcgcnVsZS4gSW4gdGhpcyBjYXNlLCBpdCBkZXBlbmRzIG9uIGRlcGxveW1lbnQgc2Nl bmFyaW8gdG8gY2hvb3NlIE1BUC1FLCBNQVAtVCBvciA0cmQtdS4NCg0KQWxzbywgYXMgSSBtZW50 aW9uZWQgZHVyaW5nIHRoZSBtZWV0aW5nLCBJIGRvdWJsZS1jaGVja2VkIHRoZSBjdXJyZW50IGlt cGxlbWVudGF0aW9uIG9mIElQdjYgc3RhY2sgKExpbnV4L0JTRCkuIElmIGltcGxlbWVudGluZyA0 cmQtdSwgSVB2NiBzdGFjayBnaXZlcyByZWNlaXZlZCBJUHY2IHBhY2tldCB0byA0cmQtdSBtb2R1 bGUgYWZ0ZXIgcHJvY2Vzc2luZyBpdC4gQnV0LCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgaW1w bGVtZW50YXRpb24gb2YgSVB2NiBzdGFjaywgSVB2NiBzdGFjayB0b3RhbGx5IHJlbW92ZXMgSVB2 NiBmcmFnbWVudCBoZWFkZXIgd2hlbiBJUHY2IHN0YWNrIGZpbmRzIElQdjYgZnJhZ21lbnQgaGVh ZGVyIGFuZCBwcm9jZXNzZXMgaXQuIA0KDQpTaW5jZSA0cmQtdSBtb2R1bGUgZ2V0cyB0aGUgcGFj a2V0IGFmdGVyIElQdjYgc3RhY2sgcHJvY2Vzc2VzIHRoZSBwYWNrZXQsIElQdjYgZnJhZ21lbnQg aGVhZGVyIGlzIG5vdCBwcmVzZW50IHdoZW4gNHJkLXUgbW9kdWxlIGdldHMgdGhlIHBhY2tldC4g NHJkLXUgdXRpbGl6ZXMgSVB2NiBmcmFnbWVudCBoZWFkZXIgdG8gY2Fycnkgc29tZSBvZiBJUHY0 IGluZm9ybWF0aW9uLiBCdXQgYWxsIGluZm9ybWF0aW9uIGVtYmVkZGVkIGluIElQdjYgZnJhZ21l bnQgaGVhZGVyIGlzIGRpc2FwcGVhcmVkIGluIElQdjYgc3RhY2sgYmVmb3JlIDRyZC11IG1vZHVs ZSBnZXRzIHRoZSBwYWNrZXQuIEhlbmNlLCBpbiBvcmRlciB0byBrZWVwL3Bhc3MgdGhlIGluZm9y bWF0aW9uIGVtYmVkZGVkIGluIElQdjYgZnJhZ21lbnQgaGVhZGVyIHRvIDRyZC11IG1vZHVsZSwg SSB0aGluayB0aGUgZXhpc3RpbmcgSVB2NiBzdGFjayBuZWVkcyB0byBiZSBjaGFuZ2VkLiANCg0K SW4gdGVybXMgb2YgTUFQLVQsIElQdjYgZnJhZ21lbnQgaGVhZGVyIGlzIGFsc28gcmVxdWlyZWQg YnV0IG5vIGluZm9ybWF0aW9uIGlzIGVtYmVkZGVkIGluIElQdjYgZnJhZ21lbnQgaGVhZGVyLiBB bHNvLCB0aGUgY3VycmVudCBJUHY2IGltcGxlbWVudGF0aW9uIGNhbiBnaXZlIG9ubHkgaW5mb3Jt YXRpb24gaWYgdGhlcmUgaXMgYSBmcmFnbWVudCBoZWFkZXIgb3Igbm90LiBTbywgTUFQLVQgY2Fu IGtub3cgaWYgdGhlcmUgaXMgYSBmcmFnbWVudCBoZWFkZXIgb3Igbm90IGFmdGVyIElQdjYgc3Rh Y2sgcHJvY2Vzc2VzIHRoZSBwYWNrZXQgd2l0aG91dCBhbnkgY2hhbmdlIG9mIHRoZSBleGlzdGlu ZyBJUHY2IHN0YWNrLg0KDQpJIHRoaW5rIE1BUC80cmQtdSBhcmUgdHJhbnNpdGlvbiB0ZWNobm9s b2d5IGFuZCBzbyBpdCBpcyBnb29kIHRvIGVsaW1pbmF0ZSBhbnkgaW1wYWN0IG9uIHRoZSBleGlz dGluZyBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHN0YWNrIGFzIG11Y2ggYXMgcG9zc2libGUuDQoN ClRoYW5rcywNClRldHN1eWEgTXVyYWthbWkNCg0KT24gMjAxMi8wMy8yNiwgYXQgMTE6NTcsIFLD qW1pIERlc3Byw6lzIHdyb3RlOg0KDQo+IEhpLCBhbGwsDQo+IA0KPiBXaXRoIHNvbWUgY28tYXV0 aG9ycyBvZiB0aGUgNHJkLVUgcHJvcG9zYWwsIHdlIHdpbGwgaG9sZCBhbiBpbmZvcm1hbCBtZWV0 aW5nIGFib3V0IGl0Lg0KPiAtIHN1YmplY3Q6IENsYXJpZmljYXRpb24gb24gd2hhdCA0cmQtVSBp cyBkZXNpZ25lZCB0byBkbywgYW5kIGhvdyBpdCBkb2VzIGl0Lg0KPiAtIFBhcnRpY2lwYW50czog d2hvZXZlciBpcyBpbnRlcmVzdGVkIGluIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIHRoZSA0cmQt VSBwcm9wb3NhbC4gDQo+IC0gcGxhY2U6ICByb29tIDIwNA0KPiAtIHRpbWUgOiAgVHVlc2RheSAx NToxNSAoZHVyYXRpb24gZGVwZW5kaW5nIG9uIHF1ZXN0aW9ucywgbWF4aW11bSB0aWxsIDE2OjMw KS4NCj4gDQo+IFRoZSBtZWV0aW5nIGNhbiBiZSBzZWVuIGFzIGEgYmFyIEJPRi4uLiB3aXRob3V0 IGRyaW5rcyBpbiB0aGUgcm9vbS4NCj4gDQo+IFNlZSB5b3UgdGhlcmUgaWYgaW50ZXJlc3RlZCwN Cj4gUkQiDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPiANCg0K From satoru.matsushima@gmail.com Tue Mar 27 19:31:43 2012 Return-Path: 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 895A821E8047 for ; Tue, 27 Mar 2012 19:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=1.656, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 RJ-ergWu9bqI for ; Tue, 27 Mar 2012 19:31:43 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A141421E801A for ; Tue, 27 Mar 2012 19:31:42 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4865351wib.13 for ; Tue, 27 Mar 2012 19:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=V71XpMncuwYrgt5RUxdGlahEoL8gIsobsVwsVFed0eA=; b=rQGqxE9M+cMZHREaiCWgkmgn5YTf0BCGg2iOyZKu+9WTIxG+ixZanvu2CdmYt7v35h 72qPprkswL3YftFZoxp9qmaD6yIbBTw697sQSWhLiREX3UJVOi4hVgGJd4pA0aEuqkYX NIyvCzbTT7mIUnd6OL/8v1wYC0q5IzenCF/YdTcxVfAq5DcQ6eMIo0B0NrcFV82H3our qPqRSUkgiPdZHwF+tcAM/UXuhCEy4H0rd74/pmaNfN1/1BOkVcDxPWlI8A7QCFSWCK91 6AMAnvKbG0wftItnuOEBUapAf03LBl7MmiwJdeDUiaMrMWDtYADZr5zGrjsqkHScIv2k MIrw== Received: by 10.180.80.9 with SMTP id n9mr2798365wix.4.1332901901874; Tue, 27 Mar 2012 19:31:41 -0700 (PDT) Received: from dhcp-453f.meeting.ietf.org (dhcp-453f.meeting.ietf.org. [130.129.69.63]) by mx.google.com with ESMTPS id 9sm7103907wid.2.2012.03.27.19.31.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 19:31:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> Date: Wed, 28 Mar 2012 04:31:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> To: Tetsuya Murakami , =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 02:31:43 -0000 I do agree with Tetsuya-san's comments. On the other hand, I couldn't = understand the reason of why the CNP is needed. Since 4rd-u focus on = support to communicate between ipv4 hosts, L4 checksum consistency could = be agnostic from any kind of 4rd-u nodes. So then I suggest that remove = checksum neutrality function from the document. cheers, --satoru On 2012/03/28, at 0:42, Tetsuya Murakami wrote: > Hi Remi, >=20 > Thank you for having the informational meeting of 4rd-u. I can = understand 4rd-u very much.=20 >=20 > As you mentioned during the informational meeting, 4rd-u defines the = new type of the translation between IPv4 and IPv6 instead of = MAP-E/MAP-T. Also, this new type of the translation has no relationship = with the mapping rule. Hence, I think 4rd-u draft can be changed only to = define the new type of the translation similar to MAP-E/MAP-T by = removing any text related to mapping rule and refer to MAP for the = mapping rule. In this case, it depends on deployment scenario to choose = MAP-E, MAP-T or 4rd-u. >=20 > Also, as I mentioned during the meeting, I double-checked the current = implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 = stack gives received IPv6 packet to 4rd-u module after processing it. = But, according to the current implementation of IPv6 stack, IPv6 stack = totally removes IPv6 fragment header when IPv6 stack finds IPv6 fragment = header and processes it.=20 >=20 > Since 4rd-u module gets the packet after IPv6 stack processes the = packet, IPv6 fragment header is not present when 4rd-u module gets the = packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 = information. But all information embedded in IPv6 fragment header is = disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in = order to keep/pass the information embedded in IPv6 fragment header to = 4rd-u module, I think the existing IPv6 stack needs to be changed.=20 >=20 > In terms of MAP-T, IPv6 fragment header is also required but no = information is embedded in IPv6 fragment header. Also, the current IPv6 = implementation can give only information if there is a fragment header = or not. So, MAP-T can know if there is a fragment header or not after = IPv6 stack processes the packet without any change of the existing IPv6 = stack. >=20 > I think MAP/4rd-u are transition technology and so it is good to = eliminate any impact on the existing implementation of IPv6 stack as = much as possible. >=20 > Thanks, > Tetsuya Murakami >=20 > On 2012/03/26, at 11:57, R=C3=A9mi Despr=C3=A9s wrote: >=20 >> Hi, all, >>=20 >> With some co-authors of the 4rd-U proposal, we will hold an informal = meeting about it. >> - subject: Clarification on what 4rd-U is designed to do, and how it = does it. >> - Participants: whoever is interested in a good understanding of the = 4rd-U proposal.=20 >> - place: room 204 >> - time : Tuesday 15:15 (duration depending on questions, maximum = till 16:30). >>=20 >> The meeting can be seen as a bar BOF... without drinks in the room. >>=20 >> See you there if interested, >> RD" >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Tue Mar 27 20:21:25 2012 Return-Path: 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 D3EAD21E80D6 for ; Tue, 27 Mar 2012 20:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 m9fPvF87-D0A for ; Tue, 27 Mar 2012 20:21:24 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7621E801A for ; Tue, 27 Mar 2012 20:21:24 -0700 (PDT) Received: by qcsq13 with SMTP id q13so454992qcs.31 for ; Tue, 27 Mar 2012 20:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GmyttI0FFDEPNu4ha4V20UpncPKo6GtXt4kp4kFbJC8=; b=ar1hPKf+9CQXc/Hmgt4xT8Sjq/mDUdyIqFkPz8LIlHzmM+B0eL77QviCOLjIA/87KW b5Up1zv7/+CIfbglxdIJH/K/y2pyH2q6n+cy89ava8sEr4229GuP8cc77fMhBl3pXUxa haCbtD98TKNWVgO/FUTu2vNidoP+9M4vSNP8sQPQJLDdQmX+/QEJFiJL49E48mGCF2uu zirNuABIFSok4vO6ILsbseHKkwBfpTOia/Ab/NB3n4iGbo1Jbl9tDhBEhLOR/JNKRUVJ ot6ZPDaLjfHcaKCAbzD4Gg6eyt4JIXutdu0Ez2yPIeEdcU2czR1+VHh7boRXUZBVSwxA RUAg== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr10972502qct.71.1332904884166; Tue, 27 Mar 2012 20:21:24 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Tue, 27 Mar 2012 20:21:24 -0700 (PDT) In-Reply-To: <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> Date: Wed, 28 Mar 2012 03:21:24 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235452e75023e03f04bc451ae9 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:21:25 -0000 --00235452e75023e03f04bc451ae9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/27 R=E9mi Despr=E9s > > Le 2012-03-27 =E0 13:12, Maoke a =E9crit : > > 2012/3/27 R=E9mi Despr=E9s >> >> With TTL transparency added, I don't see what would be missing, even wit= h >> all requirements you expressed. >> > > well, it is still uncertain how 4rd-u will do this. it is uncertain if th= e > new ad hoc complement doesn't introduce new problems. could we see it by > the end of IETF83? > > > Sure. > basic ID: > - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, > and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bit= s > 1-7 of the hop count. > > - A exit, take bit 0 from the hop count, and bits 1-7 from the packet ID. > > The only constraint it introduces is that the longest IPv6 path within th= e > domain must not exceed 127 (something that AFAIK shouldn't be a problem) > > "AFAYK" cannot be considered as a common understanding. well, it seems creative though really causes several new concerns: 1. nobody can think the leftmost bit of Hop Limit in IPv6 header is marked as "unused" or "unspecified" (actually it is often used). you'd better to update RFC2460 first. 2. not sure that IPv6 path within a domain larger than 127 hops is a corner case that is more-corner than the corner of DF=3DMF=3D1. in fact, this is t= o change the definition of routing loop criterion in a IPv6 network. 3. even domain diameter less than 127 is always true, MAP-E's generic encapsulation module can works for both the MAP and also the stateful tunneling across multiple domains unless the hop count exceeds what IPv6 protocol allows; while 4rd-u CE's header mapping module cannot be reused for stateful tunneling over multiple IPv6 domains (also because the processings are different). (you may say this is out of scope but i do hope you respect other people's scope of concern. thanks in advance!) (and it is really tough for implementators. maybe not your care and you may state it is simple. therefore i parenthesize this phrase.) on the other hand, besides the above concerns, there are still some technical flaws of this solution itself. *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish EBGP session over IPv6 with their 4rd addresses as the loopback addresses and ttl-security is set to, e.g., 254, in order to protect the peer from receiving attack messages sending by a remote third party with snoofing. the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit may offer a chance for the IPv4 node behind the CE, breaking the protection of the ttl-security, because the TCP carrying BGP is directly exposed as the payload of the generated IPv6 packet like translation but the Hop Limit is not correctly decreased. *2. when routing loop happens in the IPv6 domain, unfortunately, the Time Exceeded (hop limit exceeded) ICMPv6 message will be translated to Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a link-problem as is expected as a report on the problem of the 1-hop tunnel link. this must be confusing. best, maoke > > OK? > > RD > > > thanks, > maoke > > >> >> Regards, >> RD >> >> >> >> >> so long, >> - maoke >> >> >> >>> >>> >>> d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. Do >>>> you know a better reference than this RFC? >>>> >>> >>> RFC2260 is informational rather than standard. BGP4 specification is >>> RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL= =3D >>> 1, as i mentioned, is not a standard feature, but used in some >>> implementations (including Cisco IOS and Juniper JUNOS and the open-sou= rce >>> routing tool Quagga, to my best knowledge) in order to ensure the stand= ard >>> feature that defaultly EBGP is established over an immediate link. as a >>> quick evidence of the implementation, in bgpd.c of quagga suite we may = read >>> the piece of source code: >>> >>> peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >>> >>> it is saying, if the peer is IBGP, the TTL of IP header carrying it >>> should be set to 255; while if it is EBGP, TTL should be 1. >>> >>> >>> Not familiar enough with the subject to know whether these >>> implementations cannot be configured so that they don't care. >>> I noted that RFC4271 doesn't have the word virtual link, and >>> that RFC2328 only mentions "configured" virtual links (=3D> out of scop= e). >>> >>> If, despite this, you get WG support for a requirement of "1hop-only >>> tunnels", the best answer is IMHO to include its support in 4rd-U. >>> This AFAIK will close this issue. >>> >>> Thanks for this clarification, >>> RD >>> >>> >>> >> >> > > --00235452e75023e03f04bc451ae9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/27 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

Le 2012-03-27 =E0 13:12, = Maoke a =E9crit :
2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
With TTL transparency added, I don= 't see what would be missing, even with all requirements you expressed.=

well, it is still uncertain how 4rd-= u will do this. it is uncertain if the new ad hoc complement doesn't in= troduce new problems. could we see it by the end of IETF83?=A0

Sure.
basic ID:=A0
- = At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, and b= its 1-7 in the remaining space of the IPv6 packet ID.=A0Put 127 in bits 1-7= of the hop count.
=A0=A0
- A exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID.=A0

The only constraint it introduces is that t= he longest IPv6 path within the domain must not exceed 127 (something that = AFAIK shouldn't be a problem)
=A0

"AFAYK" cann= ot be considered as a common understanding. well, it seems creative though = really causes several new concerns:=A0

1. nobody c= an think the leftmost bit of Hop Limit in IPv6 header is marked as "un= used" or "unspecified" (actually it is often used). you'= d better to update RFC2460 first.=A0
2. not sure that IPv6 path within a domain larger than 127 hops is a c= orner case that is more-corner than the corner of DF=3DMF=3D1. in fact, thi= s is to change the definition of routing loop criterion in a IPv6 network.= =A0
3. even domain diameter less than 127 is always true, MAP-E's gene= ric encapsulation module can works for both the MAP and also the stateful t= unneling across multiple domains unless the hop count exceeds what IPv6 pro= tocol allows; while 4rd-u CE's header mapping module cannot be reused f= or stateful tunneling over multiple IPv6 domains (also because the processi= ngs are different). (you may say this is out of scope but i do hope you res= pect other people's scope of concern. thanks in advance!)=A0

(and it is really tough for implementators. maybe not y= our care and you may state it is simple. therefore i parenthesize this phra= se.)

on the other hand, besides the above concerns= , there are still some technical flaws of this solution itself.=A0

*1. consider a case where 2 CEs, 1 hop apart in IPv6 do= main, establish EBGP session over IPv6 with their 4rd addresses as the loop= back addresses and ttl-security is set to, e.g., 254, in order to protect t= he peer from receiving attack messages sending by a remote third party with= snoofing. the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit m= ay offer a chance for the IPv4 node behind the CE, breaking the protection = of the ttl-security, because the TCP carrying BGP is directly exposed as th= e payload of the generated IPv6 packet like translation but the Hop Limit i= s not correctly decreased.=A0

*2. when routing loop happens in the IPv6 domain, unfor= tunately, the Time Exceeded (hop limit exceeded) ICMPv6 message will be tra= nslated to Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather t= han a link-problem as is expected as a report on the problem of the 1-hop t= unnel link. this must be confusing.=A0

best,
maoke
=A0
=A0
OK?

RD


thanks,
maoke=A0
=A0

Regards,
RD


=A0

so long,
- maoke

=A0


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than th= is RFC?

RFC2260 is informationa= l rather than standard. BGP4 specification is RFC4271 and you may be intere= sted in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i mentioned, is not a = standard feature, but used in some implementations (including Cisco IOS and= Juniper JUNOS and the open-source routing tool Quagga, to my best knowledg= e) in order to ensure the standard feature that defaultly EBGP is establish= ed over an immediate link. as a quick evidence of the implementation, in bg= pd.c of quagga suite we may read the piece of source code:=A0

=A0 =A0peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PE= ER_IBGP ? 255 : 1);

it is saying, if the peer is I= BGP, the TTL of IP header carrying it should be set to 255; while if it is = EBGP, TTL should be 1.=A0

Not familiar enough with= the subject to know whether these implementations cannot be configured so = that they don't care.
I noted that RFC4271 doesn't have t= he word virtual link, and that=A0RFC2328 only mentions "configured&quo= t; virtual links (=3D> out of scope). =A0

If, despite this, you get WG support for a requirement = of "1hop-only tunnels", the best answer is IMHO to include its su= pport in 4rd-U.
This AFAIK will close this issue.

Thanks for this clarification,
RD
=






--00235452e75023e03f04bc451ae9-- From satoru.matsushima@gmail.com Tue Mar 27 21:11:04 2012 Return-Path: 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 E78E221E813F for ; Tue, 27 Mar 2012 21:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 bZyIxR9DkbMb for ; Tue, 27 Mar 2012 21:11:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1709D21E813E for ; Tue, 27 Mar 2012 21:11:03 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so375589wgb.13 for ; Tue, 27 Mar 2012 21:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=x7xK79zP9Em8ZupQoARYM/TgQx1mqoVAKQoKTLVAX3o=; b=LQHTkJkNYcoOvWCOHeHPEyBzeoMB4P6hscjmIE/5ROx/KV7Dq136jX5kV7AzZQVu5S GnoZ/wv8goZlTiXI7n3dPoGR+7MIvsstdAwjhaBC2denYVwkE7vbCOAu1iw4L+RATJ7t iIiwPb5NYc+vpVdn++/QxRnmt149gu+OkE6MnirY0yhih/q3YXe2R6bIZVjY3vJFGtUM EpLKNU82IYT9dpBaSeJuV0lrkRlsqZOOpZ/29VHgV37osxagH1Wj70BbJ3oagklDyHrs Sf/eQ9+29lvRa+LybgcP/+mY4tlruDbsGbewiMGoP4T0fDsLR0Ia2HSDkolXy/ZWCt58 DuAQ== Received: by 10.216.135.131 with SMTP id u3mr16069957wei.46.1332907863292; Tue, 27 Mar 2012 21:11:03 -0700 (PDT) Received: from dhcp-453f.meeting.ietf.org (dhcp-453f.meeting.ietf.org. [130.129.69.63]) by mx.google.com with ESMTPS id 6sm17952831wiz.1.2012.03.27.21.10.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 21:11:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> Date: Wed, 28 Mar 2012 06:10:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 04:11:05 -0000 FYI, section 5 of RFC5082 = (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique = that TTL is used to help tunnel packets security. Anyway,=20 On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: >=20 > Le 2012-03-27 =E0 13:12, Maoke a =E9crit : >> 2012/3/27 R=E9mi Despr=E9s >> With TTL transparency added, I don't see what would be missing, even = with all requirements you expressed. >>=20 >> well, it is still uncertain how 4rd-u will do this. it is uncertain = if the new ad hoc complement doesn't introduce new problems. could we = see it by the end of IETF83?=20 >=20 > Sure. > basic ID:=20 > - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop = count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put = 127 in bits 1-7 of the hop count. > - A exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID.=20 >=20 Too much. Don't change deeply well understand/deployed semantics, = PLEASE. > The only constraint it introduces is that the longest IPv6 path within = the domain must not exceed 127 (something that AFAIK shouldn't be a = problem) > OK? NO. cheers, --satoru= From tetsuya@ipinfusion.com Wed Mar 28 00:22:48 2012 Return-Path: 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 314B321E814C for ; Wed, 28 Mar 2012 00:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 X+g465hPZymE for ; Wed, 28 Mar 2012 00:22:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 141C621E816E for ; Wed, 28 Mar 2012 00:22:42 -0700 (PDT) Received: from mail13-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 07:22:41 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id C0D79208E8; Wed, 28 Mar 2012 07:22:41 +0000 (UTC) X-SpamScore: -31 X-BigFish: PS-31(zzbb2dIc89bh1432N98dK4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail13-am1: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=tetsuya@ipinfusion.com; helo=CH1PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1332919359126252_27938; Wed, 28 Mar 2012 07:22:39 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.236]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 0F192100287; Wed, 28 Mar 2012 07:22:39 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 07:22:38 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.139]) by CH1PRD0510HT005.namprd05.prod.outlook.com ([10.255.150.40]) with mapi id 14.16.0135.002; Wed, 28 Mar 2012 07:22:37 +0000 From: Tetsuya Murakami To: Satoru Matsushima Thread-Topic: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 Thread-Index: AQHNDLOM1y5CRYYmgkeLsKJryXrvGw== Date: Wed, 28 Mar 2012 07:22:36 +0000 Message-ID: <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> In-Reply-To: <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT005.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT005.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:22:48 -0000 SW4gdGVybXMgb2YgQ05QLCBDTlAgbmVlZHMgdG8gYmUgY2FsY3VsYXRlZCBldmVyeSB0aW1lIGlm IHRoZSBwYWNrZXQgaXMgdG93YXJkIHRvIG91dHNpZGUgb2YgZG9tYWluIGJlY2F1c2UgdGhlIGVt YmVkZGVkIElQdjQgYWRkcmVzcyBjb3VsZCBiZSBkaWZmZXJlbnQuIFNvLCBJIHRoaW5rIHRoZXJl IGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBDTlAgYW5kIHJlY2FsY3VsYXRpb24gb2YgTDQgY2hl Y2tzdW0gZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gcG9pbnQgb2Ygdmlldy4NCg0KVGhhbmtzLA0K VGV0c3V5YSBNdXJha2FtaQ0KDQpPbiAyMDEyLzAzLzI3LCBhdCAxOTozMSwgU2F0b3J1IE1hdHN1 c2hpbWEgd3JvdGU6DQoNCj4gSSBkbyBhZ3JlZSB3aXRoIFRldHN1eWEtc2FuJ3MgY29tbWVudHMu IE9uIHRoZSBvdGhlciBoYW5kLCBJIGNvdWxkbid0IHVuZGVyc3RhbmQgdGhlIHJlYXNvbiBvZiB3 aHkgdGhlIENOUCBpcyBuZWVkZWQuIFNpbmNlIDRyZC11IGZvY3VzIG9uIHN1cHBvcnQgdG8gY29t bXVuaWNhdGUgYmV0d2VlbiBpcHY0IGhvc3RzLCBMNCBjaGVja3N1bSBjb25zaXN0ZW5jeSBjb3Vs ZCBiZSBhZ25vc3RpYyBmcm9tIGFueSBraW5kIG9mIDRyZC11IG5vZGVzLiBTbyB0aGVuIEkgc3Vn Z2VzdCB0aGF0IHJlbW92ZSBjaGVja3N1bSBuZXV0cmFsaXR5IGZ1bmN0aW9uIGZyb20gdGhlIGRv Y3VtZW50Lg0KPiANCj4gY2hlZXJzLA0KPiAtLXNhdG9ydQ0KPiANCj4gDQo+IE9uIDIwMTIvMDMv MjgsIGF0IDA6NDIsIFRldHN1eWEgTXVyYWthbWkgd3JvdGU6DQo+IA0KPj4gSGkgUmVtaSwNCj4+ IA0KPj4gVGhhbmsgeW91IGZvciBoYXZpbmcgdGhlIGluZm9ybWF0aW9uYWwgbWVldGluZyBvZiA0 cmQtdS4gSSBjYW4gdW5kZXJzdGFuZCA0cmQtdSB2ZXJ5IG11Y2guIA0KPj4gDQo+PiBBcyB5b3Ug bWVudGlvbmVkIGR1cmluZyB0aGUgaW5mb3JtYXRpb25hbCBtZWV0aW5nLCA0cmQtdSBkZWZpbmVz IHRoZSBuZXcgdHlwZSBvZiB0aGUgdHJhbnNsYXRpb24gYmV0d2VlbiBJUHY0IGFuZCBJUHY2IGlu c3RlYWQgb2YgTUFQLUUvTUFQLVQuIEFsc28sIHRoaXMgbmV3IHR5cGUgb2YgdGhlIHRyYW5zbGF0 aW9uIGhhcyBubyByZWxhdGlvbnNoaXAgd2l0aCB0aGUgbWFwcGluZyBydWxlLiBIZW5jZSwgSSB0 aGluayA0cmQtdSBkcmFmdCBjYW4gYmUgY2hhbmdlZCBvbmx5IHRvIGRlZmluZSB0aGUgbmV3IHR5 cGUgb2YgdGhlIHRyYW5zbGF0aW9uIHNpbWlsYXIgdG8gTUFQLUUvTUFQLVQgYnkgcmVtb3Zpbmcg YW55IHRleHQgcmVsYXRlZCB0byBtYXBwaW5nIHJ1bGUgYW5kIHJlZmVyIHRvIE1BUCBmb3IgdGhl IG1hcHBpbmcgcnVsZS4gSW4gdGhpcyBjYXNlLCBpdCBkZXBlbmRzIG9uIGRlcGxveW1lbnQgc2Nl bmFyaW8gdG8gY2hvb3NlIE1BUC1FLCBNQVAtVCBvciA0cmQtdS4NCj4+IA0KPj4gQWxzbywgYXMg SSBtZW50aW9uZWQgZHVyaW5nIHRoZSBtZWV0aW5nLCBJIGRvdWJsZS1jaGVja2VkIHRoZSBjdXJy ZW50IGltcGxlbWVudGF0aW9uIG9mIElQdjYgc3RhY2sgKExpbnV4L0JTRCkuIElmIGltcGxlbWVu dGluZyA0cmQtdSwgSVB2NiBzdGFjayBnaXZlcyByZWNlaXZlZCBJUHY2IHBhY2tldCB0byA0cmQt dSBtb2R1bGUgYWZ0ZXIgcHJvY2Vzc2luZyBpdC4gQnV0LCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgaW1wbGVtZW50YXRpb24gb2YgSVB2NiBzdGFjaywgSVB2NiBzdGFjayB0b3RhbGx5IHJlbW92 ZXMgSVB2NiBmcmFnbWVudCBoZWFkZXIgd2hlbiBJUHY2IHN0YWNrIGZpbmRzIElQdjYgZnJhZ21l bnQgaGVhZGVyIGFuZCBwcm9jZXNzZXMgaXQuIA0KPj4gDQo+PiBTaW5jZSA0cmQtdSBtb2R1bGUg Z2V0cyB0aGUgcGFja2V0IGFmdGVyIElQdjYgc3RhY2sgcHJvY2Vzc2VzIHRoZSBwYWNrZXQsIElQ djYgZnJhZ21lbnQgaGVhZGVyIGlzIG5vdCBwcmVzZW50IHdoZW4gNHJkLXUgbW9kdWxlIGdldHMg dGhlIHBhY2tldC4gNHJkLXUgdXRpbGl6ZXMgSVB2NiBmcmFnbWVudCBoZWFkZXIgdG8gY2Fycnkg c29tZSBvZiBJUHY0IGluZm9ybWF0aW9uLiBCdXQgYWxsIGluZm9ybWF0aW9uIGVtYmVkZGVkIGlu IElQdjYgZnJhZ21lbnQgaGVhZGVyIGlzIGRpc2FwcGVhcmVkIGluIElQdjYgc3RhY2sgYmVmb3Jl IDRyZC11IG1vZHVsZSBnZXRzIHRoZSBwYWNrZXQuIEhlbmNlLCBpbiBvcmRlciB0byBrZWVwL3Bh c3MgdGhlIGluZm9ybWF0aW9uIGVtYmVkZGVkIGluIElQdjYgZnJhZ21lbnQgaGVhZGVyIHRvIDRy ZC11IG1vZHVsZSwgSSB0aGluayB0aGUgZXhpc3RpbmcgSVB2NiBzdGFjayBuZWVkcyB0byBiZSBj aGFuZ2VkLiANCj4+IA0KPj4gSW4gdGVybXMgb2YgTUFQLVQsIElQdjYgZnJhZ21lbnQgaGVhZGVy IGlzIGFsc28gcmVxdWlyZWQgYnV0IG5vIGluZm9ybWF0aW9uIGlzIGVtYmVkZGVkIGluIElQdjYg ZnJhZ21lbnQgaGVhZGVyLiBBbHNvLCB0aGUgY3VycmVudCBJUHY2IGltcGxlbWVudGF0aW9uIGNh biBnaXZlIG9ubHkgaW5mb3JtYXRpb24gaWYgdGhlcmUgaXMgYSBmcmFnbWVudCBoZWFkZXIgb3Ig bm90LiBTbywgTUFQLVQgY2FuIGtub3cgaWYgdGhlcmUgaXMgYSBmcmFnbWVudCBoZWFkZXIgb3Ig bm90IGFmdGVyIElQdjYgc3RhY2sgcHJvY2Vzc2VzIHRoZSBwYWNrZXQgd2l0aG91dCBhbnkgY2hh bmdlIG9mIHRoZSBleGlzdGluZyBJUHY2IHN0YWNrLg0KPj4gDQo+PiBJIHRoaW5rIE1BUC80cmQt dSBhcmUgdHJhbnNpdGlvbiB0ZWNobm9sb2d5IGFuZCBzbyBpdCBpcyBnb29kIHRvIGVsaW1pbmF0 ZSBhbnkgaW1wYWN0IG9uIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHN0YWNr IGFzIG11Y2ggYXMgcG9zc2libGUuDQo+PiANCj4+IFRoYW5rcywNCj4+IFRldHN1eWEgTXVyYWth bWkNCj4+IA0KPj4gT24gMjAxMi8wMy8yNiwgYXQgMTE6NTcsIFLDqW1pIERlc3Byw6lzIHdyb3Rl Og0KPj4gDQo+Pj4gSGksIGFsbCwNCj4+PiANCj4+PiBXaXRoIHNvbWUgY28tYXV0aG9ycyBvZiB0 aGUgNHJkLVUgcHJvcG9zYWwsIHdlIHdpbGwgaG9sZCBhbiBpbmZvcm1hbCBtZWV0aW5nIGFib3V0 IGl0Lg0KPj4+IC0gc3ViamVjdDogQ2xhcmlmaWNhdGlvbiBvbiB3aGF0IDRyZC1VIGlzIGRlc2ln bmVkIHRvIGRvLCBhbmQgaG93IGl0IGRvZXMgaXQuDQo+Pj4gLSBQYXJ0aWNpcGFudHM6IHdob2V2 ZXIgaXMgaW50ZXJlc3RlZCBpbiBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiB0aGUgNHJkLVUgcHJv cG9zYWwuIA0KPj4+IC0gcGxhY2U6ICByb29tIDIwNA0KPj4+IC0gdGltZSA6ICBUdWVzZGF5IDE1 OjE1IChkdXJhdGlvbiBkZXBlbmRpbmcgb24gcXVlc3Rpb25zLCBtYXhpbXVtIHRpbGwgMTY6MzAp Lg0KPj4+IA0KPj4+IFRoZSBtZWV0aW5nIGNhbiBiZSBzZWVuIGFzIGEgYmFyIEJPRi4uLiB3aXRo b3V0IGRyaW5rcyBpbiB0aGUgcm9vbS4NCj4+PiANCj4+PiBTZWUgeW91IHRoZXJlIGlmIGludGVy ZXN0ZWQsDQo+Pj4gUkQiDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+Pj4gU29mdHdp cmVzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z b2Z0d2lyZXMNCj4+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4+IFNvZnR3aXJlc0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly ZXMNCj4gDQo+IA0KDQo= From jiangdong345@gmail.com Wed Mar 28 00:51:48 2012 Return-Path: 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 27CBB21F88F1 for ; Wed, 28 Mar 2012 00:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 f0I+i7qu5evF for ; Wed, 28 Mar 2012 00:51:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 883D721F88D6 for ; Wed, 28 Mar 2012 00:51:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so1254776iaz.31 for ; Wed, 28 Mar 2012 00:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=OkwoMonAmLKxzWAEvjB9Meaqzc+ieUm8Alxp8TNmDKA=; b=d2/J0bWS/r/qMypg/Mzq0pppkFvOqL1JA42tcFBcVbpXpUy7EW1515tf9djlKG5JRL UJviwZMwPONztCr6PfD//HngdDLxge6py68cd33e/5PdxcK+aoU8xXbdbCEIoOvYRWN6 hYxMOybNRT8M1pvlUP8vRlcf2NjvVhFHWC8pxX2SL8/H1nIyOWWwMAjHQ3lIGog6HRo9 2nRcZUYuV0hHbh0P1r3iRnELO83T4BlI/0n0K04vznFKNjzr4YfQr8+py0gVCL+DZsur a/pkl7SmVVbeZN4dAo8gCWIE09ienM7jA1NlfMOiyaU6bOtUNcKDdCbTFPpBAtG4GIwm 4zBw== Received: by 10.50.42.136 with SMTP id o8mr1399819igl.38.1332921106172; Wed, 28 Mar 2012 00:51:46 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id wp4sm14526169igc.3.2012.03.28.00.51.42 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 00:51:45 -0700 (PDT) Date: Wed, 28 Mar 2012 15:51:43 +0800 From: "Jiang Dong" To: GangChen References: <20120327171926187501149@gmail.com>, X-Priority: 3 X-GUID: BA7006F6-6205-462A-9841-FD290E260208 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012032815505846727873@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart376485137478_=----" Cc: Softwires WG Subject: Re: [Softwires] =?utf-8?q?Path_to_move_forward_with_4rd=C5=A0?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:51:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart376485137478_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2FuZywNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBQbGVhc2Ugc2VlIGluIGxpbmVzLg0K DQpSZWdhcmRzIQ0KSmlhbmcgRG9uZw0KVHNpbmdodWEgVW5pdmVyc2l0eQ0KMjAxMi0wMy0yOA0K DQpGcm9tOiBHYW5nQ2hlbg0KRGF0ZTogMjAxMi0wMy0yOCAwMDozMA0KVG86IGppYW5nZG9uZzM0 NQ0KQ0M6IEtldmluIFk7IFNvZnR3aXJlcyBXRw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdUGF0 aCB0byBtb3ZlIGZvcndhcmQgd2l0aCA0cmTFoA0KMjAxMi8zLzI3LCBKaWFuZyBEb25nIDxqaWFu Z2RvbmczNDVAZ21haWwuY29tPjoNCj4gSGkgR2FuZyBhbmQgYWxsLA0KPg0KPiBJIHRoaW5rIHRo ZXJlIGFyZSBzb21lIHBvaW50cyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYmV0d2VlbiBNQVAgc2Vy aWVzIGFuZA0KPiA0cmQtVS4NCj4NCj4gNHJkLVUgc2FpZHMgIklQdjQgaGVhZGVycyBjYW4gYmUg cmV2ZXJzaWJseSBtYXBwZWQgaW50byBJUHY2IGhlYWRlcnMgc28gdGhhdA0KPiA0cmQgdHVubmVs IHBhY2tldHMgY2FuIGJlIGRlc2lnbmVkIHRvIGJlIHZhbGlkIElQdjYgcGFja2V0cyIgaW4gU2Vj dGlvbiBJLg0KPiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDRy ZC11IGFuZCBNQVAtRSBpcyAiSVB2Ng0KPiBmcmFnbWVudCBoZWFkZXIgdnMgSVB2NCBoZWFkZXIi LiBCb3RoIDRyZC1VIGFuZCBNQVAtRSBjYW4ga2VlcCB0aGUNCj4gdHJhbnNwYXJlbmN5LCB3aGls ZSA0cmQtVSByZXNlcnZlcyAxMiBieXRlcyB0byBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IGFuZA0K PiBNQVQtRSBoYXMgc29tZSBJUHY0IHJlZHVuZGFuY3kgb2N0ZXRzIGJ1dCBrZWVwIHRoZSBvcmln aW5hbCBJUC1JUA0KPiBlbmNhcHN1bGF0aW9uIHdoaWNoIGlzIGVhc3kgdG8gYmUgb3BlcmF0ZWQu DQo+DQo+IENvbXBhcmluZyB3aXRoIE1BUC1FLCA0cmQtVSBrZWVwcyB0aGUgREYgYml0LCBUT1Mg YW5kIHNvIG9uIHdpdGggYW4NCj4gYWRkaXRpb25hbCBJUHY2IGZyYWdtZW50IGhlYWRlciwgd2hp Y2ggaW5jdXJzIHJldXNpbmcgSVB2NiBvcHRpb24gNDQuDQo+DQo+IElmIDRyZC1VIGNhbiBiZSBj b25zaWRlcmVkIGFzIGEgdHVubmVsaW5nIHRlY2huaXF1ZSwgdGhlIHF1ZXN0aW9uIGlzOiBkb2Vz DQo+IGl0IGRlc2VydmUgYWRkaW5nIHRoZSBJUHY2IGZyYWdtZW50IGhlYWRlciBpbiBvcmRlciB0 byBzYXZlIDEyIGJ5dGVzDQo+IGVmZmljaWVuY3kgZWFjaCBwYWNrZXQ/DQoNCk5vdCBqdXN0IGJp dHMgc2F2aW5nLCBidXQgYWxzbyBjYXBhYmxlIG9mIGluZGVudGlmaWNhdGlvbiB3aXRoIElQdjYN CmFkZHJlc3MuIFBsZWFzZSBzZWUgbW9yZSBkZXRhaWxlZCBhdA0KZHJhZnQtZGVzcHJlcy1zb2Z0 d2lyZS1zdGF0ZWxlc3MtYW5hbHlzaXMtdG9vbC0wMQ0KDQo+IElmIDRyZC1VIGNhbiBiZSBjb25z aWRlcmVkIGFzIGEgdHJhbnNsYXRpb24gdGVjaG5pcXVlLCB0aGUgcXVlc3Rpb24gaXM6IGRvZXMN Cj4gaXQgZGVzZXJ2ZSBhZGRpbmcgdGhlIElQdjYgZnJhZ21lbnQgaGVhZGVyIGluIG9yZGVyIHRv IGtlZXAgdHJhbnNwYXJlbmN5Pw0KDQpTZWUgYWJvdmUgZHJhZnQgdG8gZ2V0IG1vcmUgaW5mb3Jt YXRpb24gb24gY29tcGFyaXNpb24uIEJUVywNCmZyYWdtZW50YXRpb24gaGVhZGVyIGlzIGluIGNv bW1vbiBmb3IgTUFQLVQgYW5kIDRyZC1VLg0KDQpbREpdIFRoYW5rcywgSSBoYXZlIHJlYWQgdGhl IGNvbXBhcmlzb24gZHJhZnQuIFdpdGggdGhlIGZyYWdtZW50YXRpb24gaGVhZGVyIDRyZC1VIGNh biBrZWVwIGl0cyB0cmFuc3BhcmVuY3kgYnV0IE1BUC1UIGNhbm5vdCwgIHNvIEkgdGhpbmsgdGhl IHVzZSBvZiBmcmFnbWVudGF0aW9uIGhlYWRlciBhcmUgbm90IHRoZSBzYW1lIGZvciBNQVAtVCBh bmQgNHJkLVUsIGFuZCBzb21lIGNvbXByb21pc2VzIG1heSBoYXZlIHRvIGJlIGNvbnNpZGVyZWQu DQoNCkJScw0KDQpHYW5nDQo+DQo+IEZyb206IEdhbmdDaGVuDQo+IERhdGU6IDIwMTItMDMtMjcg MTU6NTMNCj4gVG86IEtldmluIFkNCj4gQ0M6IFNvZnR3aXJlcyBXRw0KPiBTdWJqZWN0OiBSZTog W1NvZnR3aXJlc11QYXRoIHRvIG1vdmUgZm9yd2FyZCB3aXRoIDRyZMWgDQo+IEhlbGxvIEtldmlu IGFuZCBhbGwsDQo+DQo+IEkgYWN0dWFsbHkgc2VlIGN1cnJlbnQgbXVsdGlwbGUgc29sdXRpb24g cHJvcG9zYWwgZnJvbSBkaWZmZXJlbnQNCj4gYW5nbGUuIFJlZ2FyZGluZyB0aGUgY2hhbmdlcyB5 b3UgbWVudGlvbmVkLCBNQVAtVC9FIGlzIGFsc28gZG9pbmcNCj4gdGhhdCwgZS5nLiBhZGRlZCBm cmFnbWVudGF0aW9uIGhlYWRlciB0byBzdXJ2aXZlIERGIGJpdDsgY2hhbmdlIElDTVANCj4gSUQg ZmlsZWQgdG8gY2FycnkgdGhlIHBvcnQgaW5mb3JtYXRpb24uDQo+DQo+IDRyZC1VIGRvZXNuJ3Qg YmVhdCBNQVAtc2VyaWVzLiBJIHByZWZlciB0byB1bmRlcnN0YW5kIHRoZSBzaXR1YXRpb24gaXMN Cj4gNHJkLVUgcmFpc2VkIHNvbWUgcG9pbnRzKGUuZy4gQ05QLCBGdWxseSBJUHY0IHRyYW5zcGFy ZW5jeSkgd2hpY2ggaXMNCj4gZGVzaXJhYmxlIGhlYWRpbmcgdG8gYSBwZXJmZWN0IHByb3RvY29s IGRlc2lnbi4NCj4NCj4gQlJzDQo+DQo+IEdhbmcNCj4NCj4gMjAxMi8zLzI3LCBLZXZpbiBZIDxr eWtpbmc2QGdtYWlsLmNvbT46DQo+PiBIaSwgUmVtaSwNCj4+DQo+PiBUaGlzIGlzIGJleW9uZCB0 aGUgY2hhcnRlciBvZiBzb2Z0d2lyZSBXRywgY2hhbmdpbmcgSVB2NiBhZGRyZXNzIGZvcm1hdA0K Pj4gbmVlZHMgbXVjaCBicm9hZCBkaXNjdXNzaW9uIGluIElFVEYgY29tbXVuaXR5IHRvIHVuZGVy c3RhbmQgaXRzIGltcGFjdA0KPj4gZmlyc3QsIGJlZm9yZSB3ZSBzaG91bGQgZXZlbiBkaXNjdXNz IGlmIGl0IGlzIHZhbGlkIHRvIGRlc2lnbiBzb21ldGhpbmcNCj4+IGxpa2UgdGhpcyBpbiBzb2Z0 d2lyZS4gICBIYXZlIHlvdSBkb25lIHRoYXQgPw0KPj4NCj4+IEJlc3QgUmVnYXJkcywNCj4+DQo+ PiBLZXZpbiBZaW4NCj4+DQo+PiBPbiBUaHUsIE1hciAyMiwgMjAxMiBhdCAxMDowNCBQTSwgR3Vh bmdodWkgWXUgPHl1Lmd1YW5naHVpQGdtYWlsLmNvbT4NCj4+IHdyb3RlOg0KPj4NCj4+PiBIaSBZ aXUNCj4+Pg0KPj4+ICAgIDRyZC11IGNoYW5nZXMgdGhlIElQdjYgaGVhZGVyIGFyY2hpdGVjdHVy ZSAocmVkZWZpbmUNCj4+PiBmcmFnbWVudGF0aW9uIGhlYWRlciBleHRlbnNpb24pIGFuZCBJUHY2 IGFkZHJlc3MgYXJjaGl0ZWN0dXJlIChkaWZmZXJlbnQNCj4+PiBtZWFuaW5nIG9mIHUtYml0IHdo ZW4gZy1iaXQ9MSkuIFRoZXNlIGFyZSB0aGUgZnVuZGFtZW50YWwgY2hhbmdlcy4gSWYNCj4+PiA0 cmQtdQ0KPj4+IGJlY29tZXMgdGhlIHN0YW5kYXJkLCB0aGVuIHRoZXJlIHdpbGwgYmUgbmV3IGRl ZmluZWQg5o+RUHY2P3BhY2tldHMgb24NCj4+PiB0aGUgSW50ZXJuZXQsIHdoaWNoIGFyZSBub3Qg Y29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIElQdjYgcGFja2V0cyBhbmQNCj4+PiBubyBleGlzdGlu ZyBkZXZpY2VzIGNhbiB1bmRlcnN0YW5kIHRob3NlIHBhY2tldHMuDQo+Pj4NCj4+Pg0KPj4+IFl1 IEd1YW5naHVpIDx5Z2ggYXQgZGx1dC5lZHUuY24+DQo+Pj4gTmV0d29yayBhbmQgSW5mb3JtYXRp b24gQ2VudGVyDQo+Pj4gRGFsaWFuIFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neSwgQ2hpbmENCj4+ Pg0KPj4+DQo+Pj4gT24gRnJpLCBNYXIgMjMsIDIwMTIgYXQgMTA6MTAgQU0sIExlZSwgWWl1DQo+ Pj4gPFlpdV9MZWVAY2FibGUuY29tY2FzdC5jb20+d3JvdGU6DQo+Pj4NCj4+Pj4gSGkgR3Vhbmdo dWksDQo+Pj4+DQo+Pj4+IEkgYWdyZWUgdGhhdCBib3RoIE1BUCBhbmQgNHJkLXUgYXJlIHNpbWls YXIgdGVjaG5vbG9neSBhbmQgc29sdmluZyB0aGUNCj4+Pj4gc2FtZSBwcm9ibGVtLiBGcm9tIHRl Y2huaWNhbCBwZXJzcGVjdGl2ZSwgY2FuIHlvdSBlbGFib3JhdGUgdGhpcyBhDQo+Pj4+IGxpdGhl DQo+Pj4+IGJpdD8NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBZaXUNCj4+Pj4NCj4+Pj4gRnJv bTogR3VhbmdodWkgWXUgPHl1Lmd1YW5naHVpQGdtYWlsLmNvbT4NCj4+Pj4gRGF0ZTogVGh1LCAy MiBNYXIgMjAxMiAyMDoyNjo0MCArMDgwMA0KPj4+PiBUbzogU29mdHdpcmVzIFdHIDxzb2Z0d2ly ZXNAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBQYXRoIHRvIG1vdmUg Zm9yd2FyZCB3aXRoIDRyZD8NCj4+Pj4NCj4+Pj4gSSByZWFkIDRyZC11IGRyYWZ0IGFuZCBmb3Vu ZCBpdCBpcyBmbGF3ZWQuDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0K Pj4+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc29mdHdpcmVzDQo+Pj4NCj4+Pg0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiBT b2Z0d2lyZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zb2Z0d2lyZXM= ------=_001_NextPart376485137478_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Gang,
 
Thanks for your reply. P= lease=20 see in lines.
 
Regards!
Jiang Dong
Tsinghua University
2012-03-28
 
From: GangChen
Date: 2012-03-28 00:30
To: jiangdong345
CC: Kevin Y; Softwires WG
Subject: Re: [Softwires]Path to move forward with=20 4rd=C5=A0
2012/3/27, Jiang Dong <jiangdong345@gmail.com>:<= /DIV>
> Hi Gang and all,
>
> I think there are some points = ;need to be considered between MAP series&nb= sp;and
> 4rd-U.
>
> 4rd-U saids "IPv4 headers can be&n= bsp;reversibly mapped into IPv6 headers so t= hat
> 4rd tunnel packets can be designed=  to be valid IPv6 packets" in Section&n= bsp;I.
> In my understanding, the difference&nbs= p;between 4rd-u and MAP-E is "IPv6
> fragment header vs IPv4 header". B= oth 4rd-U and MAP-E can keep the
> transparency, while 4rd-U reserves 12&n= bsp;bytes to improve the efficiency and
> MAT-E has some IPv4 redundancy oct= ets but keep the original IP-IP
> encapsulation which is easy to be&= nbsp;operated.
>
> Comparing with MAP-E, 4rd-U keeps = the DF bit, TOS and so on with an<= /DIV>
> additional IPv6 fragment header, which&= nbsp;incurs reusing IPv6 option 44.
>
> If 4rd-U can be considered as = ;a tunneling technique, the question is: doe= s
> it deserve adding the IPv6 fragmen= t header in order to save 12 bytes
> efficiency each packet?
 
Not just bits saving, but also capable&= nbsp;of indentification with IPv6
address. Please see more detailed at
draft-despres-softwire-stateless-analysis-tool-01
 
> If 4rd-U can be considered as = ;a translation technique, the question is: d= oes
> it deserve adding the IPv6 fragmen= t header in order to keep transparency?
 
See above draft to get more information=  on comparision. BTW,
fragmentation header is in common for M= AP-T and 4rd-U.
 
[DJ] Thanks, I have read the comparison draft. With the fragmentation= =20 header 4rd-U can keep its transparency but MAP-T cannot,  so I=20 think the use of fragmentation header are not the same for = MAP-T=20 and 4rd-U, and some compromises may have to be considered.
 
BRs
 
Gang
>
> From: GangChen
> Date: 2012-03-27 15:53
> To: Kevin Y
> CC: Softwires WG
> Subject: Re: [Softwires]Path to move&nb= sp;forward with 4rd=C5=A0
> Hello Kevin and all,
>
> I actually see current multiple so= lution proposal from different
> angle. Regarding the changes you m= entioned, MAP-T/E is also doing
> that, e.g. added fragmentation header&n= bsp;to survive DF bit; change ICMP
> ID filed to carry the port in= formation.
>
> 4rd-U doesn't beat MAP-series. I p= refer to understand the situation is
> 4rd-U raised some points(e.g. CNP, = ;Fully IPv4 transparency) which is
> desirable heading to a perfect pro= tocol design.
>
> BRs
>
> Gang
>
> 2012/3/27, Kevin Y <kyking6@gmail.com>= :
>> Hi, Remi,
>>
>> This is beyond the charter of&= nbsp;softwire WG, changing IPv6 address format
>> needs much broad discussion in = ;IETF community to understand its impact
>> first, before we should even d= iscuss if it is valid to design somethi= ng
>> like this in softwire.   = Have you done that ?
>>
>> Best Regards,
>>
>> Kevin Yin
>>
>> On Thu, Mar 22, 2012 at 1= 0:04 PM, Guanghui Yu <yu.guanghui@gmail.com>
>> wrote:
>>
>>> Hi Yiu
>>>
>>>    4rd-u changes the = IPv6 header architecture (redefine
>>> fragmentation header extension) and&= nbsp;IPv6 address architecture (different
>>> meaning of u-bit when g-bit=3D1= ). These are the fundamental changes. If
>>> 4rd-u
>>> becomes the standard, then ther= e will be new defined =E6=8F=91Pv6?packets o= n
>>> the Internet, which are not&nbs= p;compatible with existing IPv6 packets and
>>> no existing devices can underst= and those packets.
>>>
>>>
>>> Yu Guanghui <ygh at dlut.edu= .cn>
>>> Network and Information Center
>>> Dalian University of Technology,&nbs= p;China
>>>
>>>
>>> On Fri, Mar 23, 2012 at&nb= sp;10:10 AM, Lee, Yiu
>>> <Yiu_Lee@cable.comcast.com>wrote:
>>>
>>>> Hi Guanghui,
>>>>
>>>> I agree that both MAP = and 4rd-u are similar technology and solving=  the
>>>> same problem. From technical&nbs= p;perspective, can you elaborate this a
>>>> lithe
>>>> bit?
>>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> From: Guanghui Yu <yu.guanghu= i@gmail.com>
>>>> Date: Thu, 22 Mar 2012 = ;20:26:40 +0800
>>>> To: Softwires WG <softwires@i= etf.org>
>>>> Subject: Re: [Softwires] Path&nb= sp;to move forward with 4rd?
>>>>
>>>> I read 4rd-u draft and = ;found it is flawed.
>>>>
>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
= ------=_001_NextPart376485137478_=------ From fibrib@gmail.com Wed Mar 28 00:59:19 2012 Return-Path: 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 DC76F21F892C for ; Wed, 28 Mar 2012 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 js-dRwRu8dzU for ; Wed, 28 Mar 2012 00:59:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB15821F896B for ; Wed, 28 Mar 2012 00:59:06 -0700 (PDT) Received: by qcsq13 with SMTP id q13so560356qcs.31 for ; Wed, 28 Mar 2012 00:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=elXZ2cs9ovKn8R/KGBJ8dDs1YOKiOqgSPeYrg4l1upU=; b=zQnmQY4hPoR81DucRULO/Gatb+MuYT03ITbs9ae6Y/Ns5VvMXNwAjsUPSS8aKc+K3S ilX5Ex7I5j428bjzc/Qp5j/9D1x3YBvvhFUn/jAsFXjI50++un9+sJOg0fbm6HQVpvg0 D4OWi2LmwckOEVueWzHUnSG21lJTQfd+Lz/3uODiTtW3JUivOb4lhGZSwYROuR6sgaFI yaU5DuiKvcLesOIbIKZgb457ckb3iWtpQ5xZJ2Psg5ZMT/8nv6XiMYbZLEZ6aWe9arft u1m+zP0lHXJry0oth4oFpNXlRqmGKt8L0Dd1YdPYO1hoQNEjnhCi2ogUvLclQf2znbHO gnNg== MIME-Version: 1.0 Received: by 10.224.111.19 with SMTP id q19mr20789094qap.24.1332921545638; Wed, 28 Mar 2012 00:59:05 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 00:59:05 -0700 (PDT) In-Reply-To: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> Date: Wed, 28 Mar 2012 07:59:05 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074d2183dc4a204bc48fb0c Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:59:20 -0000 --20cf3074d2183dc4a204bc48fb0c Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Maoke > > *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish > EBGP session over IPv6 with their 4rd addresses as the loopback addresses > and ttl-security is set to, e.g., 254, in order to protect the peer from > receiving attack messages sending by a remote third party with snoofing. > snoofing => spoofing (typo, sorry). --20cf3074d2183dc4a204bc48fb0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Maoke <fibrib@gmail.com>

*1. consider a case where 2 CEs, 1 hop = apart in IPv6 domain, establish EBGP session over IPv6 with their 4rd addre= sses as the loopback addresses and ttl-security is set to, e.g., 254, in or= der to protect the peer from receiving attack messages sending by a remote = third party with snoofing.=A0

snoofing =3D> spoofing (typo, sor= ry). =A0
--20cf3074d2183dc4a204bc48fb0c-- From despres.remi@laposte.net Wed Mar 28 01:26:46 2012 Return-Path: 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 BD53421F8879 for ; Wed, 28 Mar 2012 01:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.202, 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 5SQYib7pTXT9 for ; Wed, 28 Mar 2012 01:26:45 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 207C521F886A for ; Wed, 28 Mar 2012 01:26:44 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8503-out with ME id qwSg1i0075M8erm03wSheG; Wed, 28 Mar 2012 10:26:43 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16-281198807 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 10:26:40 +0200 Message-Id: <24F07C5B-A93A-4F0F-B3A9-107B6CA22EE1@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:26:46 -0000 --Apple-Mail-16-281198807 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-28 =E0 05:21, Maoke a =E9crit : >=20 >=20 > 2012/3/27 R=E9mi Despr=E9s >=20 > Le 2012-03-27 =E0 13:12, Maoke a =E9crit : >> 2012/3/27 R=E9mi Despr=E9s >> With TTL transparency added, I don't see what would be missing, even = with all requirements you expressed. >>=20 >> well, it is still uncertain how 4rd-u will do this. it is uncertain = if the new ad hoc complement doesn't introduce new problems. could we = see it by the end of IETF83?=20 >=20 > Sure. > basic ID:=20 > - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop = count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put = 127 in bits 1-7 of the hop count. > =20 > - A exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID.=20 >=20 > The only constraint it introduces is that the longest IPv6 path within = the domain must not exceed 127 (something that AFAIK shouldn't be a = problem) > =20 >=20 > "AFAYK" cannot be considered as a common understanding. well, it seems = creative though really causes several new concerns:=20 >=20 > 1. nobody can think the leftmost bit of Hop Limit in IPv6 header is = marked as "unused" or "unspecified" (actually it is often used). you'd = better to update RFC2460 first.=20 No need for any update AFAIK. > 2. not sure that IPv6 path within a domain larger than 127 hops is a = corner case that is more-corner than the corner of DF=3DMF=3D1. in fact, Difference: - Domain longest path is a local matter that can be ensured by ISPs. - DF=3DMF=3D1 is a service restriction that affects some users. > this is to change the definition of routing loop criterion in a IPv6 = network.=20 ??? > 3. even domain diameter less than 127 is always true, MAP-E's generic = encapsulation module can works for both the MAP and also the stateful = tunneling across multiple domains unless the hop count exceeds what IPv6 = protocol allows; while > 4rd-u CE's header mapping module cannot be reused for stateful = tunneling over multiple IPv6 domains Sorry I don't see the scenario you have in mind. > (also because the processings are different). > (you may say this is out of scope It sure seems to me out of scope. > but i do hope you respect other people's scope of concern. thanks in = advance!)=20 I do respect that, but need to understand what is meant. Besides, there are enough in-scope issues being discussed to please = defer off-sope issues. > (and it is really tough for implementators. maybe not your care and = you may state it is simple. therefore i parenthesize this phrase.) I do care about implementation, as other co-authors do. Please don't suggest we don't. > on the other hand, besides the above concerns, there are still some = technical flaws of this solution itself.=20 >=20 > *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish = EBGP session over IPv6 with their 4rd addresses as the loopback = addresses and ttl-security is set to, e.g., 254, in order to protect the = peer from receiving attack messages sending by a remote third party with = snoofing. the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit may = offer a chance for the IPv4 node behind the CE, breaking the protection = of the ttl-security, because the TCP carrying BGP is directly exposed as = the payload of the generated IPv6 packet like translation but the Hop = Limit is not correctly decreased.=20 Not understood. I have difficulty to see why a -E tunnel would be different from a -U = tunnel since both will keep TTL transparency, independently of TTL = values.=20 > *2. when routing loop happens in the IPv6 domain, unfortunately, the = Time Exceeded (hop limit exceeded) ICMPv6 message will be translated to = Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a = link-problem as is expected as a report on the problem of the 1-hop = tunnel link. this must be confusing.=20 -E seems to have the problem because this is how RFC6145 translates = ICMPv6 to ICMPv4. Cheers, RD =20 >=20 > best, > maoke > =20 > =20 > OK? >=20 > RD >=20 >>=20 >> thanks, >> maoke=20 >> =20 >>=20 >> Regards, >> RD >>=20 >>=20 >>> =20 >>>=20 >>> so long, >>> - maoke >>>=20 >>> =20 >>>=20 >>>=20 >>>> d) I didn't see any reference to TTL =3D 1 in the EBGP of RFC2260. = Do you know a better reference than this RFC? >>>>=20 >>>> RFC2260 is informational rather than standard. BGP4 specification = is RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. = TTL =3D 1, as i mentioned, is not a standard feature, but used in some = implementations (including Cisco IOS and Juniper JUNOS and the = open-source routing tool Quagga, to my best knowledge) in order to = ensure the standard feature that defaultly EBGP is established over an = immediate link. as a quick evidence of the implementation, in bgpd.c of = quagga suite we may read the piece of source code:=20 >>>>=20 >>>> peer->ttl =3D (peer_sort (peer) =3D=3D BGP_PEER_IBGP ? 255 : 1); >>>>=20 >>>> it is saying, if the peer is IBGP, the TTL of IP header carrying it = should be set to 255; while if it is EBGP, TTL should be 1.=20 >>>=20 >>> Not familiar enough with the subject to know whether these = implementations cannot be configured so that they don't care. >>> I noted that RFC4271 doesn't have the word virtual link, and that = RFC2328 only mentions "configured" virtual links (=3D> out of scope). =20= >>>=20 >>> If, despite this, you get WG support for a requirement of "1hop-only = tunnels", the best answer is IMHO to include its support in 4rd-U. >>> This AFAIK will close this issue. >>>=20 >>> Thanks for this clarification, >>> RD >>>=20 >>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-16-281198807 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-03-27 =E0 = 13:12, Maoke a =E9crit :
2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
With TTL transparency added, I = don't see what would be missing, even with all requirements you = expressed.

well, it is still uncertain how = 4rd-u will do this. it is uncertain if the new ad hoc complement doesn't = introduce new problems. could we see it by the end of = IETF83? 

Sure.
basic = ID: 
- At domain entry, put TTL bit 0 as leftmost bit of = the IPv6 hop count, and bits 1-7 in the remaining space of the IPv6 = packet ID. Put 127 in bits 1-7 of the hop count.
  
- A exit, take bit 0 from the hop count, and bits 1-7 from the = packet ID. 

The only constraint it = introduces is that the longest IPv6 path within the domain must not = exceed 127 (something that AFAIK shouldn't be a problem)
 

"AFAYK" cannot = be considered as a common understanding. well, it seems creative though = really causes several new concerns: 

1. = nobody can think the leftmost bit of Hop Limit in IPv6 header is marked = as "unused" or "unspecified" (actually it is often used). you'd better = to update RFC2460 first. 

No = need for any update AFAIK.


2. not sure that IPv6 path within a domain larger than 127 hops is = a corner case that is more-corner than the corner of DF=3DMF=3D1. in = fact,

Difference:
- = Domain longest path is a local matter that can be ensured by = ISPs.
- DF=3DMF=3D1 is a service restriction that affects some = users.

this is to change the definition of routing = loop criterion in a IPv6 = network. 

???

3. even domain diameter less than 127 is always true, MAP-E's = generic encapsulation module can works for both the MAP and also the = stateful tunneling across multiple domains unless the hop count exceeds = what IPv6 protocol allows; while =

4rd-u CE's header mapping module cannot be = reused for stateful tunneling over multiple IPv6 = domains

Sorry I don't see the = scenario you have in mind.

(also because the processings are = different).

(you may say this is out = of scope

It sure seems to me out = of scope.

but i do hope you respect other people's = scope of concern. thanks in = advance!) 

I do respect = that, but need to understand what is meant.
Besides, there are = enough in-scope issues being discussed to please defer off-sope = issues.

(and it is really tough for implementators. = maybe not your care and you may state it is simple. therefore i = parenthesize this phrase.)

I do = care about implementation, as other co-authors do.
Please = don't suggest we don't.

on the other hand, besides the above = concerns, there are still some technical flaws of this solution = itself. 

*1. consider a case where 2 CEs, 1 hop apart in IPv6 = domain, establish EBGP session over IPv6 with their 4rd addresses as the = loopback addresses and ttl-security is set to, e.g., 254, in order to = protect the peer from receiving attack messages sending by a remote = third party with snoofing. the mechanism of having IPv4 TTL's bit 0 in = IPv6 Hop Limit may offer a chance for the IPv4 node behind the CE, = breaking the protection of the ttl-security, because the TCP carrying = BGP is directly exposed as the payload of the generated IPv6 packet like = translation but the Hop Limit is not correctly = decreased. 

Not = understood.
I have difficulty to see why a -E tunnel would be = different from a -U tunnel since both will keep TTL transparency, = independently of TTL values. 

*2. when routing loop happens in the IPv6 domain, unfortunately, = the Time Exceeded (hop limit exceeded) ICMPv6 message will be translated = to Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a = link-problem as is expected as a report on the problem of the 1-hop = tunnel link. this must be = confusing. 

-E seems to have = the problem because this is how RFC6145 translates ICMPv6 to = ICMPv4.

Cheers,
RD
 
=

best,
maoke
 
 
OK?

RD


thanks, =
maoke 
 

Regards,
RD


 

so = long,
- maoke

 


d) I didn't see any reference = to TTL =3D 1 in the EBGP of RFC2260. Do you know a better reference than = this RFC?

RFC2260 is = informational rather than standard. BGP4 specification is RFC4271 and = you may be interested in the NEXT_HOP behavior of EBGP. TTL =3D 1, as i = mentioned, is not a standard feature, but used in some implementations = (including Cisco IOS and Juniper JUNOS and the open-source routing tool = Quagga, to my best knowledge) in order to ensure the standard feature = that defaultly EBGP is established over an immediate link. as a quick = evidence of the implementation, in bgpd.c of quagga suite we may read = the piece of source code: 

   peer->ttl =3D (peer_sort (peer) =3D=3D= BGP_PEER_IBGP ? 255 : 1);

it is saying, if the = peer is IBGP, the TTL of IP header carrying it should be set to 255; = while if it is EBGP, TTL should be 1. 

Not familiar enough = with the subject to know whether these implementations cannot be = configured so that they don't care.
I noted that RFC4271 = doesn't have the word virtual link, and that RFC2328 only mentions = "configured" virtual links (=3D> out of scope).  

If, despite this, you get WG support for a = requirement of "1hop-only tunnels", the best answer is IMHO to include = its support in 4rd-U.
This AFAIK will close this = issue.

Thanks for this = clarification,
RD








= --Apple-Mail-16-281198807-- From simon.perreault@viagenie.ca Wed Mar 28 01:42:05 2012 Return-Path: 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 2C2A021F88FC for ; Wed, 28 Mar 2012 01:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8eK5-wwxHVUz for ; Wed, 28 Mar 2012 01:42:04 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 766E321F88FB for ; Wed, 28 Mar 2012 01:42:04 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AD85F40054 for ; Wed, 28 Mar 2012 04:42:03 -0400 (EDT) Message-ID: <4F72CEDA.9040306@viagenie.ca> Date: Wed, 28 Mar 2012 10:42:02 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: softwires@ietf.org References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> In-Reply-To: <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:42:05 -0000 On 03/28/12 00:42, Tetsuya Murakami wrote: > Also, as I mentioned during the meeting, I double-checked the current > implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 > stack gives received IPv6 packet to 4rd-u module after processing it. > But, according to the current implementation of IPv6 stack, IPv6 > stack totally removes IPv6 fragment header when IPv6 stack finds IPv6 > fragment header and processes it. > > Since 4rd-u module gets the packet after IPv6 stack processes the > packet, IPv6 fragment header is not present when 4rd-u module gets > the packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 > information. But all information embedded in IPv6 fragment header is > disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, > in order to keep/pass the information embedded in IPv6 fragment > header to 4rd-u module, I think the existing IPv6 stack needs to be > changed. Depends how you implement it. I can think of at least one way to do it on Linux without touching the IPv6 stack. (with NF hooks) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 28 01:44:37 2012 Return-Path: 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 ADE3521F888A for ; Wed, 28 Mar 2012 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FqbP8OYyCP6v for ; Wed, 28 Mar 2012 01:44:37 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0433321F8786 for ; Wed, 28 Mar 2012 01:44:37 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 61F3E400D8 for ; Wed, 28 Mar 2012 04:44:36 -0400 (EDT) Message-ID: <4F72CF72.7080500@viagenie.ca> Date: Wed, 28 Mar 2012 10:44:34 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: softwires@ietf.org References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> In-Reply-To: <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:44:37 -0000 On 03/28/12 09:22, Tetsuya Murakami wrote: > In terms of CNP, CNP needs to be calculated every time if the packet > is toward to outside of domain because the embedded IPv4 address > could be different. So, I think there is no difference between CNP > and recalculation of L4 checksum from the implementation point of > view. On the contrary, there is a big difference. The difference is that you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc, etc. You need a lot of code to handle all existing transport protocols, and you still can't handle future protocols that people might develop. Checksum neutrality is a *big* advantage. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Wed Mar 28 01:46:04 2012 Return-Path: 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 684F221F8896 for ; Wed, 28 Mar 2012 01:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, 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 UnHK56Ell5Bg for ; Wed, 28 Mar 2012 01:46:03 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06521F864E for ; Wed, 28 Mar 2012 01:46:02 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8501-out with ME id qwlz1i0065M8erm03wm0vH; Wed, 28 Mar 2012 10:46:01 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> Date: Wed, 28 Mar 2012 10:45:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80372DB2-8377-48F1-9172-62239012C695@laposte.net> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> To: Tetsuya Murakami X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:46:04 -0000 Hi, Tetsuya-san, Thanks for your comments. Le 2012-03-28 =E0 00:42, Tetsuya Murakami a =E9crit : > Hi Remi, >=20 > Thank you for having the informational meeting of 4rd-u. I can = understand 4rd-u very much.=20 >=20 > As you mentioned during the informational meeting, 4rd-u defines the = new type of the translation between IPv4 and IPv6 instead of = MAP-E/MAP-T. Reversible header translation, yes, thus achieving transparent tunneling = of IPv4 packets. > Also, this new type of the translation has no relationship with the = mapping rule. Hence, I think 4rd-u draft can be changed only to define = the new type of the translation similar to MAP-E/MAP-T by removing any = text related to mapping rule and refer to MAP for the mapping rule. In = this case, it depends on deployment scenario to choose MAP-E, MAP-T or = 4rd-u. The purpose of U is to remove the need for ISPs to make a deployment = choice. If U is standardized, ISPs can safely deploy THE standard, without = having to make a choice. > Also, as I mentioned during the meeting, I double-checked the current = implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 = stack gives received IPv6 packet to 4rd-u module after processing it. = But, according to the current implementation of IPv6 stack, IPv6 stack = totally removes IPv6 fragment header when IPv6 stack finds IPv6 fragment = header and processes it.=20 Thanks for this confirmation. > Since 4rd-u module gets the packet after IPv6 stack processes the = packet, IPv6 fragment header is not present when 4rd-u module gets the = packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 = information. But all information embedded in IPv6 fragment header is = disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in = order to keep/pass the information embedded in IPv6 fragment header to = 4rd-u module, I think the existing IPv6 stack needs to be changed.=20 >=20 > In terms of MAP-T, IPv6 fragment header is also required but no = information is embedded in IPv6 fragment header. Also, the current IPv6 = implementation can give only information if there is a fragment header = or not. So, MAP-T can know if there is a fragment header or not after = IPv6 stack processes the packet without any change of the existing IPv6 = stack. Yes, support of 4rd-U in Linux/BSD as you describe it implies an upgrade = of the IPv6 module so that it conveys to higher layers not only the fact = that there was an extension header, but also its contained packet ID. However, in order to be capable to forward IPv6 fragments without packet = reassembly (important for performance), BRs will have to do some = processing below the API you are referring to. Different implementations = are possible. > I think MAP/4rd-u are transition technology and so it is good to = eliminate any impact on the existing implementation of IPv6 stack as = much as possible. As much as possible, I agree, but if some adaptation is needed to avoid = two incompatible variants, the new code is worth having. Regards, RD > Thanks, > Tetsuya Murakami >=20 > On 2012/03/26, at 11:57, R=E9mi Despr=E9s wrote: >=20 >> Hi, all, >>=20 >> With some co-authors of the 4rd-U proposal, we will hold an informal = meeting about it. >> - subject: Clarification on what 4rd-U is designed to do, and how it = does it. >> - Participants: whoever is interested in a good understanding of the = 4rd-U proposal.=20 >> - place: room 204 >> - time : Tuesday 15:15 (duration depending on questions, maximum = till 16:30). >>=20 >> The meeting can be seen as a bar BOF... without drinks in the room. >>=20 >> See you there if interested, >> RD" >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 From satoru.matsushima@gmail.com Wed Mar 28 01:48:10 2012 Return-Path: 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 23EE021F88EC for ; Wed, 28 Mar 2012 01:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CDQLmJ7fCA5m for ; Wed, 28 Mar 2012 01:48:09 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 59CDC21F8786 for ; Wed, 28 Mar 2012 01:48:09 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so5441701wib.1 for ; Wed, 28 Mar 2012 01:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0sDgHuvby+rb18RzcAeMXGTSTzjRKYrp8X5K1ApHBR0=; b=sUNhJb8RatlKpx/EeBere94YHCkObjhcTt1/mtvp6Swf5zv61BOqqt3yeaiGwAKdJu s265InZId3n7k770xo9mWFjdJgGxKolA35oFe5GCzJw2Ort4vTyLRvu8f8ie0tg8kYE3 eALTHODPBNQjwiD75wDfTrfQFuB06ejejaAe8SGuSMRKtI2WAnYmwzxUimXlwjDO1dKZ 9O2SMqyhqs9CkTOplchNxgC0UhiXgzv00TXvPmjxWBOQyBMAORSXTg7PQb2DhGLMf0LK K2LtC902/YTeybw4WdOwyRPJiLO6oUAp9kDMLt8uV58yb33xeOGkAHJCATBOWQZ5Qn15 6BMQ== Received: by 10.180.95.34 with SMTP id dh2mr4982703wib.15.1332924488440; Wed, 28 Mar 2012 01:48:08 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org. [130.129.83.168]) by mx.google.com with ESMTPS id 6sm19606175wiz.1.2012.03.28.01.48.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 01:48:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4F72CF72.7080500@viagenie.ca> Date: Wed, 28 Mar 2012 10:48:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:48:10 -0000 On 2012/03/28, at 10:44, Simon Perreault wrote: > On 03/28/12 09:22, Tetsuya Murakami wrote: >> In terms of CNP, CNP needs to be calculated every time if the packet >> is toward to outside of domain because the embedded IPv4 address >> could be different. So, I think there is no difference between CNP >> and recalculation of L4 checksum from the implementation point of >> view. >=20 > On the contrary, there is a big difference. The difference is that you = are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, = etc, etc, etc. You need a lot of code to handle all existing transport = protocols, and you still can't handle future protocols that people might = develop. >=20 > Checksum neutrality is a *big* advantage. Cool. How many protocols we should support for just a *transition* = mechanism? --satoru= From despres.remi@laposte.net Wed Mar 28 01:59:21 2012 Return-Path: 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 509D121F899D for ; Wed, 28 Mar 2012 01:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, 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 R4pemlpF4km3 for ; Wed, 28 Mar 2012 01:59:20 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 58C3021F890C for ; Wed, 28 Mar 2012 01:59:20 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8509-out with ME id qwzH1i0085M8erm03wzHgW; Wed, 28 Mar 2012 10:59:18 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> Date: Wed, 28 Mar 2012 10:59:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <644A1776-D114-4720-AF38-89861082923E@laposte.net> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:59:21 -0000 Le 2012-03-28 =E0 04:31, Satoru Matsushima a =E9crit : > I do agree with Tetsuya-san's comments. Answered separately. > On the other hand, I couldn't understand the reason of why the CNP is = needed. Since 4rd-u focus on support to communicate between ipv4 hosts, = L4 checksum consistency could be agnostic from any kind of 4rd-u nodes. - Without checksum neutrality, the IPv4 payload has to be modified for = the tunnel packet to be a valid IPv6 packet. This modification has to be = made protocol per protocol.=20 - RFC6145 says that CNP field wasn't needed because other address fields = can be chosen to ensure checksum neutrality. the problem is that with = stateless mapping rules, they cannot be chosen to ensure this.=20 - CNP computation is really simple.=20 Regards, RD =20 > cheers, > --satoru >=20 >=20 > On 2012/03/28, at 0:42, Tetsuya Murakami wrote: >=20 >> Hi Remi, >>=20 >> Thank you for having the informational meeting of 4rd-u. I can = understand 4rd-u very much.=20 >>=20 >> As you mentioned during the informational meeting, 4rd-u defines the = new type of the translation between IPv4 and IPv6 instead of = MAP-E/MAP-T. Also, this new type of the translation has no relationship = with the mapping rule. Hence, I think 4rd-u draft can be changed only to = define the new type of the translation similar to MAP-E/MAP-T by = removing any text related to mapping rule and refer to MAP for the = mapping rule. In this case, it depends on deployment scenario to choose = MAP-E, MAP-T or 4rd-u. >>=20 >> Also, as I mentioned during the meeting, I double-checked the current = implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 = stack gives received IPv6 packet to 4rd-u module after processing it. = But, according to the current implementation of IPv6 stack, IPv6 stack = totally removes IPv6 fragment header when IPv6 stack finds IPv6 fragment = header and processes it.=20 >>=20 >> Since 4rd-u module gets the packet after IPv6 stack processes the = packet, IPv6 fragment header is not present when 4rd-u module gets the = packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 = information. But all information embedded in IPv6 fragment header is = disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in = order to keep/pass the information embedded in IPv6 fragment header to = 4rd-u module, I think the existing IPv6 stack needs to be changed.=20 >>=20 >> In terms of MAP-T, IPv6 fragment header is also required but no = information is embedded in IPv6 fragment header. Also, the current IPv6 = implementation can give only information if there is a fragment header = or not. So, MAP-T can know if there is a fragment header or not after = IPv6 stack processes the packet without any change of the existing IPv6 = stack. >>=20 >> I think MAP/4rd-u are transition technology and so it is good to = eliminate any impact on the existing implementation of IPv6 stack as = much as possible. >>=20 >> Thanks, >> Tetsuya Murakami >>=20 >> On 2012/03/26, at 11:57, R=E9mi Despr=E9s wrote: >>=20 >>> Hi, all, >>>=20 >>> With some co-authors of the 4rd-U proposal, we will hold an informal = meeting about it. >>> - subject: Clarification on what 4rd-U is designed to do, and how it = does it. >>> - Participants: whoever is interested in a good understanding of the = 4rd-U proposal.=20 >>> - place: room 204 >>> - time : Tuesday 15:15 (duration depending on questions, maximum = till 16:30). >>>=20 >>> The meeting can be seen as a bar BOF... without drinks in the room. >>>=20 >>> See you there if interested, >>> RD" >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From simon.perreault@viagenie.ca Wed Mar 28 02:02:22 2012 Return-Path: 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 A8D1E21F8505 for ; Wed, 28 Mar 2012 02:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kng9SzRrLmZ9 for ; Wed, 28 Mar 2012 02:02:21 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3034221F873B for ; Wed, 28 Mar 2012 02:02:21 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7C954400D8; Wed, 28 Mar 2012 05:02:20 -0400 (EDT) Message-ID: <4F72D39B.9080506@viagenie.ca> Date: Wed, 28 Mar 2012 11:02:19 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: Satoru Matsushima References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> In-Reply-To: <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:02:22 -0000 On 03/28/12 10:48, Satoru Matsushima wrote: >> On the contrary, there is a big difference. The difference is that you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc, etc. You need a lot of code to handle all existing transport protocols, and you still can't handle future protocols that people might develop. >> >> Checksum neutrality is a *big* advantage. > > Cool. How many protocols we should support for just a *transition* mechanism? The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep providing clients with residual IPv4 for a potentially loooooooooooong time. So we need to be really careful to get this right, because we'll be stuck with what we design for a long time. So you have two options: a) checksum neutrality - no code specific to each transport prototol - supports all current and future transport protocols b) checksum non-neutrality - additional code necessary for each transport protocol - limited set of supported transport protocols Less code, more transport protocols. I think the choice is easy. There's a reason NPTv6 and NAT64 chose checksum neutrality... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Wed Mar 28 02:05:54 2012 Return-Path: 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 D9B9B21F89FD for ; Wed, 28 Mar 2012 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, 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 o7Yg4XERoMBf for ; Wed, 28 Mar 2012 02:05:54 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id CBD2521F89FC for ; Wed, 28 Mar 2012 02:05:53 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8508-out with ME id qx5p1i0025M8erm03x5pAQ; Wed, 28 Mar 2012 11:05:52 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 11:05:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:05:55 -0000 Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit : > FYI, section 5 of RFC5082 = (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique = that TTL is used to help tunnel packets security. Anyway,=20 >=20 > On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-03-27 =E0 13:12, Maoke a =E9crit : >>> 2012/3/27 R=E9mi Despr=E9s >>> With TTL transparency added, I don't see what would be missing, even = with all requirements you expressed. >>>=20 >>> well, it is still uncertain how 4rd-u will do this. it is uncertain = if the new ad hoc complement doesn't introduce new problems. could we = see it by the end of IETF83?=20 >>=20 >> Sure. >> basic ID:=20 >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop = count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put = 127 in bits 1-7 of the hop count. >> - A exit, take bit 0 from the hop count, and bits 1-7 from the packet = ID.=20 >>=20 >=20 > Too much. Don't change deeply well understand/deployed semantics, = PLEASE. Semantics isn't changed for any existing function. CEs and BRs (the only ones to be concerned) use unused bits to convey = some IPv4 bits that need to be conveyed for e2e transparency. No implementation or operational problem can result. If I missed a practical problem you have identified, sharing this = information would of course be useful. Thanks, RD >=20 >=20 >> The only constraint it introduces is that the longest IPv6 path = within the domain must not exceed 127 (something that AFAIK shouldn't be = a problem) >> OK? >=20 > NO. >=20 > cheers, > --satoru From satoru.matsushima@gmail.com Wed Mar 28 02:06:33 2012 Return-Path: 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 2731221F8A01 for ; Wed, 28 Mar 2012 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 na5FM06F+vzK for ; Wed, 28 Mar 2012 02:06:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD021F89DB for ; Wed, 28 Mar 2012 02:06:31 -0700 (PDT) Received: by werb10 with SMTP id b10so582343wer.31 for ; Wed, 28 Mar 2012 02:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Mixpjmfon02wY/dabuAznIx2Bab8qBECMFvjdwMqUUM=; b=pNmcPjHjiXfU8paC61ZVR7F8YK+Z601Oatyzi3r0NRnZugOAU34xvhn+WdGsrjKLxa bHr3WbjKOWJDUPtJBSmOU+CS0AyJcmXOjpM4YCx2L+JoVrSMmCw8CQ6dSXYE3FkvvMWc 29vDBqdYBckiQtntuhtbSuTv3l8toK58GeKnSwVoq5EYUUS2EvKKR1a2URnc97JS1R02 EeDq6tNWL8y8+doVVS2OynSxhBnktlc0y+ZjzcYXw86mQc/AFFifOI9EdwIfxbh7QcTA Omp4+EtcQPhTrv+uGtKnm/z7FOU6yWnBILjWes4O3/6ckf9l0iCWkZwvV0nRskRofDy4 UbJw== Received: by 10.180.105.69 with SMTP id gk5mr6072879wib.3.1332925590571; Wed, 28 Mar 2012 02:06:30 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org. [130.129.83.168]) by mx.google.com with ESMTPS id e6sm56410729wix.8.2012.03.28.02.06.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 02:06:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <644A1776-D114-4720-AF38-89861082923E@laposte.net> Date: Wed, 28 Mar 2012 11:06:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4BD3BC-C78C-4E4D-9EDC-DD90A21D0DD0@gmail.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <644A1776-D114-4720-AF38-89861082923E@laposte.net> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:06:33 -0000 On 2012/03/28, at 10:59, R=E9mi Despr=E9s wrote: >> On the other hand, I couldn't understand the reason of why the CNP is = needed. Since 4rd-u focus on support to communicate between ipv4 hosts, = L4 checksum consistency could be agnostic from any kind of 4rd-u nodes. >=20 > - Without checksum neutrality, the IPv4 payload has to be modified for = the tunnel packet to be a valid IPv6 packet. This modification has to be = made protocol per protocol.=20 My understanding is that 4rd-u focus only on between v4 hosts, a packet = looks like invalid IPv6 packet doesn't matter. > - RFC6145 says that CNP field wasn't needed because other address = fields can be chosen to ensure checksum neutrality. the problem is that = with stateless mapping rules, they cannot be chosen to ensure this.=20 Above my understanding, 4rd-u doesn't need to follow rfc6145 spec, = because during the meeting, you said that 4rd-u is a brand new transport = protocol. > - CNP computation is really simple.=20 >=20 Without CNP is much more simple. cheers, --satoru > Regards, > RD >=20 >=20 >> cheers, >> --satoru >>=20 >>=20 >> On 2012/03/28, at 0:42, Tetsuya Murakami wrote: >>=20 >>> Hi Remi, >>>=20 >>> Thank you for having the informational meeting of 4rd-u. I can = understand 4rd-u very much.=20 >>>=20 >>> As you mentioned during the informational meeting, 4rd-u defines the = new type of the translation between IPv4 and IPv6 instead of = MAP-E/MAP-T. Also, this new type of the translation has no relationship = with the mapping rule. Hence, I think 4rd-u draft can be changed only to = define the new type of the translation similar to MAP-E/MAP-T by = removing any text related to mapping rule and refer to MAP for the = mapping rule. In this case, it depends on deployment scenario to choose = MAP-E, MAP-T or 4rd-u. >>>=20 >>> Also, as I mentioned during the meeting, I double-checked the = current implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, = IPv6 stack gives received IPv6 packet to 4rd-u module after processing = it. But, according to the current implementation of IPv6 stack, IPv6 = stack totally removes IPv6 fragment header when IPv6 stack finds IPv6 = fragment header and processes it.=20 >>>=20 >>> Since 4rd-u module gets the packet after IPv6 stack processes the = packet, IPv6 fragment header is not present when 4rd-u module gets the = packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 = information. But all information embedded in IPv6 fragment header is = disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in = order to keep/pass the information embedded in IPv6 fragment header to = 4rd-u module, I think the existing IPv6 stack needs to be changed.=20 >>>=20 >>> In terms of MAP-T, IPv6 fragment header is also required but no = information is embedded in IPv6 fragment header. Also, the current IPv6 = implementation can give only information if there is a fragment header = or not. So, MAP-T can know if there is a fragment header or not after = IPv6 stack processes the packet without any change of the existing IPv6 = stack. >>>=20 >>> I think MAP/4rd-u are transition technology and so it is good to = eliminate any impact on the existing implementation of IPv6 stack as = much as possible. >>>=20 >>> Thanks, >>> Tetsuya Murakami >>>=20 >>> On 2012/03/26, at 11:57, R=E9mi Despr=E9s wrote: >>>=20 >>>> Hi, all, >>>>=20 >>>> With some co-authors of the 4rd-U proposal, we will hold an = informal meeting about it. >>>> - subject: Clarification on what 4rd-U is designed to do, and how = it does it. >>>> - Participants: whoever is interested in a good understanding of = the 4rd-U proposal.=20 >>>> - place: room 204 >>>> - time : Tuesday 15:15 (duration depending on questions, maximum = till 16:30). >>>>=20 >>>> The meeting can be seen as a bar BOF... without drinks in the room. >>>>=20 >>>> See you there if interested, >>>> RD" >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 From satoru.matsushima@gmail.com Wed Mar 28 02:18:02 2012 Return-Path: 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 469BE21E809E for ; Wed, 28 Mar 2012 02:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hFl63RKaCaAc for ; Wed, 28 Mar 2012 02:18:01 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14FB521E80A6 for ; Wed, 28 Mar 2012 02:18:00 -0700 (PDT) Received: by werb10 with SMTP id b10so590353wer.31 for ; Wed, 28 Mar 2012 02:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zDgRUlitn8PniIqPuTPEr8Gc6aOiR53Luzx6qVnSG1k=; b=ADUFaendO9uTupxahsWmTq7iyigC2ghe57dmQDRuGur1bMQ8INA9qyUxl7ylEPrarU QPG2HW348YGU/DI61vbG0A+q6Tp9oedfLSD0J1wnH8BL7sVUsJTN4syvUlyrjdFmGe6M 25Y6B1UEwss2T7FhiqzlCY1pkeFBdHMnpiHjU80DD3xaTuyKf+QNTvQw1QaavHeKdnCo TOAgPU5W31uUh0y6zTlscBMCPcgVTHc6TdDtJgwbXWJtiov1PJBwvVaRNZDQTsoXUso2 evP8g8anfnWfSvEKirqPITTaHR8UXOejOjboVqRevWKQ18ADd6ikkbXCekRP+Mn57dpa rv+A== Received: by 10.216.139.12 with SMTP id b12mr6423112wej.4.1332926280236; Wed, 28 Mar 2012 02:18:00 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org. [130.129.83.168]) by mx.google.com with ESMTPS id ex2sm10984896wib.8.2012.03.28.02.17.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 02:17:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <4F72D39B.9080506@viagenie.ca> Date: Wed, 28 Mar 2012 11:17:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:18:02 -0000 I remember that what Remi said during the meeting, is that 4rd-u is a = brand-new transport protocol which doesn't need to follow rfc6145 = translation spec. If it is true, 4rd-u doesn't need to take care = checksum consistency of any kind of L4 protocols. On the other word, 4rd-u can support transparency of original packet so = not only the CNP, but also checksum recalculation are not required. cheers, --satoru On 2012/03/28, at 11:02, Simon Perreault wrote: > On 03/28/12 10:48, Satoru Matsushima wrote: >>> On the contrary, there is a big difference. The difference is that = you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, = DCCP, etc, etc, etc. You need a lot of code to handle all existing = transport protocols, and you still can't handle future protocols that = people might develop. >>>=20 >>> Checksum neutrality is a *big* advantage. >>=20 >> Cool. How many protocols we should support for just a *transition* = mechanism? >=20 > The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used = for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time. >=20 > So you have two options: >=20 > a) checksum neutrality > - no code specific to each transport prototol > - supports all current and future transport protocols > b) checksum non-neutrality > - additional code necessary for each transport protocol > - limited set of supported transport protocols >=20 > Less code, more transport protocols. I think the choice is easy. >=20 > There's a reason NPTv6 and NAT64 chose checksum neutrality... >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Wed Mar 28 02:20:42 2012 Return-Path: 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 E5B0521E80A6 for ; Wed, 28 Mar 2012 02:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, 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 ZRk55g0bOwfI for ; Wed, 28 Mar 2012 02:20:38 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1112421E809E for ; Wed, 28 Mar 2012 02:20:37 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8506-out with ME id qxLb1i0095M8erm03xLbup; Wed, 28 Mar 2012 11:20:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B4BD3BC-C78C-4E4D-9EDC-DD90A21D0DD0@gmail.com> Date: Wed, 28 Mar 2012 11:20:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76F6B5FF-090A-43C0-A0CA-39009894CD1F@laposte.net> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <644A1776-D114-4720-AF38-89861082923E@laposte.net> <4B4BD3BC-C78C-4E4D-9EDC-DD90A21D0DD0@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:20:42 -0000 Le 2012-03-28 =E0 11:06, Satoru Matsushima a =E9crit : > On 2012/03/28, at 10:59, R=E9mi Despr=E9s wrote: >>> On the other hand, I couldn't understand the reason of why the CNP = is needed. Since 4rd-u focus on support to communicate between ipv4 = hosts, L4 checksum consistency could be agnostic from any kind of 4rd-u = nodes. >>=20 >> - Without checksum neutrality, the IPv4 payload has to be modified = for the tunnel packet to be a valid IPv6 packet. This modification has = to be made protocol per protocol.=20 >=20 > My understanding is that 4rd-u focus only on between v4 hosts, a = packet looks like invalid IPv6 packet doesn't matter. It does matter where some IPv6-only middle boxes do DPI (a point that = justifies to standardize also T if E is standardized instead of U) =20 >> - RFC6145 says that CNP field wasn't needed because other address = fields can be chosen to ensure checksum neutrality. the problem is that = with stateless mapping rules, they cannot be chosen to ensure this.=20 >=20 > Above my understanding, 4rd-u doesn't need to follow rfc6145 spec, = because during the meeting, you said that 4rd-u is a brand new transport = protocol. Right. 4rd-U doesn't follow RFC6145.=20 This point is just to emphasize that reasons that led to no CNP in = RFC6145 don't apply to 4rd-U (no contradiction). >> - CNP computation is really simple.=20 >>=20 >=20 > Without CNP is much more simple. Of course, not supporting a feature is simpler than supporting it, even = if it is simple, but the benefit of this feature is then lost (in this = instance, benefit is one standard behavior instead of two). Regards, RD >=20 > cheers, > --satoru >=20 >=20 >> Regards, >> RD >>=20 >>=20 >>> cheers, >>> --satoru >>>=20 >>>=20 >>> On 2012/03/28, at 0:42, Tetsuya Murakami wrote: >>>=20 >>>> Hi Remi, >>>>=20 >>>> Thank you for having the informational meeting of 4rd-u. I can = understand 4rd-u very much.=20 >>>>=20 >>>> As you mentioned during the informational meeting, 4rd-u defines = the new type of the translation between IPv4 and IPv6 instead of = MAP-E/MAP-T. Also, this new type of the translation has no relationship = with the mapping rule. Hence, I think 4rd-u draft can be changed only to = define the new type of the translation similar to MAP-E/MAP-T by = removing any text related to mapping rule and refer to MAP for the = mapping rule. In this case, it depends on deployment scenario to choose = MAP-E, MAP-T or 4rd-u. >>>>=20 >>>> Also, as I mentioned during the meeting, I double-checked the = current implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, = IPv6 stack gives received IPv6 packet to 4rd-u module after processing = it. But, according to the current implementation of IPv6 stack, IPv6 = stack totally removes IPv6 fragment header when IPv6 stack finds IPv6 = fragment header and processes it.=20 >>>>=20 >>>> Since 4rd-u module gets the packet after IPv6 stack processes the = packet, IPv6 fragment header is not present when 4rd-u module gets the = packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 = information. But all information embedded in IPv6 fragment header is = disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in = order to keep/pass the information embedded in IPv6 fragment header to = 4rd-u module, I think the existing IPv6 stack needs to be changed.=20 >>>>=20 >>>> In terms of MAP-T, IPv6 fragment header is also required but no = information is embedded in IPv6 fragment header. Also, the current IPv6 = implementation can give only information if there is a fragment header = or not. So, MAP-T can know if there is a fragment header or not after = IPv6 stack processes the packet without any change of the existing IPv6 = stack. >>>>=20 >>>> I think MAP/4rd-u are transition technology and so it is good to = eliminate any impact on the existing implementation of IPv6 stack as = much as possible. >>>>=20 >>>> Thanks, >>>> Tetsuya Murakami >>>>=20 >>>> On 2012/03/26, at 11:57, R=E9mi Despr=E9s wrote: >>>>=20 >>>>> Hi, all, >>>>>=20 >>>>> With some co-authors of the 4rd-U proposal, we will hold an = informal meeting about it. >>>>> - subject: Clarification on what 4rd-U is designed to do, and how = it does it. >>>>> - Participants: whoever is interested in a good understanding of = the 4rd-U proposal.=20 >>>>> - place: room 204 >>>>> - time : Tuesday 15:15 (duration depending on questions, maximum = till 16:30). >>>>>=20 >>>>> The meeting can be seen as a bar BOF... without drinks in the = room. >>>>>=20 >>>>> See you there if interested, >>>>> RD" >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >=20 From fibrib@gmail.com Wed Mar 28 02:25:34 2012 Return-Path: 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 1B2FE21F88B0 for ; Wed, 28 Mar 2012 02:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 GjkHCsY0ynka for ; Wed, 28 Mar 2012 02:25:32 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0809021F8955 for ; Wed, 28 Mar 2012 02:25:31 -0700 (PDT) Received: by qcsq13 with SMTP id q13so602486qcs.31 for ; Wed, 28 Mar 2012 02:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IMIPXrGAw/kW90yM7r/glOVkdOq8MprSsdB5bhxUHV4=; b=s1XdFxk+NNmV+SWNuKbGmM5EQqX0FV0dADAQ7YWjhXDyTR2+0MQCmT7rxP7Cwu9XCO 1an14POzR/Dtm+9fa0az6sDagvDRSntrI9aHeKA2vMPaF7kxN51zheClzWazEDwy1BM/ n82gIZXIoL8UiJC5eiAWxtn6iW7+OkmobBQViQwzDsGd/YSFy0ATX/pHei5SPsSJULTC rV5/qB5OKF1RerppmnPgISxMWDbFMc0IPAoHMf2PLmdek4kRv8WrtDxXgSaSDmBcxYF1 e2HFJY8Chz+eGMZVcazuB67vdr4zZIZY725IvqfEVzeX84Yl/E6/IlC1CW6AXp5ZO/AZ ruzw== MIME-Version: 1.0 Received: by 10.229.77.141 with SMTP id g13mr11291233qck.11.1332926731188; Wed, 28 Mar 2012 02:25:31 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 02:25:31 -0700 (PDT) In-Reply-To: <24F07C5B-A93A-4F0F-B3A9-107B6CA22EE1@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> <24F07C5B-A93A-4F0F-B3A9-107B6CA22EE1@laposte.net> Date: Wed, 28 Mar 2012 09:25:31 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235429cbe052fceb04bc4a307d Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:25:34 -0000 --00235429cbe052fceb04bc4a307d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/28 R=E9mi Despr=E9s > > 1. nobody can think the leftmost bit of Hop Limit in IPv6 header is marke= d > as "unused" or "unspecified" (actually it is often used). you'd better to > update RFC2460 first. > > > No need for any update AFAIK. > significant semantics change without update, without definition, but requires peer and operators awareness. -- AFAIK, it is not acceptable. > > > 2. not sure that IPv6 path within a domain larger than 127 hops is a > corner case that is more-corner than the corner of DF=3DMF=3D1. in fact, > > > Difference: > - Domain longest path is a local matter that can be ensured by ISPs. > see also below (*) > - DF=3DMF=3D1 is a service restriction that affects some users. > > this is to change the definition of routing loop criterion in a IPv6 > network. > > > ??? > for IPv4 packets with TTL=3D64, it would be reported fail after being forwarded in the IPv6 network 127 times; for IPv4 packets with TTL=3D128, i= t would be reported fail after 255 times of forwarding in IPv6. criterion is uncertain. (*) considering that temporarily routing loop happens when distance vector or link state changes, the limitation of 127 hops makes the diameter of the actual workable IPv6 network less than 127. operators can ensure the stable state path length but cannot ensure the case in state-transition. unfortunately, you cannot force IPv4 applictions always initializing TTL larger than 127 in order to gain the 255 HopLimit in IPv6. -E works fine with the commonly understood behavior and commonly, well understood limitations, without bias to any value of IPv4 TTL. > > 3. even domain diameter less than 127 is always true, MAP-E's generic > encapsulation module can works for both the MAP and also the stateful > tunneling across multiple domains unless the hop count exceeds what IPv6 > protocol allows; while > > > 4rd-u CE's header mapping module cannot be reused for stateful tunneling > over multiple IPv6 domains > > > Sorry I don't see the scenario you have in mind. > sorry but 4rd-u CE needs two modules working for 4rd-u header mapping and stateful tunnel/encapsulation, respectively. > > (also because the processings are different). > > > (you may say this is out of scope > > > It sure seems to me out of scope. > > but i do hope you respect other people's scope of concern. thanks in > advance!) > > > I do respect that, but need to understand what is meant. > Besides, there are enough in-scope issues being discussed to please defer > off-sope issues. > your scope is different from ours. > > (and it is really tough for implementators. maybe not your care and you > may state it is simple. therefore i parenthesize this phrase.) > > > I do care about implementation, as other co-authors do. > then please deeply consider what Satoru suggested: don't change the deeply understood semantics so much. and please consider the annoyance of copying this bit here while those bits there even for a single octet. it is surely doable and not extremely complicated though. > Please don't suggest we don't. > > on the other hand, besides the above concerns, there are still some > technical flaws of this solution itself. > > *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish > EBGP session over IPv6 with their 4rd addresses as the loopback addresses > and ttl-security is set to, e.g., 254, in order to protect the peer from > receiving attack messages sending by a remote third party with snoofing. > the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit may offer a > chance for the IPv4 node behind the CE, breaking the protection of the > ttl-security, because the TCP carrying BGP is directly exposed as the > payload of the generated IPv6 packet like translation but the Hop Limit i= s > not correctly decreased. > > > Not understood. > I have difficulty to see why a -E tunnel would be different from a -U > tunnel since both will keep TTL transparency, independently of TTL values= . > please carefully read the example. the problem here has changed. it is about the ttl-security of IPv6 routing rather than the TTL transparency of the tunneled IPv4 (which you have patched with the not-beautiful but anyway a solution). i show this example here in order to point out HopLimit > 127 is in use even if the diameter of a domain less than 127. Satoru also gave a link to a reference. -E has not the similar problem because the encapsulation won't expose an BGP message to the IPv6 peer. -T has not the problem either because the HopLimit is copied from IPv4 TTL and the ttl-security works in checking that HopLimit. > > *2. when routing loop happens in the IPv6 domain, unfortunately, the Time > Exceeded (hop limit exceeded) ICMPv6 message will be translated to Time > Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a > link-problem as is expected as a report on the problem of the 1-hop tunne= l > link. this must be confusing. > > > -E seems to have the problem because this is how RFC6145 translates ICMPv= 6 > to ICMPv4. > misunderstanding. -E doesn't have the problem because RFC6145 translation for ICMPv6-to-ICMPv4 is never utilized in -E. it would be helpful if you may take some time to get to understand the ICMPv6/iCMPv4 translation semantics. they are different for -E and -T. thanks, maoke --00235429cbe052fceb04bc4a307d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

1. nobody can think the leftm= ost bit of Hop Limit in IPv6 header is marked as "unused" or &quo= t;unspecified" (actually it is often used). you'd better to update= RFC2460 first.=A0

No need for any update AFAIK.
=

significant semantics change without= update, without definition, but requires peer and operators awareness. -- = AFAIK, it is not acceptable.=A0
=A0


<= div class=3D"gmail_quote">
2. not sure that IPv6 path within a domain larger than 127 hops is a c= orner case that is more-corner than the corner of DF=3DMF=3D1. in fact,

Difference:
- Domain l= ongest path is a local matter that can be ensured by ISPs.

see also below (*)
=A0
-= DF=3DMF=3D1 is a service restriction that affects some users.=A0

this is to change the definition of routing loop criterion in a IPv6 n= etwork.=A0

???

for IPv4 packets with TTL=3D64, it would be re= ported fail after being forwarded in the IPv6 network 127 times; for IPv4 p= ackets with TTL=3D128, it would be reported fail after 255 times of forward= ing in IPv6. criterion is uncertain. =A0

(*)
considering that temporarily routing loop= happens when distance vector or link state changes, the limitation of 127 = hops makes the diameter of the actual workable IPv6 network less than 127. = operators can ensure the stable state path length but cannot ensure the cas= e in state-transition. unfortunately, you cannot force IPv4 applictions alw= ays initializing TTL larger than 127 in order to gain the 255 HopLimit in I= Pv6.=A0

-E works fine with the commonly understood behavior and= commonly, well understood limitations, without bias to any value of IPv4 T= TL.=A0
=A0

3. even domain diameter less than 127 is always true, MAP-E's gene= ric encapsulation module can works for both the MAP and also the stateful t= unneling across multiple domains unless the hop count exceeds what IPv6 pro= tocol allows; while

4rd-u CE's header mapping module cannot be reused for stateful tu= nneling over multiple IPv6 domains

<= /div> Sorry I don't see the scenario you have in mind.

sorry but 4rd-u CE needs two modules working for 4rd-= u header mapping and stateful tunnel/encapsulation, respectively.=A0
=A0

(also because the processings are different).

= (you may say this is out of scope

It sure seems to me out of scope.

but i do hope you respect= other people's scope of concern. thanks in advance!)=A0

I do respect that, but need to understand what is mean= t.
Besides, there are enough in-scope issues being discussed to p= lease defer off-sope issues.

your scope is different from ours.=A0
=A0
(and it is really tough for implementators.= maybe not your care and you may state it is simple. therefore i parenthesi= ze this phrase.)

I do care abo= ut implementation, as other co-authors do.

then please deeply consider what Sat= oru suggested: don't change the deeply understood semantics so much. an= d please consider the annoyance of copying this bit here while those bits t= here even for a single octet. it is surely doable and not extremely complic= ated though.
=A0
Please don't suggest we don't.

on the other hand= , besides the above concerns, there are still some technical flaws of this = solution itself.=A0

*1. consider a case where 2 CEs, 1 hop apart in IPv6 do= main, establish EBGP session over IPv6 with their 4rd addresses as the loop= back addresses and ttl-security is set to, e.g., 254, in order to protect t= he peer from receiving attack messages sending by a remote third party with= snoofing. the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit m= ay offer a chance for the IPv4 node behind the CE, breaking the protection = of the ttl-security, because the TCP carrying BGP is directly exposed as th= e payload of the generated IPv6 packet like translation but the Hop Limit i= s not correctly decreased.=A0

Not understood.
I have di= fficulty to see why a -E tunnel would be different from a -U tunnel since b= oth will keep TTL transparency, independently of TTL values.=A0

please carefully read the example. the pro= blem here has changed. it is about the ttl-security of IPv6 routing rather = than the TTL transparency of the tunneled IPv4 (which you have patched with= the not-beautiful but anyway a solution). i show this example here in orde= r to point out HopLimit > 127 is in use even if the diameter of a domain= less than 127. Satoru also gave a link to a reference.=A0

-E has not the similar problem because the encapsulatio= n won't expose an BGP message to the IPv6 peer. -T has not the problem = either because the HopLimit is copied from IPv4 TTL and the ttl-security wo= rks in checking that HopLimit.=A0
=A0

*2. when routing loop happens in the IPv6 domain, unfortunately, the T= ime Exceeded (hop limit exceeded) ICMPv6 message will be translated to Time= Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a link-prob= lem as is expected as a report on the problem of the 1-hop tunnel link. thi= s must be confusing.=A0

-E seems to have the problem becaus= e this is how RFC6145 translates ICMPv6 to ICMPv4.
=

misunderstanding. -E doesn't have the problem becau= se RFC6145 translation for ICMPv6-to-ICMPv4 is never utilized in -E. it wou= ld be helpful if you may take some time to get to understand the ICMPv6/iCM= Pv4 translation semantics. they are different for -E and -T.=A0

thanks,=A0
maoke=A0
--00235429cbe052fceb04bc4a307d-- From fibrib@gmail.com Wed Mar 28 02:30:57 2012 Return-Path: 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 6160C21F8848 for ; Wed, 28 Mar 2012 02:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 H1NM4Vx4RcQr for ; Wed, 28 Mar 2012 02:30:56 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 759EB21F8845 for ; Wed, 28 Mar 2012 02:30:56 -0700 (PDT) Received: by qafi31 with SMTP id i31so395067qaf.15 for ; Wed, 28 Mar 2012 02:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H+7LNvepv66bpGfJ4rI0hOaVBdWr2Y30szII5a71dyE=; b=rfWNS7GVGYg2iAo6W/jN0Yj0WtKfZ6r11gVE+vBpB/OrXUsC31Yuv9WNriPyPdeqKd A1EFNznuPOG3RO1ws2TDHS6YfF9Sjc62E188mxsPquIeLLLAp46ag9Hb0R32ik0IRTKg ZBy/kB0dVFoAiNldXsWU6FKrW2brITfVgpLMF9fgVnIOknrAfB4o0MKLhOcWK3o7sQO5 QtntlaL5QtjMJ9X8DUeBGek3HJ+0DLpMQ+NsxRJJ2ndrBj1SK//zW8tVodH3HoOYxTDq 7ljA6ZNtrSQEtRqvG6YihxVdwlgP2B2rqP6lBkmVcVnB3okrUosIC+lx+MMfclodCSFK lW3g== MIME-Version: 1.0 Received: by 10.224.102.8 with SMTP id e8mr36844225qao.50.1332927056011; Wed, 28 Mar 2012 02:30:56 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 02:30:55 -0700 (PDT) In-Reply-To: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> Date: Wed, 28 Mar 2012 09:30:55 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b0d8af627f04bc4a43c7 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:30:57 -0000 --20cf3074b0d8af627f04bc4a43c7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/28 R=E9mi Despr=E9s > > Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit : > > > FYI, section 5 of RFC5082 ( > http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique > that TTL is used to help tunnel packets security. Anyway, > > > > On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: > > > >> > >> Le 2012-03-27 =E0 13:12, Maoke a =E9crit : > >>> 2012/3/27 R=E9mi Despr=E9s > >>> With TTL transparency added, I don't see what would be missing, even > with all requirements you expressed. > >>> > >>> well, it is still uncertain how 4rd-u will do this. it is uncertain i= f > the new ad hoc complement doesn't introduce new problems. could we see it > by the end of IETF83? > >> > >> Sure. > >> basic ID: > >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count= , > and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bit= s > 1-7 of the hop count. > >> - A exit, take bit 0 from the hop count, and bits 1-7 from the packet > ID. > >> > > > > Too much. Don't change deeply well understand/deployed semantics, PLEAS= E. > > Semantics isn't changed for any existing function. > CEs and BRs (the only ones to be concerned) use unused bits to convey som= e > IPv4 bits that need to be conveyed for e2e transparency. > unfortunately the first bit of Hop Limit is NOT "unused" at all. please also pay attention the reference that others suggested. - maoke > No implementation or operational problem can result. > > If I missed a practical problem you have identified, sharing this > information would of course be useful. > > Thanks, > RD > > > > > > > > > >> The only constraint it introduces is that the longest IPv6 path within > the domain must not exceed 127 (something that AFAIK shouldn't be a probl= em) > >> OK? > > > > NO. > > > > cheers, > > --satoru > > --20cf3074b0d8af627f04bc4a43c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit :

> FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#sectio= n-5.2) generalize a technique that TTL is used to help tunnel packets s= ecurity. Anyway,
>
> On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote:
>
>>
>> Le 2012-03-27 =E0 13:12, Maoke a =E9crit :
>>> 2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>> With TTL transparency added, I don't see what would be mis= sing, even with all requirements you expressed.
>>>
>>> well, it is still uncertain how 4rd-u will do this. it is unce= rtain if the new ad hoc complement doesn't introduce new problems. coul= d we see it by the end of IETF83?
>>
>> Sure.
>> basic ID:
>> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop c= ount, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in= bits 1-7 of the hop count.
>> - A exit, take bit 0 from the hop count, and bits 1-7 from the pac= ket ID.
>>
>
> Too much. Don't change deeply well understand/deployed semantics, = PLEASE.

Semantics isn't changed for any existing function.
CEs and BRs (the only ones to be concerned) use unused bits to convey some = IPv4 bits that need to be conveyed for e2e transparency.

unfortunately the first bit of Hop Limit is NOT "unu= sed" at all. please also pay attention the reference that others sugge= sted. - maoke=A0
=A0
No implementation or operational problem can result.

If I missed a practical problem you have identified, sharing this informati= on would of course be useful.

Thanks,
RD




>
>
>> The only constraint it introduces is that the longest IPv6 path wi= thin the domain must not exceed 127 (something that AFAIK shouldn't be = a problem)
>> OK?
>
> NO.
>
> cheers,
> --satoru


--20cf3074b0d8af627f04bc4a43c7-- From fibrib@gmail.com Wed Mar 28 02:37:10 2012 Return-Path: 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 3736721F87B2 for ; Wed, 28 Mar 2012 02:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 h88v7HZDaMcx for ; Wed, 28 Mar 2012 02:37:09 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id C20D921F8757 for ; Wed, 28 Mar 2012 02:37:08 -0700 (PDT) Received: by qafi31 with SMTP id i31so398293qaf.15 for ; Wed, 28 Mar 2012 02:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Px45WNMmS8nKcvDTpKHb1MbK9KP36TDQk/lI/QfQ+2o=; b=scjPVuZ5NuY2MXw3jtLDZX77iK7KzMmQcc30m+3ncs/SDPGbVp5mV91kKKPubuBsL8 nNhQIGFATV/mNsC9fuIDt6YCyr1PZeFtlhocqk0VT69TVBc1bAMrruJrzSTqkt6fIJxm EZW8TKUA7C7wTDjwc+1SoKJq9QabJNhgFwPVfiu9ue3Sz+QW3Uq7bPpB1LQ348DMtPRV yIO07HJJU0/TYFFHC5uKa/987MJmXqXUIYIOcsWLayRyGx2kdpfrPSSVlsI8hQDpoqxL y+9IIiHc13Z3PjcS/QNtMJ0dp07U5i0UlJr9RdUiTmD1awpqL2MQEu6zEN8rfd7CQXuF yvfg== MIME-Version: 1.0 Received: by 10.229.137.80 with SMTP id v16mr11243277qct.31.1332927428299; Wed, 28 Mar 2012 02:37:08 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 02:37:08 -0700 (PDT) In-Reply-To: <4F72CF72.7080500@viagenie.ca> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> Date: Wed, 28 Mar 2012 09:37:08 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=002354530090e00cb304bc4a59d8 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:37:10 -0000 --002354530090e00cb304bc4a59d8 Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Simon Perreault > On 03/28/12 09:22, Tetsuya Murakami wrote: > >> In terms of CNP, CNP needs to be calculated every time if the packet >> is toward to outside of domain because the embedded IPv4 address >> could be different. So, I think there is no difference between CNP >> and recalculation of L4 checksum from the implementation point of >> view. >> > > On the contrary, there is a big difference. The difference is that you are > only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, > etc, etc. You need a lot of code to handle all existing transport > protocols, and you still can't handle future protocols that people might > develop. > misunderstanding on ICMP. 1. ICMP is not transport protocol. 2. ICMP cannot benefit from CNP at all because ICMPv4 checksum doesn't cover the pseudo-header while ICMPv6 does. just FYI. - maoke > > Checksum neutrality is a *big* advantage. > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --002354530090e00cb304bc4a59d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Simon Perreault <simon.perreault@viag= enie.ca>
On 03/28/12 09:22, Tetsuya Murakami wrote:
In terms of CNP, CNP needs to be calculated every time if the packet
is toward to outside of domain because the embedded IPv4 address
could be different. So, I think there is no difference between CNP
and recalculation of L4 checksum from the implementation point of
view.

On the contrary, there is a big difference. The difference is that you are = only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc= , etc. You need a lot of code to handle all existing transport protocols, a= nd you still can't handle future protocols that people might develop.

misunderstanding on ICMP.=A0
1. = ICMP is not transport protocol.=A0
2. ICMP cannot benefit from CN= P at all because ICMPv4 checksum doesn't cover the pseudo-header while = ICMPv6 does.=A0

just FYI.=A0

- maoke
=A0

Checksum neutrality is a *big* advantage.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--002354530090e00cb304bc4a59d8-- From fibrib@gmail.com Wed Mar 28 02:47:14 2012 Return-Path: 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 A504521F86A0 for ; Wed, 28 Mar 2012 02:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7XxzctFn1Zpb for ; Wed, 28 Mar 2012 02:47:13 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 092B221F869D for ; Wed, 28 Mar 2012 02:47:12 -0700 (PDT) Received: by qcsq13 with SMTP id q13so613739qcs.31 for ; Wed, 28 Mar 2012 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDw6YJa7z+icJYKULSuWnlIAiMJJg87OmpPEHOkLZy4=; b=CCpIrXl9/gjrUCYKzDYnT9GWyYlAU22CyKTkWlnroEPwtN1gk95B31llsr71W9pJRU ytiR7r/Q2ySKD//XdNlew0MPTIvwDoYFJNXJZQXtfDjGrA1Fw3VgqRQ10PMmzEvSZqYi vcrV5ldwY8pUm4e4sgTNwlUY2bAjCA0M5fUmPmUxHqU+ZLPO9gLFaSTSc7RInTmtAEqG ehgbJBQECB0GApAikR7sARRqhpw9HTvqwZQvioEJrdQi8imxNNSCoNpXfVTMet1lrdlO 1Ad41ZnK66kYvnn4iWFPJhXrQD/noOt7eXM27avpHfm7/OApz4xagih8q2PkvkpyQNEP /xrA== MIME-Version: 1.0 Received: by 10.229.136.196 with SMTP id s4mr11277672qct.71.1332928032571; Wed, 28 Mar 2012 02:47:12 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 02:47:12 -0700 (PDT) In-Reply-To: <4F72CF72.7080500@viagenie.ca> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> Date: Wed, 28 Mar 2012 09:47:12 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=00235452e750e4841104bc4a7d39 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:47:14 -0000 --00235452e750e4841104bc4a7d39 Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Simon Perreault > On 03/28/12 09:22, Tetsuya Murakami wrote: > >> In terms of CNP, CNP needs to be calculated every time if the packet >> is toward to outside of domain because the embedded IPv4 address >> could be different. So, I think there is no difference between CNP >> and recalculation of L4 checksum from the implementation point of >> view. >> > > On the contrary, there is a big difference. The difference is that you are > only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, > etc, etc. You need a lot of code to handle all existing transport > protocols, and you still can't handle future protocols that people might > develop. > another FYI. RDP (RFC908, RFC1151) has different layout other than TCP/UDP. anyway a special process is needed for it. "you are only concerned with L3" is a mystery. thanks, maoke > > Checksum neutrality is a *big* advantage. > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00235452e750e4841104bc4a7d39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Simon Perreault <simon.perreault@viag= enie.ca>
On 03/28/12 09:22, Tetsuya Murakami wrote:
In terms of CNP, CNP needs to be calculated every time if the packet
is toward to outside of domain because the embedded IPv4 address
could be different. So, I think there is no difference between CNP
and recalculation of L4 checksum from the implementation point of
view.

On the contrary, there is a big difference. The difference is that you are = only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc= , etc. You need a lot of code to handle all existing transport protocols, a= nd you still can't handle future protocols that people might develop.

another FYI. RDP (RFC908, RFC1151) has dif= ferent layout other than TCP/UDP. anyway a special process is needed for it= . "you are only concerned with L3" is a mystery.=A0
thanks,
maoke
=A0

Checksum neutrality is a *big* advantage.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--00235452e750e4841104bc4a7d39-- From despres.remi@laposte.net Wed Mar 28 03:03:43 2012 Return-Path: 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 6786521F884F for ; Wed, 28 Mar 2012 03:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.172, 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 Z9vxpFlNdWq4 for ; Wed, 28 Mar 2012 03:03:42 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 21DB921F884A for ; Wed, 28 Mar 2012 03:03:41 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8509-out with ME id qy3f1i0065M8erm03y3fCc; Wed, 28 Mar 2012 12:03:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17-287017679 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 12:03:39 +0200 Message-Id: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:03:43 -0000 --Apple-Mail-17-287017679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-28 =E0 11:30, Maoke a =E9crit : >=20 >=20 > 2012/3/28 R=E9mi Despr=E9s >=20 > Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit : >=20 > > FYI, section 5 of RFC5082 = (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique = that TTL is used to help tunnel packets security. Anyway, > > > > On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: > > > >> > >> Le 2012-03-27 =E0 13:12, Maoke a =E9crit : > >>> 2012/3/27 R=E9mi Despr=E9s > >>> With TTL transparency added, I don't see what would be missing, = even with all requirements you expressed. > >>> > >>> well, it is still uncertain how 4rd-u will do this. it is = uncertain if the new ad hoc complement doesn't introduce new problems. = could we see it by the end of IETF83? > >> > >> Sure. > >> basic ID: > >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop = count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put = 127 in bits 1-7 of the hop count. > >> - A exit, take bit 0 from the hop count, and bits 1-7 from the = packet ID. > >> > > > > Too much. Don't change deeply well understand/deployed semantics, = PLEASE. >=20 > Semantics isn't changed for any existing function. > CEs and BRs (the only ones to be concerned) use unused bits to convey = some IPv4 bits that need to be conveyed for e2e transparency. >=20 > unfortunately the first bit of Hop Limit is NOT "unused" at all. = please also pay attention the reference that others suggested. Would you be kind enough to give again the reference of the document you = are referring to? I will look at it. Thanks. RD > - maoke=20 > =20 > No implementation or operational problem can result. >=20 > If I missed a practical problem you have identified, sharing this = information would of course be useful. >=20 > Thanks, > RD >=20 >=20 >=20 >=20 > > > > > >> The only constraint it introduces is that the longest IPv6 path = within the domain must not exceed 127 (something that AFAIK shouldn't be = a problem) > >> OK? > > > > NO. > > > > cheers, > > --satoru >=20 >=20 --Apple-Mail-17-287017679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/28 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit :

> FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) = generalize a technique that TTL is used to help tunnel packets security. = Anyway,
>
> On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote:
>
>>
>> Le 2012-03-27 =E0 13:12, Maoke a =E9crit :
>>> 2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net><= br> >>> With TTL transparency added, I don't see what would be = missing, even with all requirements you expressed.
>>>
>>> well, it is still uncertain how 4rd-u will do this. it is = uncertain if the new ad hoc complement doesn't introduce new problems. = could we see it by the end of IETF83?
>>
>> Sure.
>> basic ID:
>> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 = hop count, and bits 1-7 in the remaining space of the IPv6 packet ID. = Put 127 in bits 1-7 of the hop count.
>> - A exit, take bit 0 from the hop count, and bits 1-7 from the = packet ID.
>>
>
> Too much. Don't change deeply well understand/deployed semantics, = PLEASE.

Semantics isn't changed for any existing function.
CEs and BRs (the only ones to be concerned) use unused bits to convey = some IPv4 bits that need to be conveyed for e2e = transparency.

unfortunately the = first bit of Hop Limit is NOT "unused" at all. please also pay attention = the reference that others = suggested.

Would you be kind = enough to give again the reference of the document you are referring = to?
I will look at = it.
Thanks.

RD


- = maoke 
 
No implementation or operational problem can result.

If I missed a practical problem you have identified, sharing this = information would of course be useful.

Thanks,
RD




>
>
>> The only constraint it introduces is that the longest IPv6 path = within the domain must not exceed 127 (something that AFAIK shouldn't be = a problem)
>> OK?
>
> NO.
>
> cheers,
> --satoru



= --Apple-Mail-17-287017679-- From fibrib@gmail.com Wed Mar 28 03:20:25 2012 Return-Path: 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 CB90D21F8A24 for ; Wed, 28 Mar 2012 03:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fYF9S+DNcjYk for ; Wed, 28 Mar 2012 03:20:24 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 222F921F8A23 for ; Wed, 28 Mar 2012 03:20:24 -0700 (PDT) Received: by qaea16 with SMTP id a16so704367qae.10 for ; Wed, 28 Mar 2012 03:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EMJHyPMNuReSwN/gDjtXeLhFqRnVj5H3K5izIBTtOdE=; b=bFkuknXdgBjIe1oJKxOkHaQBxfoh1SvQ2hTH1uqx6NVWzi1yc6/w0yGlrH7nDLi7JV HhR/Be7Atb8GU/Y1X7qLIYcP/0e0ISGm5S4yHFdkyh1S9kEb7+hfBwvbiQFcvzcSCu/n xBXaMaxErGp/mXjehPWrgndbej55lg5yrf+0hOU1mUr2KWbmmeYhHvDH6PjIjk5qFLU2 drWIcwA72KDyoOl+4DwuxpgCv44ownpuaYfCZrVsci9V9qktQbqnSVijmgIPv2clyvBb kAhyDAc3zdhr90ZdXePz5tZTQ/9TZVs7wZli0tmcO128GL4OFP+A7q8f8zR92T4FoTk+ n1HA== MIME-Version: 1.0 Received: by 10.224.111.19 with SMTP id q19mr21203139qap.24.1332930023639; Wed, 28 Mar 2012 03:20:23 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 03:20:23 -0700 (PDT) In-Reply-To: <4F72D39B.9080506@viagenie.ca> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> Date: Wed, 28 Mar 2012 10:20:23 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf3074d21891c8b004bc4af4d2 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:20:26 -0000 --20cf3074d21891c8b004bc4af4d2 Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Simon Perreault > On 03/28/12 10:48, Satoru Matsushima wrote: > >> On the contrary, there is a big difference. The difference is that you >>> are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, >>> etc, etc. You need a lot of code to handle all existing transport >>> protocols, and you still can't handle future protocols that people might >>> develop. >>> >>> Checksum neutrality is a *big* advantage. >>> >> >> Cool. How many protocols we should support for just a *transition* >> mechanism? >> > > The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a > longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep > providing clients with residual IPv4 for a potentially loooooooooooong > time. So we need to be really careful to get this right, because we'll be > stuck with what we design for a long time. > > So you have two options: > > a) checksum neutrality > - no code specific to each transport prototol > FYI. Remi has clarified: no code specific to transport protocol having destination port position and pseudo-header as same as TCP has. but other protocols are exceptions, needing specific codes. exceptions include at least: 1. ICMP; 2. RDP. > - supports all current and future transport protocols > again, supports current and future transport protocols, which follows TCP layout and TCP checksum's pseudo-header definition. > b) checksum non-neutrality > - additional code necessary for each transport protocol > - limited set of supported transport protocols > see above, CNP is also a limited improvement. > > Less code, more transport protocols. I think the choice is easy. > > There's a reason NPTv6 and NAT64 chose checksum neutrality... to me, we'd better never forget Jon Postel's law for the Internet robustness, which is written in RFC793: "be conservative in what you do, be liberal in what you accept from others." a better world could be achieved by having the L4-checksum adjustment as mandatory while, when possible, having the CNP as an operational complement. as implementor, we are conservative to consider some operation circumstances may not have CNP instead of requiring all operators MUST doing so; as operator, we are also conservative to consider some protocols may not have been fully supported by the translators, and we attach the CNP in our address formation in order to survive those protocol as better as we can. requiring others offering anything into our standard is really an easy life. but it is, a sort of, selfish. thanks, maoke > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074d21891c8b004bc4af4d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Simon Perreault <simon.perreault@viag= enie.ca>
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you are = only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc= , etc. You need a lot of code to handle all existing transport protocols, a= nd you still can't handle future protocols that people might develop.
Checksum neutrality is a *big* advantage.

Cool. How many protocols we should support for just a *transition* mechanis= m?

The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a = longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep pro= viding clients with residual IPv4 for a potentially loooooooooooong time. S= o we need to be really careful to get this right, because we'll be stuc= k with what we design for a long time.

So you have two options:

a) checksum neutrality
=A0 - no code specific to each transport prototol
FYI. Remi has clarified: no code specific to transport protocol= having destination port position and pseudo-header as same as TCP has. but= other protocols are exceptions, needing specific codes. exceptions include= at least: 1. ICMP; 2. RDP.=A0
=A0
=A0 - supports all current and future transport protocols
=

again, supports current and future transport protocols,= which follows TCP layout and TCP checksum's pseudo-header definition.= =A0
=A0
b) checksum non-neutrality
=A0 - additional code necessary for each transport protocol
=A0 - limited set of supported transport protocols
see above, CNP is also a limited improvement.=A0
=A0=

Less code, more transport protocols. I think the choice is easy.

There's a reason NPTv6 and NAT64 chose checksum neutrality...

to me, we'd better never forget Jon Postel's= law for the Internet robustness, which is written in RFC793: "be cons= ervative in what you do, be liberal in what you accept from others." a= better world could be achieved by having the L4-checksum adjustment as man= datory while, when possible, having the CNP as an operational complement. a= s implementor, we are conservative to consider some operation circumstances= may not have CNP instead of requiring all operators MUST doing so; as oper= ator, we are also conservative to consider some protocols may not have been= fully supported by the translators, and we attach the CNP in our address f= ormation in order to survive those protocol as better as we can.=A0

requiring others offering anything into our standard is= really an easy life. but it is, a sort of, selfish.=A0

thanks,
maoke
=A0


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074d21891c8b004bc4af4d2-- From fibrib@gmail.com Wed Mar 28 03:25:42 2012 Return-Path: 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 1897421F891C for ; Wed, 28 Mar 2012 03:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VIX5-qA32TNg for ; Wed, 28 Mar 2012 03:25:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8121F8A3F for ; Wed, 28 Mar 2012 03:25:37 -0700 (PDT) Received: by qcsq13 with SMTP id q13so634556qcs.31 for ; Wed, 28 Mar 2012 03:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e9yAbjSXMB8wS5r7VBW1dGfd0ECPKwiI7Cf85TJQfzE=; b=yd17xzaDehT0QbCR1dAPtskX158Bj45Ay3ksHdGbMXVxQQw3Pzrq6VhqPI3p+9QKNG jkbc2KGe8U+2m3QVpj1zFXs0qnwitTTa3qr4lm3BI5HUghcdyxsviFwz2lFnfrQpnFNo tqqfh1qabXNgak4bhinfdxzyhQsRkS12iMFFhdYp6EqXiITv6SEd4y+rVNGJ4UsS6iTA ZyRtRtNFVgS3KYQIdeM4qmm4hqMJyKXfSWvpAlUhJCr4Dia6XoikmqE3XsxrmSkJ5kp+ 0wUOqPIhTN4e5m1J0bS54on/AmLgtgi2ZNAKJLHyEmTuBxLpZYN5cjtSG/HgYVy9pZNS UrHA== MIME-Version: 1.0 Received: by 10.229.77.141 with SMTP id g13mr11350982qck.11.1332930336916; Wed, 28 Mar 2012 03:25:36 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 03:25:36 -0700 (PDT) In-Reply-To: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> Date: Wed, 28 Mar 2012 10:25:36 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=00235429cbe03e077704bc4b0714 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:25:42 -0000 --00235429cbe03e077704bc4b0714 Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Maoke > > > 2012/3/28 Simon Perreault > >> On 03/28/12 10:48, Satoru Matsushima wrote: >> >>> On the contrary, there is a big difference. The difference is that you >>>> are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, >>>> etc, etc. You need a lot of code to handle all existing transport >>>> protocols, and you still can't handle future protocols that people might >>>> develop. >>>> >>>> Checksum neutrality is a *big* advantage. >>>> >>> >>> Cool. How many protocols we should support for just a *transition* >>> mechanism? >>> >> >> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for >> a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep >> providing clients with residual IPv4 for a potentially loooooooooooong >> time. So we need to be really careful to get this right, because we'll be >> stuck with what we design for a long time. >> >> So you have two options: >> >> a) checksum neutrality >> - no code specific to each transport prototol >> > > FYI. Remi has clarified: no code specific to transport protocol having > destination port position and pseudo-header as same as TCP has. but other > protocols are exceptions, needing specific codes. exceptions include at > least: 1. ICMP; 2. RDP. > > >> - supports all current and future transport protocols >> > > again, supports current and future transport protocols, which follows TCP > layout and TCP checksum's pseudo-header definition. > grammatical erratus: ... current and future transport protocol that follows ... > > >> b) checksum non-neutrality >> - additional code necessary for each transport protocol >> - limited set of supported transport protocols >> > > see above, CNP is also a limited improvement. > > >> >> Less code, more transport protocols. I think the choice is easy. >> >> There's a reason NPTv6 and NAT64 chose checksum neutrality... > > > to me, we'd better never forget Jon Postel's law for the Internet > robustness, which is written in RFC793: "be conservative in what you do, be > liberal in what you accept from others." a better world could be achieved > by having the L4-checksum adjustment as mandatory while, when possible, > having the CNP as an operational complement. as implementor, we are > conservative to consider some operation circumstances may not have CNP > instead of requiring all operators MUST doing so; as operator, we are also > conservative to consider some protocols may not have been fully supported > by the translators, and we attach the CNP in our address formation in order > to survive those protocol as better as we can. > > requiring others offering anything into our standard is really an easy > life. but it is, a sort of, selfish. > > thanks, > maoke > > >> >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > --00235429cbe03e077704bc4b0714 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Maoke <fibrib@gmail.com>


2012/3/28 Simon Perrea= ult <simon.perreault@viagenie.ca>
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you are = only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, etc= , etc. You need a lot of code to handle all existing transport protocols, a= nd you still can't handle future protocols that people might develop.
Checksum neutrality is a *big* advantage.

Cool. How many protocols we should support for just a *transition* mechanis= m?

The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a = longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep pro= viding clients with residual IPv4 for a potentially loooooooooooong time. S= o we need to be really careful to get this right, because we'll be stuc= k with what we design for a long time.

So you have two options:

a) checksum neutrality
=A0 - no code specific to each transport prototol
FYI. Remi has clarified: no code specific to transport pr= otocol having destination port position and pseudo-header as same as TCP ha= s. but other protocols are exceptions, needing specific codes. exceptions i= nclude at least: 1. ICMP; 2. RDP.=A0
=A0
=A0 - supports all current and future transport protocols
=

again, supports current and future transport prot= ocols, which follows TCP layout and TCP checksum's pseudo-header defini= tion.=A0

grammatical erratus: ... current and= future transport protocol that follows ...=A0
=A0
=A0
b) checksum non-neutrality
=A0 - additional code necessary for each transport protocol
=A0 - limited set of supported transport protocols
see above, CNP is also a limited improvement.=A0
=A0

Less code, more transport protocols. I think the choice is easy.

There's a reason NPTv6 and NAT64 chose checksum neutrality...

to me, we'd better never forget Jon Postel= 's law for the Internet robustness, which is written in RFC793: "b= e conservative in what you do, be liberal in what you accept from others.&q= uot; a better world could be achieved by having the L4-checksum adjustment = as mandatory while, when possible, having the CNP as an operational complem= ent. as implementor, we are conservative to consider some operation circums= tances may not have CNP instead of requiring all operators MUST doing so; a= s operator, we are also conservative to consider some protocols may not hav= e been fully supported by the translators, and we attach the CNP in our add= ress formation in order to survive those protocol as better as we can.=A0

requiring others offering anything into our standard is= really an easy life. but it is, a sort of, selfish.=A0

thanks,
maoke
=A0


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


--00235429cbe03e077704bc4b0714-- From ichiroumakino@gmail.com Wed Mar 28 03:28:40 2012 Return-Path: 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 5FFA721F8733 for ; Wed, 28 Mar 2012 03:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 1qeR5xuyS+D8 for ; Wed, 28 Mar 2012 03:28:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94F21F86BE for ; Wed, 28 Mar 2012 03:28:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so556156wgb.13 for ; Wed, 28 Mar 2012 03:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hRrcUoIAAXOpzdo1ZCYusWbR/GO2g8Rowq/H09MZvE8=; b=IttfWjgJZIaNMIj1N0Fr76vlh7IzUcQATrcutPBArxw9RzcExQokH8kRQrxeZPkfzK YmrKVS+ExXBCZ6FO8OoN/2vw1xNcnYCY1mnQ+3ydU+zzQIEq4G6q3KREruowyAGryAjw JZQQYjoTR4uDUARAaFMvlNx6OBx1te+HHq7ogP4zfIREGhlhemmgT3I8rHhnMj5iVq/i j0EtjebzlYD1oxC9WNuJ0cJrF0VT1NOL2U0OKyMIbozjepmqfKavcPU6eQXQuEp/8UId 6FJXbhhCjiAO5Pi/tvOkHEuht7iMHtUvsHEgDuul4SjEy1DvEdnLdz250hgFwQacNYLv zP8g== Received: by 10.180.85.69 with SMTP id f5mr5722772wiz.18.1332930518462; Wed, 28 Mar 2012 03:28:38 -0700 (PDT) Received: from dhcp-10-61-96-228.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fn2sm11753743wib.0.2012.03.28.03.28.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 03:28:37 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4F72D39B.9080506@viagenie.ca> Date: Wed, 28 Mar 2012 12:28:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:28:40 -0000 >>> On the contrary, there is a big difference. The difference is that = you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, = DCCP, etc, etc, etc. You need a lot of code to handle all existing = transport protocols, and you still can't handle future protocols that = people might develop. >>>=20 >>> Checksum neutrality is a *big* advantage. >>=20 >> Cool. How many protocols we should support for just a *transition* = mechanism? >=20 > The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used = for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time. >=20 > So you have two options: >=20 > a) checksum neutrality > - no code specific to each transport prototol > - supports all current and future transport protocols this comes with a number of caveats. and given that you need to look at the L4 to get the ports anyway... > b) checksum non-neutrality > - additional code necessary for each transport protocol existing code. existing standard. > - limited set of supported transport protocols the same issue applies above. >=20 > Less code, more transport protocols. I think the choice is easy. >=20 > There's a reason NPTv6 and NAT64 chose checksum neutrality... NAT64?? cheers, Ole= From simon.perreault@viagenie.ca Wed Mar 28 03:34:38 2012 Return-Path: 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 7A02921F8941 for ; Wed, 28 Mar 2012 03:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 1wvh-p3EXmEx for ; Wed, 28 Mar 2012 03:34:38 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E57D721F88B5 for ; Wed, 28 Mar 2012 03:34:37 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DED91400CF; Wed, 28 Mar 2012 06:34:36 -0400 (EDT) Message-ID: <4F72E93A.5080904@viagenie.ca> Date: Wed, 28 Mar 2012 12:34:34 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> In-Reply-To: <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:34:38 -0000 On 03/28/12 12:28, Ole Trøan wrote: >> There's a reason NPTv6 and NAT64 chose checksum neutrality... > > NAT64?? Yup. RFC 6052 section 4. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fibrib@gmail.com Wed Mar 28 03:39:16 2012 Return-Path: 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 D84C721F89BB for ; Wed, 28 Mar 2012 03:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 HGf+2yaRU5P6 for ; Wed, 28 Mar 2012 03:39:16 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0521F89B6 for ; Wed, 28 Mar 2012 03:39:15 -0700 (PDT) Received: by qafi31 with SMTP id i31so430694qaf.15 for ; Wed, 28 Mar 2012 03:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j3dwM3ppLxzdFCJfMjEDkVfNRpDn45ra8Jk5fZegyFk=; b=eO43/TbK7mAA1dajS3inGJ9+WZYoPBk+sdnHm4EQL6gkGvWqly40K7usc4nuW707Pc REVB8Fj61s5ALZonDzt276u7iZ/tYBxvm+zMexhMF5YFqvWbO0V+gbsmW4kH5vbYF36L 8KysJo8U5oXiw0zRLNcA7zuVwwmFVdh8WcszOp8k9kJ3EHQr3jFt8WGffNK4bkgcA4Cr jj72nda8ECrM1RpVH5aQMNujAUJyzcJPrEx+Dh0Mkwcs6nmEpQ2tfUiqD+PD0aDWHGvg IIwQkJ3pTLpetWnYHMe3jgJsewHs8iWLJQh5x8+gmOfJSxrm6E0c8KD6FITBLksTL94M jEPw== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr37215727qab.11.1332931155444; Wed, 28 Mar 2012 03:39:15 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 03:39:15 -0700 (PDT) In-Reply-To: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> Date: Wed, 28 Mar 2012 10:39:15 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b4b807c49004bc4b3876 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:39:17 -0000 --20cf3074b4b807c49004bc4b3876 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/3/28 R=E9mi Despr=E9s > > Le 2012-03-28 =E0 11:30, Maoke a =E9crit : > > > > 2012/3/28 R=E9mi Despr=E9s > >> >> Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit : >> >> > FYI, section 5 of RFC5082 ( >> http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique >> that TTL is used to help tunnel packets security. Anyway, >> > >> > On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: >> > >> >> >> >> Le 2012-03-27 =E0 13:12, Maoke a =E9crit : >> >>> 2012/3/27 R=E9mi Despr=E9s >> >>> With TTL transparency added, I don't see what would be missing, even >> with all requirements you expressed. >> >>> >> >>> well, it is still uncertain how 4rd-u will do this. it is uncertain >> if the new ad hoc complement doesn't introduce new problems. could we se= e >> it by the end of IETF83? >> >> >> >> Sure. >> >> basic ID: >> >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop >> count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 12= 7 >> in bits 1-7 of the hop count. >> >> - A exit, take bit 0 from the hop count, and bits 1-7 from the packet >> ID. >> >> >> > >> > Too much. Don't change deeply well understand/deployed semantics, >> PLEASE. >> >> Semantics isn't changed for any existing function. >> CEs and BRs (the only ones to be concerned) use unused bits to convey >> some IPv4 bits that need to be conveyed for e2e transparency. >> > > unfortunately the first bit of Hop Limit is NOT "unused" at all. please > also pay attention the reference that others suggested. > > > Would you be kind enough to give again the reference of the document you > are referring to? > I will look at it. > thank you, Remi, and here you are. what Satoru pointed out is: > FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2= ) generalize a technique that TTL is used to help tunnel packets security. and i'd like also suggest Cisco IOS and Juniper JUNOS documents about security issues regarding ttl or hop limit. sorry but it is hard to specify a very specific page because we need to pay attention to understand the whole problem. but it is not hard to google them out. (RFC2080 also covers the similar issue regarding RIPng, though multicast over the hop is involved, which might be not in the current scope of MAP while might be in the near future). thanks again for your attention. - maoke > Thanks. > > RD > --20cf3074b4b807c49004bc4b3876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

Le 2012-03-28 =E0 11:30, = Maoke a =E9crit :


=
2012/3/28 R=E9mi Despr=E9s <despres.= remi@laposte.net>

Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit :

> FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#sectio= n-5.2) generalize a technique that TTL is used to help tunnel packets s= ecurity. Anyway,
>
> On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote:
>
>>
>> Le 2012-03-27 =E0 13:12, Maoke a =E9crit :
>>> 2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>> With TTL transparency added, I don't see what would be mis= sing, even with all requirements you expressed.
>>>
>>> well, it is still uncertain how 4rd-u will do this. it is unce= rtain if the new ad hoc complement doesn't introduce new problems. coul= d we see it by the end of IETF83?
>>
>> Sure.
>> basic ID:
>> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop c= ount, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in= bits 1-7 of the hop count.
>> - A exit, take bit 0 from the hop count, and bits 1-7 from the pac= ket ID.
>>
>
> Too much. Don't change deeply well understand/deployed semantics, = PLEASE.

Semantics isn't changed for any existing function.
CEs and BRs (the only ones to be concerned) use unused bits to convey some = IPv4 bits that need to be conveyed for e2e transparency.

unfortunately the first bit of Hop Limit is NOT "unu= sed" at all. please also pay attention the reference that others sugge= sted.

Would you be kind enough to give ag= ain the reference of the document you are referring to?
I will lo= ok at it.

thank you, Remi, and = here you are.=A0

what Satoru pointed out is:=A0
> FYI, sect= ion 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) gen= eralize a technique that TTL is used to help tunnel packets security.

and i'd like also suggest Cisco IOS and Juniper JUN= OS documents about security issues regarding ttl or hop limit. sorry but it= is hard to specify a very specific page because we need to pay attention t= o understand the whole problem. but it is not hard to google them out. (RFC= 2080 also covers the similar issue regarding RIPng, though multicast over t= he hop is involved, which might be not in the current scope of MAP while mi= ght be in the near future).=A0

thanks again for your attention.=A0

- maoke
=A0
Thanks.

RD
<= /font>
--20cf3074b4b807c49004bc4b3876-- From ichiroumakino@gmail.com Wed Mar 28 03:43:44 2012 Return-Path: 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 D1A1D21F8A2A for ; Wed, 28 Mar 2012 03:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 SJUpOZSay-KA for ; Wed, 28 Mar 2012 03:43:44 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4A21F8A21 for ; Wed, 28 Mar 2012 03:43:43 -0700 (PDT) Received: by werb10 with SMTP id b10so649792wer.31 for ; Wed, 28 Mar 2012 03:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3/fHHRIVRq58dH3b2v2V1OJhYAb7tMYNewOZXsWlvrI=; b=yrZ80lpVsaDezw23D60175EAV+2ulzl7mZuiD6kgcjQJAKEaTDHYRgSJ8aLrQdbI1t fYfFX+vvnNxsELC09xVFcK3nXJMtUGhxnprAIlz7dIrrf+3YIh22tcrp2xpK+AsZWXUg QOMW7PCfkZ99cLO0aJb60DVfPMc4TBR/w0GkOtyRtft+dc84+GYKyHQ3tcKR/HGbs3MF 4YoIIlqAsLL7dn5gC1sbdzJcF658GmW19ZS1/fHkqWpgNtGsuXdMc+inkvDdWKdhmVUG c+EowWhIb0X2f2aWfFLqEvVXwOTbkpenD+OTC/XYEZHWvHoAHLSccDI41yCvKNMeaE0s pgRA== Received: by 10.180.79.135 with SMTP id j7mr5784659wix.19.1332931422795; Wed, 28 Mar 2012 03:43:42 -0700 (PDT) Received: from dhcp-10-61-96-228.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm11846590wib.4.2012.03.28.03.43.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 03:43:41 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4F72E93A.5080904@viagenie.ca> Date: Wed, 28 Mar 2012 12:43:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8C8A2869-2261-4B90-A244-71FD2182B73A@employees.org> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:43:44 -0000 >>> There's a reason NPTv6 and NAT64 chose checksum neutrality... >> >> NAT64?? > > Yup. RFC 6052 section 4. as in "We considered reserving 16 bits in the suffix to guarantee checksum neutrality, but declined" ?? cheers, Ole From despres.remi@laposte.net Wed Mar 28 03:46:50 2012 Return-Path: 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 47D5D21F8A3F for ; Wed, 28 Mar 2012 03:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.167, 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 7bu1v2oeVAG2 for ; Wed, 28 Mar 2012 03:46:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAE621F8A3E for ; Wed, 28 Mar 2012 03:46:48 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8506-out with ME id qymk1i0075M8erm03yml8x; Wed, 28 Mar 2012 12:46:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-289602831 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 12:46:44 +0200 Message-Id: References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> <24F07C5B-A93A-4F0F-B3A9-107B6CA22EE1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:46:50 -0000 --Apple-Mail-18-289602831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-28 =E0 11:25, Maoke a =E9crit : >=20 >=20 > 2012/3/28 R=E9mi Despr=E9s >=20 >> 1. nobody can think the leftmost bit of Hop Limit in IPv6 header is = marked as "unused" or "unspecified" (actually it is often used). you'd = better to update RFC2460 first.=20 >=20 > No need for any update AFAIK. >=20 > significant semantics change without update, without definition, but = requires peer and operators awareness. -- AFAIK, it is not acceptable.=20= Different understanding. If you identify an operational issue, thanks for sharing it.) >> 2. not sure that IPv6 path within a domain larger than 127 hops is a = corner case that is more-corner than the corner of DF=3DMF=3D1. in fact, >=20 > Difference: > - Domain longest path is a local matter that can be ensured by ISPs. >=20 > see also below (*) > =20 > - DF=3DMF=3D1 is a service restriction that affects some users.=20 >=20 >> this is to change the definition of routing loop criterion in a IPv6 = network.=20 >=20 > ??? >=20 > for IPv4 packets with TTL=3D64, it would be reported fail after being = forwarded in the IPv6 network 127 times; for IPv4 packets with TTL=3D128, = it would be reported fail after 255 times of forwarding in IPv6. = criterion is uncertain. =20 >=20 > (*) > considering that temporarily routing loop happens when distance vector = or link state changes, the limitation of 127 hops makes the diameter of = the actual workable IPv6 network less than 127. operators can ensure the = stable state path length but cannot ensure the case in state-transition. = unfortunately, you cannot force IPv4 applictions always initializing TTL = larger than 127 in order to gain the 255 HopLimit in IPv6.=20 >=20 > -E works fine with the commonly understood behavior and commonly, well = understood limitations, without bias to any value of IPv4 TTL.=20 > =20 >=20 >> 3. even domain diameter less than 127 is always true, MAP-E's generic = encapsulation module can works for both the MAP and also the stateful = tunneling across multiple domains unless the hop count exceeds what IPv6 = protocol allows; while >=20 >> 4rd-u CE's header mapping module cannot be reused for stateful = tunneling over multiple IPv6 domains >=20 > Sorry I don't see the scenario you have in mind. >=20 > sorry but 4rd-u CE needs two modules working for 4rd-u header mapping = and stateful tunnel/encapsulation, respectively.=20 Sorry, I don't follow what is meant. > =20 >=20 >> (also because the processings are different). >=20 >> (you may say this is out of scope >=20 > It sure seems to me out of scope. >=20 >> but i do hope you respect other people's scope of concern. thanks in = advance!)=20 >=20 > I do respect that, but need to understand what is meant. > Besides, there are enough in-scope issues being discussed to please = defer off-sope issues. >=20 > your scope is different from ours.=20 This collective "ours" is unclear to me. - Is there an identified group you are representing?=20 - Then which one? In any case this off-scope issue remains unclear to me. >> (and it is really tough for implementators. maybe not your care and = you may state it is simple. therefore i parenthesize this phrase.) >=20 > I do care about implementation, as other co-authors do. >=20 > then please deeply consider what Satoru suggested: don't change the = deeply understood semantics so much. and please consider the annoyance = of copying this bit here while those bits there even for a single octet. = it is surely doable and not extremely complicated though. > =20 > Please don't suggest we don't. >=20 >> on the other hand, besides the above concerns, there are still some = technical flaws of this solution itself.=20 >>=20 >> *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, = establish EBGP session over IPv6 with their 4rd addresses as the = loopback addresses and ttl-security is set to, e.g., 254, in order to = protect the peer from receiving attack messages sending by a remote = third party with snoofing. the mechanism of having IPv4 TTL's bit 0 in = IPv6 Hop Limit may offer a chance for the IPv4 node behind the CE, = breaking the protection of the ttl-security, because the TCP carrying = BGP is directly exposed as the payload of the generated IPv6 packet like = translation but the Hop Limit is not correctly decreased.=20 >=20 > Not understood. > I have difficulty to see why a -E tunnel would be different from a -U = tunnel since both will keep TTL transparency, independently of TTL = values.=20 >=20 > please carefully read the example. the problem here has changed. it is = about the ttl-security of IPv6 routing rather than the TTL transparency = of the tunneled IPv4 (which you have patched with the not-beautiful but = anyway a solution). i show this example here in order to point out = HopLimit > 127 is in use even if the diameter of a domain less than 127. = Satoru also gave a link to a reference.=20 >=20 > -E has not the similar problem because the encapsulation won't expose = an BGP message to the IPv6 peer. -T has not the problem either because = the HopLimit is copied from IPv4 TTL and the ttl-security works in = checking that HopLimit.=20 I am not an expert of this application, but fail to understand while = there would be any problem since: - with its added TTL preservation, U is completely transparent to TTLs - unless I am mistaken, the protocol you refer to is between two IPv4 = modules. > =20 >=20 >> *2. when routing loop happens in the IPv6 domain, unfortunately, the = Time Exceeded (hop limit exceeded) ICMPv6 message will be translated to = Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a = link-problem as is expected as a report on the problem of the 1-hop = tunnel link. this must be confusing.=20 >=20 > -E seems to have the problem because this is how RFC6145 translates = ICMPv6 to ICMPv4. >=20 > misunderstanding. -E doesn't have the problem because RFC6145 = translation for ICMPv6-to-ICMPv4 is never utilized in -E. What happens then if a BR to CE packet, for example, is discarded by an = in-domain IPv6 router? - A BR will receive an ICMPv6 error message, right? - Will it be just ignored, or translated to ICMPv4? =20 > it would be helpful if you may take some time to get to understand the = ICMPv6/iCMPv4 translation semantics. they are different for -E and -T.=20= Once more one of these statements I would have preferred not to hear = from you. RD >=20 > thanks,=20 > maoke=20 --Apple-Mail-18-289602831 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/28 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

1. nobody can think the = leftmost bit of Hop Limit in IPv6 header is marked as "unused" or = "unspecified" (actually it is often used). you'd better to update = RFC2460 first. 

No need for any update = AFAIK.

significant semantics = change without update, without definition, but requires peer and = operators awareness. -- AFAIK, it is not = acceptable. 

Different = understanding.
If you identify an operational issue, thanks = for sharing it.)

2. not sure that IPv6 path within a domain larger than 127 hops is = a corner case that is more-corner than the corner of DF=3DMF=3D1. in = fact, =

Difference:
- = Domain longest path is a local matter that can be ensured by ISPs.

see also below = (*)
 
- = DF=3DMF=3D1 is a service restriction that affects some = users. 

this is to change the definition of routing loop criterion in a = IPv6 = network. 

???

for IPv4 packets with TTL=3D64, it = would be reported fail after being forwarded in the IPv6 network 127 = times; for IPv4 packets with TTL=3D128, it would be reported fail after = 255 times of forwarding in IPv6. criterion is uncertain.  

(*)
considering that temporarily routing = loop happens when distance vector or link state changes, the limitation = of 127 hops makes the diameter of the actual workable IPv6 network less = than 127. operators can ensure the stable state path length but cannot = ensure the case in state-transition. unfortunately, you cannot force = IPv4 applictions always initializing TTL larger than 127 in order to = gain the 255 HopLimit in IPv6. 

-E works fine with the commonly understood behavior = and commonly, well understood limitations, without bias to any value of = IPv4 TTL. 
 

3. even domain diameter less than 127 is always true, MAP-E's = generic encapsulation module can works for both the MAP and also the = stateful tunneling across multiple domains unless the hop count exceeds = what IPv6 protocol allows; while

4rd-u CE's header mapping module cannot be = reused for stateful tunneling over multiple IPv6 = domains

Sorry I don't see the scenario you have in = mind.

sorry but 4rd-u CE = needs two modules working for 4rd-u header mapping and stateful = tunnel/encapsulation, = respectively. 

Sorry, I = don't follow what is meant.
 

(also because the processings are different). =

(you may say this is out of = scope

It sure seems to me out of scope.

but i do hope you respect other people's = scope of concern. thanks in advance!) 

I do respect that, but need to understand what is = meant.
Besides, there are enough in-scope issues being = discussed to please defer off-sope = issues.

your scope is different from = ours. 

This collective = "ours" is unclear to me.
- Is there an identified group you = are representing? 
- Then which one?
In any = case this off-scope issue remains unclear to = me.


(and it is really tough for = implementators. maybe not your care and you may state it is simple. = therefore i parenthesize this = phrase.)

I do care about = implementation, as other co-authors do.

then please deeply consider what = Satoru suggested: don't change the deeply understood semantics so much. = and please consider the annoyance of copying this bit here while those = bits there even for a single octet. it is surely doable and not = extremely complicated though.
 
Please don't suggest we = don't.

on the other = hand, besides the above concerns, there are still some technical flaws = of this solution itself. 

*1. consider a case where 2 CEs, 1 hop apart in IPv6 = domain, establish EBGP session over IPv6 with their 4rd addresses as the = loopback addresses and ttl-security is set to, e.g., 254, in order to = protect the peer from receiving attack messages sending by a remote = third party with snoofing. the mechanism of having IPv4 TTL's bit 0 in = IPv6 Hop Limit may offer a chance for the IPv4 node behind the CE, = breaking the protection of the ttl-security, because the TCP carrying = BGP is directly exposed as the payload of the generated IPv6 packet like = translation but the Hop Limit is not correctly decreased. 

Not understood.
I have = difficulty to see why a -E tunnel would be different from a -U tunnel = since both will keep TTL transparency, independently of TTL = values. 

please carefully read the example. the = problem here has changed. it is about the ttl-security of IPv6 routing = rather than the TTL transparency of the tunneled IPv4 (which you have = patched with the not-beautiful but anyway a solution). i show this = example here in order to point out HopLimit > 127 is in use even if = the diameter of a domain less than 127. Satoru also gave a link to a = reference. 

-E has not the similar problem because the = encapsulation won't expose an BGP message to the IPv6 peer. -T has not = the problem either because the HopLimit is copied from IPv4 TTL and the = ttl-security works in checking that = HopLimit. 

I am not an = expert of this application, but fail to understand while there would be = any problem since:
- with its added TTL preservation, U is = completely transparent to TTLs
- unless I am = mistaken, the protocol you refer to is between two IPv4 = modules.

 

*2. when routing loop happens in the IPv6 domain, unfortunately, = the Time Exceeded (hop limit exceeded) ICMPv6 message will be translated = to Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a = link-problem as is expected as a report on the problem of the 1-hop = tunnel link. this must be confusing. 

-E seems to have the problem = because this is how RFC6145 translates ICMPv6 to = ICMPv4.

misunderstanding. -E = doesn't have the problem because RFC6145 translation for = ICMPv6-to-ICMPv4 is never utilized in = -E.

What happens then if a BR to = CE packet, for example, is discarded by an in-domain IPv6 = router?
- A BR will receive an ICMPv6 error message, = right?
- Will it be just ignored, or translated to = ICMPv4?
 
it would be helpful if you may take some = time to get to understand the ICMPv6/iCMPv4 translation semantics. they = are different for -E and = -T. 

Once more one of = these statements I would have preferred not to hear from = you.

RD


thanks, 
maoke 

= --Apple-Mail-18-289602831-- From simon.perreault@viagenie.ca Wed Mar 28 03:48:32 2012 Return-Path: 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 D7E9D21F899D for ; Wed, 28 Mar 2012 03:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, 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 qXMe0Glp7Muz for ; Wed, 28 Mar 2012 03:48:32 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC7421F8997 for ; Wed, 28 Mar 2012 03:48:32 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 71FCE40054; Wed, 28 Mar 2012 06:48:31 -0400 (EDT) Message-ID: <4F72EC7D.7000904@viagenie.ca> Date: Wed, 28 Mar 2012 12:48:29 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> <8C8A2869-2261-4B90-A244-71FD2182B73A@employees.org> In-Reply-To: <8C8A2869-2261-4B90-A244-71FD2182B73A@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:48:33 -0000 On 03/28/12 12:43, Ole Trøan wrote: >>>> There's a reason NPTv6 and NAT64 chose checksum neutrality... >>> >>> NAT64?? >> >> Yup. RFC 6052 section 4. > > as in "We considered reserving 16 > bits in the suffix to guarantee checksum neutrality, but declined" No, as in: - The well-known prefix is intentionally checksum-neutral. - Network-specific prefixes can be chosen so that translation is checksum-neutral. (thus no need to do it in the suffix, as you quoted above) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fibrib@gmail.com Wed Mar 28 03:50:10 2012 Return-Path: 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 0459521F8A51 for ; Wed, 28 Mar 2012 03:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ACfS2u7Bskfl for ; Wed, 28 Mar 2012 03:50:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA3D21F8A4E for ; Wed, 28 Mar 2012 03:50:09 -0700 (PDT) Received: by qcsq13 with SMTP id q13so647679qcs.31 for ; Wed, 28 Mar 2012 03:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EwnNzPeeFAx2nsIuJfEpJhgJJiraQlvzw2UPQBsSt1Q=; b=kv+amDwh/r9Tl1wC+sAf2JWnAnXxvSLecXgFzznceCx/ralIeJbzrY1PmDUduLG8lW kh+ErcYFSqlJd625dBhBKa39uIg0JWi6GA7g6bdythPdHdQZHIzwR8goLnTe6S7xOeli MKuwyBAGIxZcfzCplYS3AGbbs/0UDURxhP30gXjGfx5YxcvGAYL0tB2Jq5Ie/i1uAIcf 7aH33QgdSlaIZvQJ3sqSeMssH8OIEl2LIW4Gw86iK4k20c7hdJSSM5SqpHOqkREJ8MX5 qIhDg2KaThXFFFw22dvk823mxLKZfOCthq+NmfyjFc4XWdznAbw5+Vv638+++7rKC5s/ C4YQ== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr37250607qab.11.1332931808749; Wed, 28 Mar 2012 03:50:08 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 03:50:08 -0700 (PDT) In-Reply-To: <4F72E93A.5080904@viagenie.ca> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> Date: Wed, 28 Mar 2012 10:50:08 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf3074b4b8f868c604bc4b5e70 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:50:10 -0000 --20cf3074b4b8f868c604bc4b5e70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Simon, 2012/3/28 Simon Perreault > On 03/28/12 12:28, Ole Tr=F8an wrote: > >> There's a reason NPTv6 and NAT64 chose checksum neutrality... >>> >> >> NAT64?? >> > > Yup. RFC 6052 section 4. do you mean the following paragraph: "In the case of stateful translation, checksum neutrality does not eliminate checksum computation during translation, as only one of the two addresses would be checksum neutral. We considered reserving 16 bits in the suffix to guarantee checksum neutrality, but declined because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff." good citation! and i would like to point out: 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful NAT64 is also required to use checksum-neutral address -- liberal to others 2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself 3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative to itself just my 2 cents. hope it helps. - maoke > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b4b8f868c604bc4b5e70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Simon,=A0

2012/3/28 Simon Perreault = <simon.= perreault@viagenie.ca>
On 03/28/12 12:28, Ole Tr=F8an wrote:
There's a reason NPTv6 and NAT64 chose checksum neutrality...

NAT64??

Yup. RFC 6052 section 4.

do you mean the fo= llowing paragraph:=A0

"In the case of statefu= l translation, checksum neutrality does not
eliminate checksum comput= ation during translation, as only one of the
two addresses would be checksum neutral. We considered reserving 16
= bits in the suffix to guarantee checksum neutrality, but declined
because it would not help with stateful translation and because
checksum neutrality can also be achieved by an appropriate choice of
= the Network-Specific Prefix, i.e., selecting a prefix whose one's=A0 complement checksum equals either 0 or 0xffff."

good citation! and i would like to point out:=A0
1. as= a stateless address mapping, RFC6052 doesn't assumes any stateful NAT6= 4 is also required to use checksum-neutral address -- liberal to others
2. as a operational option, RFC6052 considers having checksum-neutrali= ty through, e.g., choosing proper prefix if possible -- conservative to its= elf
3. comparing with RFC6145, the latter doesn't assume ther= e MUST be a checksum-neutral address but keep adjusting L4 checksum -- cons= ervative to itself=A0

just my 2 cents. hope it helps.=A0

=
- maoke
=A0


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b4b8f868c604bc4b5e70-- From simon.perreault@viagenie.ca Wed Mar 28 03:54:47 2012 Return-Path: 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 6AB4121F8985 for ; Wed, 28 Mar 2012 03:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 83B9t31QqWkC for ; Wed, 28 Mar 2012 03:54:46 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3B21F8966 for ; Wed, 28 Mar 2012 03:54:46 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D2B9540054; Wed, 28 Mar 2012 06:54:45 -0400 (EDT) Message-ID: <4F72EDF4.8050609@viagenie.ca> Date: Wed, 28 Mar 2012 12:54:44 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: Maoke References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:54:47 -0000 On 03/28/12 12:50, Maoke wrote: > Yup. RFC 6052 section 4. > > > do you mean the following paragraph: No. See my response to Ole. > 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful > NAT64 is also required to use checksum-neutral address -- liberal to others Not sure what you mean. Agree that checksum neutrality does not help stateful NAT64. I'm talking about stateless NAT64. > 2. as a operational option, RFC6052 considers having checksum-neutrality > through, e.g., choosing proper prefix if possible -- conservative to itself Yes. > 3. comparing with RFC6145, the latter doesn't assume there MUST be a > checksum-neutral address but keep adjusting L4 checksum -- conservative > to itself Yes. Checksum neutrality still rocks. ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fibrib@gmail.com Wed Mar 28 04:04:27 2012 Return-Path: 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 13C2421F8738 for ; Wed, 28 Mar 2012 04:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 c6hS9nTkXrs4 for ; Wed, 28 Mar 2012 04:04:25 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E452C21F8643 for ; Wed, 28 Mar 2012 04:04:24 -0700 (PDT) Received: by qcsq13 with SMTP id q13so655131qcs.31 for ; Wed, 28 Mar 2012 04:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s2+svlKPxZBQkshruX2g9WK73ZH6UOvPm+tPu/tW4ig=; b=dBbFwyUdEr1x1rOScF1gV+OP1FhgrCp/EpCdcE/zwlAco0Oi8RyU3eyef2XowzLAmF fWD/cwSuHaVYSHxGbZX02/OYr6E8q0UNqgFchl6XjI/haCLpPYIoMLa7BGZQzRP72lfC c+LsVAr8WXUN3MdfEETZecvacaDukYmJ+HEAp0fwGTH6Jn5UDClvVLSKblAmSD4G6x+a yMDbRUCfYyXd+oD5l2du9porkJKrNIOYuxH/QGCY+6FLaBLF0/bm9ZAdh7F9kSZyeyAI mZfV6ZmAozoYhdg1t93v5PVpI4FLK/7foA9dDce9ho0r8CRl3vAidn4SpNmON0YbnVrF TVYQ== MIME-Version: 1.0 Received: by 10.229.137.80 with SMTP id v16mr11333778qct.31.1332932664456; Wed, 28 Mar 2012 04:04:24 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Wed, 28 Mar 2012 04:04:24 -0700 (PDT) In-Reply-To: <4F72EDF4.8050609@viagenie.ca> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> <4F72EDF4.8050609@viagenie.ca> Date: Wed, 28 Mar 2012 11:04:24 +0000 Message-ID: From: Maoke To: Simon Perreault Content-Type: multipart/alternative; boundary=002354530090f975a904bc4b9169 Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:04:27 -0000 --002354530090f975a904bc4b9169 Content-Type: text/plain; charset=ISO-8859-1 2012/3/28 Simon Perreault > On 03/28/12 12:50, Maoke wrote: > >> Yup. RFC 6052 section 4. >> >> >> do you mean the following paragraph: >> > > No. See my response to Ole. > > > 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful >> NAT64 is also required to use checksum-neutral address -- liberal to >> others >> > > Not sure what you mean. Agree that checksum neutrality does not help > stateful NAT64. I'm talking about stateless NAT64. > > > 2. as a operational option, RFC6052 considers having checksum-neutrality >> through, e.g., choosing proper prefix if possible -- conservative to >> itself >> > > Yes. > > > 3. comparing with RFC6145, the latter doesn't assume there MUST be a >> checksum-neutral address but keep adjusting L4 checksum -- conservative >> to itself >> > > Yes. > > Checksum neutrality still rocks. ;) i am not against that checksum neutrality is useful but i don't think it it wise to write it into a standard, forcing others doing. on the other hand, even we write it in, we'd better not to have it as a reason for disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction. it is good to have a checksum-neutral address format, if situation allows, as a deployment option, rather than a mandatory element in standard. because it can only play the role of a complement in some cases. that's my point. hope it clarifies. ;-) - maoke > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --002354530090f975a904bc4b9169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/28 Simon Perreault <simon.perreault@viag= enie.ca>
On 03/28/12 12:50, Maoke wrote:
=A0 =A0Yup. RFC 6052 section 4.


do you mean the following paragraph:

No. See my response to Ole.


1. as a stateless address mapping, RFC6052 doesn't assumes any stateful=
NAT64 is also required to use checksum-neutral address -- liberal to others=

Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64.


2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself=

Yes.


3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative
to itself

Yes.

Checksum neutrality still rocks. ;)

i am no= t against that checksum neutrality is useful but i don't think it it wi= se to write it into a standard, forcing others doing. on the other hand, ev= en we write it in, we'd better not to have it as a reason for disabling= the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is= a wrong direction.=A0

it is good to have a checksum-neutral address format, i= f situation allows, as a deployment option, rather than a mandatory element= in standard. because it can only play the role of a complement in some cas= es. that's my point.=A0

hope it clarifies. ;-)

- maoke= =A0
=A0


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--002354530090f975a904bc4b9169-- From tetsuya@ipinfusion.com Wed Mar 28 04:21:29 2012 Return-Path: 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 8A1D721E80BC for ; Wed, 28 Mar 2012 04:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y6H9fgS88Php for ; Wed, 28 Mar 2012 04:21:27 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8C21E8019 for ; Wed, 28 Mar 2012 04:21:27 -0700 (PDT) Received: from mail73-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 11:21:26 +0000 Received: from mail73-va3 (localhost [127.0.0.1]) by mail73-va3-R.bigfish.com (Postfix) with ESMTP id 2821340031B; Wed, 28 Mar 2012 11:21:26 +0000 (UTC) X-SpamScore: -11 X-BigFish: PS-11(zzbb2dI1432N98dK4015Izz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail73-va3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=tetsuya@ipinfusion.com; helo=CH1PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail73-va3 (localhost.localdomain [127.0.0.1]) by mail73-va3 (MessageSwitch) id 1332933683700986_31094; Wed, 28 Mar 2012 11:21:23 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.238]) by mail73-va3.bigfish.com (Postfix) with ESMTP id 921EF160137; Wed, 28 Mar 2012 11:21:23 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 11:21:22 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.8.139]) by CH1PRD0510HT005.namprd05.prod.outlook.com ([10.255.150.40]) with mapi id 14.16.0135.002; Wed, 28 Mar 2012 11:21:22 +0000 From: Tetsuya Murakami To: Simon Perreault Thread-Topic: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 Thread-Index: AQHNDNTn1y5CRYYmgkeLsKJryXrvGw== Date: Wed, 28 Mar 2012 11:21:21 +0000 Message-ID: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <4F72CEDA.9040306@viagenie.ca> In-Reply-To: <4F72CEDA.9040306@viagenie.ca> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <33D09E060C780F4DB86EE572F95A5AF4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0510HT005.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0510HT005.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: "" Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:21:31 -0000 On 2012/03/28, at 1:42, Simon Perreault wrote: > On 03/28/12 00:42, Tetsuya Murakami wrote: >> Also, as I mentioned during the meeting, I double-checked the current >> implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 >> stack gives received IPv6 packet to 4rd-u module after processing it. >> But, according to the current implementation of IPv6 stack, IPv6 >> stack totally removes IPv6 fragment header when IPv6 stack finds IPv6 >> fragment header and processes it. >>=20 >> Since 4rd-u module gets the packet after IPv6 stack processes the >> packet, IPv6 fragment header is not present when 4rd-u module gets >> the packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 >> information. But all information embedded in IPv6 fragment header is >> disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, >> in order to keep/pass the information embedded in IPv6 fragment >> header to 4rd-u module, I think the existing IPv6 stack needs to be >> changed. >=20 > Depends how you implement it. I can think of at least one way to do it on= Linux without touching the IPv6 stack. (with NF hooks) Yes. It could be possible. But NAT44 requires a network device. If NAT44 is= also utilized, a 4rd-u module attached to IPv6 stack similar to a tunnel/p= seudo device is reasonable from the implementation point of view. Thanks, Tetsuya Murakami= From simon.perreault@viagenie.ca Wed Mar 28 04:50:00 2012 Return-Path: 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 7867921F8990 for ; Wed, 28 Mar 2012 04:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 YfqfsbXDg6OL for ; Wed, 28 Mar 2012 04:49:59 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C24E021F898A for ; Wed, 28 Mar 2012 04:49:59 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-159e.meeting.ietf.org [130.129.21.158]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EDC85400D8; Wed, 28 Mar 2012 07:49:58 -0400 (EDT) Message-ID: <4F72FAE4.9020500@viagenie.ca> Date: Wed, 28 Mar 2012 13:49:56 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: Tetsuya Murakami References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <4F72CEDA.9040306@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:50:00 -0000 On 03/28/12 13:21, Tetsuya Murakami wrote: >> Depends how you implement it. I can think of at least one way to do >> it on Linux without touching the IPv6 stack. (with NF hooks) > > Yes. It could be possible. But NAT44 requires a network device. If > NAT44 is also utilized, a 4rd-u module attached to IPv6 stack similar > to a tunnel/pseudo device is reasonable from the implementation point > of view. Yes of course. IPv6 to IPv4: - NF hook to receive IPv6 packets. - Translate IPv6 into IPv4. - Inject into v4 stack. IPv4 to IPv6: - Route(s) pointing to 4rd device. - Translate IPv4 into IPv6. - Inject into v6 stack. We did something very similar in our Linux NAT64 implementation, as part of the Ecdysis project. See URL in my signature for source code. That's just one possible way to implement 4rd-U on Linux. I'm sure there are others. And the vast majority of the code would be identical with a MAP or 4rd implementation since they all are so similar. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From despres.remi@laposte.net Wed Mar 28 05:10:59 2012 Return-Path: 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 1F4A521E8182 for ; Wed, 28 Mar 2012 05:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.162, 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 lUODPOgY6HaA for ; Wed, 28 Mar 2012 05:10:58 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD721E8097 for ; Wed, 28 Mar 2012 05:10:56 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8509-out with ME id r0At1i0045M8erm030AtTN; Wed, 28 Mar 2012 14:10:55 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21-294650297 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 14:10:52 +0200 Message-Id: <74CE24BE-205B-4B38-8B69-E8AC46FF2E24@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:10:59 -0000 --Apple-Mail-21-294650297 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On the subject of TTL semantics between adjacent nodes, here is what I = understand (so far): - Some protocols above IP, only applicable between adjacent nodes, can = be better protected if TTLs are set to 255 by sources. - This is important if there is no ingress filtering (a situation that = should be avoided in 4rd domains anyway, but let's accept it). Now, with the now specified TTL-presevation of 4rd-U, the IPv6 hop count = derived from an IPv4 TTL=3D255 is also 255, which is the desirable = value. If I missed something, please don't get crossed, your additional = explanations will be welcome. Regards, RD Le 2012-03-28 =E0 12:39, Maoke a =E9crit : >=20 >=20 > 2012/3/28 R=E9mi Despr=E9s >=20 > Le 2012-03-28 =E0 11:30, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/3/28 R=E9mi Despr=E9s >>=20 >> Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit : >>=20 >> > FYI, section 5 of RFC5082 = (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique = that TTL is used to help tunnel packets security. Anyway, >> > >> > On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote: >> > >> >> >> >> Le 2012-03-27 =E0 13:12, Maoke a =E9crit : >> >>> 2012/3/27 R=E9mi Despr=E9s >> >>> With TTL transparency added, I don't see what would be missing, = even with all requirements you expressed. >> >>> >> >>> well, it is still uncertain how 4rd-u will do this. it is = uncertain if the new ad hoc complement doesn't introduce new problems. = could we see it by the end of IETF83? >> >> >> >> Sure. >> >> basic ID: >> >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop = count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put = 127 in bits 1-7 of the hop count. >> >> - A exit, take bit 0 from the hop count, and bits 1-7 from the = packet ID. >> >> >> > >> > Too much. Don't change deeply well understand/deployed semantics, = PLEASE. >>=20 >> Semantics isn't changed for any existing function. >> CEs and BRs (the only ones to be concerned) use unused bits to convey = some IPv4 bits that need to be conveyed for e2e transparency. >>=20 >> unfortunately the first bit of Hop Limit is NOT "unused" at all. = please also pay attention the reference that others suggested. >=20 > Would you be kind enough to give again the reference of the document = you are referring to? > I will look at it. >=20 > thank you, Remi, and here you are.=20 >=20 > what Satoru pointed out is:=20 > > FYI, section 5 of RFC5082 = (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique = that TTL is used to help tunnel packets security. >=20 > and i'd like also suggest Cisco IOS and Juniper JUNOS documents about = security issues regarding ttl or hop limit. sorry but it is hard to = specify a very specific page because we need to pay attention to = understand the whole problem. but it is not hard to google them out. = (RFC2080 also covers the similar issue regarding RIPng, though multicast = over the hop is involved, which might be not in the current scope of MAP = while might be in the near future).=20 >=20 > thanks again for your attention.=20 >=20 > - maoke > =20 > Thanks. >=20 > RD --Apple-Mail-21-294650297 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/28 R=E9mi = Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-03-28 =E0 = 11:30, Maoke a =E9crit :



2012/3/28 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-03-28 =E0 06:10, Satoru Matsushima a =E9crit :

> FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) = generalize a technique that TTL is used to help tunnel packets security. = Anyway,
>
> On 2012/03/27, at 14:02, R=E9mi Despr=E9s wrote:
>
>>
>> Le 2012-03-27 =E0 13:12, Maoke a =E9crit :
>>> 2012/3/27 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>> With TTL transparency added, I don't see what would be = missing, even with all requirements you expressed.
>>>
>>> well, it is still uncertain how 4rd-u will do this. it is = uncertain if the new ad hoc complement doesn't introduce new problems. = could we see it by the end of IETF83?
>>
>> Sure.
>> basic ID:
>> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 = hop count, and bits 1-7 in the remaining space of the IPv6 packet ID. = Put 127 in bits 1-7 of the hop count.
>> - A exit, take bit 0 from the hop count, and bits 1-7 from the = packet ID.
>>
>
> Too much. Don't change deeply well understand/deployed semantics, = PLEASE.

Semantics isn't changed for any existing function.
CEs and BRs (the only ones to be concerned) use unused bits to convey = some IPv4 bits that need to be conveyed for e2e = transparency.

unfortunately the = first bit of Hop Limit is NOT "unused" at all. please also pay attention = the reference that others suggested.

Would you be kind enough to give = again the reference of the document you are referring to?
I = will look at it.

thank you, = Remi, and here you are. 

what Satoru pointed out is: 
> = FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) = generalize a technique that TTL is used to help tunnel packets = security.

and i'd like also suggest Cisco IOS and Juniper = JUNOS documents about security issues regarding ttl or hop limit. sorry = but it is hard to specify a very specific page because we need to pay = attention to understand the whole problem. but it is not hard to google = them out. (RFC2080 also covers the similar issue regarding RIPng, though = multicast over the hop is involved, which might be not in the current = scope of MAP while might be in the near future). 

thanks again for your = attention. 

- = maoke
 
Thanks.

RD

= --Apple-Mail-21-294650297-- From despres.remi@laposte.net Wed Mar 28 05:19:59 2012 Return-Path: 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 6190121E8196 for ; Wed, 28 Mar 2012 05:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.158, 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 0V3mflKmPTof for ; Wed, 28 Mar 2012 05:19:58 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id C5CEF21E817F for ; Wed, 28 Mar 2012 05:19:57 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8506-out with ME id r0Ku1i0025M8erm030KuqU; Wed, 28 Mar 2012 14:19:56 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-22-295192486 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 14:19:54 +0200 Message-Id: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:19:59 -0000 --Apple-Mail-22-295192486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-28 =E0 12:20, Maoke a =E9crit : >=20 >=20 > 2012/3/28 Simon Perreault > On 03/28/12 10:48, Satoru Matsushima wrote: > On the contrary, there is a big difference. The difference is that you = are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, = etc, etc, etc. You need a lot of code to handle all existing transport = protocols, and you still can't handle future protocols that people might = develop. >=20 > Checksum neutrality is a *big* advantage. >=20 > Cool. How many protocols we should support for just a *transition* = mechanism? >=20 > The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used = for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time. >=20 > So you have two options: >=20 > a) checksum neutrality > - no code specific to each transport prototol >=20 > FYI. Remi has clarified: no code specific to transport protocol having = destination port position and pseudo-header as same as TCP has. but = other protocols are exceptions, needing specific codes. exceptions = include at least: 1. ICMP; 2. RDP.=20 The problem with RDP exists only for shared-address CEs. For this, the specification doesn't propose to do anything (RDP isn't = more supported for shared-address CEs in U than in T or E). > =20 > - supports all current and future transport protocols >=20 > again, supports current and future transport protocols, which follows = TCP layout and TCP checksum's pseudo-header definition.=20 > =20 > b) checksum non-neutrality > - additional code necessary for each transport protocol > - limited set of supported transport protocols >=20 > see above, CNP is also a limited improvement.=20 > =20 >=20 > Less code, more transport protocols. I think the choice is easy. >=20 > There's a reason NPTv6 and NAT64 chose checksum neutrality... >=20 > to me, we'd better never forget Jon Postel's law for the Internet = robustness, which is written in RFC793: "be conservative in what you do, = be liberal in what you accept from others." Never forgotten. Actually already applied well before stated by Jon (that was in the = seventies... the old X.25 times !) > a better world could be achieved by having the L4-checksum adjustment = as mandatory while, when possible, having the CNP as an operational = complement. as implementor, we are conservative to consider some = operation circumstances may not have CNP instead of requiring all = operators MUST doing so; as operator, we are also conservative to = consider some protocols may not have been fully supported by the = translators, and we attach the CNP in our address formation in order to = survive those protocol as better as we can.=20 >=20 > requiring others offering anything into our standard is really an easy = life. but it is, a sort of, selfish.=20 The proposal is not to add CNP in E, only to have U instead of E+T (or = just T or just E). RD >=20 > thanks, > maoke > =20 >=20 >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-22-295192486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/3/28 Simon Perreault <simon.perreault@viagenie.ca>
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you = are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, = etc, etc, etc. You need a lot of code to handle all existing transport = protocols, and you still can't handle future protocols that people might = develop.

Checksum neutrality is a *big* advantage.

Cool. How many protocols we should support for just a *transition* = mechanism?

The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for = a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time.

So you have two options:

a) checksum neutrality
  - no code specific to each transport = prototol

FYI. Remi has clarified: no = code specific to transport protocol having destination port position and = pseudo-header as same as TCP has. but other protocols are exceptions, = needing specific codes. exceptions include at least: 1. ICMP; 2. = RDP. 


 
  - supports all current and future transport = protocols

again, supports current = and future transport protocols, which follows TCP layout and TCP = checksum's pseudo-header definition. 
 
b) checksum non-neutrality
  - additional code necessary for each transport protocol
  - limited set of supported transport = protocols

see above, CNP is also a = limited improvement. 
 

Less code, more transport protocols. I think the choice is easy.

There's a reason NPTv6 and NAT64 chose checksum = neutrality...

to me, we'd better never = forget Jon Postel's law for the Internet robustness, which is written in = RFC793: "be conservative in what you do, be liberal in what you accept = from others."

Never = forgotten.
Actually already applied well before stated by Jon = (that was in the seventies... the old X.25 times = !)

a better world could be achieved by having = the L4-checksum adjustment as mandatory while, when possible, having the = CNP as an operational complement. as implementor, we are conservative to = consider some operation circumstances may not have CNP instead of = requiring all operators MUST doing so; as operator, we are also = conservative to consider some protocols may not have been fully = supported by the translators, and we attach the CNP in our address = formation in order to survive those protocol as better as we = can. 

requiring others offering anything into our standard = is really an easy life. but it is, a sort of, = selfish. 

The proposal is = not to add CNP in E, only to have U instead of E+T (or just T or just = E).

RD



thanks,
maoke
 


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> = http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-22-295192486-- From james.huang@huawei.com Wed Mar 28 05:29:44 2012 Return-Path: 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 2E2F921E8197 for ; Wed, 28 Mar 2012 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 tjrVVqUKhmhK for ; Wed, 28 Mar 2012 05:29:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 25F4C21E81C1 for ; Wed, 28 Mar 2012 05:29:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEL47794; Wed, 28 Mar 2012 08:29:42 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 05:27:11 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 05:27:07 -0700 Received: from SZXEML522-MBS.china.huawei.com ([fe80::d63:ad74:b260:1928]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 20:27:00 +0800 From: Huangjing To: Maoke , Simon Perreault Thread-Topic: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 Thread-Index: AQHNC4JkfHS4ColpKUy1tFwYt3tWKZZ+OMWAgAA/5oCAAFFNAIAAFuYAgAAA+wCAAAP7gIAAGBkAgAABrQCAAARZAIAAAUkAgAACtACAAJycqQ== Date: Wed, 28 Mar 2012 12:26:59 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC1CDC9751@szxeml522-mbs.china.huawei.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> <4F72EDF4.8050609@viagenie.ca>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9751szxeml522mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:29:44 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9751szxeml522mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "i am not against that checksum neutrality is useful but i don't think it i= t wise to write it into a standard ".. Checksum neutral is also recommended in http://tools.ietf.org/html/rfc6296= #page-10 ________________________________ From: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on behalf of = Maoke [fibrib@gmail.com] Sent: Wednesday, March 28, 2012 19:04 To: Simon Perreault Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 2012/3/28 Simon Perreault > On 03/28/12 12:50, Maoke wrote: Yup. RFC 6052 section 4. do you mean the following paragraph: No. See my response to Ole. 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful NAT64 is also required to use checksum-neutral address -- liberal to others Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64. 2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself Yes. 3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative to itself Yes. Checksum neutrality still rocks. ;) i am not against that checksum neutrality is useful but i don't think it it= wise to write it into a standard, forcing others doing. on the other hand,= even we write it in, we'd better not to have it as a reason for disabling = the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is = a wrong direction. it is good to have a checksum-neutral address format, if situation allows, = as a deployment option, rather than a mandatory element in standard. becaus= e it can only play the role of a complement in some cases. that's my point. hope it clarifies. ;-) - maoke Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca --_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9751szxeml522mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
&q= uot;i am not against that checksum neutrality is useful but i don't think i= t it wise to write it into a standard "..

Checksum neutral is also recommended in  http://tools.ietf.org/html/rfc6296#page-10 


From: softwires-bounces@ietf.org [softwi= res-bounces@ietf.org] on behalf of Maoke [fibrib@gmail.com]
Sent: Wednesday, March 28, 2012 19:04
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room= 204



2012/3/28 Simon Perreault <= simon.perr= eault@viagenie.ca>
On 03/28/12 12:50, Maoke wrote:
   Yup. RFC 6052 section 4.


do you mean the following paragraph:

No. See my response to Ole.


1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use checksum-neutral address -- liberal to others=

Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64.


2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself=

Yes.


3. comparing with RFC6145, the latter doesn't assume there MUST be a
checksum-neutral address but keep adjusting L4 checksum -- conservative
to itself

Yes.

Checksum neutrality still rocks. ;)

i am not against that checksum neutrality is useful but i don't think = it it wise to write it into a standard, forcing others doing. on the other = hand, even we write it in, we'd better not to have it as a reason for disab= ling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction. 

it is good to have a checksum-neutral address format, if situation all= ows, as a deployment option, rather than a mandatory element in standard. b= ecause it can only play the role of a complement in some cases. that's my p= oint. 

hope it clarifies. ;-)

- maoke 
 


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

--_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9751szxeml522mbschi_-- From despres.remi@laposte.net Wed Mar 28 10:56:57 2012 Return-Path: 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 9922221E816E for ; Wed, 28 Mar 2012 10:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 XguRJuju19v6 for ; Wed, 28 Mar 2012 10:56:56 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72221E816A for ; Wed, 28 Mar 2012 10:56:54 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id E9A1F940008; Wed, 28 Mar 2012 19:56:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 19:56:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:56:57 -0000 Le 2012-03-28 =E0 11:17, Satoru Matsushima a =E9crit : > I remember that what Remi said during the meeting, is that 4rd-u is a = brand-new transport protocol I doubt I said "brand new transport protocol": - 4rd-U builds on a lot of previous work - it isn't a transport-layer protocol.=20 However, I did say and now confirm that, unlike -T, it doesn't use = RFC6145.=20 Consequently, RFC6145 doesn't need to be modified for U to be deployed. RD > which doesn't need to follow rfc6145 translation spec. > If it is true, 4rd-u doesn't need to take care checksum consistency of = any kind of L4 protocols. > On the other word, 4rd-u can support transparency of original packet = so not only the CNP, but also checksum recalculation are not required. >=20 > cheers, > --satoru >=20 >=20 > On 2012/03/28, at 11:02, Simon Perreault wrote: >=20 >> On 03/28/12 10:48, Satoru Matsushima wrote: >>>> On the contrary, there is a big difference. The difference is that = you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, = DCCP, etc, etc, etc. You need a lot of code to handle all existing = transport protocols, and you still can't handle future protocols that = people might develop. >>>>=20 >>>> Checksum neutrality is a *big* advantage. >>>=20 >>> Cool. How many protocols we should support for just a *transition* = mechanism? >>=20 >> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used = for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time. >>=20 >> So you have two options: >>=20 >> a) checksum neutrality >> - no code specific to each transport prototol >> - supports all current and future transport protocols >> b) checksum non-neutrality >> - additional code necessary for each transport protocol >> - limited set of supported transport protocols >>=20 >> Less code, more transport protocols. I think the choice is easy. >>=20 >> There's a reason NPTv6 and NAT64 chose checksum neutrality... >>=20 >> Simon >> --=20 >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Mar 28 10:58:31 2012 Return-Path: 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 AAC5E21E80A4 for ; Wed, 28 Mar 2012 10:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 8E+ajN1cviFK for ; Wed, 28 Mar 2012 10:58:31 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 33B5021E809F for ; Wed, 28 Mar 2012 10:58:29 -0700 (PDT) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0F13C822E1; Wed, 28 Mar 2012 19:58:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 28 Mar 2012 19:56:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:58:31 -0000 Le 2012-03-28 =E0 11:17, Satoru Matsushima a =E9crit : > I remember that what Remi said during the meeting, is that 4rd-u is a = brand-new transport protocol I doubt I said "brand new transport protocol": - 4rd-U builds on a lot of previous work - it isn't a transport-layer protocol.=20 However, I did say and now confirm that, unlike -T, it doesn't use = RFC6145.=20 Consequently, RFC6145 doesn't need to be modified for U to be deployed. RD > which doesn't need to follow rfc6145 translation spec. > If it is true, 4rd-u doesn't need to take care checksum consistency of = any kind of L4 protocols. > On the other word, 4rd-u can support transparency of original packet = so not only the CNP, but also checksum recalculation are not required. >=20 > cheers, > --satoru >=20 >=20 > On 2012/03/28, at 11:02, Simon Perreault wrote: >=20 >> On 03/28/12 10:48, Satoru Matsushima wrote: >>>> On the contrary, there is a big difference. The difference is that = you are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, = DCCP, etc, etc, etc. You need a lot of code to handle all existing = transport protocols, and you still can't handle future protocols that = people might develop. >>>>=20 >>>> Checksum neutrality is a *big* advantage. >>>=20 >>> Cool. How many protocols we should support for just a *transition* = mechanism? >>=20 >> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used = for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to = keep providing clients with residual IPv4 for a potentially = loooooooooooong time. So we need to be really careful to get this right, = because we'll be stuck with what we design for a long time. >>=20 >> So you have two options: >>=20 >> a) checksum neutrality >> - no code specific to each transport prototol >> - supports all current and future transport protocols >> b) checksum non-neutrality >> - additional code necessary for each transport protocol >> - limited set of supported transport protocols >>=20 >> Less code, more transport protocols. I think the choice is easy. >>=20 >> There's a reason NPTv6 and NAT64 chose checksum neutrality... >>=20 >> Simon >> --=20 >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Wed Mar 28 10:59:02 2012 Return-Path: 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 E9B8621E81AD; Wed, 28 Mar 2012 10:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 V-BxufKspaZ5; Wed, 28 Mar 2012 10:59:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9721E8191; Wed, 28 Mar 2012 10:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120328175901.20220.24268.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 10:59:01 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:59:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Option for IPv4-Embedded Multicast and Unicast IP= v6 Prefixes Author(s) : Mohamed Boucadair Jacni Qin Tina Tsou Xiaohong Deng Filename : draft-ietf-softwire-multicast-prefix-option-00.txt Pages : 8 Date : 2012-03-28 This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4- embedded IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-multicast-prefix-op= tion-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-multicast-prefix-opt= ion-00.txt From cuiyong@tsinghua.edu.cn Wed Mar 28 11:25:49 2012 Return-Path: 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 2D4B321E8040 for ; Wed, 28 Mar 2012 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.196 X-Spam-Level: * X-Spam-Status: No, score=1.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, MANGLED_TOOL=2.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 RipmCjwTHdv0 for ; Wed, 28 Mar 2012 11:25:48 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3FF21E8029 for ; Wed, 28 Mar 2012 11:25:48 -0700 (PDT) Received: from [80.13.203.67] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SCxZ2-00088P-8Q for softwires@ietf.org; Thu, 29 Mar 2012 02:25:45 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 29 Mar 2012 02:25:39 +0800 From: Yong Cui To: Message-ID: Thread-Topic: Slides for Friday Softwire session Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: [Softwires] Slides for Friday Softwire session X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:25:49 -0000 Folks, According to your agenda, we haven't received the followings slides. Please send your slides to Alain and me asap. http://www.ietf.org/proceedings/83/agenda/agenda-83-softwire.htm 3 Tetsuya Murakami / Ole Troan (Map team) MAP Encapsulation (MAP-E) =AD specification http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation/ 4 R=E9mi Despr=E9s IPv4 Residual Deployment via IPv6 - Unified Solution (4rd) http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u/ Feature Analysis Tool for stateless IPv4/IPv6 (MAP-T, MAP-E, 4rd) http://datatracker.ietf.org/doc/draft-despres-softwire-stateless-analysis-t ool/ 6 Xiaohong Deng Multicast Extensions to DS-Lite Technique in Broadband Deployments http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ 7 Xiaohong Deng DHCPv6 Options for IPv6 DS-Lite Multicast Prefix http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option/ 9 Behcet Sarikaya Multicast Support for 6rd http://datatracker.ietf.org/doc/draft-sarikaya-softwire-6rdmulticast/ Thanks for cooperation, Yong & Alain From fibrib@gmail.com Thu Mar 29 02:33:16 2012 Return-Path: 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 D880721F88FA for ; Thu, 29 Mar 2012 02:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 uoRZSESQAbHn for ; Thu, 29 Mar 2012 02:33:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 228DF21F874F for ; Thu, 29 Mar 2012 02:33:16 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1430024qcs.31 for ; Thu, 29 Mar 2012 02:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IlbDAb+YWfhZVuvqo+erSDezToGh6GbWl9WEbR/cPRI=; b=zQeM72Hf+WyuTaq4bewFhGX4wUYKaAlaHPvM4lb1mnVRgSz4Ww3f3lUqIqcrL5LyLc NLKYh9JvBMiCJU2rgpyeDc5lZUyHqG1vL+n5Zpmzmwsa+6DfUgWKsgXi4RctSQDv62g0 8EvGfQ4y/MJRvm7KfU9XIHliYzUU14g6LYD2KPvYx4UilrgdxzLTHLgdc3hDvaRQE35f ikXxuSCWKrennd6Gy0dwraBU0EH7LUrMp4ZlBwWhtecLxgaC7be7VboLwpesGc05k7QZ 3he346B/mSwODk9EfYW7PSTjxxlW+cGj7iGTvEjNDPzsu33P1189+QmsLXuh6kQ6GttG fOzA== MIME-Version: 1.0 Received: by 10.224.102.8 with SMTP id e8mr42234090qao.50.1333013595642; Thu, 29 Mar 2012 02:33:15 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Thu, 29 Mar 2012 02:33:15 -0700 (PDT) In-Reply-To: <74CE24BE-205B-4B38-8B69-E8AC46FF2E24@laposte.net> References: <3B92F90E-50BC-4D78-B3AB-B4F7179B339B@laposte.net> <8D4CE035-F36D-44E6-8EC7-4CD40FA41542@laposte.net> <74CE24BE-205B-4B38-8B69-E8AC46FF2E24@laposte.net> Date: Thu, 29 Mar 2012 09:33:15 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074b0d8d95bee04bc5e69d7 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] 4rd-u behavior in dynamic routing X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:33:17 -0000 --20cf3074b0d8d95bee04bc5e69d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/3/28 R=E9mi Despr=E9s > On the subject of TTL semantics between adjacent nodes, here is what I > understand (so far): > - Some protocols above IP, only applicable between adjacent nodes, can be > better protected if TTLs are set to 255 by sources. > - This is important if there is no ingress filtering (a situation that > should be avoided in 4rd domains anyway, but let's accept it). > > Now, with the now specified TTL-presevation of 4rd-U, the IPv6 hop count > derived from an IPv4 TTL=3D255 is also 255, which is the desirable value. > with your newly proposed solution, yes, IPv4 TTL is fine. but on the other hand, the IPv6 also needs TTL(HopLimit)=3D255 to protect something. we have to concern if 4rd-u possibly introduces some new measures for the attackers breaking such kind of protection mechanism, as putting the first bit of IPv4 TTL into IPv6 HopLimit CHANGES the semantics of IPv6's HopLimit! regards, maoke > > If I missed something, please don't get crossed, your additional > explanations will be welcome. > > Regards, > RD > > --20cf3074b0d8d95bee04bc5e69d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi,

2012/3/28 R=E9mi Despr=E9s <despres.remi= @laposte.net>
On the subject of TTL semantics be= tween adjacent nodes, here is what I understand (so far):
- Some = protocols above IP, only applicable between adjacent nodes, can be better p= rotected if TTLs are set to 255 by sources.
- This is important if there is no ingress filtering (a situation that= should be avoided in 4rd domains anyway, but let's accept it).

Now, with the now specified TTL-presevation of 4rd-U, the= IPv6=A0hop count derived from=A0an IPv4 TTL=3D255 is also 255, which is th= e desirable value.

with your newly proposed solution, y= es, IPv4 TTL is fine. but on the other hand, the IPv6 also needs TTL(HopLim= it)=3D255 to protect something. we have to concern if 4rd-u possibly introd= uces some new measures for the attackers breaking such kind of protection m= echanism, as putting the first bit of IPv4 TTL into IPv6 HopLimit CHANGES t= he semantics of IPv6's HopLimit!

regards,
maoke
=A0

If I missed something, please don't get crossed, your additional expla= nations will be welcome.

Regards,
RD


--20cf3074b0d8d95bee04bc5e69d7-- From james.huang@huawei.com Thu Mar 29 04:22:44 2012 Return-Path: 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 D645821F8527 for ; Thu, 29 Mar 2012 04:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GCd6oMpni1gj for ; Thu, 29 Mar 2012 04:22:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9247121F880C for ; Thu, 29 Mar 2012 04:22:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM22180; Thu, 29 Mar 2012 07:22:40 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:20:02 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:19:52 -0700 Received: from SZXEML522-MBS.china.huawei.com ([fe80::d63:ad74:b260:1928]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 19:19:46 +0800 From: Huangjing To: Maoke , Simon Perreault Thread-Topic: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 Thread-Index: AQHNC4JkfHS4ColpKUy1tFwYt3tWKZZ+OMWAgAA/5oCAAFFNAIAAFuYAgAAA+wCAAAP7gIAAGBkAgAABrQCAAARZAIAAAUkAgAACtACAAhvYeg== Date: Thu, 29 Mar 2012 11:19:45 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0@szxeml522-mbs.china.huawei.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> <4F72EDF4.8050609@viagenie.ca>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0szxeml522mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:22:44 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0szxeml522mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable just to clarify, maybe my point is not clear in the previous reply. you said " i don't think it it wise to write it into a standard", but as i = know, checksum neutral is also recommended in http://tools.ietf.org/html/r= fc6296#page-10, it is a useful technology which can be put into a standard ________________________________ From: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on behalf of = Maoke [fibrib@gmail.com] Sent: Wednesday, March 28, 2012 19:04 To: Simon Perreault Cc: softwires@ietf.org Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 2012/3/28 Simon Perreault > On 03/28/12 12:50, Maoke wrote: Yup. RFC 6052 section 4. do you mean the following paragraph: No. See my response to Ole. 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful NAT64 is also required to use checksum-neutral address -- liberal to others Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64. 2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself Yes. 3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative to itself Yes. Checksum neutrality still rocks. ;) i am not against that checksum neutrality is useful but i don't think it it= wise to write it into a standard, forcing others doing. on the other hand,= even we write it in, we'd better not to have it as a reason for disabling = the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is = a wrong direction. it is good to have a checksum-neutral address format, if situation allows, = as a deployment option, rather than a mandatory element in standard. becaus= e it can only play the role of a complement in some cases. that's my point. hope it clarifies. ;-) - maoke Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca --_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0szxeml522mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
just to clarify, maybe my point is not clear in the previous reply.

you said " i don't think it it wise to write it into a standard", = but as i know, checksum neutral is also recommended in  http://tools.ietf.org/html/rfc6296#page-10,
it is a useful technology which can be put into a standard


From: softwires-bounces@ietf.org [softwi= res-bounces@ietf.org] on behalf of Maoke [fibrib@gmail.com]
Sent: Wednesday, March 28, 2012 19:04
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room= 204



2012/3/28 Simon Perreault <= simon.perr= eault@viagenie.ca>
On 03/28/12 12:50, Maoke wrote:
   Yup. RFC 6052 section 4.


do you mean the following paragraph:

No. See my response to Ole.


1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use checksum-neutral address -- liberal to others=

Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64.


2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself=

Yes.


3. comparing with RFC6145, the latter doesn't assume there MUST be a
checksum-neutral address but keep adjusting L4 checksum -- conservative
to itself

Yes.

Checksum neutrality still rocks. ;)

i am not against that checksum neutrality is useful but i don't think = it it wise to write it into a standard, forcing others doing. on the other = hand, even we write it in, we'd better not to have it as a reason for disab= ling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction. 

it is good to have a checksum-neutral address format, if situation all= ows, as a deployment option, rather than a mandatory element in standard. b= ecause it can only play the role of a complement in some cases. that's my p= oint. 

hope it clarifies. ;-)

- maoke 
 


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

--_000_774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0szxeml522mbschi_-- From fibrib@gmail.com Thu Mar 29 05:38:51 2012 Return-Path: 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 11B6E21F8A8B for ; Thu, 29 Mar 2012 05:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 ZuWkU83kDinA for ; Thu, 29 Mar 2012 05:38:50 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9716E21F8A93 for ; Thu, 29 Mar 2012 05:38:49 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1535024qcs.31 for ; Thu, 29 Mar 2012 05:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KfLIScL+Ee8HU6/hFFlpGMpviOdJcYuVhYVCHBe/FIE=; b=Iv6m7KevtOhatM5WjZ4dFz8PylGcjpavgQDeIjgwYVsZnn/h62F4BJjJOi0zRojFUe hnLBoELX973rga2nxO3MudesaUj94l3OSemhtUPhJa9HyylXEmcs2EQqtNfcuD8vZP4p hmv/k6vQ8zEKBNj7vkrFb/FknJIzwYK2De9GxRTederTV9ClTm250JUeda0b3P/pudxY cIeXUHCkmYK+m1ApyMnvntBeVhcHv0OJI55lxdUJ8Iu9tndo4LODI576/u+PB5Q6Q2q0 hTWzJvU4BoZUP+azUHVSCutakI4a8T2+vNoPAHzJo5jPTZhSGMyeJOpjNqXNR/wyW1ut nDOg== MIME-Version: 1.0 Received: by 10.224.102.8 with SMTP id e8mr42958260qao.50.1333024729122; Thu, 29 Mar 2012 05:38:49 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Thu, 29 Mar 2012 05:38:49 -0700 (PDT) In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0@szxeml522-mbs.china.huawei.com> References: <919245F0-02B5-48BC-A763-095397F45E0C@laposte.net> <3FA25CEE-C287-46B9-99F5-6A3D727BFBF7@ipinfusion.com> <1F475C28-C7E9-4A44-BC48-443DF6678E8C@gmail.com> <475B220E-01CB-4055-8FEF-392A0EACEE37@ipinfusion.com> <4F72CF72.7080500@viagenie.ca> <3346943C-F2AD-4A0E-8D10-58F23992AF6C@gmail.com> <4F72D39B.9080506@viagenie.ca> <4DEB4C23-1377-43A2-A2D5-063FA0D5FFBD@employees.org> <4F72E93A.5080904@viagenie.ca> <4F72EDF4.8050609@viagenie.ca> <774B240D54DAB844B37EE80C2DD8E8BC1CDC9AA0@szxeml522-mbs.china.huawei.com> Date: Thu, 29 Mar 2012 12:38:49 +0000 Message-ID: From: Maoke To: Huangjing Content-Type: multipart/alternative; boundary=20cf3074b0d874c89904bc6101ba Cc: "softwires@ietf.org" Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:38:51 -0000 --20cf3074b0d874c89904bc6101ba Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA3=D4=C229=C8=D5=D0=C7=C6=DA=CB=C4=A3=ACHuangjing =D0=B4=B5= =C0=A3=BA > just to clarify, maybe my point is not clear in the previous reply. > > you said " i don't think it it wise to write it into a standard", but as > i know, checksum neutral is also recommended in > http://tools.ietf.org/html/rfc6296#page-10, > it is a useful technology which can be put into a standard > well, i should clarify i meant "...into a standard of the MAP scope." NAPT is fine to use whatever address without need to consider much about operation nor other devices, but MAP involves device interoperation and operation. it'd better the standard is made conservative. - M > > > ------------------------------ > *From:* softwires-bounces@ietf.org 'softwires-bounces@ietf.org');> [softwires-bounces@ietf.org] > on behalf of Maoke [fibrib@gmail.com 'fibrib@gmail.com');>] > *Sent:* Wednesday, March 28, 2012 19:04 > *To:* Simon Perreault > *Cc:* softwires@ietf.org 'softwires@ietf.org');> > *Subject:* Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 20= 4 > > > > 2012/3/28 Simon Perreault 'cvml', 'simon.perreault@viagenie.ca');>> > >> On 03/28/12 12:50, Maoke wrote: >> >>> Yup. RFC 6052 section 4. >>> >>> >>> do you mean the following paragraph: >>> >> >> No. See my response to Ole. >> >> >> 1. as a stateless address mapping, RFC6052 doesn't assumes any stateful >>> NAT64 is also required to use checksum-neutral address -- liberal to >>> others >>> >> >> Not sure what you mean. Agree that checksum neutrality does not help >> stateful NAT64. I'm talking about stateless NAT64. >> >> >> 2. as a operational option, RFC6052 considers having checksum-neutralit= y >>> through, e.g., choosing proper prefix if possible -- conservative to >>> itself >>> >> >> Yes. >> >> >> 3. comparing with RFC6145, the latter doesn't assume there MUST be a >>> checksum-neutral address but keep adjusting L4 checksum -- conservative >>> to itself >>> >> >> Yes. >> >> Checksum neutrality still rocks. ;) > > > i am not against that checksum neutrality is useful but i don't think it > it wise to write it into a standard, forcing others doing. on the other > hand, even we write it in, we'd better not to have it as a reason for > disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum > adjustment is a wrong direction. > > it is good to have a checksum-neutral address format, if situation > allows, as a deployment option, rather than a mandatory element in > standard. because it can only play the role of a complement in some cases= . > that's my point. > > hope it clarifies. ;-) > > - maoke > > >> >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> > > --20cf3074b0d874c89904bc6101ba Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=D4=DA 2012=C4=EA3=D4=C229=C8=D5=D0=C7=C6=DA=CB=C4=A3=ACHuangjing = =D0=B4=B5=C0=A3=BA
just to clarify, maybe my point is not clear in the previous reply.

you said " i don't think it it wise to write it into a standa= rd", but as i know, checksum neutral is also recommended in  http://tools.ietf.org/html/rfc6296#page-10,
it is a useful technology which can be put into a standard
=

well, i should clarify i meant "= ;...into a standard of the MAP scope." NAPT is fine to use whatever ad= dress without need to consider much about operation nor other devices, but = MAP involves device interoperation and operation. it'd better the stand= ard is made conservative. - M
 


Fro= m: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on behalf of Maoke [fibrib@gmail.com]
Sent: Wednesday, March 28, 2012 19:04
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room= 204



2012/3/28 Simon Perreault <= simon.perreault@viagenie.ca>
On 03/28/12 12:50, Maoke wrote:
   Yup. RFC 6052 section 4.


do you mean the following paragraph:

No. See my response to Ole.


1. as a stateless address mapping, RFC6052 doesn't assumes any stateful=
NAT64 is also required to use checksum-neutral address -- liberal to others=

Not sure what you mean. Agree that checksum neutrality does not help statef= ul NAT64. I'm talking about stateless NAT64.


2. as a operational option, RFC6052 considers having checksum-neutrality through, e.g., choosing proper prefix if possible -- conservative to itself=

Yes.


3. comparing with RFC6145, the latter doesn't assume there MUST be a checksum-neutral address but keep adjusting L4 checksum -- conservative
to itself

Yes.

Checksum neutrality still rocks. ;)

i am not against that checksum neutrality is useful but i don't th= ink it it wise to write it into a standard, forcing others doing. on the ot= her hand, even we write it in, we'd better not to have it as a reason f= or disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction. 

it is good to have a checksum-neutral address format, if situation all= ows, as a deployment option, rather than a mandatory element in standard. b= ecause it can only play the role of a complement in some cases. that's = my point. 

hope it clarifies. ;-)

- maoke 
 


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

--20cf3074b0d874c89904bc6101ba-- From mohamed.boucadair@orange.com Thu Mar 29 05:45:46 2012 Return-Path: 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 0A36821F8B03; Thu, 29 Mar 2012 05:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 8YBMy51ER6Zm; Thu, 29 Mar 2012 05:45:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 527EB21F8A6A; Thu, 29 Mar 2012 05:45:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B0E25264380; Thu, 29 Mar 2012 14:45:44 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9161527C071; Thu, 29 Mar 2012 14:45:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 29 Mar 2012 14:45:44 +0200 From: To: "mboned@ietf.org" Date: Thu, 29 Mar 2012 14:45:42 +0200 Thread-Topic: draft-ietf-softwire-multicast-prefix-option: review request Thread-Index: Ac0NqdpRImBnZmPkSG2pZpsiR9e/eQ== Message-ID: <94C682931C08B048B7A8645303FDC9F36E28733824@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E28733824PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.29.90323 Cc: Softwires WG , "draft-ietf-softwire-multicast-prefix-option@tools.ietf.org" Subject: [Softwires] draft-ietf-softwire-multicast-prefix-option: review request X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:45:46 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E28733824PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I was unable to present this I-D during the mboned meeting. I'm sending thi= s e-mail to request a review from mboned WG: http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 FWIW, this version does already integrate some of the comments from Stig. Comments and suggestions are more than welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E28733824PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
I= was unable=20 to present this I-D during the mboned meeting. I'm sending this e-mail to=20 request a review from mboned WG:
<= SPAN=20 class=3D268433512-29032012>http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-opt= ion-00
<= SPAN=20 class=3D268433512-29032012> 
F= WIW, this=20 version does already integrate some of the comments from=20 Stig.
 
C= omments and=20 suggestions are more than welcome.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E28733824PUEXCB1Bnante_-- From despres.remi@laposte.net Thu Mar 29 07:43:52 2012 Return-Path: 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 4826D21F893C for ; Thu, 29 Mar 2012 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, 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 V5EbWM6TiaKk for ; Thu, 29 Mar 2012 07:43:51 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id D855521F890E for ; Thu, 29 Mar 2012 07:43:50 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8506-out with ME id rSjn1i0055M8erm03Sjnhn; Thu, 29 Mar 2012 16:43:48 +0200 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 16:43:47 +0200 Message-Id: To: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] Reassembly cache in 4rd-U and not in MAP - Clarification? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:43:52 -0000 Hi Ole, One of your slides mentions a difference between MAP and 4rd-U = concerning Reassembly caching. Could you clarify what is the issue? Thanks, RD= From ichiroumakino@gmail.com Thu Mar 29 08:56:47 2012 Return-Path: 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 64C5321E813F for ; Thu, 29 Mar 2012 08:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 BnnVL7C9N3BK for ; Thu, 29 Mar 2012 08:56:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5452E21E8200 for ; Thu, 29 Mar 2012 08:56:46 -0700 (PDT) Received: by eeke51 with SMTP id e51so1288864eek.31 for ; Thu, 29 Mar 2012 08:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ad5e8HJReW6BJdnBgXHA1bqHrRLoLPNq0Na2WxccBW0=; b=f+8DfZWP6F97W7Smdxb7LRaXP4nJF1FGJFEGlz+kbME6S9cUaGc9tnur4dfxvPuYWR zLiajx4W5x06BMgDOqm68pDEWYFn3v4zzD0p6M3ckoVVAEQfazsn2Bu59eqKg55oFUVB sftAKBHSMdfHx7WoBLcSmqxBUOF+8JAAPQF+YQNPzYst887UfR29GovAj1u8LJjqzd9O b4AQabdZtu2/03t4lYVmMHezxk3HyEiMjox1cxzJGRijUsHyU+ylRNg57ot6jreuAr/Z 3EcvJ7yJXC9ePId53re4a4t6V9Tv/lkJR+tSYgPQdl4lD+4xa5YdukAC+MntTOrU+S2G pLSA== Received: by 10.14.29.72 with SMTP id h48mr1980495eea.124.1333036605478; Thu, 29 Mar 2012 08:56:45 -0700 (PDT) Received: from ?IPv6:2001:df8::80:bd3f:cd4b:1896:61d7? ([2001:df8:0:80:bd3f:cd4b:1896:61d7]) by mx.google.com with ESMTPS id x8sm22858588eea.10.2012.03.29.08.56.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:56:44 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 29 Mar 2012 17:56:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG Subject: Re: [Softwires] Reassembly cache in 4rd-U and not in MAP - Clarification? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:56:47 -0000 Remi, > One of your slides mentions a difference between MAP and 4rd-U = concerning Reassembly caching. > Could you clarify what is the issue? purely that 4rd-U includes text on it, and the latest MAP draft hasn't = adopted that (yet). cheers, Ole= From despres.remi@laposte.net Thu Mar 29 09:30:30 2012 Return-Path: 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 AF7F421F88C6 for ; Thu, 29 Mar 2012 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, 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 q2zOPPOjXHFT for ; Thu, 29 Mar 2012 09:30:30 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5021F88C9 for ; Thu, 29 Mar 2012 09:30:28 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id rUWR1i00A37Y3f403UWRgz; Thu, 29 Mar 2012 18:30:27 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 29 Mar 2012 18:30:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] Reassembly cache in 4rd-U and not in MAP - Clarification? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:30:31 -0000 Le 2012-03-29 =E0 17:56, Ole Tr=F8an a =E9crit : > Remi, >=20 >> One of your slides mentions a difference between MAP and 4rd-U = concerning Reassembly caching. >> Could you clarify what is the issue? >=20 > purely that 4rd-U includes text on it, and the latest MAP draft hasn't = adopted that (yet). I didn't guess it because: - the word cache doesn't appear in our draft - it is rather the fact that NO reassembly cache is needed that is a = recommended feature of 4rd-U (specified with a SHOULD).=20 Functionally, it means BR's ability to forward fragmented packets = without reassembling them, even if sent to shared-address CEs. =20 Thanks, RD >=20 > cheers, > Ole From sunqi.csnet.thu@gmail.com Fri Mar 30 04:22:28 2012 Return-Path: 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 5C24321F851B for ; Fri, 30 Mar 2012 04:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] 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 g1JOPzPZZWOc for ; Fri, 30 Mar 2012 04:22:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA321F8514 for ; Fri, 30 Mar 2012 04:22:27 -0700 (PDT) Received: by iazz13 with SMTP id z13so1038040iaz.31 for ; Fri, 30 Mar 2012 04:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=X9CX0ZBSojMlDCwdeUBZFKU3cn7mMbMRMITuZRklADI=; b=xgJEu64vnvVSSN0UgO1aHFnShYTYAsVKvgiG8y3PFAU2LpuSRjXAXSvMYBugd2lp+C /cd0FVm1C9w2hce7WrJw6bwUGZtGJgQdEUJYdJ0lZkY29GwYnJBOSe3YJ/Bq7eKJqLA3 wpcY741BYdxCgQkkOSWUyxLPHWHOfWYsozcQmq7FVkMOeKThNQFuL9RlciSUIEb9YyTS 7AQApDkYHYLCtQQdQFq9JzA1UTbJSJoTDV21iC7e41aeDRpTXKU+MyVnRmPSuiZhvN+a omAZUWiE/AhIate+2fPbvl+BbFXLQSqhrvljK9LvQQGaFwvgJJfntuJ+IAAsETFF6sOL YUOA== Received: by 10.50.13.228 with SMTP id k4mr1063673igc.42.1333106547243; Fri, 30 Mar 2012 04:22:27 -0700 (PDT) Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id cw5sm1419577igc.17.2012.03.30.04.22.15 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 04:22:26 -0700 (PDT) Date: Fri, 30 Mar 2012 19:22:00 +0800 From: "Qi Sun" To: "Tetsuya Murakami" , "Wojciech Dec" X-Priority: 3 X-GUID: 98F7FFCA-8ABD-4083-8D38-80FE85BBF6D7 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012033019220056808518@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart287527061657_=----" Cc: softwires WG Subject: [Softwires] Comments on MAP-T X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:22:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart287527061657_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KDQpBZnRlciB0aGUgZGlzY3Vzc2lvbiB0b2RheSBhdCB0aGUgc29mdHdp cmUsIEkgcmVyZWFkIHRoZSBkcmFmdCBhbmQgaGVyZSBhcmUgc29tZSBjb21tZW50cy4gDQpQbGVh c2UgaGVscCBtZSB3aXRoIHVuZGVyc3RhbmRpbmcgeW91IHdlbGwgOi0pDQoNCjEsIEluIHNlY3Rp b24gNy40LCB0aGUgNHRoIHBhcmFncmFwaDoNCk90aGVyd2lzZSwgdGhlIElQdjYgZGVzdGluYXRp b24gYWRkcmVzcyAoSVB2NC10cmFuc2xhdGVhYmxlIGFkZHJlc3MpIE1VU1QgYmUgZGVyaXZlZCBm cm9tDQogICAgIHRoZSByZWNlaXZlZCBJUHY0IGRlc3RpbmF0aW9uIGFkZHJlc3MgcGVyIERNUi4g IFRoZSBkZXN0aW5hdGlvbiBwb3J0IG51bWJlciBNVVNUIGJlIHVuY2hhbmdlZC4NCiANCkNvbnNp ZGVyaW5nIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgZGVyaXZlZCBmcm9tIHRoZSBy ZWNlaXZlZCBJUHY0IGRlc3RpbmF0aW9uIGFkZHJlc3MNCiBwZXIgRE1SLCB3aHkgdGhlIElQdjYg ZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhbiBJUHY0LXRyYW5zbGF0YWJsZSBhZGRyZXNzLCBub3Qg SVB2NC1jb252ZXJ0ZWQNCiBhZGRyZXNzPw0KDQoyLCBJbiBzZWN0aW9uIDcuNQ0KICAgQXQgdGhl IENFLCB0aGUgSVB2NCBzb3VyY2UgYWRkcmVzcyBNVVNUIGJlIGRlcml2ZWQgZnJvbSB0aGUgSVB2 Ng0KICAgc291cmNlIGFkZHJlc3MgKElQdjYtY29udmVydGVkIGFkZHJlc3MpIGFzIHBlciB0aGUg RE1SLCBvciBhcyBwZXIgdGhlDQogICBGTVIuICBUaGUgc291cmNlIHBvcnQgbnVtYmVyIE1VU1Qg YmUgdW5jaGFuZ2VkLg0KDQphKSAgICAgIEFzIGZhciBhcyBJIGNhbiBzZWUsIHRoZSChsElQdjYt Y29udmVydGVkIGFkZHJlc3OhsSBpcyBhbiBJUHY0IGFkZHJlc3MgY29udmVydGVkIGZyb20gYW4g SVB2NiBhZGRyZXNzLg0KICAgIElNSE8gdGhlIGV4cHJlc3Npb24gc2hvdWxkIGJlIElQdjQtY29u dmVydGVkIGFkZHJlc3MsIGJ1dCBJoa9tIG5vdCBzdXJlIHdoZXRoZXIgSaGvbSByaWdodC4NCmIp ICAgICAgSWYgdGhlIElQdjYgc291cmNlIGFkZHJlc3MgaXMgZGVyaXZlZCBhcyBwZXIgRk1SLCBJ TUhPIGl0IHNob3VsZCBiZSChsElQdjQtdHJhbnNsYXRhYmxlIGFkZHJlc3OhsSwgDQogICAgICBp bnN0ZWFkIG9mIElQdjQtY29udmVydGVkIGFkZHJlc3MuDQoNCiANCiAgIElQdjQgRGVzdGluYXRp b24gQWRkcmVzcyBhbmQgRGVzdGluYXRpb24gUG9ydCBOdW1iZXI6IEF0IHRoZSBDRSwgdGhlDQog ICBJUHY0IGRlc3RpbmF0aW9uIGFkZHJlc3MgTVVTVCBiZSBkZXJpdmVkIGZyb20gdGhlIElQdjYg ZGVzdGluYXRpb24NCiAgIGFkZHJlc3MgKElQdjYtdHJhbnNsYXRhYmxlIGFkZHJlc3MpIGFzIHBl ciBCTVIuICBUaGUgZGVzdGluYXRpb24gcG9ydA0KICAgbnVtYmVyIE1VU1QgYmUgdW5jaGFuZ2Vk Lg0KDQpJoa9tIHdvbmRlcmluZyBpZiB0aGUgobBJUHY2LXRyYW5zbGF0YWJsZSBhZGRyZXNzobEg aXMgSVB2NC10cmFuc2xhdGFibGUgYWRkcmVzcy4NCg0KMywgSW4gc2VjdGlvbiA2LjIuMQ0KVGhl IElQdjYgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgTVVTVCB0aGVuIGJlIGRlcml2 ZWQgYXMgcGVyIFNlY3Rpb24gNiBvZiB0aGlzIGRyYWZ0LCBhbmShrS4uDQogDQpJTUhPIHRoZSBz dXBlciBsaW5rIKGwU2VjdGlvbiA2obEgbWF5IGJlIKGwU2VjdGlvbiA3obEsIHJlZmVycmluZyB0 byBzZWN0aW9uIDYuNC4xIGFuZCA2LjQuMi4gRGlkIEkgdW5kZXJzdGFuZCByaWdodD8NCiANClRo ZXJlIGlzIGEgc2FtZSBzdXBlciBsaW5rIGluIHNlY3Rpb24gNi4yLjIuDQogDQogDQpQbGVhc2Ug Y29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgYW55dGhpbmcuDQogDQpCZXN0IFJlZ2FyZHMh DQogDQoNCg0KDQpRaSBTdW4= ------=_001_NextPart287527061657_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear authors,
 
After the discussion today at the softwire, I reread the draft a= nd=20 here are some comments.
Please help me with understanding you well :-)
 

1, In section 7.4, the 4th=20 paragraph:

Otherwise, the IPv6 destination address=20 (IPv4-translateable address) MUST be derived from

     the received IPv4 destination address pe= r=20 DMR.  The destination port n= umber=20 MUST be unchanged.

 

Considering the IPv6 destination address= is=20 derived from the received IPv4 destination address

 per DMR, why the IPv6 destination = address is=20 an IPv4-translatable address, not IPv4-converted

 address?

 

2, In section 7.5

   At the = CE, the=20 IPv4 source address MUST be derived from the IPv6

   source = address=20 (IPv6-converted address) as per the DMR, or as per the

   FMR.  The source port number MUST be=20 unchanged.

 

a)     =20 As far as I can see, the =A1=B0IPv6-converted address=A1=B1 i= s an IPv4 address=20 converted from an IPv6 address.

    IMHO the expression should be IPv4-convert= ed=20 address, but I=A1=AFm not sure whether I=A1=AFm right. b)     =20 If the IPv6 source address is derived as per FMR, IMHO it sho= uld be=20 =A1=B0IPv4-translatable address=A1=B1,

      instead of IPv4-converted=20 address.

 

   IPv4 De= stination=20 Address and Destination Port Number: At the CE, the

   IPv4 de= stination=20 address MUST be derived from the IPv6 destination

   address= (IPv6-translatable address) as= per=20 BMR.  The destination=20 port

   number = MUST be=20 unchanged.

 

I=A1=AFm wondering if the =A1=B0IPv6-translatable address=A1= =B1 is IPv4-translatable=20 address.

=

3, In section 6.2.1

The IPv6 source and destination addresse= s MUST=20 then be derived as per Section 6 of this draft,=20 and=A1=AD..

 

IMHO the super link =A1=B0Section 6=A1= =B1 may be =A1=B0Section=20 7=A1=B1, referring to section 6.4.1 and 6.4.2. Did I understand=20 right?

 

There is a same super link in = section=20 6.2.2.

 

 

Please correct me if I misunderstood=20 anything.

 

Best Regards!

 

Qi Sun
------=_001_NextPart287527061657_=------ From jiangsheng@huawei.com Fri Mar 30 08:06:10 2012 Return-Path: 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 47FBA21F86D6 for ; Fri, 30 Mar 2012 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 PrAaozYt4O07 for ; Fri, 30 Mar 2012 08:06:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5300D21F85D1 for ; Fri, 30 Mar 2012 08:06:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV12694; Fri, 30 Mar 2012 11:06:08 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 08:03:44 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 08:03:51 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 23:03:47 +0800 From: Sheng Jiang To: Softwires WG Thread-Topic: Have the WG drop other stateless solutions already? Thread-Index: Ac0OhcEbYfTmwAGrS6aDBsH4wbI0Vg== Date: Fri, 30 Mar 2012 15:03:47 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47D44C@SZXEML506-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] Have the WG drop other stateless solutions already? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:06:10 -0000 Hi, Softwirers, I get very confused when I walked out the Softwire meeting this morning. Wh= y did we only talk about making choice between 4rd-U and MAP? There are als= o several other stateless solutions, too. As far as I recalled, the Softwir= e WG have NOT decided to drop them at all. They should be discussed togethe= r and equally. If the Softwire WG is going to choose single one solution, it should be cho= ose among all these solutions. Until we have decided drop all other statele= ss solutions, this is not a two-horse race, yet. Best regards, Sheng= From chenycmx@gmail.com Fri Mar 30 21:59:05 2012 Return-Path: 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 9F93221F865F for ; Fri, 30 Mar 2012 21:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] 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 gL9tUyvrpaJ5 for ; Fri, 30 Mar 2012 21:59:04 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9839721F865E for ; Fri, 30 Mar 2012 21:59:04 -0700 (PDT) Received: by dady13 with SMTP id y13so323484dad.27 for ; Fri, 30 Mar 2012 21:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=niIpFOjObatagdD8swbqJGuZiSyqls6Yv8AAy/U+h40=; b=qSam7xT5rQd8+PnrwDqzLAp2b/bFDPIupkbpkiTxhLiLL7rCLlSIavh+sizlaM5Esv lpOosO3C9YdPHuArFjCoUhjnTGy6mng1qaW+vX4V5xKaYbiBiyAWzzKsxRn7Uidq9O4l bHLClNNAMXUhuOu0FH5BBe+A+vBTe10fXCXovLm/7RC09v9p9Pc6yDTVlDcDVBkN4umO WDWENrNiRdkELd7vY0mYLKzBinA2pTnu/RYDZqoOsw4gNmBoJJs6PxmGlJss/97WryQV 7loNQ7IrtpQQap3QQNUchw+S40EfSjHC3eNVvfp0+pt46ZSgbUnHFrkS78OlwBdj5mau EBAw== MIME-Version: 1.0 Received: by 10.68.234.99 with SMTP id ud3mr2756367pbc.109.1333169944323; Fri, 30 Mar 2012 21:59:04 -0700 (PDT) Received: by 10.142.74.18 with HTTP; Fri, 30 Mar 2012 21:59:04 -0700 (PDT) Date: Sat, 31 Mar 2012 12:59:04 +0800 Message-ID: From: Yuchi Chen To: Tetsuya Murakami Content-Type: multipart/alternative; boundary=047d7b33d144f4e67804bc82d07d Cc: softwires WG Subject: [Softwires] Questions about draft-mdt-softwire-map-translation-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 04:59:05 -0000 --047d7b33d144f4e67804bc82d07d Content-Type: text/plain; charset=ISO-8859-1 Dear Murakami-San, I'm very concerned about your work on MAP-T. I've read the draft-mdt-softwire-map-translation-01, and I'm confused with some statements in the draft. Questions are as follows: 1. In section 7.4, there is a statement saying "Otherwise, the IPv6 destination address (IPv4-translatable address) MUST be derived from the received IPv4 destination address per DMR." I'm wondering if the IPv4-translatable address here should be IPv4-converted address. 2. In section 7.5, the expressions of "IPv6-converted address" and "IPv6-translatable address" confused me. I am wondering if the "IPv6-converted address" should be "IPv4-converted address"or not, and if the "IPv6-translatable address" should be "IPv4-translatable address". Here is are two pictures which depict my understanding of the draft. Pic 1. Upstream from CE to BR: CE BR IPv4 src BMR IPv6 src (IPv4-translatable) FMR IPv4 src --------------> --------------> IPv4 dst FMR, DMR IPv6 dst (IPv4-converted) DMR IPv4 dst Pic 2. Downstream from BR to CE: CE BR IPv4 src FMR, DMR IPv6 src (IPv4-converted) DMR IPv4 src <-------------- <-------------- IPv4 dst BMR IPv6 dst (IPv4-translatable) FMR IPv4 dst I'm not so sure if my understanding is right. Please correct me if there is any mistake I've made. Thank you very much! Best regards! Yuchi Chen --047d7b33d144f4e67804bc82d07d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Murakami-San,
=A0
I'm=A0very concerned about your work= on=20 MAP-T.=A0I've read the draft-mdt-softwire-map-translation-01, and I'= ;m confused=20 with some statements in the draft. Questions are as follows:
=A0
1. In section 7.4, there is a statement = saying=20 "Otherwise,=A0the=A0IPv6=20
destination=A0address=A0(IPv4-translatable=A0address)=A0MUST=A0be=A0de= rived=A0from
the=A0received=A0IPv4=A0destination=A0address=A0per=A0DMR."
I'm wondering if the IPv4-translatable address here should be=20 IPv4-converted address.
=A0
2. In section 7.5, the expressions of=20 "IPv6-converted address" and "IPv6-translatable address"= ; confused me.=A0I=A0am=20 wondering if=A0the "IPv6-converted address"=A0should be "IPv= 4-converted address"or=20 not, and=A0if the "IPv6-translatable address" should be "IPv= 4-translatable=20 address".=A0
=A0
Here is=A0are two pictures which depict my understanding=A0of the draf= t.
=A0
Pic 1. Upstream from CE to BR:
CE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 BR
IPv4 src=A0=A0=A0=A0BMR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6 sr= c=20 (IPv4-translatable)=A0=A0=A0=A0=A0=A0FMR =A0 =A0 =A0IPv4 src=A0
--------------> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----= ---------->=20
IPv4 dst=A0=A0=A0=A0FMR, DMR =A0 =A0 IPv6 dst (IPv4-converted) =A0 =A0= =A0 =A0 DMR =A0 =A0 =A0IPv4=A0dst=A0
=A0
Pic 2. Downstream from BR to CE:
CE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 BR
IPv4 src=A0=A0=A0=A0=A0FMR, DMR=A0=A0=A0 IPv6 src=20 (IPv4-converted)=A0=A0=A0=A0=A0=A0=A0=A0=A0DMR=A0=A0=A0=A0=A0=A0=A0IPv4 src= =A0
<-------------- =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= --------------
IPv4 dst =A0 =A0 BMR =A0 =A0 =A0 =A0 =A0 =A0 IPv6 dst (IPv4-translatab= le) =A0 =A0 =A0 FMR =A0 =A0 =A0IPv4=A0dst=A0
=A0
I'm not so sure if my understanding is right. Please=A0correct me = if there is=20 any mistake I've made. Thank you=A0very much!
=A0
Best regards!
Yuchi Chen
--047d7b33d144f4e67804bc82d07d-- From despres.remi@laposte.net Sat Mar 31 07:57:11 2012 Return-Path: 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 1B5A321F8463 for ; Sat, 31 Mar 2012 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 aXPcVzyHTRvh for ; Sat, 31 Mar 2012 07:56:51 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id A74AA21F85D7 for ; Sat, 31 Mar 2012 07:56:49 -0700 (PDT) Received: from [192.168.1.73] ([89.170.204.111]) by mwinf8503-out with ME id sEwk1i0042QjjJp03Ewkfj; Sat, 31 Mar 2012 16:56:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 31 Mar 2012 16:56:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> References: To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 14:57:11 -0000 Alain, You had initially announced that either one specification would be = chosen for standard track (among T, E, and U), or specifications would = all become WG drafts on the experimental track ((*) below). In Paris: (a)The MAP proposal became presented as an inseparable T+E package.=20 (b) The WG couldn't make a consensus choice between T+E or U. Now publishing both MAP-T+E and 4rd-U as WG documents on the = experimental track, is therefore consistent with what was announced (and = was also asked for by several at the end of the meeting).=20 As you explained, this won't prevent from selecting one for standard = track later on, based on better market experience. After what we had at IETF 83, this is in my understanding the only = irreproachable course of action Thanks, RD Le 2012-03-20 =E0 00:38, Alain Durand a =E9crit : > Dear wg, >=20 > After a number of discussions with my co-chair, our AD and various = authors, here is how we would like to move forward wrt 4rd. >=20 > 1) There is an observation that all the solutions on the table E, T & = U actually solve the stateless problem we started with. > There are differences, but it is unclear if those differences are = really significant. E and T are the original Encapsulation and = Translation > proposals, U is an hybrid unifying solution. >=20 > 2) We have already agreed back in Beijing that we would publish all = necessary documents. The issue here is the 'label' or 'status' those > documents have at IETF. In particular, do we want to publish them as = Experimental, Informational or Standard Track. >=20 > We are at the point now where we need to make progress. In Paris, we = would like to ask for presentations from the proponents of each = candidate solution (E, T & U). > Each presentation should cover an overview of the proposed solution, = explain how it compares to the others and make a case as why it should = be the one on the Standard Track. We will allocate 20 minutes for each = presentation. >=20 > Then, we, chairs, would like to ask a series of questions to the = working group. In order to make this process transparent, here is the = list of questions we want to ask > and their sequence. >=20 > Q1: Without pre-supposing which one will be selected, do you agree to = publish 1 of the 3 proposals on the Standard Track and publish the = other(s) as Informational if still asked to? (*) > If the answer is NO, then the process stops and we will publish = everything as Experimental and come back in 12-24 months to see what = gets adopted by the market. > If the answer is YES, we move to the next question. >=20 >=20 > Q2: Do you believe that the WG should publish U as the one Standards = Track document? >=20 > If the answer is YES, the process stop, we put U on the Standard Track = and publish E & T as Informational. > If the answer is NO, we are left with E & T (U then might be abandoned = or published as Historical/Informational) >=20 >=20 > Q3: Which of E and T do you want to see moving on the standard track = (you can only express support for one)? >=20 > If there is a clear outcome from this question, we would publish that = proposal on the Standard Track and the other one as Informational. > If there is no clear consensus on this question, we will publish both = E & T as Experimental. >=20 > In the meantime, we would like to encourage discussion on the mailing = list to foster our common understanding of the various technologies and = how they relate to each other. >=20 > Alain & Yong, wg co-chairs. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Sat Mar 31 15:15:39 2012 Return-Path: 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 A78A121F8731 for ; Sat, 31 Mar 2012 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 CQtWxPrNbs17 for ; Sat, 31 Mar 2012 15:15:39 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F2DEC21F872F for ; Sat, 31 Mar 2012 15:15:38 -0700 (PDT) Received: by qaea16 with SMTP id a16so939114qae.10 for ; Sat, 31 Mar 2012 15:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t34r4q5Wiv5DpKqheMDSdAChL9S05E5mO4Y68jfqPcE=; b=r+GoTIlmel5REsskN4OAMabgNYo7hbrzqDL+qNMK4MsAQrMtHDQ0QQos4DnqrUTIUr vBNZb6sAAMCkWOz5JgAe/wFc7MIpDsQe5eMUU6NNNoeT8x2huogNj74pEsFPD86QKuLM ccwzsLOBuv0X6BVVV9SeiWVBu1hzGG4Wc2xTfDBr54WILJCiIW3K+3vjv3DW+yCpU89a CbSZc/SxF8mlUpyWadEP1940j+F8XGX6/SBKQxBLLsy2+YyG5TLRc30tKIhSWQFUaFA7 w1KbT2ZGu62oFe65BkjFxYQyEH5LUiQ1YrRXYmSh705K0uXVMg9M8XVjpBYpCaSfa4NH 820Q== MIME-Version: 1.0 Received: by 10.224.223.76 with SMTP id ij12mr4744639qab.11.1333232138577; Sat, 31 Mar 2012 15:15:38 -0700 (PDT) Received: by 10.229.136.202 with HTTP; Sat, 31 Mar 2012 15:15:38 -0700 (PDT) In-Reply-To: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net> Date: Sun, 1 Apr 2012 07:15:38 +0900 Message-ID: From: Maoke To: Softwires-wg Content-Type: multipart/alternative; boundary=20cf3074b4b805e74d04bc914c5b Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 22:15:39 -0000 --20cf3074b4b805e74d04bc914c5b Content-Type: text/plain; charset=ISO-8859-1 hi all, i listented to the softwire wg live on March 30 online and recorded my comments in the jabber room. as the person who was mentioned by the presenter not less than twice, i have to point out that it is unfair that the presenter mentioned me with only acknowledgment to my effort but my point of views. my summerized comment on 4rd-u is: it is flawed in both architecture and technical aspects, and now still uncertain in several details. it would become as a ridiculous and weird record in the ietf history, had the wg made a decision of putting two as experimental, one is well-understood, well-coded and well-practised while the other is misleading the understanding on the Internet architecture, not yet coded, not yet tested by any operators. our company, as an ISP and as a provider doing also application services, including those over mobile platforms, is waiting for the MAP standard desirably. we have no interest in introducing the 4rd-u elements into our platforms. personally i won't code a stuff with obvious architectural flaws but, if i were believing in the 4rd-u, i would do the code and operational test with serious self-checking as MAP-T and MAP-E teams already have done, before talking on any doc-track issue with the community. this is the way of being responsible. thanks, maoke --20cf3074b4b805e74d04bc914c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi all,=A0

i listented to the softwi= re wg live on March 30 online and recorded my comments in the jabber room. = as the person who was mentioned by the presenter not less than twice, i hav= e to point out that it is unfair that the presenter mentioned me with only = acknowledgment to my effort but my point of views. my summerized comment on= 4rd-u is: it is flawed in both architecture and technical aspects, and now= still uncertain in several details.=A0

it would become as a ridiculous and weird record in the =A0ietf his= tory, had the wg made a decision of putting two as experimental, one is wel= l-understood, well-coded and well-practised while the other is misleading t= he understanding on the Internet architecture, not yet coded, not yet teste= d by any operators.

our company, as an ISP and as a provider doing also app= lication services, including those over mobile platforms, is waiting for th= e MAP standard desirably. we have no interest in introducing the 4rd-u elem= ents into our platforms.

personally i won't code a stuff with obvious architectural fla= ws but, if i were believing in the 4rd-u, i would do the code and operation= al test with serious self-checking as MAP-T and MAP-E teams already have do= ne, before talking on any doc-track issue with the community. this is the w= ay of being responsible.

thanks,
maoke
 --20cf3074b4b805e74d04bc914c5b-- From jiangsheng@huawei.com Sat Mar 31 17:47:45 2012 Return-Path: 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 37E4921F864A for ; Sat, 31 Mar 2012 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 FJXLkhBMEY54 for ; Sat, 31 Mar 2012 17:47:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 718CB21F863E for ; Sat, 31 Mar 2012 17:47:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV98444; Sat, 31 Mar 2012 20:47:44 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Mar 2012 17:47:34 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Mar 2012 17:47:43 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sun, 1 Apr 2012 08:47:38 +0800 From: Sheng Jiang To: Maoke , Softwires-wg Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=85?= Thread-Index: Ac0GKWtjiwfJTLnPSeG4n7AZAdsQIAI4gK6AAA9UOAAAE5N9pw== Date: Sun, 1 Apr 2012 00:47:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E47D79D@SZXEML506-MBS.china.huawei.com> References: <93992ECA-2135-4CE3-8FAE-FF371C286D2B@laposte.net>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B921E47D79DSZXEML506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=85?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 00:47:45 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B921E47D79DSZXEML506MBSchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Without any prejudgement, we are going to implement 4rd-u and do operationa= l tests. If there are any architecture conflict with the basic IPv6 archtec= ture, we would like to propose modification for 4rd-u design. In principle,= we have no any interests to change the current IPv6 architecture at all. W= e will make sure it is a transition mechanism to help current IPv6 getting = deployed, rather than another IP. Best regards, Sheng ________________________________ From: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on behalf of = Maoke [fibrib@gmail.com] Sent: 01 April 2012 6:15 To: Softwires-wg Cc: Yong Cui; Ralph Droms Subject: Re: [Softwires] Path to move forward with 4rd=85 hi all, i listented to the softwire wg live on March 30 online and recorded my comm= ents in the jabber room. as the person who was mentioned by the presenter n= ot less than twice, i have to point out that it is unfair that the presente= r mentioned me with only acknowledgment to my effort but my point of views.= my summerized comment on 4rd-u is: it is flawed in both architecture and t= echnical aspects, and now still uncertain in several details. it would become as a ridiculous and weird record in the ietf history, had = the wg made a decision of putting two as experimental, one is well-understo= od, well-coded and well-practised while the other is misleading the underst= anding on the Internet architecture, not yet coded, not yet tested by any o= perators. our company, as an ISP and as a provider doing also application services, i= ncluding those over mobile platforms, is waiting for the MAP standard desir= ably. we have no interest in introducing the 4rd-u elements into our platfo= rms. personally i won't code a stuff with obvious architectural flaws but, if i = were believing in the 4rd-u, i would do the code and operational test with = serious self-checking as MAP-T and MAP-E teams already have done, before ta= lking on any doc-track issue with the community. this is the way of being r= esponsible. thanks, maoke --_000_5D36713D8A4E7348A7E10DF7437A4B921E47D79DSZXEML506MBSchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Without any prejudgement, we are going to implement 4rd-u and do operati= onal tests. If there are any architecture conflict with the basic IPv6= archtecture, we would like to propose modification for 4rd-u design. In pr= inciple, we have no any interests to change the current IPv6 architecture at all. We will make sure it is = a transition mechanism to help current IPv6 getting deployed, rather than a= nother IP.

 

Best regards,

 

Sheng

From: softwires-bounces@ietf.org [softwire= s-bounces@ietf.org] on behalf of Maoke [fibrib@gmail.com]
Sent: 01 April 2012 6:15
To: Softwires-wg
Cc: Yong Cui; Ralph Droms
Subject: Re: [Softwires] Path to move forward with 4rd=85

hi a= ll, 

i listented to the softwire wg live on March 30 online and recorded my= comments in the jabber room. as the person who was mentioned by the presen= ter not less than twice, i have to point out that it is unfair that the pre= senter mentioned me with only acknowledgment to my effort but my point of views. my summerized comment on 4rd-u is: it = is flawed in both architecture and technical aspects, and now still uncerta= in in several details. 

it would become as a ridiculous and weird record in the  ietf his= tory, had the wg made a decision of putting two as experimental, one is wel= l-understood, well-coded and well-practised while the other is misleading t= he understanding on the Internet architecture, not yet coded, not yet tested by any operators.

our company, as an ISP and as a provider doing also application servic= es, including those over mobile platforms, is waiting for the MAP standard = desirably. we have no interest in introducing the 4rd-u elements into our p= latforms.
personally i won't code a stuff with obvious architectural= flaws but, if i were believing in the 4rd-u, i would do the code and opera= tional test with serious self-checking as MAP-T and MAP-E teams already hav= e done, before talking on any doc-track issue with the community. this is the way of being responsible.

thanks,
maoke
--_000_5D36713D8A4E7348A7E10DF7437A4B921E47D79DSZXEML506MBSchi_-- From eleven.fuyu@huawei.com Sat Mar 31 18:25:13 2012 Return-Path: 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 360E921F8679 for ; Sat, 31 Mar 2012 18:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8n3ZVdc4ybkj for ; Sat, 31 Mar 2012 18:25:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9269921F8650 for ; Sat, 31 Mar 2012 18:25:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEN96416; Sat, 31 Mar 2012 21:25:12 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Mar 2012 18:24:56 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Mar 2012 18:24:51 -0700 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.169]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sun, 1 Apr 2012 09:24:37 +0800 From: "Fuyu (Eleven)" To: Sheng Jiang Thread-Topic: Have the WG drop other stateless solutions already? Thread-Index: Ac0OhcEbYfTmwAGrS6aDBsH4wbI0VgAi5QlQ Date: Sun, 1 Apr 2012 01:24:37 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B921E47D44C@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47D44C@SZXEML506-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG Subject: Re: [Softwires] Have the WG drop other stateless solutions already? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 01:25:13 -0000 Agree. I think we shouldn't drop other stateless solutions as: draft-cui-softwire-b4-translated-ds-lite-05 draft-penno-softwire-sdnat-02 They are all belong to stateless scope and with the same network architectu= re of IPv4 traffic across IPv6 access network as MAP and 4rd-U. Cheers=20 Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Sheng Jiang Sent: Friday, March 30, 2012 11:04 PM To: Softwires WG Subject: [Softwires] Have the WG drop other stateless solutions already? Hi, Softwirers, I get very confused when I walked out the Softwire meeting this morning. Wh= y did we only talk about making choice between 4rd-U and MAP? There are als= o several other stateless solutions, too. As far as I recalled, the Softwir= e WG have NOT decided to drop them at all. They should be discussed togethe= r and equally. If the Softwire WG is going to choose single one solution, it should be cho= ose among all these solutions. Until we have decided drop all other statele= ss solutions, this is not a two-horse race, yet. Best regards, Sheng _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Sat Mar 31 19:34:56 2012 Return-Path: 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 577ED21F8722 for ; Sat, 31 Mar 2012 19:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.064 X-Spam-Level: X-Spam-Status: No, score=-100.064 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 tAukaIUI5-EO for ; Sat, 31 Mar 2012 19:34:55 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD7F21F8720 for ; Sat, 31 Mar 2012 19:34:55 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7816177; Sat, 31 Mar 2012 22:28:25 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 22:34:41 -0400 From: "Lee, Yiu" To: Sheng Jiang , Maoke , Softwires-wg Thread-Topic: =?Windows-1252?Q?[Softwires]_Path_to_move_forward_with_4rd=8A?= Thread-Index: AQHND6/8jacCaH5YPUiuWQCkD4hIkg== Date: Sun, 1 Apr 2012 02:34:40 +0000 Message-ID: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E47D79D@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416078078_5919938" MIME-Version: 1.0 Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] =?windows-1252?q?Path_to_move_forward_with_4rd=8A?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 02:34:56 -0000 --B_3416078078_5919938 Content-type: multipart/alternative; boundary="B_3416078076_5946401" --B_3416078076_5946401 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sheng, Thanks very much for letting us know you are going to implement 4rd-u. Please share the results in the ML. I am very much interested to see how 4rd-u would cause any conflict in IPv6. Thanks, Yiu From: Sheng Jiang Date: Sun, 1 Apr 2012 00:47:36 +0000 To: Maoke , Softwires-wg Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] Path to move forward with 4rd=8A Without any prejudgement, we are going to implement 4rd-u and do operationa= l tests. If there are any architecture conflict with the basic IPv6 archtecture, we would like to propose modification for 4rd-u design. In principle, we have no any interests to change the current IPv6 architecture at all. We will make sure it is a transition mechanism to help current IPv6 getting deployed, rather than another IP. =20 Best regards, =20 Sheng --B_3416078076_5946401 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Sheng,

Thanks very much for letting us know you are going to implement 4rd-u= . Please share the results in the ML. I am very much interested to see how 4= rd-u would cause any conflict in IPv6.

Thanks,
Yiu

From: Shen= g Jiang <jiangsheng@huawei.com= >
Date: Sun, 1 Apr 2012 00:47:3= 6 +0000
To: Maoke <fibrib@gmail.com>, Softwires-wg <softwires@ietf.org>
Cc: Yong Cui <= cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: <= /span> Re: [Softwires] Path to move forward with 4rd…

Without any prejudgement, we are going to implement 4rd-u and do operationa= l tests. If there are any architecture conflict with the basic IPv6 arc= htecture, we would like to propose modification for 4rd-u design. In princip= le, we have no any interests to change the current IPv6 architecture at= all. We will make sure it is a transition mechanism to help current IP= v6 getting deployed, rather than another IP.

 

Best regards,

 =

Sheng

= --B_3416078076_5946401-- --B_3416078078_5919938 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTA0LlJ cXjt+39biynP9HM++SjaMTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MDEwMjM0MzZaMA0GCSqGSIb3DQEBAQUABIIBABpuqSUcvpvoDVvrzAkZ/j9M QyAyw5qCMv0721nkHveqFPMf6yWl9OtgB9caSfliA/Hjqr7MFrWAgZF2lXC/06bYxh09wsGV QRJ128GavhtLFFLBgIL0/2TYKahtFwNOQX/opHot2kpNDmvVjWxMW8xDC1oshdJGksVleuyS 69JIAnd2liaZfj7IVYs4cvWdOVbxJaXAglDeUG7vtO/LrPdcOv5Ori0eLCy2JMbVs6Mn5sRU Fn3+Y36zAphAFr/7pvcZ+T8DG/6quQIV0sviyGC9zjVwIa0vqlTg6epOTxjwcMZvjvasTTN1 J1qpWuz4+vlhw5FPK05idoiKe+VAPaA= --B_3416078078_5919938-- From sunjingwen@live.cn Sat Mar 31 20:05:14 2012 Return-Path: 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 97E8621F86F1 for ; Sat, 31 Mar 2012 20:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.558 X-Spam-Level: ** X-Spam-Status: No, score=2.558 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] 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 uAB40DmBY-ek for ; Sat, 31 Mar 2012 20:05:14 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2621F86C6 for ; Sat, 31 Mar 2012 20:05:13 -0700 (PDT) Received: from BLU0-SMTP460 ([65.55.111.135]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Mar 2012 20:05:13 -0700 X-Originating-IP: [59.64.255.250] X-Originating-Email: [sunjingwen@live.cn] Message-ID: Received: from COMPUTER ([59.64.255.250]) by BLU0-SMTP460.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Mar 2012 20:05:12 -0700 Date: Sun, 1 Apr 2012 11:05:10 +0800 From: sunjingwen To: mark , ot X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart883405716811_=----" X-OriginalArrivalTime: 01 Apr 2012 03:05:12.0442 (UTC) FILETIME=[411AD5A0:01CD0FB4] Cc: softwires WG Subject: [Softwires] [softwire]Basic Requirements for Customer Edge Routers X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sunjingwen List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 03:05:14 -0000 ------=_001_NextPart883405716811_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KSSd2ZSByZWFkIHRoZSBkcmFmdC10b3duc2xleS10cm9hbi1pcHY2LWNl LXRyYW5zaXRpb25pbmctMDIsIGFuZCBJIGhhdmUgYSBxdWVzdGlvbiBjb25mdXNlZCBtZSB2ZXJ5 IG11Y2guDQogDQpJbiBzZWN0aW9uIDQuMywgDQo+SW4gdGhlIGNhc2Ugb2YgRFMtTGl0ZSBhbmQg TmF0aXZlIElQdjQgY29uZmlndXJhdGlvbiBiZWluZyBwcmVzZW50IGF0IHRoZSBzYW1lIHRpbWUs IA0KPkRTLUxpdGUgd291bGQgYmUgcHJlZmVycmVkIGFzIGl0IHVzZXMgSVB2NiB0cmFuc3BvcnQg YW5kIE5hdGl2ZSBJUHY0IGRvZXMgbm90Lg0KIA0KRG8geW91IG1lYW4gaWYgdGhlIENFIHJlY2Vp dmUgdXNlcqGvcyBJUHY0IHBhY2tldCwgaXQgd2lsbCBjaG9vc2UgdG8gdXNlIHR1bm5lbCByYXRo ZXIgdGhhbiBJUHY0Pw0KQnV0IEkgdGhpbmsgaWYgdXNlIG5hdGl2ZSBJUHY0IGNhbiBhbHNvIGFy cml2ZSB0aGUgZGVzdGluYXRpb24gKElQdjQgaW50ZXJuZXQpLCB0aGUgbmF0aXZlIElQdjQgd2ls bCBtb3JlIGVmZmljaWVudCB0aGFuIHRoZSB0dW5uZWwsIGJlY2F1c2UgaXQgbmVlZG6hr3QgZW5j YXBzdWxhdGlvbiBhbmQgZGVjYXBzdWxhdGlvbi4NCiANClBsZWFzZSBjb3JyZWN0IG1lIGlmIHRo ZXJlIGlzIGFueSBtaXN0YWtlfg0KIA0KICAgICBUaGFuayB5b3UNCg0KDQoNCg0KQmVzdCByZWdh cmRzIQ0Kc3VuIGppbmd3ZW4= ------=_001_NextPart883405716811_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear authors,

I've read the draft-townsley-troan-ipv6-ce-transitioning-02, = and I=20 have a question confused me very much.

 

In section 4.3,

<= SPAN=20 style=3D"FONT-FAMILY: =CB=CE=CC=E5; FONT-SIZE: 12pt; mso-bidi-font-family:= =CB=CE=CC=E5; mso-font-kerning: 0pt"=20 lang=3DEN-US>>In the case of DS-Lite and Native IPv4 configuration bein= g=20 present at the same time,

<= SPAN=20 style=3D"FONT-FAMILY: =CB=CE=CC=E5; FONT-SIZE: 12pt; mso-bidi-font-family:= =CB=CE=CC=E5; mso-font-kerning: 0pt"=20 lang=3DEN-US>>DS-Lite would be preferred as it uses IPv6 transport=20 and Native IPv4 does not.

 

Do you mean if the CE receive user=A1=AFs IPv4 packet, it wil= l choose to=20 use tunnel rather than IPv4?

But I think if use native IPv4 can also arrive the destinatio= n (IPv4=20 internet), the native IPv4 will more efficient than the tunnel, because it= =20 needn=A1=AFt encapsulation and decapsulation.

 

Please correct me if there is any mistake~<= /P>

 

     Thank=20 you

 
Best regards!
sun jingwen
------=_001_NextPart883405716811_=------