Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

Ole Trøan <otroan@employees.org> Sat, 04 February 2012 14:01 UTC

Return-Path: <ichiroumakino@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970BA21F853A for <softwires@ietfa.amsl.com>; Sat, 4 Feb 2012 06:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 khnEotqFCic7 for <softwires@ietfa.amsl.com>; Sat, 4 Feb 2012 06:01:01 -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 D5C7F21F852C for <softwires@ietf.org>; Sat, 4 Feb 2012 06:01:00 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so4163086wib.31 for <softwires@ietf.org>; Sat, 04 Feb 2012 06:01:00 -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=SDg2/qem4HNHNiXyCddFROUa4o4J5CCsGbdVwvTQ7R0=; b=ho53GNIRx21fR5vRKwjHMRwsxnDbzt5vxJ0s5KHiym5NwoUjJczMXtAxcrikB8jGlA EuH0sO8y1BRBwY+4u2EuoOR8JGH5iAjhFDb/yIg6yUAA0AcpeEcVuPK43ts2RHMnFw03 cYLuWtyPBUrlLOGxhw8rb8f9tb3k+foyKzEqQ=
Received: by 10.180.92.226 with SMTP id cp2mr17486952wib.10.1328364059995; Sat, 04 Feb 2012 06:00:59 -0800 (PST)
Received: from dhcp-10-55-92-208.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id p10sm13362137wic.0.2012.02.04.06.00.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 06:00:58 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= <otroan@employees.org>
In-Reply-To: <A128A101-FA41-47E2-A221-3FB2E329B128@laposte.net>
Date: Sat, 4 Feb 2012 15:00:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D3E4FAC-954D-4AA6-825D-64776F945488@employees.org>
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> <258788AA-60F6-4736-82C0-CA02D45D0805@huawei.com> <A128A101-FA41-47E2-A221-3FB2E329B128@laposte.net>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG <softwires@ietf.org>, Ralph Droms <rdroms@cisco.com>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Feb 2012 14:01:01 -0000

Remi,

>>>> I know we've discussed the V octet a lot earlier. I can't remember all the nuances we discussed. could you summarize, e.g. in the feature draft I suggested earlier.
>>> ...
>>> "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.  It can also facilitate maintenance by facilitating distinction between 4rd Tunnel packets and native-IPv6 packets.  Within CEs, IPv6 packets can safely be routed to the 4rd function based on a /80 prefix because no internal route for native IPv6 can have a destination prefix that start with this one." 
> 
>> Assume there is a CE Router with /32 IPv6 addresses in an enterprise network.
>> "based on a /80 prefix" for what? Would u elaborate or reword the last sentence for better understanding for readers like me? Merci.
> 
> If a CE has a /32 prefix, say p:p::/32, and some Mapping rule that derives an IPv4 prefix or address from it, all 4rd Tunnel packets sent to it have, according to the 4rd-U draft, an IPv6 destination starting with p:p:0:0:3000::/80.
> Within the CE, all packets whose destination start with this prefix can be routed, within the CE, to the 4rd function. 
> Native IPv6 packets are routed in the CE with prefixes that are either longer than the CE 4rd prefix and non-overlapping, or shorter. In both cases adding a route for the 4rd /80 doesn't impact how they are routed.
> Does this clarify?

so what you are saying is that for an End-User IPv6 prefix of /56. there will be 256 /80 routes?

cheers,
Ole