[Softwires] MAP & 4rd-U - Robust Renumbering avoidance (V octet)

Rémi Després <despres.remi@laposte.net> Mon, 06 February 2012 09:18 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C754621F84D5 for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 01:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6Vy+6xFtsovL for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 01:18:02 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 19A1E21F84AA for <softwires@ietf.org>; Mon, 6 Feb 2012 01:18:01 -0800 (PST)
Received: from filter.sfr.fr (localhost []) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 461327000613; Mon, 6 Feb 2012 10:18:01 +0100 (CET)
Received: from [] (per92-10-88-166-221-144.fbx.proxad.net []) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 881BF7000087; Mon, 6 Feb 2012 10:18:00 +0100 (CET)
X-SFR-UUID: 20120206091800557.881BF7000087@msfrf2114.sfr.fr
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?= <despres.remi@laposte.net>
In-Reply-To: <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org>
Date: Mon, 6 Feb 2012 10:18:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4A250AB-99E5-4F78-BE49-D93475687FE8@laposte.net>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <C694D7DC-2F98-434F-8123-751E2C1A98D0@employees.org> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <B94D39A0-CA66-4AE6-BDC5-E4DFA2D47BEC@employees.org> <A8A6FDA2-0FFC-44D2-BEDF-29FB012D3113@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org>
To: =?iso-8859-1?Q?Ole_Tr=F8an?= <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: [Softwires] MAP & 4rd-U - Robust Renumbering avoidance (V octet)
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: Mon, 06 Feb 2012 09:18:02 -0000

Le 2012-02-06 à 09:33, Ole Trøan a écrit :
>>> MAP is more flexible with regards to not depending on the V octet.
>> (a) Which flexibility? To do what? 
> supports arbitrary end-user IPv6 prefix length, without regard for 'magic bits' in the interface-id.

If you have a use case where CEs need longer that /64 prefixes for native IPv6, I will look at them and comment.
If CE IPv6 prefixes longer than /64 are only used to convey CE IPv4 addresses, I don't see the problem of having these addresses always starting at bit 80. (It simplifies at least documentation and maintenance. Standardization is sometimes making simplifying choices when nothing functional is lost by making them.)

>> (b) Do you negate that:
>> - with MAP as is, an IPv6 site may have to change its assignment of subnet prefixes to support MAP
> only if the first subnet in the end-user IPv6 prefix is used by another internal router, that isn't going to act as a MAP CE.

"Only if", yes, but indeed in this case.
Having never to renumber is better than having to renumber in some cases, and better than having no residual IPv4 service on some subnets.

>> - This is never needed with 4rd-U, thanks to the V octet.
> renumbering is in any case going to happen in the home,

Not understood.
Renumbering should be avoided if it can (IMHO).

> and we have to design our protocols to deal with it.

> can we just agree to disagree on the V-octet, and not spend any more working group time on it?

Technical debate is finished if:
- You accept that never having to renumber is a useful feature, compared to having to do it in some cases.
- You avoid statements like "renumbering is in any case going to happen in the home" to negate value of renumbering avoidance.

> it would be good if you wrote up a more detailed analysis in a separate draft, so the considerations are kept somewhere.

I will write a comparison table.


> cheers,
> Ole