Re: [Softwires] 4rd Address Mapping - version-01

Rémi Després <despres.remi@free.fr> Fri, 30 September 2011 12:17 UTC

Return-Path: <despres.remi@free.fr>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9821F869E for <softwires@ietfa.amsl.com>; Fri, 30 Sep 2011 05:17:10 -0700 (PDT)
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=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 IeRnWj9vBaq5 for <softwires@ietfa.amsl.com>; Fri, 30 Sep 2011 05:17:09 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0021F863E for <softwires@ietf.org>; Fri, 30 Sep 2011 05:17:07 -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 CDC3D940189; Fri, 30 Sep 2011 14:19:55 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@free.fr>
In-Reply-To: <593B5458-3276-43D7-AF32-2FB8EF899AE7@employees.org>
Date: Fri, 30 Sep 2011 14:19:44 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <332BEE87-D2F4-496B-8D73-16AC7FFA2B71@free.fr>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <B3D5FABA-72BA-4C35-A068-D823CC0A4682@laposte.net> <CAM+vMERSbGuraAC9snvGUgPBOY40m5p0SX46qfVqJaB6bHmvCw@mail.gmail.com> <D8B8F1D1-1FE7-44E1-A6C6-E1480BD91C0A@ipinfusion.com> <4E82C970.8060801@jacni.com> <3580FD83-1FD6-4A5D-9AB1-046FBE47AFBB@employees.org> <823C69D6-D040-4959-8A5A-3B1B2CAF7734@free.fr> <C1DB0E47-C4F8-4AAF-B754-379B9B47BB95@employees.org> <EC5F7306-8EA6-4707-A8EF-D8D2BEC5E3B9@free.fr> <593B5458-3276-43D7-AF32-2FB8EF899AE7@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg <softwires@ietf.org>, Wojciech Dec <wdec@cisco.com>
Subject: Re: [Softwires] 4rd Address Mapping - version-01
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2011 12:17:10 -0000

Le 30 sept. 2011 à 19:20, Ole Troan a écrit :

> Remi,
> 
>>>>> in the general case there is no way to guarantee that a host doesn't pick the same IID.
>>>> 
>>>> Well, "no guarantee"...  unless a safe way of doing it is specified!
>>>> And this is already the case with 4rd-addmapping-01.
>>>> (If you would keep doubts after a careful check, please share your understanding.)
>>>> 
>>>> The modified format discussed in Beijing with Xing Li, Congxiao Bao, and Wojciech Dec, to be documented soon, will have the same property.
>>> 
>>> there are no guarantees, and no safe way of doing that.
>>> there is no enforcement of global uniqueness of interface ids.
>>> e.g. the use of longer than /64 prefixes, manual configuration.
>>> you have a high probability of it being unique. and as long as it is only used for pretty printing and troubleshooting, then do you care?
>> 
>> Still, the Modified EUI-64 format of RFC 4291 has been designed to ensure unicity of these Universal-scope IIDs.
>> True, a user can manually configure an EUI-64 IID that he shouldn't. The confusion that results is then his responsibility.
>> The same applies if a host behind a 4rd CE configures a 4rd IID: it won't be reachable from the Internet. 
>> 
>> Possibility of misconfiguration MUST NOT be a reason to give up specifying formats that work in absence of misconfigurations (as done with the modified EUI-64 format of RFC 4291).
> 
> that's a property that was highly speculative 15 years ago when it was specified and a property that has never been verified.
> but, let me turn the question around. what are the requirements for a globally unique interface-id? how is it going to be used?
> both for encapsulation and translation?

In both cases, the CE node can recognize 4rd packets, and process them as such, without preempting any IID value that might be a legitimate value for a host behind the CE.

> is it expected that routers have to make forwarding decisions on an interface-id?

No.
Ordinary routers are concerned with IIDs only on destination links but here, like with 6to4 and 6rd, there is no last link where the IID is exploited.

RD




> 
> cheers,
> Ole