From jouni.nospam@gmail.com Thu Dec 1 02:14:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB121F8C49 for ; Thu, 1 Dec 2011 02:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpiFhzbl6Hxf for ; Thu, 1 Dec 2011 02:13:59 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6721F8C3F for ; Thu, 1 Dec 2011 02:13:59 -0800 (PST) Received: by eabm6 with SMTP id m6so2211945eab.31 for ; Thu, 01 Dec 2011 02:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=muRQXNJZo0G0O4QYwLzFoffAl/zp/kGmpHJfwPpbrCI=; b=DK5n/fuLihFHKfb9EQmFfr6rHsSkhrUdVS26XSuX40csGxWTSSFeuG8jBGnEB4q0K9 +vSuukHWflYCrTqDINDm7L+P1nVaf85BgIRkFCwS8A+hVB/2NQyMCMOKO+2/XmqKlFLd 2/tLXN+4Jw9b4+0MPEVX35ijg1DiLNY6SR0hc= Received: by 10.180.80.98 with SMTP id q2mr4327859wix.53.1322734437368; Thu, 01 Dec 2011 02:13:57 -0800 (PST) Received: from [10.255.128.228] ([192.100.123.77]) by mx.google.com with ESMTPS id gd6sm5422910wbb.1.2011.12.01.02.13.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 02:13:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Thu, 1 Dec 2011 12:13:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F38860B-C948-4C8D-B92B-F420647CAE30@gmail.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:14:00 -0000 Lorenzo, We got into this by the gentle guidance form IETF how to do it. It was = quite a long ago already.. and discussed quite extensively in DHC WG. = Now also part of Rel-10 in 3GPP. - Jouni On Nov 30, 2011, at 10:12 PM, Lorenzo Colitti wrote: > On Wed, Nov 30, 2011 at 12:03, V=EDzdal Ale=9A = wrote: > the Prefix Delegation RFC 3633 states a limitation in section 12.1 = that 'a prefix delegated to a requesting router cannot be used by the = delegating router'. This limitation is a problem for the 3GPP case where = they have standardised that the link prefix (/64) and the delegated = prefix shall be aggregatable to a single prefix. So, you can use = pd-exclude to signal the prefix part >=20 > in use. >=20 >=20 > Fine, but if the only problem is that text, then why do we need a new = option? Can't we just say somewhere that if the part of the prefix is = used to connect the requesting router to the network, then the network = MUST signal that to the client using some other means such as an RA?=20 From ichiroumakino@gmail.com Thu Dec 1 02:47:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8E21F8C00 for ; Thu, 1 Dec 2011 02:47:44 -0800 (PST) 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 ECKJ-IzIFITH for ; Thu, 1 Dec 2011 02:47:43 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44C21F8BF9 for ; Thu, 1 Dec 2011 02:47:42 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so2226366bkb.31 for ; Thu, 01 Dec 2011 02:47:42 -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=/bpPejZv5kRAyfYRUgNstq97BL5mKDNNedRrMuhImOg=; b=ZeUC0bZ7P/v4aaqggHqytJKt+t9Kkj8kejHRRzwb+ItbfHwozP1ebItqFxB7bCYv9w XF+nuRZLixB4pFXO1iEKcCeQQsSb92nUapbo6B0U8WZOZaXHsPadv6Brjvn+ysv3dEWN vTe/xbpcOpUwT48Dg3qpBtKBglatdNdOCZT0Y= Received: by 10.205.127.140 with SMTP id ha12mr617814bkc.51.1322736462114; Thu, 01 Dec 2011 02:47:42 -0800 (PST) Received: from dhcp-10-61-105-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id iu9sm10514744bkc.0.2011.12.01.02.47.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 02:47:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: Date: Thu, 1 Dec 2011 11:47:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:47:44 -0000 Lorenzo, > > Why using =93some other means=94 when you can achieve this behavior = with just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option? >=20 > indeed. you can't first delegate a prefix to some other administrative = entity, and then expect to be able to take that back without explicit = signaling. if you did this through an RA or a routing protocol or some = other means, you still have to handle potential conflicts. signalling up = front is a lot cleaner and it avoids the corner cases. >=20 > Signaling exclusion by itself is not sufficient, because you also need = to tell the requesting router where the excluded prefix is. no. > For example, what is an implementation supposed to do if it gets a PD = of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the = next hop for 2001:db8:1:2::/64? Discard? It needs to know, at least for = the purpose of sending unreachables. normal RIB lookup. i.e. will follow default. > Since you need to tell the requesting router where the prefix is = anyway, you might as well just tell it where it is and not bother to = tell it that the prefix is excluded. cheers, Ole From ichiroumakino@gmail.com Thu Dec 1 02:52:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E935F21F8B59 for ; Thu, 1 Dec 2011 02:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 3GIgj4WzR1wv for ; Thu, 1 Dec 2011 02:52:05 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED421F8B5C for ; Thu, 1 Dec 2011 02:52:05 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so2232225bkb.31 for ; Thu, 01 Dec 2011 02:52:04 -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=NMe6UjjaJSSdC1P5TPT0ZGobUZUgisasOoupgCo+X7U=; b=HUjfwuKXYsgz7QTCLHt7nsuyqv+/TqL6bVq0ox4JeRBSCEA+YXAfd/aLOj0x/i+gAX 2h9RlkNxBKESUsEeZaUd2zkiQ+YNKlLgDH2KlZ2zKYwRgdKBsiFPgLUeeFCgbGAJ615D OIrJtNbbOZ7sc8ch6kXPUCjuX+B8mS2rhHth8= Received: by 10.204.152.83 with SMTP id f19mr6745855bkw.90.1322736723016; Thu, 01 Dec 2011 02:52:03 -0800 (PST) Received: from dhcp-10-61-105-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm10485148bkv.9.2011.12.01.02.52.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 02:52:01 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com> Date: Thu, 1 Dec 2011 11:51:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D42CADA-0FC9-4211-8406-A345F3D47C42@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DEC 865F895@ employees.or g> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:52:06 -0000 Hemant, > >For example, what is an implementation supposed to do if it gets a PD = of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the = next hop for 2001:db8:1:2::/64? > =20 > If I read the exclude document = (http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude-03), I see that = the /64 above is used on the RR for the link between the RR and the DR. = Since the DR is the first-hop router for the RR (section 3 of the = exclude document says so), the next-hop for the global /64 above is the = IPv6 link-local address of the DR. See also this text from section 6.1 = of the exclude document. that's not what pd-exclude says. the excluded prefix is _not_ delegated = to the RR. > [The requesting router must create sink routes for the delegated > prefixes minus the excluded prefixes. This may be done by creating > sink routes for delegated prefixes and more specific routes for the > excluded prefixes.] > =20 > I could use a /128 from the excluded /64 on any virtual interface to = source ICMPv6 errors. not on the RR no. unless the excluded prefix is signaled in e.g. an RA = from the DR. cheers, Ole= From mark@townsley.net Thu Dec 1 03:22:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F1B21F8B81 for ; Thu, 1 Dec 2011 03:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=0.275, 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 SyImUXvR86jd for ; Thu, 1 Dec 2011 03:22:35 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8038721F8B03 for ; Thu, 1 Dec 2011 03:22:34 -0800 (PST) Received: by eabm6 with SMTP id m6so2301929eab.31 for ; Thu, 01 Dec 2011 03:22:32 -0800 (PST) Received: by 10.213.15.203 with SMTP id l11mr439401eba.126.1322738552062; Thu, 01 Dec 2011 03:22:32 -0800 (PST) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 49sm16569409eec.1.2011.12.01.03.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 03:22:30 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary=Apple-Mail-5-833964638 Date: Thu, 1 Dec 2011 12:22:28 +0100 Message-Id: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> To: "v6ops@ietf.org Operations" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [v6ops] Section 4.4 of 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 11:22:37 -0000 --Apple-Mail-5-833964638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I finally got a chance to go through section 4.4 and provide specific = comments. In short, it should come as no surprise that I think this = section needs work. Please see inline as well as the conclusion towards = the end. Thanks, - Mark > 4.4. Transition Technologies Support >=20 > 4.4.1. 6rd >=20 > The IPv6 CE Router can be used to offer IPv6 service to a LAN, even > when the WAN access network only supports IPv4. One technology = that > supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment > (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside > IPv4 at the IPv6 CE Router and sends it to a Service Provider = Border > Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6 > prefix during 6rd configuration, and sub-delegates the 6rd = delegated > prefix to devices in the LAN. IMHO, the above is just making the document longer. You can simply = include the sentence below. RFC 5969 is a normative, so you can rely on = the reader to go read it.=20 > The IPv6 CE Router SHOULD implement 6rd functionality as specified = in > [RFC5969]. >=20 > 6rd requirements: >=20 > 6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE > Router WAN interface MUST support at least one 6rd Virtual > Interface. 6rd is implemented with a "6rd virtual interface" (see terminology = section of RFC 5969) which is not bound to a WAN interface as you are = suggesting in this requirement. I would remove the requirement = altogether, as it is part of RFC 5969 anyway, and by re-specifying we = run the risk of introducing inconsistencies.=20 > 6RD-2: If the IPv6 CE router implements 6rd functionality, it MUST > support 6rd configuration via the 6rd DHCPv4 Option (212) = and > if the IPv6 CE router is capable of automated configuration > of IPv4 through IPCP (i.e., over a PPP connection), it MUST > support user-entered configuration of 6rd. =20 Why not just say it MUST support DHCPv4 option 212 and Manual = configuration and stop at that? If we are going to include manual = config, it is effectively *always* an option, not just for PPP or any = other type of access link. Just make it a MUST and be done. Further, if we are going to mention PPP, rather than falling back to = manual only, why not allow DHCP configuration after PPP IPCP is = finished? =46rom RFC2131: "DHCPINFORM - Client to server, asking only for local = configuration parameters; client already has externally configured = network address." Back when the PPP folks actively decided to stop duplicating DHCP = functionality in IPCP, this was the recommended approach (and Windows = stacks and the like actually try to obtain additional parameters for PPP = connections after IPCP comes up, though often the network does not have = any additional parameters to give...). This gives PPP connections a = pretty decent chance to work with 6rd automatically, using the same DHCP = configuration as non-PPP.=20 > The IPv6 CE > router MAY use other mechanisms to configure 6rd = parameters. > Such mechanisms are outside the scope of this document. Seems obvious, but OK.=20 > 6RD-3: If the CE router implements 6rd functionality, it MUST = allow > the user to specify whether all IPv6 traffic goes to the = 6rd > Border Relay, or whether IPv6 traffic to other destinations > within the same 6rd domain are routed directly to those >=20 >=20 >=20 > Singh, et al. Expires May 25, 2012 [Page = 13] > =20 > Internet-Draft IPv6 CE Router Requirements November = 2011 >=20 >=20 > destinations. The CE router MAY use other mechanisms to > configure this. Such mechanisms are outside the scope of > this document. Do you really mean the "user" is supposed to be able to specify whether = IPv6 traffic always going through the BR, or the "operator" is supposed = to be able to specify this? This behavior, while straight-forward to implement as it is effectively = removing a more-specific route on the 6rd virtual interface, is out of = scope of RFC 5969 as currently defined. There is no way to specify this = in DHCPv4 configuration. One might be able to configure this from the = network with PIO or DHCPv6 route options in a general manner, but this = hasn't been specified anywhere that I am aware of within the context of = 6rd. I understand the BBF has included some specifics around this, and = perhaps it is best if those requirements stay in the BBF or at least we = provide a reference to them from here. Otherwise, this requirement = remains under-specified as written, and if expounded would effectively = be an update (in the formal sense) to RFC 5969.=20 > 6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data > MUST NOT be sent on any 6rd tunnel. As long as the high-level requirement is RFC 5969 only, there is no need = to mention multicast. If in the future someone implements 6rd multicast = (there are drafts on it), why stop them? Best to just remove this = (non-)requirement from the document. > 6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite > ([RFC6333]) tunnel. Again, why over-specify? Sure, the operational steps you take should not = lead you down this path, but if the router is following a logical set of = routing and virtual interface constructs, this would just work. Why make = the CE vendor go out of their way to check to see if this is happening = and drop packets?=20 > 4.4.2. Dual-Stack Lite(DS-Lite) >=20 > Even as users migrate from IPv4 to IPv6 addressing, a significant > percentage of Internet resources and content will remain accessible > only through IPv4. Also, many end-user devices will only support > IPv4. As a consequence, Service Providers require mechanisms to > allow customers to continue to access content and resources using > IPv4 even after the last IPv4 allocations have been fully depleted. > One technology that can be used for IPv4 address extension is DS- > Lite. >=20 > DS-Lite enables a Service Provider to share IPv4 addresses among > multiple customers by combining two well-known technologies: IP in = IP > (IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically, > Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at > the IPv6 CE Router and sends it to a Service Provider Address = Family > Transition Router (AFTR). Configuration of the IPv6 CE Router to > support IPv4 LAN traffic is outside the scope of this document. >=20 IMHO - As with the 6rd "summary" text, I think the most important line = is the following one, and the previous paragraphs may be omitted or = shrunk to one or two lines at best.=20 > The IPv6 CE Router SHOULD implement DS-Lite functionality as > specified in [RFC6333]. >=20 > WAN requirements: >=20 > DLW-1: To facilitate IPv4 extension over an IPv6 network, if the = CE > Router supports DS-Lite functionality, the CE Router WAN > interface MUST implement a B4 Interface as specified in > [RFC6333]. As with the "6rd interface" case, this really seems repetitive. It = should be sufficient to say "implement DS-Lite" ... Also, virtual = interfaces are not tied to any physical interfaces per se, they exist = independently. They may be used for WAN connectivity, but they are a = fully separate interface in terms of the RIB and such.=20 >=20 > DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the > CE Router MUST support using a DS-Lite DHCPv6 option > [RFC6334] to configure the DS-Lite tunnel. The IPv6 CE > Router MAY use other mechanisms to configure DS-Lite > parameters. Such mechanisms are outside the scope of this > document. >=20 >=20 >=20 >=20 >=20 >=20 > Singh, et al. Expires May 25, 2012 [Page = 14] > =20 > Internet-Draft IPv6 CE Router Requirements November = 2011 >=20 >=20 > DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address > Translation (NAT) on IPv4 traffic encapsulated using = DS-Lite. >=20 > DLW-4: If the IPv6 CE Router is configured with a public IPv4 > address on its WAN interface, where public IPv4 address is > defined as any address which is not in the private IP = address > space specified in [RFC5735], then the IPv6 CE Router = SHOULD > disable the DS-Lite B4 element. This is very bad direction. DS-Lite was designed to combat Private IPv4 Address Exhaustion, and you = have a requirement that talks about the CPE receiving not only a Public = but a Private IPv4 address and tying specific behavior to that?=20 Where is the requirement that if DS-Lite is configured, the CPE should = not be expected to receive an IPv4 address at all on its WAN interface = so that it doesn't hammer the network asking for one? Or, (and perhaps = this is better) the recommended way for DHCPv4 (and PPP IPCP) to tell = the CPE that it has no IPv4 and not to ask for it (so we don't repeat = the "DHCPv6 storm" problem talked about so much here)?=20 That's what we should be defining here, or you have hamstrung the whole = point of DS-Lite which was to reduce the number of IPv4 addresses = (public or private!) needed by the access network. The CPE MUST be able = to operate in the *absence* of an IPv4 address on its WAN interface! = That's the requirement we need here! Also, specific nits on the above wording (though I think the whole = requirement is in question):=20 - "RFC 5735 private IP address space" is just an indirection to RFC = 1918, just call it RFC 1918.=20 - I see a possible conflict here with the /10 space that may or may not = be allocated for CGN deployment. >=20 > DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast > data MUST NOT be sent on any DS-Lite tunnel. Why not? As with the similar 6rd requirement, please just leave this = out. Why hamstring future efforts to define multicast here? >=20 > DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD > tunnel. Why make a requirement on the forwarding path here? Sure, it is probably = bad operational practice to configure a CE such that it would end up = with a routing path that did this, but this kind of requirement forces = the CE to actually check on the forwarding path whether this is = occurring and drop the packet if it does. A CE could easily misinterpret = this as filtering all Protocol 41 traffic. Not to mention, this could = end up becoming a test case for certification.=20 In general: Let's please avoid making any sort of laundry lists of MUST = NOTs around negative cases. We're better off defining MUSTs for things = we want to happen.=20 >=20 > 4.4.3. Transition Technologies Coexistence >=20 > Supporting transition technologies that may coexist with native > service requires control over provisioning and sunsetting. Some > guidelines follow: >=20 > 1. Initiate native IPv4/IPv6 provisioning (e.g. via DHCP) > simultaneously. >=20 > 2. After IPv4 provisioning completes, if 6rd parameters are = obtained > from the DHCPv4 transaction or configured on the device, = initiate > 6rd. >=20 > 3. After IPv6 provisioning completes, if DS-Lite parameters are > obtained from the DHCPv6 transaction or configured on the = device, > initiate DS-Lite. >=20 > 4. Routes over the DS-Lite tunnel always have a higher > administrative distance than native IPv4 routes. higher or lower? Do you want traffic to prefer native or tunneled here? = I read this as preferring native IPv4, but perhaps the real goal is to = prefer IPv6? >=20 > 5. Selection of 6rd tunnel or native IPv6 output interface on the = CE > router is determined by the source IPv6 address of the packet > from a host, when different prefixes are available over 6rd vs. > native IPv6. If the two interfaces provide the CE router with > the same prefix, then the CE router prefers the native IPv6 > interface to the 6rd interface for forwarding traffic out the = WAN > when both 6rd and native IPv6 interfaces are active. This is close, but I think it would be much better to define the = multihoming requirements generically and have 6rd just be one special = case.=20 >=20 > 6. The CE router messages to the host the use of native IPv6 in > preference to 6rd, in the case where the two interfaces use > different prefixes. "CE router messages to the host" - with what, a new protocol? The host = does what it wants with the prefixes it has, the router is a slave to = its source selection and has to route out the appropriate interface = accordingly. This is "the curse of end-to-end" to quote Lorenzo.=20 >=20 > During a sunsetting activity such as deprecating 6rd and moving to >=20 >=20 >=20 > Singh, et al. Expires May 25, 2012 [Page = 15] > =20 > Internet-Draft IPv6 CE Router Requirements November = 2011 >=20 >=20 > native IPv6, the IPv6 CE router MUST immediately advertise the 6rd > prefix with a Preferred Lifetime of zero and a Valid Lifetime of = the > lower of the current Valid Lifetime and two hours (which must be > decremented in real time) in a Router Advertisement message as > described in Section 5.5.3, (e) of [RFC4862]. =20 "The CE route MUST immediately advertise the 6rd prefix.... " when? = when "during a sunsetting activity" ? How do you trigger that in = software? As an implementor, I would have no idea what this MUST really = means.=20 The heart of the problem here is *over-specification*. All the CPE needs = to do is to deprecate the address when its lifetime expires just like = any other prefix. This will happen naturally once the DHCPv4 lease that = 6rd was provisioned with expires and no new 6rd option arrives with the = renewal (if there is any MUST needed, it's at this stage). So: No = special cases. No immediate interrupts to do this or that. No new case() = statements specifically for 6rd, 6rd+native, 6rd+native+ds-lite, etc. = Just the normal code run through when interfaces come up and down and = prefixes are timed out. Nothing special. No surprises. > Due to the two hours > rule specified in [RFC4862], the 6rd and the native IPv6 prefix = will > coexist in the home network. The two hours rule specified in = section > 5.5.3 of [RFC4862] causes any deprecated prefix to linger on the = node > even when an RA has sent a Preferred Lifetime of zero to expire the > prefix to the node. During such coexistence of multiple prefixes, > the CE router sends an ICMPv6 error for packets sourced or destined > related to the deprecated prefix. Note this document already > includes text in bullet L-14 in section 4.3 for such a provision. Pointing out the two hour issue is fine, as well as what to do with = deprecated prefixes, but this is *all* normal mutlihoming/renumbering = procedures. We would be far better off defining this generally, and = letting 6rd + native just fall in line happily as any other case where = there are two interfaces with prefixes assigned.=20 I'm afraid that the requirements as written will lead to a lot of = inconsistency. Let's please reuse basic routing design constructs and = apply defaults as we need them. For example: When DS-Lite is configured, it is represented as a virtual interface = that happens to only have IPv4 configured on it. When 6rd is configured = it is an interface that just happens to only have IPv6 configured on it. = If the ISP configures native IPv4 at the same time, that's it's = business. If the ISP configures native IPv6 at the same time, that's = also it's business. The CPE should accept these configurations, = advertise prefixes and assign addressed on the LAN side accordingly, and = then ensure that when packets are sent upstream they get sent to the = right native or virtual interface (and associated RIB) and forwarded = accordingly. The upstream decisions are based on source routing, longest = prefix match, and metrics for each of the interfaces for which we define = the defaults for. The virtual interfaces handle how to encap, decap, = NAT, not-NAT, etc.=20 I think this approach will lead to a much simpler set of specific = requirements, far more consistency of behavior, and resiliency in the = face of variant operational approaches.=20 - Mark --Apple-Mail-5-833964638 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
4.4.  Transition =
Technologies Support



4.4.1.  6rd


   The IPv6 CE Router can be used to offer IPv6 service to a LAN, even
   when the WAN access network only supports IPv4.  One technology that
   supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment
   (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside
   IPv4 at the IPv6 CE Router and sends it to a Service Provider Border
   Relay (BR).  The IPv6 CE Router calculates a 6rd delegated IPv6
   prefix during 6rd configuration, and sub-delegates the 6rd delegated
   prefix to devices in the LAN.

IMHO, the above is just making = the document longer. You can simply include the sentence below. RFC 5969 = is a normative, so you can rely on the reader to go read = it. 

   The =
IPv6 CE Router SHOULD implement 6rd functionality as specified in
   [RFC5969].

   6rd requirements:

   6RD-1:  If the IPv6 CE Router implements 6rd functionality, the CE
           Router WAN interface MUST support at least one 6rd Virtual
           Interface.

6rd is implemented with a "6rd = virtual interface" (see terminology section of RFC 5969) which is not = bound to a WAN interface as you are suggesting in this requirement. I = would remove the requirement altogether, as it is part of RFC 5969 = anyway, and by re-specifying we run the risk of introducing = inconsistencies. 


   6RD-2:  If the IPv6 CE router =
implements 6rd functionality, it MUST
           support 6rd configuration via the 6rd DHCPv4 Option (212) and
           if the IPv6 CE router is capable of automated configuration
           of IPv4 through IPCP (i.e., over a PPP connection), it MUST
           support user-entered configuration of 6rd.  =

Why not just say it MUST support = DHCPv4 option 212 and Manual configuration and stop at that? If we = are going to include manual config, it is effectively *always* an = option, not just for PPP or any other type of access link. Just make it = a MUST and be done.

Further, if we are going to = mention PPP, rather than falling back to manual only, why not allow DHCP = configuration after PPP IPCP is = finished?

From RFC2131: "DHCPINFORM =   -  Client to server, asking only for local = configuration parameters; client already has externally = configured network address."

Back when the = PPP folks actively decided to stop duplicating DHCP functionality in = IPCP, this was the recommended approach (and Windows stacks and the like = actually try to obtain additional parameters for PPP connections after = IPCP comes up, though often the network does not have any additional = parameters to give...). This gives PPP connections a pretty decent = chance to work with 6rd automatically, using the same DHCP configuration = as non-PPP. 


The IPv6 CE
           router MAY use other mechanisms to configure 6rd parameters.
           Such mechanisms are outside the scope of this document.

Seems obvious, but = OK. 

   =
6RD-3:  If the CE router implements 6rd functionality, it MUST allow
           the user to specify whether all IPv6 traffic goes to the 6rd
           Border Relay, or whether IPv6 traffic to other destinations
           within the same 6rd domain are routed directly to those



Singh, et al. =
            Expires May 25, 2012                 [Page 13]

 =



This behavior, while straight-forward to =
implement as it is effectively removing a more-specific route on the 6rd =
virtual interface, is out of scope of RFC 5969 as currently defined. =
There is no way to specify this in DHCPv4 configuration. One might be =
able to configure this from the network with PIO or DHCPv6 route options =
in a general manner, but this hasn't been specified anywhere that I am =
aware of within the context of 6rd. I understand the BBF has included =
some specifics around this, and perhaps it is best if those requirements =
stay in the BBF or at least we provide a reference to them from here. =
Otherwise, this requirement remains under-specified as written, and if =
expounded would effectively be an update (in the formal sense) to RFC =
5969. 

   =
6RD-4:  If 6rd is operational on the IPv6 CE Router, multicast data
           MUST NOT be sent on any 6rd tunnel.


As long as the high-level =
requirement is RFC 5969 only, there is no need to mention multicast. If =
in the future someone implements 6rd multicast (there are drafts on it), =
why stop them? Best to just remove this (non-)requirement from the =
document.

   =
6RD-5:  The CE Router MUST NOT forward 6RD traffic over a DS-Lite
           ([RFC6333]) tunnel.


Again, why over-specify? Sure, =
the operational steps you take should not lead you down this path, but =
if the router is following a logical set of routing and virtual =
interface constructs, this would just work. Why make the CE vendor go =
out of their way to check to see if this is happening and drop =
packets? 

4.4.2.  Dual-Stack Lite(DS-Lite)


   Even as users migrate from IPv4 to IPv6 addressing, a significant
   percentage of Internet resources and content will remain accessible
   only through IPv4.  Also, many end-user devices will only support
   IPv4.  As a consequence, Service Providers require mechanisms to
   allow customers to continue to access content and resources using
   IPv4 even after the last IPv4 allocations have been fully depleted.
   One technology that can be used for IPv4 address extension is DS-
   Lite.

   DS-Lite enables a Service Provider to share IPv4 addresses among
   multiple customers by combining two well-known technologies: IP in IP
   (IPv4-in-IPv6) tunneling and Carrier Grade NAT.  More specifically,
   Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
   the IPv6 CE Router and sends it to a Service Provider Address Family
   Transition Router (AFTR).  Configuration of the IPv6 CE Router to
   support IPv4 LAN traffic is outside the scope of this document.



IMHO - As with the 6rd "summary" =
text, I think the most important line is the following one, and the =
previous paragraphs may be omitted or shrunk to one or two lines at =
best. 


   The IPv6 CE Router SHOULD implement =
DS-Lite functionality as
   specified in [RFC6333].

   WAN requirements:

   DLW-1:  To facilitate IPv4 extension over an IPv6 network, if the CE
           Router supports DS-Lite functionality, the CE Router WAN
           interface MUST implement a B4 Interface as specified in
           [RFC6333].


As with the "6rd interface" case, =
this really seems repetitive. It should be sufficient to say "implement =
DS-Lite" ... Also, virtual interfaces are not tied to any physical =
interfaces per se, they exist independently. They may be used for WAN =
connectivity, but they are a fully separate interface in terms of the =
RIB and such. 

   DLW-2:  If the IPv6 CE Router implements DS-Lite functionality, the
           CE Router MUST support using a DS-Lite DHCPv6 option
           [RFC6334] to configure the DS-Lite =
tunnel.  The IPv6 CE
           Router MAY use other mechanisms to configure DS-Lite
           parameters.  Such mechanisms are outside the scope of this
           document.






Singh, et al. =
            Expires May 25, 2012                 [Page 14]

 =

RFC5735], then the IPv6 CE Router SHOULD
           disable the DS-Lite B4 element.


This is very bad =
direction.

DS-Lite was designed to combat =
Private IPv4 Address Exhaustion, and you have a requirement that talks =
about the CPE receiving not only a Public but a Private IPv4 address and =
tying specific behavior to that? 

Where is =
the requirement that if DS-Lite is configured, the CPE should not be =
expected to receive an IPv4 address at all on its WAN interface so that =
it doesn't hammer the network asking for one? Or, (and perhaps this is =
better) the recommended way for DHCPv4 (and PPP IPCP) to tell the CPE =
that it has no IPv4 and not to ask for it (so we don't repeat the =
"DHCPv6 storm" problem talked about so much =
here)? 

That's what we should be defining =
here, or you have hamstrung the whole point of DS-Lite which was to =
reduce the number of IPv4 addresses (public or private!) needed by the =
access network. The CPE MUST be able to operate in the *absence* of an =
IPv4 address on its WAN interface! That's the requirement we need =
here!

Also, specific nits on the above wording =
(though I think the whole requirement is in =
question): 

- "RFC 5735 private IP address =
space" is just an indirection to RFC 1918, just call it RFC =
1918. 
- I see a possible conflict here with the /10 =
space that may or may not be allocated for CGN =
deployment.


   DLW-5:  If DS-Lite is operational on the IPv6 CE Router, multicast
           data MUST NOT be sent on any DS-Lite tunnel.


Why not? As with the similar 6rd =
requirement, please just leave this out. Why hamstring future efforts to =
define multicast here?


   DLW-6:  The CE Router MUST NOT forward DS-Lite traffic over a 6RD
           tunnel.


Why make a requirement on the =
forwarding path here? Sure, it is probably bad operational practice to =
configure a CE such that it would end up with a routing path that did =
this, but this kind of requirement forces the CE to actually check on =
the forwarding path whether this is occurring and drop the packet if it =
does. A CE could easily misinterpret this as filtering all Protocol 41 =
traffic. Not to mention, this could end up becoming a test case for =
certification. 

In general: Let's please =
avoid making any sort of laundry lists of MUST NOTs around negative =
cases. We're better off defining MUSTs for things we want to =
happen. 

4.4.3.  Transition Technologies =
Coexistence


   Supporting transition technologies that may coexist with native
   service requires control over provisioning and sunsetting.  Some
   guidelines follow:

   1.  Initiate native IPv4/IPv6 provisioning (e.g. via DHCP)
       simultaneously.

   2.  After IPv4 provisioning completes, if 6rd parameters are obtained
       from the DHCPv4 transaction or configured on the device, initiate
       6rd.

   3.  After IPv6 provisioning completes, if DS-Lite parameters are
       obtained from the DHCPv6 transaction or configured on the device,
       initiate DS-Lite.

   4.  Routes over the DS-Lite tunnel always have a higher
       administrative distance than native IPv4 routes.


higher or lower? Do you want =
traffic to prefer native or tunneled here? I read this as preferring =
native IPv4, but perhaps the real goal is to prefer =
IPv6?

   5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
       router is determined by the source IPv6 address of the packet
       from a host, when different prefixes are available over 6rd vs.
       native IPv6.  If the two interfaces provide the CE router with
       the same prefix, then the CE router prefers the native IPv6
       interface to the 6rd interface for forwarding traffic out the WAN
       when both 6rd and native IPv6 interfaces are =
active.

This is close, but I think =
it would be much better to define the multihoming requirements =
generically and have 6rd just be one special =
case. 

   6.  The CE router messages to the host the use of native IPv6 in
       preference to 6rd, in the case where the two interfaces use
       different prefixes.


"CE router messages to the host" =
- with what, a new protocol? The host does what it wants with the =
prefixes it has, the router is a slave to its source selection and has =
to route out the appropriate interface accordingly. This is "the curse =
of end-to-end" to quote Lorenzo. 

   During a sunsetting activity such as deprecating 6rd and moving to



Singh, et al. =
            Expires May 25, 2012                 [Page 15]

 =

Section 5.5.3, (e) of [RFC4862].  =


"The CE route MUST immediately =
advertise the 6rd prefix.... "  when? when "during a sunsetting =
activity" ? How do you trigger that in software? As an implementor, =
I would have no idea what this MUST really =
means. 

The heart of the problem here is =
*over-specification*. All the CPE needs to do is to deprecate the =
address when its lifetime expires just like any other prefix. This will =
happen naturally once the DHCPv4 lease that 6rd was provisioned with =
expires and no new 6rd option arrives with the renewal (if there is any =
MUST needed, it's at this stage). So: No special cases. No immediate =
interrupts to do this or that. No new case() statements specifically for =
6rd, 6rd+native, 6rd+native+ds-lite, etc. Just the normal code run =
through when interfaces come up and down and prefixes are timed out. =
Nothing special. No surprises.

Due to the two hours
   rule specified in [RFC4862], the 6rd and the native IPv6 =
prefix will
   coexist in the home network.  The two hours rule specified in section
   5.5.3 of [RFC4862] causes any deprecated prefix to =
linger on the node
   even when an RA has sent a Preferred Lifetime of zero to expire the
   prefix to the node.  During such coexistence of multiple prefixes,
   the CE router sends an ICMPv6 error for packets sourced or destined
   related to the deprecated prefix.  Note this document already
   includes text in bullet L-14 in section 4.3 for such a provision.


Pointing out the two hour issue is =
fine, as well as what to do with deprecated prefixes, but this is *all* =
normal mutlihoming/renumbering procedures. We would be far better off =
defining this generally, and letting 6rd + native just fall in line =
happily as any other case where there are two interfaces with prefixes =
assigned. 

I'm afraid that the =
requirements as written will lead to a lot of inconsistency. Let's =
please reuse basic routing design constructs and apply defaults as we =
need them. For example:

When DS-Lite is =
configured, it is represented as a virtual interface that happens to =
only have IPv4 configured on it. When 6rd is configured it is an =
interface that just happens to only have IPv6 configured on it. If the =
ISP configures native IPv4 at the same time, that's it's business. If =
the ISP configures native IPv6 at the same time, that's also it's =
business. The CPE should accept these configurations, advertise prefixes =
and assign addressed on the LAN side accordingly, and then ensure that =
when packets are sent upstream they get sent to the right native or =
virtual interface (and associated RIB) and forwarded accordingly. The =
upstream decisions are based on source routing, longest prefix match, =
and metrics for each of the interfaces for which we define the defaults =
for. The virtual interfaces handle how to encap, decap, NAT, not-NAT, =
etc. 

I think this approach will =
lead to a much simpler set of specific requirements, far more =
consistency of behavior, and resiliency in the face of variant =
operational approaches. 

- =
Mark




=

--Apple-Mail-5-833964638--

From shemant@cisco.com  Thu Dec  1 06:02:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3163221F8783 for ; Thu,  1 Dec 2011 06:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  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 ZnM8iSqBQRCh for ; Thu,  1 Dec 2011 06:02:31 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F2EDE1F0CBC for ; Thu,  1 Dec 2011 06:02:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=770; q=dns/txt; s=iport; t=1322748133; x=1323957733; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WJ8JbyeySwZkWD+PQ0IN2+pSwnduIsJBfLd9rKRDcyo=; b=jopfCsVX9EumzuEqcOeWYvOJq/YHFxDgoK1LrFb8EW/RMErRyBuWoHtZ +84o3nHME2gZMdEwuXKBmkx3sARf6iGNxXKjh2YoQxqD4sgWI1oW+dEyU AZzyqu5KQyHrYJAoZNg2PI+j9z/ufmokPkaGwoBSEjZ/lYh95aA+d6IMU w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhABABEppk6tJXG9/2dsb2JhbACQRY4WeJRVkjSGGQSGUI15hBOGSQ
X-IronPort-AV: E=Sophos;i="4.69,603,1315180800"; d="scan'208";a="37820862"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 01 Dec 2011 14:02:12 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1E2CJq011219;  Thu, 1 Dec 2011 14:02:12 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 08:02:12 -0600
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: Thu, 1 Dec 2011 08:02:11 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE2E1@XMB-RCD-109.cisco.com>
In-Reply-To: <7D42CADA-0FC9-4211-8406-A345F3D47C42@employees.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcywF0Owffvpe40cTVSVGk6v1H8rBwAGaAOg
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com> <7D42CADA-0FC9-4211-8406-A345F3D47C42@employees.org>
From: "Hemant Singh (shemant)" 
To: "Ole Troan" 
X-OriginalArrivalTime: 01 Dec 2011 14:02:12.0336 (UTC) FILETIME=[D2CBCF00:01CCB031]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 14:02:32 -0000

Ole,

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Thursday, December 01, 2011 5:52 AM
Cc: Lorenzo Colitti; v6ops@ietf.org; jouni korhonen
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt


>that's not what pd-exclude says. the excluded prefix is _not_ delegated
to the RR.

OK.  However the excluded prefix is used by the DR on the link to the RR
and the DR is the first-hop router to the RR.  So why wouldn't the RR
and DR be on-link for the excluded prefix?  Or does the exclude document
assume a unnumbered WAN? =20

>not on the RR no. unless the excluded prefix is signaled in e.g. an RA
from the DR.

I had assumed the fact.  See my on-link response above.

Hemant

From jouni.nospam@gmail.com  Thu Dec  1 06:40:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C211E835C for ; Thu,  1 Dec 2011 06:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UpTMStqAvNB for ; Thu,  1 Dec 2011 06:40:03 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7911E80D5 for ; Thu,  1 Dec 2011 06:40:02 -0800 (PST)
Received: by eabm6 with SMTP id m6so2553825eab.31 for ; Thu, 01 Dec 2011 06:40:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c3Nzg1A+XoqItGCHJzCiMsDoueJH/znojUKNwHIXJek=; b=r3K3BB5ys6EpHhYpuTtzshTBvF377LwqTszy3bcaug0PHXgiDZ5SWP4vMg5eLHP5V6 jZ3e9KchU1DKjvj5VFoCmfQGZsM9VPU+2NZ5iRGmfaMlF4kInZtJmjYKEjHWZ5Ij3mfr HmYru0DQCHanavpP3qwzAHLQhHmZmnjKvVKJw=
Received: by 10.213.10.145 with SMTP id p17mr561774ebp.43.1322750401069; Thu, 01 Dec 2011 06:40:01 -0800 (PST)
Received: from [10.255.135.253] ([192.100.123.77]) by mx.google.com with ESMTPS id 58sm13420326eet.11.2011.12.01.06.39.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 06:39:59 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: jouni korhonen 
In-Reply-To: <4ED698D6.5090305@gmail.com>
Date: Thu, 1 Dec 2011 16:39:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com>
References: 			<2963F168-45CB-4042-8238-56DF538B0543@gmail.com>			<2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com>	<1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>	<8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>			<1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <4ED698D6.5090305@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 14:40:03 -0000

Brian,

Getting that happen is quite unlikely. Rel-10 is already frozen.

- Jouni


On Nov 30, 2011, at 10:57 PM, Brian E Carpenter wrote:

> On 2011-12-01 09:12, Lorenzo Colitti wrote:
>> On Wed, Nov 30, 2011 at 12:03, V=EDzdal Ale=9A =
 wrote:
>>=20
>>> the Prefix Delegation RFC 3633 states a limitation in section 12.1 =
that 'a
>>> prefix delegated to a requesting router cannot be used by the =
delegating
>>> router'. This limitation is a problem for the 3GPP case where they =
have
>>> standardised that the link prefix (/64) and the delegated prefix =
shall be
>>> aggregatable to a single prefix. So, you can use pd-exclude to =
signal the
>>> prefix part in use.
>>>=20
>>=20
>> Fine, but if the only problem is that text, then why do we need a new
>> option? Can't we just say somewhere that if the part of the prefix is =
used
>> to connect the requesting router to the network, then the network =
MUST
>> signal that to the client using some other means such as an RA?
>=20
> Better would be for someone who visits 3GPP land to persuade them to =
remove
> that restriction, which is obviously annoying.
>=20
>    Brian
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From ichiroumakino@gmail.com  Thu Dec  1 06:55:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E338711E83EA for ; Thu,  1 Dec 2011 06:55:19 -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 izdxT7YWWBWB for ; Thu,  1 Dec 2011 06:55:19 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 394D211E83D8 for ; Thu,  1 Dec 2011 06:55:19 -0800 (PST)
Received: by eabm6 with SMTP id m6so2573736eab.31 for ; Thu, 01 Dec 2011 06:55:18 -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=02BRKII8TaiMHX/6U7k2WsTFWtxtsWz+qF0EaOlrrFI=; b=H1GsdoITd2PNZfrt1nzi75JzMeKYo/kTPgbw82N5OWl9nknFAyUnUcRRUkXWbaw21X IAtF96g8iZ58tMQhHkU9yy5fy6O94nJ3eMteLw9ormDc+oFLvPMsksnmjQFsXN591TzH NhwCVLcYW4cZJWpzL073Hhj56NbuaX00EWi48=
Received: by 10.213.13.65 with SMTP id b1mr1159697eba.86.1322751290132; Thu, 01 Dec 2011 06:54:50 -0800 (PST)
Received: from dhcp-10-61-105-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id c9sm16367943eeb.0.2011.12.01.06.54.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 06:54:49 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE2E1@XMB-RCD-109.cisco.com>
Date: Thu, 1 Dec 2011 15:54:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A022663-4505-4EE5-8AF6-893322E2A264@employees.org>
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com> <7D42CADA-0FC9-4211-8406-A345F3D47C42@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE2E1@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 14:55:20 -0000

Hemant,

>> that's not what pd-exclude says. the excluded prefix is _not_ =
delegated
> to the RR.
>=20
> OK.  However the excluded prefix is used by the DR on the link to the =
RR
> and the DR is the first-hop router to the RR.  So why wouldn't the RR
> and DR be on-link for the excluded prefix?  Or does the exclude =
document
> assume a unnumbered WAN? =20

the DR (or whomever is in administrative control of that prefix) is free =
to use the excluded prefix for whatever it likes.
it may be typical to use that for the prefix on the link between RR and =
the DR.

>> not on the RR no. unless the excluded prefix is signaled in e.g. an =
RA
> from the DR.
>=20
> I had assumed the fact.  See my on-link response above.

typical I expect, but note that the _DR_ is in control, not the RR.

cheers,
Ole=

From shemant@cisco.com  Thu Dec  1 08:46:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0311E828D for ; Thu,  1 Dec 2011 08:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 e7MIX-xPFd9l for ; Thu,  1 Dec 2011 08:46:01 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 900FF11E8262 for ; Thu,  1 Dec 2011 08:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=46208; q=dns/txt; s=iport; t=1322757959; x=1323967559; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=a5Zw9b5YS1xfHIZyowFp4B1s+egCnmz2jiOqlo3oae8=; b=HUCAKu80QkjpQ/dJW/ztY6aKV0l1AVqO43W9A/GYjOr01ETbUQsVFd56 Vroez7w0EngRQ6QB7NWeCOkATeFkdAmERtcMzGQFDx/DjW+gkQisxA/xw 4iorf/u/yrVgMezvEthCoYqymvVb3rQIuMiOYl5yH/ppHxzRtxfVw+afb k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAP6t106tJXG//2dsb2JhbABEgk2YCYgjAYd/gQWBcgEBAQMBEgEJEQM3EgULAgEIEQQBAQsGEAEGAQYBRQMBBQgBAQQBEggah2UImSABnlKKPWMEiCieYA
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; d="scan'208,217";a="40370789"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 01 Dec 2011 16:45:58 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB1GjwJr024470;  Thu, 1 Dec 2011 16:45:58 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 10:45:58 -0600
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_01CCB048.B376AA4B"
Date: Thu, 1 Dec 2011 10:45:57 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com>
In-Reply-To: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Section 4.4 of 6204-bis
Thread-Index: AcywG5GBOQBtp+YsTgmfooI2ncr23wAKEHHA
References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , 
X-OriginalArrivalTime: 01 Dec 2011 16:45:58.0503 (UTC) FILETIME=[B3A5E770:01CCB048]
Subject: Re: [v6ops] Section 4.4 of 6204-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 16:46:07 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB048.B376AA4B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

Thanks for the review.  Comments below.  Chris, Barbara, and Lorenzo,
please see some responses below that you could also reply to.

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Section 4.4 of 6204-bis

=20

=20

=20
=20

>4.4.1.  6rd

=20
=20
 >  The IPv6 CE Router can be used to offer IPv6 service to a LAN, even
 >  when the WAN access network only supports IPv4.  One technology that
 >  supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment
 >  (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside
 >  IPv4 at the IPv6 CE Router and sends it to a Service Provider Border
 >  Relay (BR).  The IPv6 CE Router calculates a 6rd delegated IPv6
 >  prefix during 6rd configuration, and sub-delegates the 6rd delegated
 >  prefix to devices in the LAN.

=20

>IMHO, the above is just making the document longer. You can simply
include the sentence below. RFC 5969 is a normative, so you can rely on
the reader to go read >it.=20





>   The IPv6 CE Router SHOULD implement 6rd functionality as specified
in
>   [RFC5969  ].
=20
This is an editorial nit.  Chris Donley added the text to give some
perspective to the CPE router vendor.   "Just making the document
longer" is a nit as well.   I am open either way.  =20
=20
=20
>   6rd requirements:
=20
>   6RD-1:  If the IPv6 CE Router implements 6rd functionality, the CE
>           Router WAN interface MUST support at least one 6rd Virtual
>           Interface.

=20

>6rd is implemented with a "6rd virtual interface" (see terminology
section of RFC 5969) which is not bound to a WAN interface as you are
suggesting in this >requirement. I would remove the requirement
>altogether, as it is part of RFC 5969 anyway, and by re-specifying we
run the risk of introducing inconsistencies.=20

=20

The WAN keyword is used to point out that the CE router does not
initiate 6rd in the LAN segment.   It is crystal clear the 6rd virtual
interface is a virtual network interface and such an interface is not
bound to any physical interface.  However, the traffic from the 6rd
virtual interface uses the WAN physical interface to reach the SP.
Thus I think this is a nit and the text in rfc6204bis stays.



>   6RD-2:  If the IPv6 CE router implements 6rd functionality, it MUST
>           support 6rd configuration via the 6rd DHCPv4 Option (212)
and
>           if the IPv6 CE router is capable of automated configuration
>           of IPv4 through IPCP (i.e., over a PPP connection), it MUST
>           support user-entered configuration of 6rd. =20

=20

>Why not just say it MUST support DHCPv4 option 212 and Manual
configuration and stop at that? If we are going to include manual
config, it is effectively >*always* an option, not just for PPP or any
other >type of access link. Just make it a MUST and be done.

=20

>Further, if we are going to mention PPP, rather than falling back to
manual only, why not allow DHCP configuration after PPP IPCP is
finished?

=20

Agree.  Barbara can comment as well since she provided such text.

=20

>From RFC2131: "DHCPINFORM   -  Client to server, asking only for local
configuration parameters; client already has externally configured
network address."

=20

>Back when the PPP folks actively decided to stop duplicating DHCP
functionality in IPCP, this was the recommended approach (and Windows
stacks and the like actually try to obtain additional >parameters for
PPP connections after IPCP comes up, though often the network does not
have any additional parameters to give...). This gives PPP connections a
pretty decent chance to work with 6rd >automatically, using the same
DHCP configuration as non-PPP.=20

=20

Agree.

=20





>   6RD-3:  If the CE router implements 6rd functionality, it MUST allow
>           the user to specify whether all IPv6 traffic goes to the 6rd
>           Border Relay, or whether IPv6 traffic to other destinations
>           within the same 6rd domain are routed directly to those
=20
=20
=20
>Singh, et al.             Expires May 25, 2012                 [Page
13]
  =20
>Internet-Draft         IPv6 CE Router Requirements         November
2011
=20
=20
>           destinations.  The CE router MAY use other mechanisms to
>           configure this.  Such mechanisms are outside the scope of
>           this document.

=20

>Do you really mean the "user" is supposed to be able to specify whether
IPv6 traffic always going through the BR, or the "operator" is supposed
to be able to >specify this?

=20

>This behavior, while straight-forward to implement as it is effectively
removing a more-specific route on the 6rd virtual interface, is out of
scope of RFC 5969 >as currently defined. There is no way to specify this
in DHCPv4 configuration. One might be able to configure this from the
network with PIO or DHCPv6 route >options in a general manner, but this
hasn't been specified anywhere that I am aware of within the context of
6rd. I understand the BBF has included some >specifics around this, and
perhaps it is best if those requirements stay in the BBF or at least we
provide a reference to them from here. Otherwise, this >requirement
remains under-specified as written, and if expounded would effectively
be an update (in the formal sense) to RFC 5969.=20


How does BBF specify the CE router gets configured to go directly to
other destinations? =20

=20

>   6RD-4:  If 6rd is operational on the IPv6 CE Router, multicast data
>           MUST NOT be sent on any 6rd tunnel.

=20

>As long as the high-level requirement is RFC 5969 only, there is no
need to mention multicast. If in the future someone implements 6rd
multicast (there are >drafts on it), why stop them? Best to just remove
>this (non-)requirement from the document.


When the future mcast over 6rd document gets to be an RFC, the CPE
router document also changes.  Till that happens, this bullet stays.

=20

>   6RD-5:  The CE Router MUST NOT forward 6RD traffic over a DS-Lite
>           ([RFC6333  ]) tunnel.

=20

>Again, why over-specify? Sure, the operational steps you take should
not lead you down this path, but if the router is following a logical
set of routing and >virtual interface constructs, this would just work.
Why make the CE vendor go out of their way to check to see if this is
happening and drop packets?=20


Implementations do stupid things and thus it's good to specify such
text.  At the Taipei IETF during a hallway conversation between myself,
Lorenzo, Ole, and some others, I heard Lorenzo say, "it's good to
include rules such as this one."  Lorenzo can keep me honest.


>4.4.2.  Dual-Stack Lite(DS-Lite)

=20
=20
>   Even as users migrate from IPv4 to IPv6 addressing, a significant
>   percentage of Internet resources and content will remain accessible
>   only through IPv4.  Also, many end-user devices will only support
>   IPv4.  As a consequence, Service Providers require mechanisms to
>   allow customers to continue to access content and resources using
>   IPv4 even after the last IPv4 allocations have been fully depleted.
>   One technology that can be used for IPv4 address extension is DS-
>   Lite.
=20
>   DS-Lite enables a Service Provider to share IPv4 addresses among
>   multiple customers by combining two well-known technologies: IP in
IP
>   (IPv4-in-IPv6) tunneling and Carrier Grade NAT.  More specifically,
>   Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
>   the IPv6 CE Router and sends it to a Service Provider Address Family
>   Transition Router (AFTR).  Configuration of the IPv6 CE Router to
>   support IPv4 LAN traffic is outside the scope of this document.
=20

=20

>IMHO - As with the 6rd "summary" text, I think the most important line
is the following one, and the previous paragraphs may be omitted or
shrunk to one or two >lines at best.=20

=20





>   The IPv6 CE Router SHOULD implement DS-Lite functionality as
>   specified in [RFC6333  ].
=20
Same reply as above.  Am open to change.  Chris added such text.  He can
reply.=20
=20
>   WAN requirements:
=20
>   DLW-1:  To facilitate IPv4 extension over an IPv6 network, if the CE
>           Router supports DS-Lite functionality, the CE Router WAN
>           interface MUST implement a B4 Interface as specified in
>           [RFC6333  ].

=20

>As with the "6rd interface" case, this really seems repetitive. It
should be sufficient to say "implement DS-Lite" ... Also, virtual
interfaces are not tied to >any physical interfaces per se, they exist
independently. They may be used for WAN connectivity, but they are a
fully separate interface in terms of the RIB and >such.=20


Same response as earlier about the same comment for 6rd text.   WAN
separates from the LAN of the CPE.  Text stays.

=20

I and reply to other comments in another set of emails.

=20

Thanks,

=20

Hemant

=20
=20
=20

------_=_NextPart_001_01CCB048.B376AA4B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
Thanks for the review.  Comments below.  =
Chris, Barbara, and Lorenzo, please see some responses below that you =
could also reply to.
 
From: =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Mark Townsley
Sent: Thursday, December 01, 2011 6:22 =
AM
To: v6ops@ietf.org Operations
Subject: [v6ops] =
Section 4.4 of 6204-bis
 
 
 
 
>4.4.1.  =
6rd
 
 
 =
>  The IPv6 CE Router can be used to offer =
IPv6 service to a LAN, even
 =
>  when the WAN access network only supports =
IPv4.  One technology that
 =
>  supports IPv6 service over an IPv4 network =
is IPv6 Rapid Deployment
 =
>  (6rd). 6rd encapsulates IPv6 traffic from =
the end user LAN inside
 =
>  IPv4 at the IPv6 CE Router and sends it to =
a Service Provider Border
 =
>  Relay (BR).  The IPv6 CE Router =
calculates a 6rd delegated IPv6
 =
>  prefix during 6rd configuration, and =
sub-delegates the 6rd delegated
 =
>  prefix to devices in the =
LAN.
 
>IMHO, the above is =
just making the document longer. You can simply include the sentence =
below. RFC 5969 is a normative, so you can rely on the reader to go read =
>it. 
<=
p class=3DMsoNormal>

>   The IPv6 CE Router SHOULD implement =
6rd functionality as specified in
> =
  [RFC5969].
 
This is =
an editorial nit.  Chris Donley added the text to give some =
perspective to the CPE router vendor.   “Just making the =
document longer” is a nit as well.   I am open either =
way.   
 
 
>   6rd =
requirements:
 
>   6RD-1:  If the IPv6 CE Router =
implements 6rd functionality, the CE
>        &nb=
sp;  Router WAN interface MUST support at least one 6rd =
Virtual
>        &nb=
sp;  Interface.
 
>6rd is implemented =
with a "6rd virtual interface" (see terminology section of RFC =
5969) which is not bound to a WAN interface as you are suggesting in =
this >requirement. I would =
remove the requirement >altogether, as it is part of RFC 5969 =
anyway, and by re-specifying we run the risk of introducing =
inconsistencies. 
 
The =
WAN keyword is used to point out that the CE router does not initiate =
6rd in the LAN segment.   It is crystal clear the 6rd virtual =
interface is a virtual network interface and such an interface is not =
bound to any physical interface.  However, the traffic from the 6rd =
virtual interface uses the WAN physical interface to reach the =
SP.   Thus I think this is a nit and the text in rfc6204bis =
stays.

>   6RD-2:  If the IPv6 CE router =
implements 6rd functionality, it MUST
>        &nb=
sp;  support 6rd configuration via the 6rd DHCPv4 Option (212) =
and
>        &nb=
sp;  if the IPv6 CE router is capable of automated =
configuration
>        &nb=
sp;  of IPv4 through IPCP (i.e., over a PPP connection), it =
MUST
>        &nb=
sp;  support user-entered configuration of 6rd.  =

 
>Why not just say it =
MUST support DHCPv4 option 212 and Manual configuration and stop at =
that? If we are going to include manual config, it is effectively =
>*always* an option, not just =
for PPP or any other >type of =
access link. Just make it a MUST and be =
done.
 
>Further, if we are =
going to mention PPP, rather than falling back to manual only, why not =
allow DHCP configuration after PPP IPCP is =
finished?
 
Agree.  Barbara can comment as well since she =
provided such text.
 
>From RFC2131: "DHCPINFORM   -  Client to =
server, asking only for local configuration parameters; client =
already has externally configured network =
address."
 
>Back when the PPP =
folks actively decided to stop duplicating DHCP functionality in IPCP, =
this was the recommended approach (and Windows stacks and the like =
actually try to obtain additional >parameters for PPP connections after =
IPCP comes up, though often the network does not have any additional =
parameters to give...). This gives PPP connections a pretty decent =
chance to work with 6rd >automatically, using the same DHCP =
configuration as non-PPP. 
 
Agree.
 


>   6RD-3:  If the CE router =
implements 6rd functionality, it MUST allow
>        &nb=
sp;  the user to specify whether all IPv6 traffic goes to the =
6rd
>        &nb=
sp;  Border Relay, or whether IPv6 traffic to other =
destinations
>        &nb=
sp;  within the same 6rd domain are routed directly to =
those
 
 
 
>Singh, =
et =
al.           &nbs=
p; Expires May 25, 2012        =
         [Page =
13]
<=
span style=3D'color:white;text-decoration:none'> 
>Internet-Draft      =
;   IPv6 CE Router =
Requirements         November =
2011
 
 
>        &nb=
sp;  destinations.  The CE router MAY use other mechanisms =
to
>        =
   configure this.  Such mechanisms are outside the =
scope of
>        &nb=
sp;  this document.
 
>Do you really mean =
the "user" is supposed to be able to specify whether IPv6 =
traffic always going through the BR, or the "operator" is =
supposed to be able to >specify =
this?
 
>This behavior, =
while straight-forward to implement as it is effectively removing a =
more-specific route on the 6rd virtual interface, is out of scope of RFC =
5969 >as currently defined. =
There is no way to specify this in DHCPv4 configuration. One might be =
able to configure this from the network with PIO or DHCPv6 route >options in a general manner, but this =
hasn't been specified anywhere that I am aware of within the context of =
6rd. I understand the BBF has included some >specifics around this, and perhaps it =
is best if those requirements stay in the BBF or at least we provide a =
reference to them from here. Otherwise, this >requirement remains under-specified =
as written, and if expounded would effectively be an update (in the =
formal sense) to RFC 5969. 

How does BBF specify the CE =
router gets configured to go directly to other destinations?  =

 
> =
  6RD-4:  If 6rd is operational on the IPv6 CE Router, =
multicast data
>        &nb=
sp;  MUST NOT be sent on any 6rd =
tunnel.
 
>As long as the =
high-level requirement is RFC 5969 only, there is no need to mention =
multicast. If in the future someone implements 6rd multicast (there are =
>drafts on it), why stop them? =
Best to just remove >this =
(non-)requirement from the document.

When the future mcast over 6rd =
document gets to be an RFC, the CPE router document also changes.  =
Till that happens, this bullet stays.
 
>   6RD-5:  The CE Router MUST NOT =
forward 6RD traffic over a DS-Lite
>        &nb=
sp;  ([RFC6333]) tunnel.
 
>Again, why =
over-specify? Sure, the operational steps you take should not lead you =
down this path, but if the router is following a logical set of routing =
and >virtual interface =
constructs, this would just work.  Why make the CE vendor go out of =
their way to check to see if this is happening and drop =
packets? 

Implementations do stupid things and thus =
it’s good to specify such text.  At the Taipei IETF during a =
hallway conversation between myself, Lorenzo, Ole, and some others, I =
heard Lorenzo say, “it’s good to include rules such as this =
one.”  Lorenzo can keep me =
honest.
>4.4.2.  =
Dual-Stack Lite(DS-Lite)
 
 
>   Even as users migrate from IPv4 to =
IPv6 addressing, a significant
>   percentage of Internet resources and =
content will remain accessible
>   only through IPv4.  Also, many =
end-user devices will only support
>   IPv4.  As a consequence, Service =
Providers require mechanisms to
>   allow customers to continue to access =
content and resources using
>   IPv4 even after the last IPv4 =
allocations have been fully depleted.
>   One technology that can be used for =
IPv4 address extension is DS-
>   Lite.
 
>   DS-Lite enables a Service Provider to =
share IPv4 addresses among
>   multiple customers by combining two =
well-known technologies: IP in IP
>   (IPv4-in-IPv6) tunneling and Carrier =
Grade NAT.  More specifically,
>   Dual-Stack-Lite encapsulates IPv4 =
traffic inside an IPv6 tunnel at
>   the IPv6 CE Router and sends it to a =
Service Provider Address Family
>   Transition Router (AFTR).  =
Configuration of the IPv6 CE Router to
>   support IPv4 LAN traffic is outside =
the scope of this document.
 
 
>IMHO - As with the =
6rd "summary" text, I think the most important line is the =
following one, and the previous paragraphs may be omitted or shrunk to =
one or two >lines at =
best. 
 


>   The IPv6 CE Router SHOULD implement =
DS-Lite functionality as
>   specified in [RFC6333].
 
Same =
reply as above.  Am open to change.  Chris added such =
text.  He can reply. 
 
>   WAN =
requirements:
 
>   DLW-1:  To facilitate IPv4 =
extension over an IPv6 network, if the CE
>        &nb=
sp;  Router supports DS-Lite functionality, the CE Router =
WAN
>        &nb=
sp;  interface MUST implement a B4 Interface as specified =
in
>        &nb=
sp;  [RFC6333].
 
>As with the =
"6rd interface" case, this really seems repetitive. It should =
be sufficient to say "implement DS-Lite" ... Also, virtual =
interfaces are not tied to >any =
physical interfaces per se, they exist independently. They may be used =
for WAN connectivity, but they are a fully separate interface in terms =
of the RIB and >such. 

Same response as earlier about the same comment =
for 6rd text.   WAN separates from the LAN of the CPE.  =
Text stays.
 
I and reply to other comments in another set of =
emails.
 
Thanks,
 
Hemant
 
 
 

------_=_NextPart_001_01CCB048.B376AA4B--

From lorenzo@google.com  Thu Dec  1 10:18:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2121F91A3 for ; Thu,  1 Dec 2011 10:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.787
X-Spam-Level: 
X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vhiVLys49bdq for ; Thu,  1 Dec 2011 10:18:04 -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 CBAB721F91A2 for ; Thu,  1 Dec 2011 10:18:00 -0800 (PST)
Received: by yenl9 with SMTP id l9so1275867yen.31 for ; Thu, 01 Dec 2011 10:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Y7gzCvJl1HFobW/I5BSYDjTLhn/truBBfg0esAQNOgs=; b=RKFqSz1KZ3Z0oQQUn6gWNumDBjuKYBxgIJaXT48KM6bUjjYobzWCB8H/4Vw+KMojku Qwyp2SRCRhTAVRdRqk1g==
Received: by 10.236.131.82 with SMTP id l58mr13431230yhi.36.1322763480204; Thu, 01 Dec 2011 10:18:00 -0800 (PST)
Received: by 10.236.131.82 with SMTP id l58mr13431215yhi.36.1322763480119; Thu, 01 Dec 2011 10:18:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 10:17:39 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8E@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8E@GRFMBX704BA020.griffon.local>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 10:17:39 -0800
Message-ID: 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=20cf3011e2035ab89804b30bdfad
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:18:04 -0000

--20cf3011e2035ab89804b30bdfad
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 30, 2011 at 17:16, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> Yes you can install the aggregate route but you would need either another
> dhc option that tells the BNG what aggregate route needs to be installed
> per each customer or you have to do by manual configuration.
> In my opinion using PD-exclude is operational much simpler
>

This is not a problem for the BNG at all. When you do DHCPv6 PD, the BNG
needs to install a route for the customer's aggregate pointed at the
(link-local) address of the CE router that sent the DHCPv6 request. That
needs to happen regardless of whether one of the /64s is directly connected
to the BNG or not - otherwise the customer doesn't get his packets.

If you also want to have one of the /64s out of that aggregate as directly
connected, you need to configure it on an interface on the BNG (otherwise
it doesn't work). As soon as you do that, the directly connected route will
take precedence over the aggregate because it's more specific. So the BNG
really doesn't care.

The exclude option is only for the benefit of the CE router, so it knows
that it can't assign that /64 to one of its downstream interfaces. I'm
arguing that we don't need to tell it that, because it will know this from
the RA.

--20cf3011e2035ab89804b30bdfad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 17:16, Maglione Roberta =
<=
roberta.maglione@telecomitalia.it> wrote:


Yes you can install the aggregate route but you would need either another d=
hc option that tells the BNG what aggregate route needs to be installed per=
 each customer or you have to do by manual configuration.

In my opinion using PD-exclude is operational much simpler
=


This is not a problem for the BNG at all. When you do D=
HCPv6 PD, the BNG needs to install a route for the customer's aggregate=
 pointed at the (link-local) address of the CE router that sent the DHCPv6 =
request.=A0That needs to happen regardless of whether one of the /64s is di=
rectly connected to the BNG or not - otherwise the customer doesn't get=
 his packets.




If you also want to have one of the /64s out of that ag=
gregate as directly connected, you need to configure it on an interface on =
the BNG (otherwise it doesn't work). As soon as you do that, the direct=
ly connected route will take precedence over the aggregate because it's=
 more specific. So the BNG really doesn't care.




The exclude option is only for the benefit of the CE ro=
uter, so it knows that it can't assign that /64 to one of its downstrea=
m interfaces. I'm arguing that we don't need to tell it that, becau=
se it will know this from the RA.





--20cf3011e2035ab89804b30bdfad--

From lorenzo@google.com  Thu Dec  1 10:20:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB921F91BC for ; Thu,  1 Dec 2011 10:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Level: 
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 YI-j0kO-D+xr for ; Thu,  1 Dec 2011 10:20:12 -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 AF05321F91A3 for ; Thu,  1 Dec 2011 10:20:12 -0800 (PST)
Received: by yenl9 with SMTP id l9so1278268yen.31 for ; Thu, 01 Dec 2011 10:20:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AfdJH/tbdj3YJEWKEZx4jMHglfzlvyS0aSgK9KaUG10=; b=yr1mI6CfRA1pJj4k2VcvtztYd2q01GfIOvYLSqZpyraJA4qZegT0cM0bkxx7lLiEOu m7N69KML8tmAWjeg3f0g==
Received: by 10.236.183.52 with SMTP id p40mr13600646yhm.19.1322763612366; Thu, 01 Dec 2011 10:20:12 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr13600613yhm.19.1322763612170; Thu, 01 Dec 2011 10:20:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 10:19:51 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 10:19:51 -0800
Message-ID: 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=bcaec52c5ea939a87e04b30be7cd
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:20:13 -0000

--bcaec52c5ea939a87e04b30be7cd
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 30, 2011 at 21:58, Hemant Singh (shemant) wrote:

> [The requesting router must create sink routes for the delegated
>
> prefixes minus the excluded prefixes.  This may be done by creating****
>
>  sink routes for delegated prefixes and more specific routes for the****
>
> excluded prefixes.]****
>
> ** **
>
> I could use a /128 from the excluded /64 on any virtual interface to
> source ICMPv6 errors.
>

Great, so you have to create more specific routes for the excluded
prefixes. What's the next-hop for those routes? The DHCPv6 exclude option
doesn't tell you what it should be. The only thing that *does* tell you
what it should be is the RA.

So the question, again, is: since you already need the RA to be able to
create the sink routes properly, why do you need the exclude?

--bcaec52c5ea939a87e04b30be7cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 21:58, Hemant Singh (she=
mant) <shemant@ci=
sco.com> wrote:



[The requesting router must create=
 sink routes for the delegated



 prefixes minus the excluded prefixe=
s.=A0 This may be done by creating


 sink routes for delegated prefixes and more specific routes for the<=
u>
 excluded prefixes.]



=A0
I could use a /128 from the excluded /64 on any virtual inte=
rface to source ICMPv6 errors.




Great, so you have to create =
more specific routes for the excluded prefixes. What's the next-hop for=
 those routes? The DHCPv6 exclude option doesn't tell you what it shoul=
d be. The only thing that *does* tell you what it should be is the RA.



So the question, again, is: since you already need the RA to be ab=
le to create the sink routes properly, why do you need the exclude?


--bcaec52c5ea939a87e04b30be7cd--

From lorenzo@google.com  Thu Dec  1 10:22:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B221F91E5 for ; Thu,  1 Dec 2011 10:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.81
X-Spam-Level: 
X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 HdsBR+e0BBui for ; Thu,  1 Dec 2011 10:22:18 -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 B601B21F91E3 for ; Thu,  1 Dec 2011 10:22:18 -0800 (PST)
Received: by yenl9 with SMTP id l9so1280704yen.31 for ; Thu, 01 Dec 2011 10:22:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Pr1gumutbi7kbFKFTN3OJ9J8Fkc3CXIV5lp2haV9FaE=; b=DiGgfYXH5Dba+cyaxMHJIVhCfDbZGZdmJr7Ocb4MQk1xV88OeZlSExBUF+PYbEBHPi Mv0KHaXfKhiWXpWwmzrw==
Received: by 10.236.183.52 with SMTP id p40mr13617090yhm.19.1322763738241; Thu, 01 Dec 2011 10:22:18 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr13617073yhm.19.1322763738157; Thu, 01 Dec 2011 10:22:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 10:21:57 -0800 (PST)
In-Reply-To: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org>  <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 10:21:57 -0800
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=bcaec52c5ea9bc127a04b30bee59
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:22:19 -0000

--bcaec52c5ea9bc127a04b30bee59
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 1, 2011 at 02:47, Ole Troan  wrote:

> > For example, what is an implementation supposed to do if it gets a PD of
> 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop
> for 2001:db8:1:2::/64? Discard? It needs to know, at least for the purpose
> of sending unreachables.
>
> normal RIB lookup. i.e. will follow default.
>

But you don't want it to follow default. You want it to be an on-link route
on the interface that's connected to the BNG. Or at least, that's the
use-case that motivated the existence of this option.

--bcaec52c5ea9bc127a04b30bee59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2011 at 02:47, Ole Troan <otroan@employees.org<=
/a>> wrote:



> For example, what is an implementation supposed to d=
o if it gets a PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64?=
 What's the next hop for 2001:db8:1:2::/64? Discard? It needs to know, =
at least for the purpose of sending unreachables.






normal RIB lookup. i.e. will follow default.
But you don't want it to follow default. You want it to be =
an on-link route on the interface that's connected to the BNG. Or at le=
ast, that's the use-case that motivated the existence of this option.




--bcaec52c5ea9bc127a04b30bee59--

From lorenzo@google.com  Thu Dec  1 10:23:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D58B21F8B1E for ; Thu,  1 Dec 2011 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.819
X-Spam-Level: 
X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 WeWXWEKbOWoz for ; Thu,  1 Dec 2011 10:23:39 -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 089E421F91E8 for ; Thu,  1 Dec 2011 10:23:38 -0800 (PST)
Received: by yenl9 with SMTP id l9so1282266yen.31 for ; Thu, 01 Dec 2011 10:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AvPCyQMUH9Te12DOyf9ahtMFreL8TtEFqsltcA8eLFI=; b=bhUPno+Kfz82sw0+o83FHNRAs3UfESd/KuW2sOTlYx6ufVOncM0prXfRuBsxZLxSer EvnMaVevgI5KPfPRNotw==
Received: by 10.101.158.28 with SMTP id k28mr2100437ano.7.1322763818319; Thu, 01 Dec 2011 10:23:38 -0800 (PST)
Received: by 10.101.158.28 with SMTP id k28mr2100427ano.7.1322763818190; Thu, 01 Dec 2011 10:23:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 10:23:17 -0800 (PST)
In-Reply-To: <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <4ED698D6.5090305@gmail.com> <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 10:23:17 -0800
Message-ID: 
To: jouni korhonen 
Content-Type: multipart/alternative; boundary=0016e68fc8cd81468804b30bf368
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:23:39 -0000

--0016e68fc8cd81468804b30bf368
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 1, 2011 at 06:39, jouni korhonen  wrote:

> Getting that happen is quite unlikely. Rel-10 is already frozen.


Frozen standards should not depend on internet drafts. The draft even says
that it is inappropriate to cite IETF standards other than as work in
progress, right?

--0016e68fc8cd81468804b30bf368
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2011 at 06:39, jouni korhonen <jouni.nospam@g=
mail.com> wrote:


Getting that happen is quite unlikely. Rel-10 is already frozen.

Frozen standards should not depend on internet drafts=
. The draft even says that it is inappropriate to cite IETF standards other=
 than as work in progress, right?





--0016e68fc8cd81468804b30bf368--

From bs7652@att.com  Thu Dec  1 10:44:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0712A21F9205 for ; Thu,  1 Dec 2011 10:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.433
X-Spam-Level: 
X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LCA0kCs+mzwT for ; Thu,  1 Dec 2011 10:44:37 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B621F9202 for ; Thu,  1 Dec 2011 10:44:37 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-11.tower-120.messagelabs.com!1322765075!51750037!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6546 invoked from network); 1 Dec 2011 18:44:35 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Dec 2011 18:44:35 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB1Ih7Zs015803; Thu, 1 Dec 2011 13:43:08 -0500
Received: from 01AL10015010627.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB1Ih1F8015706; Thu, 1 Dec 2011 13:43:02 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 12:43:38 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 13:43:38 -0500
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_01CCB059.2385F862"
Date: Thu, 1 Dec 2011 13:44:25 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F213AB69F@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Section 4.4 of 6204-bis
Thread-Index: AcywG5GBOQBtp+YsTgmfooI2ncr23wAKEHHAAANj2aA=
References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Mark Townsley" , 
X-OriginalArrivalTime: 01 Dec 2011 18:43:38.0464 (UTC) FILETIME=[23B67600:01CCB059]
Subject: Re: [v6ops] Section 4.4 of 6204-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:44:40 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB059.2385F862
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

In-line, marked with .

Barbara

=20

>   6RD-2:  If the IPv6 CE router implements 6rd functionality, it MUST
>           support 6rd configuration via the 6rd DHCPv4 Option (212)
and
>           if the IPv6 CE router is capable of automated configuration
>           of IPv4 through IPCP (i.e., over a PPP connection), it MUST
>           support user-entered configuration of 6rd. =20

=20

>Why not just say it MUST support DHCPv4 option 212 and Manual
configuration and stop at that? If we are going to include manual
config, it is effectively >*always* an option, not just for PPP or any
other >type of access link. Just make it a MUST and be done.

=20

Because the MSOs said they didn't want to implement manual
configuration in their devices. So we compromised on language that would
provide them an exclusion, but make sure they capability was present in
devices where it was actually needed.

=20

>Further, if we are going to mention PPP, rather than falling back to
manual only, why not allow DHCP configuration after PPP IPCP is
finished?

=20

Agree.  Barbara can comment as well since she provided such text.

=20

 Nothing prohibits DHCPv4 configuration after IPCP. I don't see
anything that says it's not allowed. However, it can't be assumed, since
almost no PPP-based access network runs a DHCPv4 server for
PPP-connected customers. And any ISP who isn't running a DHCPv4 server
today, is *highly* unlikely to add one just for 6rd. Remember, the
promise of 6rd is that it doesn't require upgrades to existing
infrastructure in the access network. To suggest that this CE router
draft somehow can require PPP access networks to add DHCPv4 servers in
order to do 6rd is a non-starter. In my experience, CE router vendors
are looking for realistic advice, and not purist recommendations that
are not representative of the real world.

=20

>From RFC2131: "DHCPINFORM   -  Client to server, asking only for local
configuration parameters; client already has externally configured
network address."

=20

>Back when the PPP folks actively decided to stop duplicating DHCP
functionality in IPCP, this was the recommended approach (and Windows
stacks and the like actually try to obtain additional >parameters for
PPP connections after IPCP comes up, though often the network does not
have any additional parameters to give...). This gives PPP connections a
pretty decent chance to work with 6rd >automatically, using the same
DHCP configuration as non-PPP.=20

=20

Agree.

=20

 See above comment.=20

>   6RD-3:  If the CE router implements 6rd functionality, it MUST allow
>           the user to specify whether all IPv6 traffic goes to the 6rd
>           Border Relay, or whether IPv6 traffic to other destinations
>           within the same 6rd domain are routed directly to those
>           destinations.  The CE router MAY use other mechanisms to
>           configure this.  Such mechanisms are outside the scope of
>           this document.

=20

>Do you really mean the "user" is supposed to be able to specify whether
IPv6 traffic always going through the BR, or the "operator" is supposed
to be able to >specify this?

=20

>This behavior, while straight-forward to implement as it is effectively
removing a more-specific route on the 6rd virtual interface, is out of
scope of RFC 5969 >as currently defined. There is no way to specify this
in DHCPv4 configuration. One might be able to configure this from the
network with PIO or DHCPv6 route >options in a general manner, but this
hasn't been specified anywhere that I am aware of within the context of
6rd. I understand the BBF has included some >specifics around this, and
perhaps it is best if those requirements stay in the BBF or at least we
provide a reference to them from here. Otherwise, this >requirement
remains under-specified as written, and if expounded would effectively
be an update (in the formal sense) to RFC 5969.=20


How does BBF specify the CE router gets configured to go directly to
other destinations? =20

=20

 Via TR-069, or manually. It would be nice if it could also be via
DHCPv4 option, but the companies asking for this don't really see the
lack of a DHCPv4 option as being a showstopper.

=20


------_=_NextPart_001_01CCB059.2385F862
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


In-line, marked with <bhs>.
Barbara
 
>   6RD-2:  If the IPv6 CE router =
implements 6rd functionality, it MUST
>        &nb=
sp;  support 6rd configuration via the 6rd DHCPv4 Option (212) =
and
>        &nb=
sp;  if the IPv6 CE router is capable of automated =
configuration
>        &nb=
sp;  of IPv4 through IPCP (i.e., over a PPP connection), it =
MUST
>        &nb=
sp;  support user-entered configuration of 6rd.  =

 
>Why not just say it =
MUST support DHCPv4 option 212 and Manual configuration and stop at =
that? If we are going to include manual config, it is effectively =
>*always* an option, not just =
for PPP or any other >type of =
access link. Just make it a MUST and be done.
 
<bhs>Because the MSOs said they didn’t want to implement =
manual configuration in their devices. So we compromised on language =
that would provide them an exclusion, but make sure they capability was =
present in devices where it was actually =
needed.
 
>Further, if we are =
going to mention PPP, rather than falling back to manual only, why not =
allow DHCP configuration after PPP IPCP is =
finished?
 
Agree.  Barbara can comment as well since she =
provided such text.
 
<bhs> Nothing prohibits DHCPv4 configuration after IPCP. I =
don’t see anything that says it’s not allowed. However, it =
can’t be assumed, since almost no PPP-based access network runs a =
DHCPv4 server for PPP-connected customers. And any ISP who isn’t =
running a DHCPv4 server today, is *highly* unlikely to add one =
just for 6rd. Remember, the promise of 6rd is that it doesn’t =
require upgrades to existing infrastructure in the access network. To =
suggest that this CE router draft somehow can require PPP access =
networks to add DHCPv4 servers in order to do 6rd is a non-starter. In =
my experience, CE router vendors are looking for realistic advice, and =
not purist recommendations that are not representative of the real =
world.
 
>From RFC2131: "DHCPINFORM   -  Client to =
server, asking only for local configuration parameters; client =
already has externally configured network =
address."
 
>Back when the PPP =
folks actively decided to stop duplicating DHCP functionality in IPCP, =
this was the recommended approach (and Windows stacks and the like =
actually try to obtain additional >parameters for PPP connections after =
IPCP comes up, though often the network does not have any additional =
parameters to give...). This gives PPP connections a pretty decent =
chance to work with 6rd >automatically, using the same DHCP =
configuration as non-PPP. 
 
Agree.
 
<bhs> See above comment. =

>   6RD-3:  If the CE router =
implements 6rd functionality, it MUST allow
>        &nb=
sp;  the user to specify whether all IPv6 traffic goes to the =
6rd
>        &nb=
sp;  Border Relay, or whether IPv6 traffic to other =
destinations
>        &nb=
sp;  within the same 6rd domain are routed directly to =
those
>        &nb=
sp;  destinations.  The CE router MAY use other mechanisms =
to
>        =
   configure this.  Such mechanisms are outside the =
scope of
>        &nb=
sp;  this document.
 
>Do you really mean =
the "user" is supposed to be able to specify whether IPv6 =
traffic always going through the BR, or the "operator" is =
supposed to be able to >specify =
this?
 
>This behavior, =
while straight-forward to implement as it is effectively removing a =
more-specific route on the 6rd virtual interface, is out of scope of RFC =
5969 >as currently defined. =
There is no way to specify this in DHCPv4 configuration. One might be =
able to configure this from the network with PIO or DHCPv6 route >options in a general manner, but this =
hasn't been specified anywhere that I am aware of within the context of =
6rd. I understand the BBF has included some >specifics around this, and perhaps it =
is best if those requirements stay in the BBF or at least we provide a =
reference to them from here. Otherwise, this >requirement remains under-specified =
as written, and if expounded would effectively be an update (in the =
formal sense) to RFC 5969. 

How does BBF specify the CE =
router gets configured to go directly to other destinations?  =

 
<bhs> Via TR-069, or manually. It would be nice if it could =
also be via DHCPv4 option, but the companies asking for this don’t =
really see the lack of a DHCPv4 option as being a =
showstopper.
 
=

------_=_NextPart_001_01CCB059.2385F862--

From ichiroumakino@gmail.com  Thu Dec  1 10:44:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D335711E80FE for ; Thu,  1 Dec 2011 10:44:55 -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, 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 9xWQalgKpvZ6 for ; Thu,  1 Dec 2011 10:44:55 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7321F9201 for ; Thu,  1 Dec 2011 10:44:54 -0800 (PST)
Received: by eabm6 with SMTP id m6so2868293eab.31 for ; Thu, 01 Dec 2011 10:44:53 -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=x8SGgJK3Id3AoMIQQHYKfjU9GKlt/QfPULR6glicC10=; b=u03qnse5BpSrTV05qT4Ii9sD4WNnzR/92trfQVdjtDOkoFVqugzW/zR69d0PiP+N8I S89yE+8X6DOMIF2sXefdnD7IjmEEW927w5+61NvrBlDTTx0T/MXZ2LZZK7gSaAIg7iyi ou/s5tiMC2boQAiQykca6alWqQUlPlGXw1qUE=
Received: by 10.180.3.37 with SMTP id 5mr5631696wiz.43.1322765093795; Thu, 01 Dec 2011 10:44:53 -0800 (PST)
Received: from dhcp-10-61-105-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 6sm6716346wby.22.2011.12.01.10.44.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:44:49 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Thu, 1 Dec 2011 19:44:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org>  <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 18:44:55 -0000

Lorenzo,

> > For example, what is an implementation supposed to do if it gets a =
PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the =
next hop for 2001:db8:1:2::/64? Discard? It needs to know, at least for =
the purpose of sending unreachables.
>=20
> normal RIB lookup. i.e. will follow default.
>=20
> But you don't want it to follow default. You want it to be an on-link =
route on the interface that's connected to the BNG. Or at least, that's =
the use-case that motivated the existence of this option.

the only thing the exclude option says, is that the prefix is _not_ part =
of the delegation.
it may be used as the onlink prefix on the RR - DR link, if so the RR =
can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR =
doesn't need to know about it.

cheers,
Ole


From shemant@cisco.com  Thu Dec  1 11:11:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE12C1F0C4A for ; Thu,  1 Dec 2011 11:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.275
X-Spam-Level: 
X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 LhqlTsg-CnsN for ; Thu,  1 Dec 2011 11:11:27 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5C21F9114 for ; Thu,  1 Dec 2011 11:11:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=29576; q=dns/txt; s=iport; t=1322766686; x=1323976286; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=FHqVRpJTKC0VgH6rj2Ie0E4ZLvDWvs1GZxnEdN6/LYc=; b=Cc4mPi082J8MaMxiVK61yVw/xppUl4UcKzJy0lf/mx2DdhxzewO76oQ0 GMu4ADIStmlb7aTjTA8nDiDfDx/xw3g2275euvpyRBnZkte8mZMBm78oR flP6G3/Y1kSjhnlLc1a2pVpOhXUkhsyEzgzTcrEXxKPGJJpKn7RE/2Glz s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgAAHzQ106tJV2d/2dsb2JhbABEgk2YCYgjAYUOgnGBBYFyAQEBAwESAQkRA0QKCwIBCBEEAQELBhABBgEGAUUJCAEBBAESCBqHZQiZOAGeR4o9YwSIKJ5g
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; d="scan'208,217";a="40427837"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 01 Dec 2011 19:11:26 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pB1JBPL4022789;  Thu, 1 Dec 2011 19:11:25 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 13:11:25 -0600
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_01CCB05D.054785C5"
Date: Thu, 1 Dec 2011 13:11:24 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE4C8@XMB-RCD-109.cisco.com>
In-Reply-To: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Section 4.4 of 6204-bis
Thread-Index: AcywG5GBOQBtp+YsTgmfooI2ncr23wANEWAA
References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , 
X-OriginalArrivalTime: 01 Dec 2011 19:11:25.0708 (UTC) FILETIME=[0577B4C0:01CCB05D]
Subject: Re: [v6ops] Section 4.4 of 6204-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 19:11:31 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB05D.054785C5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Section 4.4 of 6204-bis

=20

=20





=20

>4.4.3.  Transition Technologies Coexistence

=20
=20
>   Supporting transition technologies that may coexist with native
>   service requires control over provisioning and sunsetting.  Some
>   guidelines follow:
=20
>   1.  Initiate native IPv4/IPv6 provisioning (e.g. via DHCP)
>       simultaneously.
=20
>   2.  After IPv4 provisioning completes, if 6rd parameters are
obtained
>       from the DHCPv4 transaction or configured on the device,
initiate
>       6rd.
=20
>   3.  After IPv6 provisioning completes, if DS-Lite parameters are
>       obtained from the DHCPv6 transaction or configured on the
device,
>       initiate DS-Lite.
=20
>   4.  Routes over the DS-Lite tunnel always have a higher
>       administrative distance than native IPv4 routes.

=20

>higher or lower? Do you want traffic to prefer native or tunneled here?
I read this as preferring native IPv4, but perhaps the real goal is to
prefer IPv6?


Higher admin distance means lower priority and hence the DS-Lite tunnel
has lower priority when both native IPv4 and DS-Lite run concurrently.
There is nothing to discuss about IPv6 for this bullet.

=20
>   5.  Selection of 6rd tunnel or native IPv6 output interface on the
CE
>       router is determined by the source IPv6 address of the packet
>       from a host, when different prefixes are available over 6rd vs.
>       native IPv6.  If the two interfaces provide the CE router with
>       the same prefix, then the CE router prefers the native IPv6
>       interface to the 6rd interface for forwarding traffic out the
WAN
>       when both 6rd and native IPv6 interfaces are active.

=20

>This is close, but I think it would be much better to define the
multihoming requirements generically and have 6rd just be one special
case.=20


See Wes's reply to Brian Carpenter in v6ops.  We wanted the cheap CPE
router to have a simple algorithm to forward packets when native IPv6
and 6rd have different prefixes.  The algorithm is checking the source
address of the packet.   Why is the text not complete and instead close?
Source-address based switching is in line with PBR (switching on source
address bit) that multihoming will require.   We wanted to stay away
from the general multihoming requirement.  If you can please suggest
some text that could change the bullet from close to complete that would
help much.=20

=20
>   During a sunsetting activity such as deprecating 6rd and moving to
=20
=20
=20
>Singh, et al.             Expires May 25, 2012                 [Page
15]
  =20
>Internet-Draft         IPv6 CE Router Requirements         November
2011
=20
=20
>   native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
>   prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
>   lower of the current Valid Lifetime and two hours (which must be
>   decremented in real time) in a Router Advertisement message as
>   described in Section 5.5.3
 ,
(e) of [RFC4862  ]. =20

=20

>"The CE route MUST immediately advertise the 6rd prefix.... "  when?
when "during a sunsetting activity" ?=20

=20

Of course, during a sunsetting activity - the paragraph starts with
"During a sunsetting activity".

=20

>How do you trigger that in software? As an implementor, I would have no
idea what this MUST really means.=20

=20

The CPE completes DHCPv4 renewal process and does not receive any 6rd
option in DHCPv4.  At this juncture, the 6rd prefix is deprecated.  It
is the SP's configuration to pick higher value for DHCPV4 lease_time vs.
the 6rd prefix lifetime.  A retail CPE performs NUD (section 8 of RFC
5969) and NUD does not get replied to.  The retail CPE deprecates the
6rd prefix.=20

=20

>The heart of the problem here is *over-specification*. All the CPE
needs to do is to deprecate the address when its lifetime expires just
like any other prefix. >This will happen naturally once the DHCPv4 lease
that 6rd was provisioned with expires and no new 6rd option arrives with
the renewal (if there is any MUST >needed, it's at this stage). So: No
special cases. No immediate interrupts to do this or that. No new case()
statements specifically for 6rd, 6rd+native, >6rd+native+ds-lite, etc.
Just the normal code run through when interfaces come up and down and
prefixes are timed out. Nothing special. No surprises.


We too want to keep rules simple, but deprecation also involves the LAN
segment and RFC 4862's two-hour rule.   Further, you missed the "during"
the deprecation process when 6rd and native IPv6 run concurrently.
Thus there is no over-specification that I can see.

=20

>Due to the two hours
>   rule specified in [RFC4862  ],
the 6rd and the native IPv6 prefix will
>   coexist in the home network.  The two hours rule specified in
section
=20
>   5.5.3

of [RFC4862  ] causes any deprecated
prefix to linger on the node
>   even when an RA has sent a Preferred Lifetime of zero to expire the
>   prefix to the node.  During such coexistence of multiple prefixes,
>   the CE router sends an ICMPv6 error for packets sourced or destined
>   related to the deprecated prefix.  Note this document already
>   includes text in bullet L-14 in section 4.3

for such a provision.

=20

>Pointing out the two hour issue is fine, as well as what to do with
deprecated prefixes, but this is *all* normal mutlihoming/renumbering
procedures. We would be >far better off defining this generally, and
letting 6rd + native just fall in line happily as any other case where
there are two interfaces with prefixes >assigned.=20

=20

We have difference in opinion.  We want to define specific behavior for
a cheap CPE while you want generic requirements that make implementation
rules fuzzy to CPE implementers.   We cannot punt to general
multihoming/renumbering procedures that maps to many complex devices and
complex networks. =20

=20

>I'm afraid that the requirements as written will lead to a lot of
inconsistency.=20

=20

What specific inconsistency do we have with the current text?

=20

Hemant

=20


------_=_NextPart_001_01CCB05D.054785C5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet=
f.org] On Behalf Of Mark Townsley
Sent: Thursday, =
December 01, 2011 6:22 AM
To: v6ops@ietf.org =
Operations
Subject: [v6ops] Section 4.4 of =
6204-bis
 
 


 
>4.4.3.  =
Transition Technologies Coexistence
 
 
>   Supporting transition =
technologies that may coexist with native
>   service requires control over =
provisioning and sunsetting.  Some
>   guidelines =
follow:
 
>   1.  Initiate native =
IPv4/IPv6 provisioning (e.g. via DHCP)
>       =
simultaneously.
 
>   2.  After IPv4 provisioning =
completes, if 6rd parameters are obtained
>       from the =
DHCPv4 transaction or configured on the device, =
initiate
>       =
6rd.
 
>   3.  After IPv6 provisioning =
completes, if DS-Lite parameters are
>       obtained =
from the DHCPv6 transaction or configured on the =
device,
>       initiate =
DS-Lite.
 
>   4.  Routes over the DS-Lite =
tunnel always have a higher
>       =
administrative distance than native IPv4 =
routes.
 
>higher or =
lower? Do you want traffic to prefer native or tunneled here? I read =
this as preferring native IPv4, but perhaps the real goal is to prefer =
IPv6?

Higher admin =
distance means lower priority and hence the DS-Lite tunnel has lower =
priority when both native IPv4 and DS-Lite run concurrently. =
  There is nothing to discuss about IPv6 for this =
bullet.
 
>   5.  Selection of 6rd tunnel =
or native IPv6 output interface on the CE
>       router is =
determined by the source IPv6 address of the =
packet
>       from a =
host, when different prefixes are available over 6rd =
vs.
>       native =
IPv6.  If the two interfaces provide the CE router =
with
>       the same =
prefix, then the CE router prefers the native =
IPv6
>       interface =
to the 6rd interface for forwarding traffic out the =
WAN
>       when both =
6rd and native IPv6 interfaces are =
active.
 
>This is close, =
but I think it would be much better to define the multihoming =
requirements generically and have 6rd just be one special =
case. 

See Wes’s =
reply to Brian Carpenter in v6ops.  We wanted the cheap CPE router =
to have a simple algorithm to forward packets when native IPv6 and 6rd =
have different prefixes.  The algorithm is checking the source =
address of the packet.   Why is the text not complete and =
instead close?  Source-address based switching is in line with PBR =
(switching on source address bit) that multihoming will =
require.   We wanted to stay away from the general multihoming =
requirement.  If you can please suggest some text that could change =
the bullet from close to complete that would help much. =

 
>   During a sunsetting activity such =
as deprecating 6rd and moving to
 
 
 
>Singh, et =
al.           &nbs=
p; Expires May 25, =
2012           &nb=
sp;     [Page 15]
 =

>Internet-Draft     &=
nbsp;   IPv6 CE Router =
Requirements         November =
2011
 
 
>   native IPv6, the IPv6 CE router =
MUST immediately advertise the 6rd
>   prefix with a Preferred Lifetime =
of zero and a Valid Lifetime of the
>   lower of the current Valid =
Lifetime and two hours (which must be
>   decremented in real time) in a =
Router Advertisement message as
>   described in Section 5.5.3, (e) of [RFC4862].  =

 
>"The CE =
route MUST immediately advertise the 6rd prefix.... "  when? =
when "during a sunsetting activity" ? 
 
Of course, during a =
sunsetting activity – the paragraph starts with “During a =
sunsetting activity”.
 
>How do you =
trigger that in software? As an implementor, I would have no idea =
what this MUST really means. 
 
The CPE completes =
DHCPv4 renewal process and does not receive any 6rd option in =
DHCPv4.  At this juncture, the 6rd prefix is deprecated.  It =
is the SP’s configuration to pick higher value for DHCPV4 =
lease_time vs. the 6rd prefix lifetime.  A retail CPE performs NUD =
(section 8 of RFC 5969) and NUD does not get replied to.  The =
retail CPE deprecates the 6rd prefix. =

 
>The heart of =
the problem here is *over-specification*. All the CPE needs to do is to =
deprecate the address when its lifetime expires just like any other =
prefix. >This will happen naturally once the DHCPv4 lease that 6rd =
was provisioned with expires and no new 6rd option arrives with the =
renewal (if there is any MUST >needed, it's at this stage). So: No =
special cases. No immediate interrupts to do this or that. No new case() =
statements specifically for 6rd, 6rd+native, >6rd+native+ds-lite, =
etc. Just the normal code run through when interfaces come up and down =
and prefixes are timed out. Nothing special. No =
surprises.

We too want to =
keep rules simple, but deprecation also involves the LAN segment and RFC =
4862’s two-hour rule.   Further, you missed the =
“during” the deprecation process when 6rd and native IPv6 =
run concurrently.    Thus there is no over-specification =
that I can see.
 
>Due to the two =
hours
>   rule specified in [RFC4862], the 6rd and the =
native IPv6 prefix will
>   coexist in the home =
network.  The two hours rule specified in section
>   5.5.3 of [RFC4862] causes any deprecated prefix to =
linger on the node
>   even when an RA has sent a =
Preferred Lifetime of zero to expire the
>   prefix to the node.  During =
such coexistence of multiple prefixes,
>   the CE router sends an ICMPv6 =
error for packets sourced or destined
>   related to the deprecated =
prefix.  Note this document already
>   includes text in bullet L-14 in =
section 4.3 for such a provision.
 
>Pointing out =
the two hour issue is fine, as well as what to do with deprecated =
prefixes, but this is *all* normal mutlihoming/renumbering procedures. =
We would be >far better off defining this generally, and letting 6rd =
+ native just fall in line happily as any other case where there are two =
interfaces with prefixes =
>assigned. 
 
We have difference =
in opinion.  We want to define specific behavior for a cheap CPE =
while you want generic requirements that make implementation rules fuzzy =
to CPE implementers.   We cannot punt to general =
multihoming/renumbering procedures that maps to many complex devices and =
complex networks.  
 
>I'm afraid that =
the requirements as written will lead to a lot of inconsistency. =

 
What specific =
inconsistency do we have with the current text?
 
Hemant
 

------_=_NextPart_001_01CCB05D.054785C5--

From shemant@cisco.com  Thu Dec  1 11:22:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873DC21F8D39 for ; Thu,  1 Dec 2011 11:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 y7PeRJRKECyK for ; Thu,  1 Dec 2011 11:22:39 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9A321F8D38 for ; Thu,  1 Dec 2011 11:22:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1268; q=dns/txt; s=iport; t=1322767359; x=1323976959; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=J7iRYoerjWK6rPDFKJQrAk4xoa51sp15dBOpE/1MYQQ=; b=FSryU1E/cp19eipiLRvkKQOl9Eui/sfjcwPkJl9wqEcZe8L0kBqTgp+P Su+Bd6bZtThx0jVLhFOY65DmCV7WLK9BQgRGaq9B9XlhiJqdwD1nG1xHG xEMLm+TLReHtjuRd93FIkpp1tQqBTkFomlh6nFdQ7SPc7ZcXaVez3SEZR 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAI3T106tJV2b/2dsb2JhbABEmliQI4EFgXIBAQEDAQEBAQ8BHQo0CwwEAgEIDgMEAQELBhcBBgEmHwkIAQEEARIIGodlCJk0AZ5DBIo9YwSIKJ5g
X-IronPort-AV: E=Sophos;i="4.71,279,1320624000"; d="scan'208";a="40419824"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 01 Dec 2011 19:22:39 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB1JMdK1013663;  Thu, 1 Dec 2011 19:22:39 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 13:22:38 -0600
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: Thu, 1 Dec 2011 13:22:37 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE4E1@XMB-RCD-109.cisco.com>
In-Reply-To: <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcywWV/HYkh6Ind7Sl2m2hpzL/WzXAABQOKA
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC8 4-4249-B93A-71DE C865F895 @employees.o rg><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>
From: "Hemant Singh (shemant)" 
To: "Ole Troan" , "Lorenzo Colitti" 
X-OriginalArrivalTime: 01 Dec 2011 19:22:38.0701 (UTC) FILETIME=[969A49D0:01CCB05E]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 19:22:40 -0000

Great summary, Ole. =20

Thanks,

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Ole Troan
Sent: Thursday, December 01, 2011 1:45 PM
To: Lorenzo Colitti
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Lorenzo,

> > For example, what is an implementation supposed to do if it gets a
PD of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the
next hop for 2001:db8:1:2::/64? Discard? It needs to know, at least for
the purpose of sending unreachables.
>=20
> normal RIB lookup. i.e. will follow default.
>=20
> But you don't want it to follow default. You want it to be an on-link
route on the interface that's connected to the BNG. Or at least, that's
the use-case that motivated the existence of this option.

the only thing the exclude option says, is that the prefix is _not_ part
of the delegation.
it may be used as the onlink prefix on the RR - DR link, if so the RR
can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR
doesn't need to know about it.

cheers,
Ole

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

From lorenzo@google.com  Thu Dec  1 11:28:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB221F9007 for ; Thu,  1 Dec 2011 11:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.841
X-Spam-Level: 
X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AqeFzoMpUbmd for ; Thu,  1 Dec 2011 11:28:15 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21D0F21F9006 for ; Thu,  1 Dec 2011 11:28:15 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2626782ggn.31 for ; Thu, 01 Dec 2011 11:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cL3MdhQZvlK6dDMTfVhUEwPrT3dKULZqH1KG7q88QGE=; b=eDxlZ587jyntWRRaKGcPxJOmmZI2NXSVNGf9XZHxU+GrC57MuxULQSuvTOfrQA7S9R ev+8m85Uo9ZhSWuI7sOA==
Received: by 10.236.128.138 with SMTP id f10mr14611933yhi.2.1322767694296; Thu, 01 Dec 2011 11:28:14 -0800 (PST)
Received: by 10.236.128.138 with SMTP id f10mr14611905yhi.2.1322767694123; Thu, 01 Dec 2011 11:28:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 11:27:52 -0800 (PST)
In-Reply-To: <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org>  <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org>  <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 11:27:52 -0800
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=20cf3005dd9087518f04b30cdaca
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 19:28:15 -0000

--20cf3005dd9087518f04b30cdaca
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 1, 2011 at 10:44, Ole Troan  wrote:

> > But you don't want it to follow default. You want it to be an on-link
> route on the interface that's connected to the BNG. Or at least, that's the
> use-case that motivated the existence of this option.
>
> the only thing the exclude option says, is that the prefix is _not_ part
> of the delegation.
> it may be used as the onlink prefix on the RR - DR link, if so the RR can
> use SLAAC and Prefix Discovery. if it is used somewhere else, the RR
> doesn't need to know about it.
>

But that creates an unreasonable burden on implementations.

To do this, implementations need to either a) create routes for all
excluded prefixes copying the default, and update them whenever the default
changes, or b) fully deaggregate every received prefix and install more
specifics for the ones that aren't excluded.

If you don't do either a) or b), then you're dropping traffic to global
addresses that the network has explicitly told you don't belong to you, and
that's broken.

So if you're a CE implementer, what are you supposed to put in the routing
table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes?
What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 routes?

--20cf3005dd9087518f04b30cdaca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2011 at 10:44, Ole Troan <otr=
oan@employees.org> wrote:




> But you don't want it to follow default. You want it to be an=
 on-link route on the interface that's connected to the BNG. Or at leas=
t, that's the use-case that motivated the existence of this option.







the only thing the exclude option says, is that the prefix is _not_ p=
art of the delegation.

it may be used as the onlink prefix on the RR - DR link, if so the RR can u=
se SLAAC and Prefix Discovery. if it is used somewhere else, the RR doesn&#=
39;t need to know about it.

But that cr=
eates an unreasonable burden on implementations.




To do this,=A0implementations need to either a) create =
routes for all excluded prefixes copying the default, and update them whene=
ver the default changes, or b) fully deaggregate every received prefix and =
install more specifics for the ones that aren't excluded.




If you don't do either a) or b), then you're dr=
opping traffic to global addresses that the network has explicitly told you=
 don't belong to you, and that's broken.



So if you're a CE implementer, what are you supposed to put in the rout=
ing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes?=
 What if you DHCPv6 PD a=A0/64 which excludes a /128? Create 2^64 - 1 route=
s?






--20cf3005dd9087518f04b30cdaca--

From ichiroumakino@gmail.com  Thu Dec  1 11:41:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94511E814A for ; Thu,  1 Dec 2011 11:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Level: 
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136,  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 t9u0V41bUhp9 for ; Thu,  1 Dec 2011 11:41:15 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A64C111E813E for ; Thu,  1 Dec 2011 11:41:14 -0800 (PST)
Received: by bkbzt19 with SMTP id zt19so2914900bkb.31 for ; Thu, 01 Dec 2011 11:41:13 -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=WzvQmHFO0Y2rwVi8pSIjXSo45zdkfwQ/XRw6B2i/FHo=; b=X/q+BBJhl5gb5Of6RcAusVAnZaTophfkGzhkuXcgqLuFac3rS/ziTjhAY/9JfHs0x8 Mq5sJkNUbApUuzclkGZSrGXWTTw2U0u7fKfKrN5Erkf+OiX7hhzfTmd43akZXPhCjwho TZqYqgriPmwQzpNUUOj7AUo98p+v0cGNMQ5aU=
Received: by 10.205.120.20 with SMTP id fw20mr8934203bkc.39.1322768473650; Thu, 01 Dec 2011 11:41:13 -0800 (PST)
Received: from dhcp-10-61-105-78.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e8sm13507290bkd.7.2011.12.01.11.41.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 11:41:12 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Thu, 1 Dec 2011 20:41:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org>  <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org>  <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 19:41:15 -0000

Lorenzo,

> > But you don't want it to follow default. You want it to be an =
on-link route on the interface that's connected to the BNG. Or at least, =
that's the use-case that motivated the existence of this option.
>=20
> the only thing the exclude option says, is that the prefix is _not_ =
part of the delegation.
> it may be used as the onlink prefix on the RR - DR link, if so the RR =
can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR =
doesn't need to know about it.
>=20
> But that creates an unreasonable burden on implementations.
>=20
> To do this, implementations need to either a) create routes for all =
excluded prefixes copying the default, and update them whenever the =
default changes, or b) fully deaggregate every received prefix and =
install more specifics for the ones that aren't excluded.
>=20
> If you don't do either a) or b), then you're dropping traffic to =
global addresses that the network has explicitly told you don't belong =
to you, and that's broken.
>=20
> So if you're a CE implementer, what are you supposed to put in the =
routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 =
routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - =
1 routes?

that's implementation specific.
put in a "fallback" route for the excluded prefix pointing to the =
default for example.

cheers,
Ole


From shemant@cisco.com  Thu Dec  1 11:47:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA2E21F9188 for ; Thu,  1 Dec 2011 11:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.255
X-Spam-Level: 
X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 CMcFCS2m0Ys0 for ; Thu,  1 Dec 2011 11:47:05 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAED21F9178 for ; Thu,  1 Dec 2011 11:47:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8913; q=dns/txt; s=iport; t=1322768825; x=1323978425; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=jYlDQQ+DCZdjmAeoWcjBaUfL598QFYygd+XiHLpa838=; b=mLmj3ZCSNUwmZ46mcbtyCJ6onI/qmi0MhHmtCLrqFq+OiKyR19YjigRd 0c/7q4li19oAggscZg0QKOTU7SZ1L0MtA5vtP++vNtyb4mOPDx6OYmJza nIy9oRc5fZmnEcdWhYcA7v/tooDnXojBqQQFkfFw2LedRkFLXp7ND3BBD 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcAAKvY106tJV2b/2dsb2JhbABEgk2YDJAjgQWBcgEBAQECARIBCREDTgsCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodlmUYBnkaKPWMEiCieYA
X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; d="scan'208,217";a="40437158"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 01 Dec 2011 19:47:04 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB1Jl42A023444;  Thu, 1 Dec 2011 19:47:04 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Dec 2011 13:47:04 -0600
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_01CCB062.000D37E4"
Date: Thu, 1 Dec 2011 13:47:03 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE51E@XMB-RCD-109.cisco.com>
In-Reply-To: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Section 4.4 of 6204-bis
Thread-Index: AcywG5GBOQBtp+YsTgmfooI2ncr23wAQzzNA
References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , 
X-OriginalArrivalTime: 01 Dec 2011 19:47:04.0361 (UTC) FILETIME=[00344190:01CCB062]
Subject: Re: [v6ops] Section 4.4 of 6204-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 19:47:06 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB062.000D37E4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Section 4.4 of 6204-bis

=20

=20

=20
>   6.  The CE router messages to the host the use of native IPv6 in
>       preference to 6rd, in the case where the two interfaces use
>       different prefixes.

=20

>"CE router messages to the host" - with what, a new protocol? The host
does what it wants with the prefixes it has, the router is a slave to
its source selection and has to route out the appropriate interface
>accordingly. This is "the curse of end-to-end" to quote Lorenzo.=20

=20

We had text for this bullet to say that the CPE sends to the host a SAS
Policy Table but could not get consensus on the design team to include
the term of "SAS Policy Table".   The 6man WG has a draft on
distribution of SAS Policy Table via DHCP.   Another distribution
mechanism is manual where the user checks the CPE router and see that
6rd has prefix A and native IPv6 has prefix B and thus provisions the
host SAS Policy Table to prefer native IPv6 over 6rd.  The rule that you
specified in v6ops can also be folded in the host SAS Policy Table. =20

=20

Hemant





=20

=20

=20

=20




=20


------_=_NextPart_001_01CCB062.000D37E4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Mark Townsley
Sent: Thursday, December 01, 2011 6:22 =
AM
To: v6ops@ietf.org Operations
Subject: [v6ops] =
Section 4.4 of 6204-bis
 
 
 
>   6.  The CE =
router messages to the host the use of native IPv6 =
in
>     &nbs=
p; preference to 6rd, in the case where the two interfaces =
use
>     &nbs=
p; different prefixes.

 

>"CE = router messages to the host" - with what, a new protocol? The host = does what it wants with the prefixes it has, the router is a slave to = its source selection and has to route out the appropriate interface = >accordingly. This is "the = curse of end-to-end" to quote Lorenzo. 

 

We had text for this bullet to say that the CPE sends to the host a = SAS Policy Table but could not get consensus on the design team to = include the term of “SAS Policy Table”.   The 6man = WG has a draft on distribution of SAS Policy Table via DHCP. =   Another distribution mechanism is manual where the user = checks the CPE router and see that 6rd has prefix A and native IPv6 has = prefix B and thus provisions the host SAS Policy Table to prefer native = IPv6 over 6rd.  The rule that you specified in v6ops can also be = folded in the host SAS Policy Table. 

 

Hemant



 

 

 

 


 

------_=_NextPart_001_01CCB062.000D37E4-- From mark@townsley.net Thu Dec 1 11:57:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533EC1F0C55 for ; Thu, 1 Dec 2011 11:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.256, 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 vmKvc+M4cvoE for ; Thu, 1 Dec 2011 11:57:16 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68C231F0C50 for ; Thu, 1 Dec 2011 11:57:15 -0800 (PST) Received: by faap14 with SMTP id p14so1975776faa.31 for ; Thu, 01 Dec 2011 11:57:14 -0800 (PST) Received: by 10.204.9.211 with SMTP id m19mr8722259bkm.92.1322769433205; Thu, 01 Dec 2011 11:57:13 -0800 (PST) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j9sm13633409bkd.2.2011.12.01.11.56.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 11:57:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-14-864820693 From: Mark Townsley In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F213AB69F@crexc50p> Date: Thu, 1 Dec 2011 20:56:44 +0100 Message-Id: <7E5672F5-9F1F-40F4-B585-17A6C70E22EF@townsley.net> References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F213AB69F@crexc50p> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Section 4.4 of 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 19:57:17 -0000 --Apple-Mail-14-864820693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 1, 2011, at 7:44 PM, STARK, BARBARA H wrote: > In-line, marked with . > Barbara > =20 > > 6RD-2: If the IPv6 CE router implements 6rd functionality, it = MUST > > support 6rd configuration via the 6rd DHCPv4 Option (212) = and > > if the IPv6 CE router is capable of automated = configuration > > of IPv4 through IPCP (i.e., over a PPP connection), it = MUST > > support user-entered configuration of 6rd. =20 > =20 > >Why not just say it MUST support DHCPv4 option 212 and Manual = configuration and stop at that? If we are going to include manual = config, it is effectively >*always* an option, not just for PPP or any = other >type of access link. Just make it a MUST and be done. > =20 > Because the MSOs said they didn=92t want to implement manual = configuration in their devices. > So we compromised on language that would provide them an exclusion, = but make sure they capability was present in devices where it was = actually needed. Ah, so if the router supports PPP, it MUST have manual config. If it = doesn't support PPP, it really should not have manual config?=20 So now the document has hidden Cable vs. DSL origin requirements, with = PPP as the switch for which is being catered too.=20 This kind of wiggle-wording might seem clever from the operational side, = but from the vendor side it's extremely annoying if not completely out = of touch. Either you guys want custom devices, in which case you really = don't need well-defined standards specs, or you want standards so that = we don't have to build different versions for different types of ISPs = (we call that "splatter", and it's absolutely something that hurts the = retail side when it comes to building these things on a budget that can = work across a myriad of SP environments).=20 Manual config is either a requirement or not, tying it to DHCP, PPP, = 3GPP, or anything else is making this document more complex, and the job = of the vendors more difficult (read: more expensive for consumers).=20 > =20 > >Further, if we are going to mention PPP, rather than falling back to = manual only, why not allow DHCP configuration after PPP IPCP is = finished? > =20 > Agree. Barbara can comment as well since she provided such text. > =20 > Nothing prohibits DHCPv4 configuration after IPCP. I don=92t see = anything that says it=92s not allowed. However, it can=92t be assumed, = since almost no PPP-based access network runs a DHCPv4 server for = PPP-connected customers. And any ISP who isn=92t running a DHCPv4 server = today, is *highly* unlikely to add one just for 6rd. Remember, the = promise of 6rd is that it doesn=92t require upgrades to existing = infrastructure in the access network. To suggest that this CE router = draft somehow can require PPP access networks to add DHCPv4 servers in = order to do 6rd is a non-starter. In my experience, CE router vendors = are looking for realistic advice, and not purist recommendations that = are not representative of the real world. There is a draft on how to add this to PPP IPCP. If that's easier than = DHCP, I'd like to hear it, but I usually hear that the BNG vendors can't = be bothered to add a new option to IPCP. Also there is the pushback that = pppext is likely to give, though I'm with you on the "realistic advice" = side: if adding this to PPP IPCP will help you deploy IPv6 to more = customers sooner, and your vendors will comply, let's do it. BTW, BNGs can *be* the DHCP server and return a reply that consists of = nothing but option 212 (and not worrying about the IP address lease = part). That doesn't require new "DHCP infrastructure", at least not in = the sense of new DHCP servers.=20 > =20 > >=46rom RFC2131: "DHCPINFORM - Client to server, asking only for = local configuration parameters; client already has externally configured = network address." > =20 > >Back when the PPP folks actively decided to stop duplicating DHCP = functionality in IPCP, this was the recommended approach (and Windows = stacks and the like actually try to obtain additional >parameters for = PPP connections after IPCP comes up, though often the network does not = have any additional parameters to give...). This gives PPP connections a = pretty decent chance to work with 6rd >automatically, using the same = DHCP configuration as non-PPP.=20 > =20 > Agree. > =20 > See above comment. >=20 Please read http://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00 > > 6RD-3: If the CE router implements 6rd functionality, it MUST = allow > > the user to specify whether all IPv6 traffic goes to the = 6rd > > Border Relay, or whether IPv6 traffic to other = destinations > > within the same 6rd domain are routed directly to those > > destinations. The CE router MAY use other mechanisms to > > configure this. Such mechanisms are outside the scope of > > this document. > =20 > >Do you really mean the "user" is supposed to be able to specify = whether IPv6 traffic always going through the BR, or the "operator" is = supposed to be able to >specify this? > =20 > >This behavior, while straight-forward to implement as it is = effectively removing a more-specific route on the 6rd virtual interface, = is out of scope of RFC 5969 >as currently defined. There is no way to = specify this in DHCPv4 configuration. One might be able to configure = this from the network with PIO or DHCPv6 route >options in a general = manner, but this hasn't been specified anywhere that I am aware of = within the context of 6rd. I understand the BBF has included some = >specifics around this, and perhaps it is best if those requirements = stay in the BBF or at least we provide a reference to them from here. = Otherwise, this >requirement remains under-specified as written, and if = expounded would effectively be an update (in the formal sense) to RFC = 5969.=20 >=20 > How does BBF specify the CE router gets configured to go directly to = other destinations?=20 It just did, I suppose. In TR-124-something, right? > =20 > Via TR-069, or manually. It would be nice if it could also be = via DHCPv4 option, but the companies asking for this don=92t really see = the lack of a DHCPv4 option as being a showstopper. > =20 Right, when it was added it to BBF docs rather than starting with the = IETF, it effectively became a BBF-only, largely TR-69-only, thing. = That's fine, but that makes circling the requirement back around to the = root, a problem.=20 - Mark --Apple-Mail-14-864820693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 1, 2011, at 7:44 PM, STARK, = BARBARA H wrote:

In-line, marked with = <bhs>.
>   6RD-2:  If the IPv6 CE router implements 6rd =
functionality, it MUST
>>           if =
the IPv6 CE router is capable of automated =
configuration
>           of =
IPv4 through IPCP (i.e., over a PPP connection), it =
MUST
>           =
support user-entered configuration of 6rd.  =
>Why not just say it MUST support DHCPv4 option 212 and Manual = configuration and stop at that? If we are going to include manual = config, it is effectively >*always* an option, not just for PPP or = any other >type of access link. Just = make it a MUST and be done.
So we = compromised on language that would provide them an exclusion, but make = sure they capability was present in devices where it was actually = needed.

Ah, so if the router supports PPP, it MUST have manual = config. If it doesn't support PPP, it really should not have manual = config? 

So now the document has hidden = Cable vs. DSL origin requirements, with PPP as the switch for which is = being catered too. 

This kind of = wiggle-wording might seem clever from the operational side, but from the = vendor side it's extremely annoying if not completely out of touch. = Either you guys want custom devices, in which case you really don't need = well-defined standards specs, or you want standards so that we don't = have to build different versions for different types of ISPs (we call = that "splatter", and it's absolutely something that hurts the retail = side when it comes to building these things on a budget that can work = across a myriad of SP = environments). 

Manual config is either a = requirement or not, tying it to DHCP, PPP, 3GPP, or anything else is = making this document more complex, and the job of the vendors more = difficult (read: more expensive for = consumers). 

>Further, if we are going to mention PPP, rather than falling = back to manual only, why not allow DHCP configuration after PPP IPCP is = finished?
 

BTW,  BNGs can *be* the DHCP = server and return a reply that consists of nothing but option 212 (and = not worrying about the IP address lease part). That doesn't require new = "DHCP infrastructure", at least not in the sense of new DHCP = servers. 

>From RFC2131: "DHCPINFORM   -  Client to = server, asking only for local configuration parameters; client = already has externally configured network = address."
>Back when the PPP folks actively decided to stop duplicating = DHCP functionality in IPCP, this was the recommended approach (and = Windows stacks and the like actually try to obtain additional >parameters for PPP connections after IPCP = comes up, though often the network does not have any additional = parameters to give...). This gives PPP connections a pretty decent = chance to work with 6rd >automatically, using the same DHCP = configuration as non-PPP. 
 
<bhs> See above = comment.

Please = read http= ://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00

   6RD-3:  If =
the CE router implements 6rd functionality, it MUST =
allow
>           =
the user to specify whether all IPv6 traffic goes to the =
6rd
>           =
Border Relay, or whether IPv6 traffic to other =
destinations
>           =
within the same 6rd domain are routed directly to =
those
>           =
destinations.  The CE router MAY use other mechanisms =
to
>        =
   configure this.  Such mechanisms are outside the =
scope of
>           =
this document.
>Do you really mean the "user" is supposed to be able to specify = whether IPv6 traffic always going through the BR, or the "operator" is = supposed to be able to >specify = this?
>This behavior, while straight-forward to implement as it is = effectively removing a more-specific route on the 6rd virtual interface, = is out of scope of RFC 5969 >as currently defined. There is no way to = specify this in DHCPv4 configuration. One might be able to configure = this from the network with PIO or DHCPv6 route >options in a general manner, but this = hasn't been specified anywhere that I am aware of within the context of = 6rd. I understand the BBF has included some >specifics around this, and perhaps it is = best if those requirements stay in the BBF or at least we provide a = reference to them from here. Otherwise, this >requirement remains under-specified as = written, and if expounded would effectively be an update (in the formal = sense) to RFC 5969. 

How does BBF = specify the CE router gets configured to go directly to other = destinations? 

It just did, I suppose. In TR-124-something, = right?

Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:27:30 -0000 In theory yes.. in practice it depends. We got stuff for Rel-8 that is = still in IESG. So quite unlikely anything to happen other than draft = being updated to RFC number, especially when the I-D is showing progress = (like proto write-up done recently). - JOuni On Dec 1, 2011, at 8:23 PM, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 06:39, jouni korhonen = wrote: > Getting that happen is quite unlikely. Rel-10 is already frozen. >=20 > Frozen standards should not depend on internet drafts. The draft even = says that it is inappropriate to cite IETF standards other than as work = in progress, right? From lorenzo@google.com Thu Dec 1 12:29:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1741F0CAE for ; Thu, 1 Dec 2011 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.853 X-Spam-Level: X-Spam-Status: No, score=-102.853 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Eil42XU6to1O for ; Thu, 1 Dec 2011 12:29:31 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14C1F0C90 for ; Thu, 1 Dec 2011 12:29:31 -0800 (PST) Received: by ghrr18 with SMTP id r18so2679171ghr.31 for ; Thu, 01 Dec 2011 12:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=GiKSRDOhHDfG34W4GBs/RtCANgsjUHe6PXsefX0G54g=; b=oiZdD5WMWKlo9PQU2Q80mECrTLuxnuSJ1ODd9B6jmzT2mP4OfVc8FYFLmDLZl5GSbe wnLAcOg+atxSRJ1VyJfQ== Received: by 10.236.128.138 with SMTP id f10mr15003510yhi.2.1322771371210; Thu, 01 Dec 2011 12:29:31 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr15003493yhi.2.1322771371129; Thu, 01 Dec 2011 12:29:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 12:29:10 -0800 (PST) In-Reply-To: <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 12:29:10 -0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=20cf3005dd90b1fbca04b30db57e X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:29:32 -0000 --20cf3005dd90b1fbca04b30db57e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 11:41, Ole Troan wrote: > > So if you're a CE implementer, what are you supposed to put in the > routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 > routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 > routes? > > that's implementation specific. > put in a "fallback" route for the excluded prefix pointing to the default > for example. > And when the default changes, or you lose the default? Send the traffic to a gateway that doesn't exist any more? Or keep monitoring the routing table for changes so you can keep your excluded routes pointing in the right direction? Neither of these seem reasonable things to ask of an implementation. --20cf3005dd90b1fbca04b30db57e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 11:41, Ole Troan <otr= oan@employees.org> wrote:
> So if you're a CE implementer, what are you supposed to = put in the routing table if you DHCPv6 PD a /48 which excludes a /64? Creat= e 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2= ^64 - 1 routes?

that's implementation specific.
put in a "fallback" route for the excluded prefix pointing to the= default for example.

And when the defa= ult changes, or you lose the default? Send the traffic to a gateway that do= esn't exist any more? Or keep monitoring the routing table for changes = so you can keep your excluded routes pointing in the right direction? Neith= er of these seem reasonable things to ask of an implementation.
--20cf3005dd90b1fbca04b30db57e-- From shemant@cisco.com Thu Dec 1 12:48:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1A11E80A4 for ; Thu, 1 Dec 2011 12:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 X+1woqQwacjC for ; Thu, 1 Dec 2011 12:48:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7711E8089 for ; Thu, 1 Dec 2011 12:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=25323; q=dns/txt; s=iport; t=1322772524; x=1323982124; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=CMRPwRcw8NTZ7B8YaQTmlRnmrmv9Cv4y7cITvQkQCEk=; b=hZ/21/0HMuRlwxfeHJQIE0b92pySIehbpWpGHwrU78GWC40gdMtwox8v TUcYI+RzXXRyKHqh1C5uGuoDsqK4SIfXsKDdXEBezs1RCgkuXFv2X+/8E hP15xwmXSoc4xzgJw8aDEDO3d10UIGxKCDlBEEsnaTZ+teP+VW43mj17m E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAHrn106tJXHA/2dsb2JhbABDgk2YDogjAYd/gQWBcgEBAQECARIBCREDTgsCAQgRBAEBCwYQBwEGAUUJCAEBBAESCBqHZQiZNQGeRIo9YwSIKJ5g X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; d="scan'208,217";a="40442185" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 01 Dec 2011 20:48:44 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pB1KmhQ1004354; Thu, 1 Dec 2011 20:48:43 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 14:48:43 -0600 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_01CCB06A.9CFB4600" Date: Thu, 1 Dec 2011 14:48:42 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE577@XMB-RCD-109.cisco.com> In-Reply-To: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Section 4.4 of 6204-bis Thread-Index: AcywG5GBOQBtp+YsTgmfooI2ncr23wASSSiA References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , X-OriginalArrivalTime: 01 Dec 2011 20:48:43.0580 (UTC) FILETIME=[9D1C47C0:01CCB06A] Subject: Re: [v6ops] Section 4.4 of 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:48:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB06A.9CFB4600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Thursday, December 01, 2011 6:22 AM To: v6ops@ietf.org Operations Subject: [v6ops] Section 4.4 of 6204-bis =20 =20 > DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the > CE Router MUST support using a DS-Lite DHCPv6 option > [RFC6334 ] to configure the DS-Lite tunnel. The IPv6 CE > Router MAY use other mechanisms to configure DS-Lite > parameters. Such mechanisms are outside the scope of this > document. =20 =20 =20 =20 =20 =20 >Singh, et al. Expires May 25, 2012 [Page 14] =20 >Internet-Draft IPv6 CE Router Requirements November 2011 =20 =20 > DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address > Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. =20 > DLW-4: If the IPv6 CE Router is configured with a public IPv4 > address on its WAN interface, where public IPv4 address is > defined as any address which is not in the private IP address > space specified in [RFC5735 ], then the IPv6 CE Router SHOULD > disable the DS-Lite B4 element. =20 >This is very bad direction. =20 No. =20 >DS-Lite was designed to combat Private IPv4 Address Exhaustion, and you have a requirement that talks about the CPE receiving not only a Public but a Private >IPv4 address and tying specific behavior to that?=20 =20 Where does the text say both of public IPv4 and private IPv4? The text only says that if the CPE router is deployed in a native IPv4 deployment, the CPE has no use for DS-Lite and the CPE should disable DS-Lite. Not all IPv4 deployments are IPv4 address depleted and that is what the CPE does in such a deployment. Please see more of my responses below as well.=20 =20 >Where is the requirement that if DS-Lite is configured, the CPE should not be expected to receive an IPv4 address at all on its WAN interface so that it doesn't >hammer the network asking for one? Or, (and perhaps this is better) the recommended way for DHCPv4 (and PPP IPCP) to tell the CPE that it has no IPv4 and not to >ask for it (so we don't repeat the "DHCPv6 storm" problem talked about so much here)?=20 =20 See the Coexistence section which is section 4.4.3 in rfc6204bis and bullets 1 and 3. Of course, by default DHC (v4 or v6) tries forever. In bullet 1, DHC is one means the CPE WAN uses to acquire a native IPv4 address. While DHCPv4 tries forever, if DHCPv6 completes and the CPE is issued DS-Lite parameters via DHCPv6 or DS-Lite is manually configured on the CPE, the CPE turns on DS-Lite and stops DHCPv4. No DHCP storm. =20 =20 >That's what we should be defining here, or you have hamstrung the whole point of DS-Lite which was to reduce the number of IPv4 addresses (public or private!) >needed by the access network. The CPE MUST be able to operate in the *absence* of an IPv4 address on its WAN interface! That's the requirement we need here! =20 If the CPE uses native IPv4 the CPE does need a public IPv4 address on the WAN because the CPE has to do NAT44. =20 =20 >Also, specific nits on the above wording (though I think the whole requirement is in question):=20 =20 >- "RFC 5735 private IP address space" is just an indirection to RFC 1918, just call it RFC 1918.=20 >- I see a possible conflict here with the /10 space that may or may not be allocated for CGN deployment. =20 Francois-Xavier Le Bail in v6ops asked to use rfc 5735 and I agree with him. If Francois-Xavier agrees to move back to 1918, we can change the text. There can be any number of possible conflicts in the future but we have to start somewhere for private IPv4 address space. That is why the requirement was changed from a MUST to a SHOULD. =20 =20 > DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast > data MUST NOT be sent on any DS-Lite tunnel. =20 >Why not? As with the similar 6rd requirement, please just leave this out. Why hamstring future efforts to define multicast here? =20 When future comes and an RFC is available, the text will change. Till then it is good to keey multicast data out of IP transition tech. =20 > DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD > tunnel. =20 >Why make a requirement on the forwarding path here? Sure, it is probably bad operational practice to configure a CE such that it would end up with a routing path >that did this, but this kind of requirement forces the CE to actually check on the forwarding path whether this is occurring and drop the packet if it does. A CE >could easily misinterpret this as filtering all Protocol 41 traffic. Not to mention, this could end up becoming a test case for certification.=20 =20 >In general: Let's please avoid making any sort of laundry lists of MUST NOTs around negative cases. We're better off defining MUSTs for things we want to >happen.=20 Same response as the response I gave in an earlier email today to 6RD-5. The response is reproduced below. =20 "Implementations do stupid things and thus it's good to specify such text. At the Taipei IETF during a hallway conversation between myself, Lorenzo, Ole, and some others, I heard Lorenzo say, "it's good to include rules such as this one." Lorenzo can keep me honest." =20 Hemant =20 ------_=_NextPart_001_01CCB06A.9CFB4600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

 

From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Mark Townsley
Sent: Thursday, December 01, 2011 6:22 = AM
To: v6ops@ietf.org Operations
Subject: [v6ops] = Section 4.4 of 6204-bis

 

 
 =
>  DLW-2:  If the IPv6 CE Router implements DS-Lite =
functionality, the
 =
>          CE Router =
MUST support using a DS-Lite DHCPv6 option
 =
>          [RFC6334] to =
configure the DS-Lite tunnel.  The IPv6 CE
 =
>          Router MAY =
use other mechanisms to configure DS-Lite
 =
>          =
parameters.  Such mechanisms are outside the scope of =
this
 >        &nb=
sp; document.
 
 
 
 
 
 
>Singh, et =
al.           &nbs=
p; Expires May 25, =
2012           &nb=
sp;     [Page 14]
<=
span style=3D'color:windowtext;text-decoration:none'> =

>Internet-Draft       =
  IPv6 CE Router =
Requirements         November =
2011
 
 
>   DLW-3:  IPv6 CE =
Router MUST NOT perform IPv4 Network Address
>     &nbs=
p;     Translation (NAT) on IPv4 traffic =
encapsulated using DS-Lite.
 
>   DLW-4:  If the =
IPv6 CE Router is configured with a public IPv4
>     &nbs=
p;     address on its WAN interface, where public =
IPv4 address is
>     &nbs=
p;     defined as any address which is not in the =
private IP address
>     &nbs=
p;     space specified in [RFC5735], then the IPv6 CE Router =
SHOULD
>     &nbs=
p;     disable the DS-Lite B4 =
element.

 

>This is very = bad direction.

 

No.

 

>DS-Lite was designed to combat Private IPv4 Address = Exhaustion, and you have a requirement that talks about the CPE = receiving not only a Public but a Private >IPv4 address and tying = specific behavior to that? 

 

Where = does the text say both of public IPv4 and private IPv4?  The text = only says that if the CPE router is deployed in a native IPv4 = deployment, the CPE has no use for DS-Lite and the CPE should disable = DS-Lite.   Not all IPv4 deployments are IPv4 address depleted = and that is what the CPE does in such a deployment.  Please see = more of my responses below as well.

 

>Where is the requirement that if DS-Lite is configured, the = CPE should not be expected to receive an IPv4 address at all on its WAN = interface so that it doesn't >hammer the network asking for one? Or, = (and perhaps this is better) the recommended way for DHCPv4 (and PPP = IPCP) to tell the CPE that it has no IPv4 and not to >ask for it (so = we don't repeat the "DHCPv6 storm" problem talked about so = much here)? 

 

See = the Coexistence section which is section 4.4.3 in rfc6204bis and bullets = 1 and 3.  Of course, by default DHC (v4 or v6) tries forever.  = In bullet 1, DHC is one means the CPE WAN uses to acquire a native IPv4 = address.  While DHCPv4 tries forever, if DHCPv6 completes and the = CPE is issued DS-Lite parameters via DHCPv6 or DS-Lite is manually = configured on the CPE, the CPE turns on DS-Lite and stops DHCPv4. =  No DHCP storm.

 

 

>That's what we should be defining here, or you have hamstrung = the whole point of DS-Lite which was to reduce the number of IPv4 = addresses (public or private!) >needed by the access network. The CPE = MUST be able to operate in the *absence* of an IPv4 address on its WAN = interface! That's the requirement we need = here!

 

If the CPE uses native IPv4 the CPE does need a public IPv4 address = on the WAN because the CPE has to do NAT44.  =

 

>Also, specific nits = on the above wording (though I think the whole requirement is in = question): 

 

>- "RFC = 5735 private IP address space" is just an indirection to RFC 1918, = just call it RFC 1918. 

>- I see a possible conflict here with the /10 space that may = or may not be allocated for CGN = deployment.

 

Francois-Xavier Le Bail in v6ops asked to use rfc = 5735 and I agree with him.   If Francois-Xavier agrees to move = back to 1918, we can change the text.  There can be any number of = possible conflicts in the future but we have to start somewhere for = private IPv4 address space.  That is why the requirement was = changed from a MUST to a SHOULD.  = 

 
>   DLW-5:  If DS-Lite is =
operational on the IPv6 CE Router, multicast
>        &nb=
sp;  data MUST NOT be sent on any DS-Lite =
tunnel.

 

>Why not? As = with the similar 6rd requirement, please just leave this out. Why = hamstring future efforts to define multicast = here?

 

When = future comes and an RFC is available, the text will change.  Till = then it is good to keey multicast data out of IP transition = tech.

 
>   DLW-6:  The CE =
Router MUST NOT forward DS-Lite traffic over a 6RD
>     &nbs=
p;     tunnel.

 

>Why make a = requirement on the forwarding path here? Sure, it is probably bad = operational practice to configure a CE such that it would end up with a = routing path >that did this, but this kind of requirement forces the = CE to actually check on the forwarding path whether this is occurring = and drop the packet if it does. A CE >could easily misinterpret this = as filtering all Protocol 41 traffic. Not to mention, this could end up = becoming a test case for = certification. 

 

>In general: = Let's please avoid making any sort of laundry lists of MUST NOTs around = negative cases. We're better off defining MUSTs for things we want to = >happen. 


Same response as the response I gave in an = earlier email today to 6RD-5.  The response is reproduced = below.

 

“Implementations do stupid things and thus = it’s good to specify such text.  At the Taipei IETF during a = hallway conversation between myself, Lorenzo, Ole, and some others, I = heard Lorenzo say, “it’s good to include rules such as this = one.”  Lorenzo can keep me = honest.”

 

Hemant

 

------_=_NextPart_001_01CCB06A.9CFB4600-- From brian.e.carpenter@gmail.com Thu Dec 1 13:20:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5811F0C56 for ; Thu, 1 Dec 2011 13:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dY9P3OCFyNUL for ; Thu, 1 Dec 2011 13:20:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D821C1F0C5E for ; Thu, 1 Dec 2011 13:20:27 -0800 (PST) Received: by faap14 with SMTP id p14so2054587faa.31 for ; Thu, 01 Dec 2011 13:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HgTxpB2v/ihO0bKPHsl31uADtfDLWqcRAWLKTxPVpa4=; b=qTO8v/W4GC6bpCQnVeExCHdkPEqjx3+Ld3h/+RIuvgQPp78X96L7PZqbQYMb09GHiY /p36cTC+eRzPXW9Ru4fdE8eM1+ciBiLYx9FE02QARffVZ4KtJfDSaL7E5zY9JJ/FvV3u olrJPzW9gV7UIQh0rao5TL7dSwtcLkrWJNMk0= Received: by 10.204.155.76 with SMTP id r12mr9058727bkw.115.1322774426879; Thu, 01 Dec 2011 13:20:26 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id hw14sm14083569bkc.16.2011.12.01.13.20.24 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 13:20:26 -0800 (PST) Message-ID: <4ED7EF92.2050807@gmail.com> Date: Fri, 02 Dec 2011 10:20:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni korhonen References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <4ED698D6.5090305@gmail.com> <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com> In-Reply-To: <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:20:29 -0000 Jouni, On 2011-12-02 03:39, jouni korhonen wrote: > Brian, >=20 > Getting that happen is quite unlikely. Rel-10 is already frozen. So it could be fixed in Rel-11, or ignored in practice. In any case we should not hamper the generic CPE because of this restriction in one particular release of one particular access technology. As I said a day or two ago, issues specific to a given access technology should be clearly separated from the generic requirements. Brian > - Jouni >=20 >=20 > On Nov 30, 2011, at 10:57 PM, Brian E Carpenter wrote: >=20 >> On 2011-12-01 09:12, Lorenzo Colitti wrote: >>> On Wed, Nov 30, 2011 at 12:03, V=C3=ADzdal Ale=C5=A1 wrote: >>> >>>> the Prefix Delegation RFC 3633 states a limitation in section 12.1 t= hat 'a >>>> prefix delegated to a requesting router cannot be used by the delega= ting >>>> router'. This limitation is a problem for the 3GPP case where they h= ave >>>> standardised that the link prefix (/64) and the delegated prefix sha= ll be >>>> aggregatable to a single prefix. So, you can use pd-exclude to signa= l the >>>> prefix part in use. >>>> >>> Fine, but if the only problem is that text, then why do we need a new= >>> option? Can't we just say somewhere that if the part of the prefix is= used >>> to connect the requesting router to the network, then the network MUS= T >>> signal that to the client using some other means such as an RA? >> Better would be for someone who visits 3GPP land to persuade them to r= emove >> that restriction, which is obviously annoying. >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 From lorenzo@google.com Thu Dec 1 14:50:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F511E8146 for ; Thu, 1 Dec 2011 14:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.875 X-Spam-Level: X-Spam-Status: No, score=-102.875 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 nk6ZPSdUk8aM for ; Thu, 1 Dec 2011 14:50:25 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFED211E8138 for ; Thu, 1 Dec 2011 14:50:24 -0800 (PST) Received: by ywm13 with SMTP id 13so2836164ywm.31 for ; Thu, 01 Dec 2011 14:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=nDN3m2gNC/r3CB92rT4AMlXTnkV3fjOhp4WRmtxUi2M=; b=JEhWHc2xB5iJwqqEA4AH/9CpqVm5URE1AAcKCRdr55PJsFdrhJIKcxtjoV+64/jBOS ramnu6dKWIwrZka4cLUg== Received: by 10.236.131.82 with SMTP id l58mr14932357yhi.36.1322779817296; Thu, 01 Dec 2011 14:50:17 -0800 (PST) Received: by 10.236.131.82 with SMTP id l58mr14932339yhi.36.1322779817207; Thu, 01 Dec 2011 14:50:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 14:49:56 -0800 (PST) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 14:49:56 -0800 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=20cf3011e2031ee66e04b30fadca X-System-Of-Record: true Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:50:25 -0000 --20cf3011e2031ee66e04b30fadca Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant) wrote: > Good use case. Note the rule that Mark specified, as I said, is already > part of RFC 3484, section 6, and Rule 7. Thus a CPE is entitled to use the > rule 7 and rfc6204bis can still be silent about this rule because the rule > is already specified in RFC 3484. > RFC 3484 is not relevant here. It describes how nodes choose source addressing when originating packets. It doesn't apply to forwarding traffic. --20cf3011e2031ee66e04b30fadca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 28, 2011 at 19:43, Hemant Singh (she= mant) <shemant@ci= sco.com> wrote:

Good use case.=A0 N= ote the rule that Mark specified, as I said, is already part of RFC 3484, s= ection 6, and Rule 7.=A0 Thus a CPE is entitled to use the rule 7 and rfc62= 04bis can still be silent about this rule because the rule is already speci= fied in RFC 3484.

RFC 3484 is not relevant here. It describes h= ow nodes choose source addressing when originating packets. It doesn't = apply to forwarding traffic.
--20cf3011e2031ee66e04b30fadca-- From shemant@cisco.com Thu Dec 1 15:13:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50FA21F8494 for ; Thu, 1 Dec 2011 15:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mxBuV7NQMmCz for ; Thu, 1 Dec 2011 15:13:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9A21F8445 for ; Thu, 1 Dec 2011 15:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7629; q=dns/txt; s=iport; t=1322781199; x=1323990799; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=q3nj9s2W9VEqT7fMoxl479CrTGqMAoFlR0FuPBQWxvA=; b=WZ3UpwQ+0i8h2ykB8nE0JGXm30npbUsUqhjGVlb+vBvkqK4ZAV74iBWN ynOm3MGFuM0z3urFM0DLilvCvWWV+q3TMKpVZB5Z9oyQ9B5QDgQqeZbrK 6zcupLLmGmLWmSmFTqRl7GnfeOH3gW0n/lav4xIPW88svrae4Z/2eWvOV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAADQJ2E6tJV2Z/2dsb2JhbABDgk2YE5AjgQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqhOQGeQoo9YwSIKJ5g X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; d="scan'208,217";a="40474886" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 01 Dec 2011 23:13:18 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1NDIZq010660; Thu, 1 Dec 2011 23:13:18 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 17:13:18 -0600 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_01CCB07E.CF5AF70A" Date: Thu, 1 Dec 2011 17:13:17 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: Acywe5i9LnH4ertWSMeBzXzrCyS32AAAcRGg References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 01 Dec 2011 23:13:18.0285 (UTC) FILETIME=[CFA337D0:01CCB07E] Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:13:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB07E.CF5AF70A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, =20 Agree. However I am only drawing a parallel with the RFC 3484 rule for source-based routing - that's all. For example when PBR routes based on the source-address, PBR has to first match the source-address of the packet with an ACL and then apply a PBR rule for next-hop which for 6rd sunsetting is 6rd vs. native IPv6 each using different prefixes. This 6rd tunneled vs. native IPv6 source-based forwarding is similar in principle to the rule 7 of section 6 of RFC 3484. =20 Also, the rule specified by Mark is a valid rule for CPE router requirements even with Victor's use case because the network has to issue an ICMPv4/ICMPv6 Destination Unreachable to the source CPE. Having thought some more on Victor's use case where source CPE sent 6rd tunneled packet but the destination CPE switched to native IPv6, if the CPEs are communicating directly, the source CPE should timeout NUD with the destination CPE and not even issue any packet on the tunnel to the destination CPE. =20 =20 Hemant =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Thursday, December 01, 2011 5:50 PM To: Hemant Singh (shemant) Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen; v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting =20 On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant) wrote: Good use case. Note the rule that Mark specified, as I said, is already part of RFC 3484, section 6, and Rule 7. Thus a CPE is entitled to use the rule 7 and rfc6204bis can still be silent about this rule because the rule is already specified in RFC 3484. RFC 3484 is not relevant here. It describes how nodes choose source addressing when originating packets. It doesn't apply to forwarding traffic. ------_=_NextPart_001_01CCB07E.CF5AF70A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,

 

Agree.    However I am only drawing a parallel with = the RFC 3484 rule for source-based routing – that’s = all.     For example when PBR routes based on the = source-address, PBR has to first match the source-address of the packet = with an ACL and then apply a PBR rule for next-hop which for 6rd = sunsetting is 6rd vs. native IPv6 each using different = prefixes.   This 6rd tunneled vs. native IPv6 source-based = forwarding is similar in principle to the rule 7 of section 6 of RFC = 3484.

 

Also, the rule specified by Mark is a valid rule for CPE router = requirements even with Victor’s use case because the network has = to issue an ICMPv4/ICMPv6 Destination Unreachable to the source = CPE.  Having thought some more on Victor’s use case where = source CPE sent 6rd tunneled packet but the destination CPE switched to = native IPv6, if the CPEs are communicating directly, the source CPE = should timeout NUD with the destination CPE and not even issue any = packet on the tunnel to the destination CPE.  =

 

Hemant

 

From:= = Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Thursday, = December 01, 2011 5:50 PM
To: Hemant Singh = (shemant)
Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; = Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting

 

On Mon, = Nov 28, 2011 at 19:43, Hemant Singh (shemant) <shemant@cisco.com> = wrote:

Good use = case.  Note the rule that Mark specified, as I said, is already = part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to = use the rule 7 and rfc6204bis can still be silent about this rule = because the rule is already specified in RFC = 3484.

RFC = 3484 is not relevant here. It describes how nodes choose source = addressing when originating packets. It doesn't apply to forwarding = traffic.

------_=_NextPart_001_01CCB07E.CF5AF70A-- From mark@townsley.net Thu Dec 1 15:32:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6911E80A2 for ; Thu, 1 Dec 2011 15:32:07 -0800 (PST) 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 NHXgBpi-kyAk for ; Thu, 1 Dec 2011 15:32:06 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 154E711E809A for ; Thu, 1 Dec 2011 15:32:05 -0800 (PST) Received: by eabm6 with SMTP id m6so3194375eab.31 for ; Thu, 01 Dec 2011 15:32:05 -0800 (PST) Received: by 10.180.108.114 with SMTP id hj18mr6465320wib.2.1322782325114; Thu, 01 Dec 2011 15:32:05 -0800 (PST) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dy1sm2008089wib.18.2011.12.01.15.32.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 15:32:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21-877736600 From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> Date: Fri, 2 Dec 2011 00:32:00 +0100 Message-Id: <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:32:07 -0000 --Apple-Mail-21-877736600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 2, 2011, at 12:13 AM, Hemant Singh (shemant) wrote: > Lorenzo, > =20 > Agree. However I am only drawing a parallel with the RFC 3484 rule = for source-based routing =96 that=92s all. For example when PBR = routes based on the source-address, PBR has to first match the = source-address of the packet with an ACL and then apply a PBR rule for = next-hop which for 6rd sunsetting is 6rd vs. native IPv6 each using = different prefixes. This 6rd tunneled vs. native IPv6 source-based = forwarding is similar in principle to the rule 7 of section 6 of RFC = 3484. > =20 > Also, the rule specified by Mark is a valid rule for CPE router = requirements even with Victor=92s use case because the network has to = issue an ICMPv4/ICMPv6 Destination Unreachable to the source CPE. = Having thought some more on Victor=92s use case where source CPE sent = 6rd tunneled packet but the destination CPE switched to native IPv6, if = the CPEs are communicating directly, the source CPE should timeout NUD = with the destination CPE and not even issue any packet on the tunnel to = the destination CPE.=20 Are you referring to the "NUD" feature of 6rd? That's mostly for = troubleshooting, and only for CE to BR reachability.=20 - Mark > =20 > Hemant > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Thursday, December 01, 2011 5:50 PM > To: Hemant Singh (shemant) > Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen; = v6ops@ietf.org > Subject: Re: [v6ops] 6rd Sunsetting > =20 > On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant) = wrote: > Good use case. Note the rule that Mark specified, as I said, is = already part of RFC 3484, section 6, and Rule 7. Thus a CPE is entitled = to use the rule 7 and rfc6204bis can still be silent about this rule = because the rule is already specified in RFC 3484. >=20 > RFC 3484 is not relevant here. It describes how nodes choose source = addressing when originating packets. It doesn't apply to forwarding = traffic. --Apple-Mail-21-877736600 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 2, 2011, at 12:13 AM, Hemant = Singh (shemant) wrote:

Lorenzo,
Agree.    However I am only drawing a = parallel with the RFC 3484 rule for source-based routing =96 that=92s = all.     For example when PBR routes based on the = source-address, PBR has to first match the source-address of the packet = with an ACL and then apply a PBR rule for next-hop which for 6rd = sunsetting is 6rd vs. native IPv6 each using different = prefixes.   This 6rd tunneled vs. native IPv6 source-based = forwarding is similar in principle to the rule 7 of section 6 of RFC = 3484.
 
Also, the rule specified by Mark = is a valid rule for CPE router requirements even with Victor=92s use = case because the network has to issue an ICMPv4/ICMPv6 Destination = Unreachable to the source CPE.  Having thought some more on = Victor=92s use case where source CPE sent 6rd tunneled packet but the = destination CPE switched to native IPv6, if the CPEs are communicating = directly, the source CPE should timeout NUD with the destination CPE and = not even issue any packet on the tunnel to the destination = CPE. 

Are you referring to the "NUD" feature of 6rd? That's mostly for = troubleshooting, and only for CE to BR = reachability. 

- Mark

 
 
 Lorenzo = Colitti [mailto:lorenzo@google.com] 
Sent: Thursday, December 01, 2011 = 5:50 PM
To: Hemant Singh = (shemant)
Cc: Victor Kuarsingh; Mark = Townsley; Tom Taylor; Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting

= --Apple-Mail-21-877736600-- From shemant@cisco.com Thu Dec 1 15:46:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A104C11E80B8 for ; Thu, 1 Dec 2011 15:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GnsF6zVahILs for ; Thu, 1 Dec 2011 15:46:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4611E80B6 for ; Thu, 1 Dec 2011 15:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4680; q=dns/txt; s=iport; t=1322783207; x=1323992807; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=6njZoKIqrijlql5aIsz3a+oSXhkMYRSjwszqKHSsqr8=; b=eN63fhN60ZusDs5rjrYPgNohX5s0mtqKdNlJB5VHTDW/KNHTZ2jIotet RZ6i0X87VVeRTM9cpZXjjhjlVOTq7R7Z8aEoAyfRBSULWGVAk7iCPpLIi OkOz0quFlGR5W8LNEWX/rciUKG9C5GdHHYBG7iEgYsy62k89p85dPkYFJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAAN0Q2E6tJXG9/2dsb2JhbABDgk2YE5AjgQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqhMgGeR4o9YwSIKJ5g X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; d="scan'208,217";a="40495538" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 01 Dec 2011 23:46:47 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1NklTR011495; Thu, 1 Dec 2011 23:46:47 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 17:46:46 -0600 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_01CCB083.7C827993" Date: Thu, 1 Dec 2011 17:46:45 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> In-Reply-To: <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcywgW/uVK6zi7BnR6SBswmQzyMBrgAAV/4w References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" X-OriginalArrivalTime: 01 Dec 2011 23:46:46.0811 (UTC) FILETIME=[7CCFF6B0:01CCB083] Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:46:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB083.7C827993 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, December 01, 2011 6:32 PM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting =20 >Are you referring to the "NUD" feature of 6rd? That's mostly for troubleshooting, and only for CE to BR reachability.=20 =20 NUD recommended for tunnels from RFC 4213. =20 =20 Hemant ------_=_NextPart_001_01CCB083.7C827993 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mark Townsley [mailto:mark@townsley.net]
Sent: Thursday, = December 01, 2011 6:32 PM
To: Hemant Singh = (shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; = Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting

 

>Are you = referring to the "NUD" feature of 6rd? That's mostly for = troubleshooting, and only for CE to BR = reachability. 

 

NUD recommended for tunnels from RFC 4213.  =

 

Hemant

------_=_NextPart_001_01CCB083.7C827993-- From mark@townsley.net Thu Dec 1 15:53:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94A71F0C50 for ; Thu, 1 Dec 2011 15:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.226, 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 CwPa97m2ZgjC for ; Thu, 1 Dec 2011 15:53:04 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D91831F0C45 for ; Thu, 1 Dec 2011 15:53:03 -0800 (PST) Received: by eabm6 with SMTP id m6so3217060eab.31 for ; Thu, 01 Dec 2011 15:53:03 -0800 (PST) Received: by 10.180.106.3 with SMTP id gq3mr6261351wib.34.1322783582803; Thu, 01 Dec 2011 15:53:02 -0800 (PST) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id x8sm2025095wix.17.2011.12.01.15.53.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 15:53:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-878995121 From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> Date: Fri, 2 Dec 2011 00:52:58 +0100 Message-Id: <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:53:04 -0000 --Apple-Mail-23-878995121 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 2, 2011, at 12:46 AM, Hemant Singh (shemant) wrote: > =20 > =20 > From: Mark Townsley [mailto:mark@townsley.net]=20 > Sent: Thursday, December 01, 2011 6:32 PM > To: Hemant Singh (shemant) > Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; = v6ops@ietf.org > Subject: Re: [v6ops] 6rd Sunsetting > =20 > >Are you referring to the "NUD" feature of 6rd? That's mostly for = troubleshooting, and only for CE to BR reachability.=20 > =20 > NUD recommended for tunnels from RFC 4213.=20 Except that RFC 5969 says: A typical 6rd deployment may consist of a very large number of CEs within the same domain. Reachability between CEs is based on IPv4 routing, and sending NUD or any periodic packets between 6rd CE devices beyond isolated troubleshooting of the 6rd mechanism is NOT RECOMMENDED. - Mark > =20 > Hemant --Apple-Mail-23-878995121 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 2, 2011, at 12:46 AM, Hemant = Singh (shemant) wrote:

 
>Are you referring to the "NUD" feature of = 6rd? That's mostly for troubleshooting, and only for CE to BR = reachability. 
 
NUD recommended for tunnels from = RFC = 4213. 
<= br>
Except that RFC 5969 says:

   A typical 6rd deployment may =
consist of a very large number of CEs
   within the same domain.  Reachability between CEs is based on IPv4
   routing, and sending NUD or any periodic packets between 6rd CE
   devices beyond isolated troubleshooting of the 6rd mechanism is NOT
   RECOMMENDED.

- = Mark

In-Reply-To: <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcywhF4DdBSKCz64RdWXjE7VuC+xewAADVog References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" X-OriginalArrivalTime: 01 Dec 2011 23:57:55.0210 (UTC) FILETIME=[0B358EA0:01CCB085] Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:57:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB085.0AF2491C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, December 01, 2011 6:53 PM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting =20 =20 >Except that RFC 5969 says: =20 > A typical 6rd deployment may consist of a very large number of CEs > within the same domain. Reachability between CEs is based on IPv4 > routing, and sending NUD or any periodic packets between 6rd CE > devices beyond isolated troubleshooting of the 6rd mechanism is NOT > RECOMMENDED. =20 For Victor's use case, the source CPE using 6rd has lot network connectivity to destination CPE. Would this network connectivity be good to troubleshoot with NUD? =20 =20 Hemant ------_=_NextPart_001_01CCB085.0AF2491C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mark Townsley [mailto:mark@townsley.net]
Sent: Thursday, = December 01, 2011 6:53 PM
To: Hemant Singh = (shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; = Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting

 

 

>Except that = RFC 5969 says:

 

>   A typical 6rd =
deployment may consist of a very large number of =
CEs
>   within the same =
domain.  Reachability between CEs is based on =
IPv4
>   routing, and sending =
NUD or any periodic packets between 6rd CE
>   devices beyond =
isolated troubleshooting of the 6rd mechanism is =
NOT
>   =
RECOMMENDED.

 

For Victor’s use case, the source CPE using 6rd has lot network = connectivity to destination CPE.   Would this network = connectivity be good to troubleshoot with NUD?  =

 

Hemant

------_=_NextPart_001_01CCB085.0AF2491C-- From C.Donley@cablelabs.com Thu Dec 1 16:06:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDA711E8138 for ; Thu, 1 Dec 2011 16:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 rl8le-vpi5Jb for ; Thu, 1 Dec 2011 16:06:13 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0A11E8141 for ; Thu, 1 Dec 2011 16:05:24 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pB205K91030777; Thu, 1 Dec 2011 17:05:20 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 1 Dec 2011 17:05:20 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 1 Dec 2011 17:05:20 -0700 From: Chris Donley To: Mark Townsley , "STARK, BARBARA H" Date: Thu, 1 Dec 2011 17:06:27 -0700 Thread-Topic: [v6ops] Section 4.4 of 6204-bis Thread-Index: AcywhhSrxeZIOjqFTB+qN/6k2eB02Q== Message-ID: In-Reply-To: <7E5672F5-9F1F-40F4-B585-17A6C70E22EF@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAFD3A562F548cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Section 4.4 of 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:06:15 -0000 --_000_CAFD3A562F548cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, Please see in-line (marked with [CD]). Chris From: Mark Townsley > Date: Thu, 1 Dec 2011 12:56:44 -0700 To: "STARK, BARBARA H" > Cc: Hemant Singh >, "v6ops@ietf= .org" >, Chris= Donley >, Lorenzo Co= litti > Subject: Re: [v6ops] Section 4.4 of 6204-bis On Dec 1, 2011, at 7:44 PM, STARK, BARBARA H wrote: In-line, marked with . Barbara > 6RD-2: If the IPv6 CE router implements 6rd functionality, it MUST > support 6rd configuration via the 6rd DHCPv4 Option (212) and > if the IPv6 CE router is capable of automated configuration > of IPv4 through IPCP (i.e., over a PPP connection), it MUST > support user-entered configuration of 6rd. >Why not just say it MUST support DHCPv4 option 212 and Manual configuratio= n and stop at that? If we are going to include manual config, it is effecti= vely >*always* an option, not just for PPP or any other >type of access lin= k. Just make it a MUST and be done. Because the MSOs said they didn=92t want to implement manual configura= tion in their devices. So we compromised on language that would provide them an exclusion, but mak= e sure they capability was present in devices where it was actually needed. Ah, so if the router supports PPP, it MUST have manual config. If it doesn'= t support PPP, it really should not have manual config? [CD] We don't specify manual config for anything in eRouter. We certainly = don't want to add a UI just for 6rd, especially since native IPv6 is define= d in DOCSIS 3.0. So now the document has hidden Cable vs. DSL origin requirements, with PPP = as the switch for which is being catered too. [CD] That was in original 6204, as well. Cable/DSL provisioning models are= similar, but there are key differences, in particular around WAN-side prov= isioning. DOCSIS specifies the use of DHCPv6 (only), whereas BBF includes a= dditional options. This kind of wiggle-wording might seem clever from the operational side, bu= t from the vendor side it's extremely annoying if not completely out of tou= ch. Either you guys want custom devices, in which case you really don't nee= d well-defined standards specs, or you want standards so that we don't have= to build different versions for different types of ISPs (we call that "spl= atter", and it's absolutely something that hurts the retail side when it co= mes to building these things on a budget that can work across a myriad of S= P environments). [CD] Would you rather we said implement eRouter AND TR-124? I think that wo= uld be more confusing. 6204bis is a compromise that fits both provisioning = models reasonably well. Manual config is either a requirement or not, tying it to DHCP, PPP, 3GPP, = or anything else is making this document more complex, and the job of the v= endors more difficult (read: more expensive for consumers). [CD] As I said, we don't want to require a UI just for 6rd, which in a cabl= e environment, would only be needed for pre-DOCSIS 3.0 systems. However, B= BF does need manual config for PPP. >Further, if we are going to mention PPP, rather than falling back to manua= l only, why not allow DHCP configuration after PPP IPCP is finished? Agree. Barbara can comment as well since she provided such text. Nothing prohibits DHCPv4 configuration after IPCP. I don=92t see anyt= hing that says it=92s not allowed. However, it can=92t be assumed, since al= most no PPP-based access network runs a DHCPv4 server for PPP-connected cus= tomers. And any ISP who isn=92t running a DHCPv4 server today, is *highly* = unlikely to add one just for 6rd. Remember, the promise of 6rd is that it d= oesn=92t require upgrades to existing infrastructure in the access network.= To suggest that this CE router draft somehow can require PPP access networ= ks to add DHCPv4 servers in order to do 6rd is a non-starter. In my experie= nce, CE router vendors are looking for realistic advice, and not purist rec= ommendations that are not representative of the real world. There is a draft on how to add this to PPP IPCP. If that's easier than DHCP= , I'd like to hear it, but I usually hear that the BNG vendors can't be bot= hered to add a new option to IPCP. Also there is the pushback that pppext i= s likely to give, though I'm with you on the "realistic advice" side: if ad= ding this to PPP IPCP will help you deploy IPv6 to more customers sooner, a= nd your vendors will comply, let's do it. BTW, BNGs can *be* the DHCP server and return a reply that consists of not= hing but option 212 (and not worrying about the IP address lease part). Tha= t doesn't require new "DHCP infrastructure", at least not in the sense of n= ew DHCP servers. >From RFC2131: "DHCPINFORM - Client to server, asking only for local con= figuration parameters; client already has externally configured network add= ress." >Back when the PPP folks actively decided to stop duplicating DHCP function= ality in IPCP, this was the recommended approach (and Windows stacks and th= e like actually try to obtain additional >parameters for PPP connections af= ter IPCP comes up, though often the network does not have any additional pa= rameters to give...). This gives PPP connections a pretty decent chance to = work with 6rd >automatically, using the same DHCP configuration as non-PPP. Agree. See above comment. Please read http://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00 > 6RD-3: If the CE router implements 6rd functionality, it MUST allow > the user to specify whether all IPv6 traffic goes to the 6rd > Border Relay, or whether IPv6 traffic to other destinations > within the same 6rd domain are routed directly to those > destinations. The CE router MAY use other mechanisms to > configure this. Such mechanisms are outside the scope of > this document. >Do you really mean the "user" is supposed to be able to specify whether IP= v6 traffic always going through the BR, or the "operator" is supposed to be= able to >specify this? >This behavior, while straight-forward to implement as it is effectively re= moving a more-specific route on the 6rd virtual interface, is out of scope = of RFC 5969 >as currently defined. There is no way to specify this in DHCPv= 4 configuration. One might be able to configure this from the network with = PIO or DHCPv6 route >options in a general manner, but this hasn't been spec= ified anywhere that I am aware of within the context of 6rd. I understand t= he BBF has included some >specifics around this, and perhaps it is best if = those requirements stay in the BBF or at least we provide a reference to th= em from here. Otherwise, this >requirement remains under-specified as writt= en, and if expounded would effectively be an update (in the formal sense) t= o RFC 5969. How does BBF specify the CE router gets configured to go directly to other = destinations? It just did, I suppose. In TR-124-something, right? Via TR-069, or manually. It would be nice if it could also be via DHC= Pv4 option, but the companies asking for this don=92t really see the lack o= f a DHCPv4 option as being a showstopper. Right, when it was added it to BBF docs rather than starting with the IETF,= it effectively became a BBF-only, largely TR-69-only, thing. That's fine, = but that makes circling the requirement back around to the root, a problem. - Mark --_000_CAFD3A562F548cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mark,

Please see in-line (marked with [CD]).

=
Chris
From: M= ark Townsley <mark@townsley.net= >
Date: Thu, 1 Dec 2011 12:5= 6:44 -0700
To: "STARK, BAR= BARA H" <bs7652@att.com>Cc: Hemant Singh <shemant@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>, Chris Donley <c.donley@cablelabs.com>, Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [v6ops] Section 4.4 of 6204-bis
=


On Dec 1, 2011, at 7:44 PM, STARK, BARBARA H wrote:
In-line, marked with <bhs>.
Barbara
 
>&n=
bsp;  6RD-2:  If the IPv6 CE router implements 6rd functionality,=
 it MUST
>   =
;        support 6rd configuration via t=
he 6rd DHCPv4 Option (212) and
>           if the IP=
v6 CE router is capable of automated configuration
<= pre style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 10pt; font-family: 'Courier New'; page-break-be= fore: always; ">>        &n= bsp;  of IPv4 through IPCP (i.e., over a PPP connection), it MUST= 
     =
      support user-entered configuration of 6rd.&n=
bsp;
 
Why not just say it MUST support DHCPv4 option 212 and Manual configuratio= n and stop at that? If we are going to include manual config, it is ef= fectively >*always* an option, not just for PPP = or any other >type of access link. Just make it= a MUST and be done.
 <= /o:p>
<bhs>Because the MSOs said they = didn=92t want to implement manual configuration in their devices.

So we compromis= ed on language that would provide them an exclusion, but make sure they cap= ability was present in devices where it was actually needed.

Ah, so = if the router supports PPP, it MUST have manual config. If it doesn't suppo= rt PPP, it really should not have manual config? 

[CD] We don't specify manual config for anythi= ng in eRouter.  We certainly don't want to add a UI just for 6rd, espe= cially since native IPv6 is defined in DOCSIS 3.0.
<= /span>

So now the document has hidden Cable vs. DSL origin= requirements, with PPP as the switch for which is being catered too. =
[CD] That was in original 6204, as well= .  Cable/DSL provisioning models are similar, but there are key differ= ences, in particular around WAN-side provisioning. DOCSIS specifies the use= of DHCPv6 (only), whereas BBF includes additional options.

<= /div>
This kind of wiggle-wording might seem clever from the operationa= l side, but from the vendor side it's extremely annoying if not completely = out of touch. Either you guys want custom devices, in which case you really= don't need well-defined standards specs, or you want standards so that we = don't have to build different versions for different types of ISPs (we call= that "splatter", and it's absolutely something that hurts the re= tail side when it comes to building these things on a budget that can work = across a myriad of SP environments). 
[CD] Would you rather we said implement eRouter AND TR-124? I think that= would be more confusing. 6204bis is a compromise that fits both provisioni= ng models reasonably well.  

Manual config is e= ither a requirement or not, tying it to DHCP, PPP, 3GPP, or anything else i= s making this document more complex, and the job of the vendors more diffic= ult (read: more expensive for consumers). 
[CD] As I said, we don= 't want to require a UI just for 6rd, which in a cable environment, would o= nly be needed for pre-DOCSIS 3.0 systems.  However, BBF does need manu= al config for PPP.  
 
>Further, if we are going to mention PPP, rat= her than falling back to manual only, why not allow DHCP configuration afte= r PPP IPCP is finished?
 
Agree.  Barbara can comment as = well since she provided such text.
<bhs> Nothing proh= ibits DHCPv4 configuration after IPCP. I don=92t see anything that says it= =92s not allowed. However, it can=92t be assumed, since almost no PPP-based= access network runs a DHCPv4 server for PPP-connected customers. And any I= SP who isn=92t running a DHCPv4 server today, is *highly* unlikely t= o add one just for 6rd. Remember, the promise of 6rd is that it doesn=92t r= equire upgrades to existing infrastructure in the access network. To sugges= t that this CE router draft somehow can require PPP access networks to add = DHCPv4 servers in order to do 6rd is a non-starter. In my experience, CE ro= uter vendors are looking for realistic advice, and not purist recommendatio= ns that are not representative of the real world.
<= /div>

There is a draft o= n how to add this to PPP IPCP. If that's easier than DHCP, I'd like to hear= it, but I usually hear that the BNG vendors can't be bothered to add a new= option to IPCP. Also there is the pushback that pppext is likely to give, = though I'm with you on the "realistic advice" side: if adding thi= s to PPP IPCP will help you deploy IPv6 to more customers sooner, and your = vendors will comply, let's do it.

BTW,  BNGs = can *be* the DHCP server and return a reply that consists of nothing but op= tion 212 (and not worrying about the IP address lease part). That doesn't r= equire new "DHCP infrastructure", at least not in the sense of ne= w DHCP servers. 

&= nbsp;
>From RFC2131: "= ;DHCPINFORM   -  Client to server, asking only for local configur= ation parameters; client already has externally configured networ= k address."
 
=
>Back when the PPP folks actively decided to stop duplicatin= g DHCP functionality in IPCP, this was the recommended approach (and Window= s stacks and the like actually try to obtain additional &g= t;parameters for PPP connections after IPCP comes up, though often t= he network does not have any additional parameters to give...). This gives = PPP connections a pretty decent chance to work with 6rd &g= t;automatically, using the same DHCP configuration as non-PPP. =
 
Agree.
 
=

<bhs> See above comment.

Please read http://to= ols.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00

>=
   6RD-3:  If the CE router implements 6rd functionality, it=
 MUST allow
>  &n=
bsp;        the user to specify whether =
all IPv6 traffic goes to the 6rd
>           Border =
Relay, or whether IPv6 traffic to other destinations
>        =
   within the same 6rd domain are routed directly to those
>     &n=
bsp;     destinations.  The CE router MAY use othe=
r mechanisms to
> &nbs=
p;         configure this.  Su=
ch mechanisms are outside the scope of
>           t=
his document.
 
>Do you really mean the "user" is supposed to be able to sp=
ecify whether IPv6 traffic always going through the BR, or the "operat=
or" is supposed to be able to&nb=
sp;>specify this=
?
 
This behavior, while straight-forward to implement as it is effectively re= moving a more-specific route on the 6rd virtual interface, is out of scope = of RFC 5969 >as currently defined. There is no= way to specify this in DHCPv4 configuration. One might be able to configur= e this from the network with PIO or DHCPv6 route >options in a general manner, but this hasn't been specified anywhere that= I am aware of within the context of 6rd. I understand the BBF has included= some >specifics around this, and perhaps it is = best if those requirements stay in the BBF or at least we provide a referen= ce to them from here. Otherwise, this=  >requireme= nt remains under-specified as written, and if expounded would effectively b= e an update (in the formal sense) to RFC 5969. 

<= span style=3D"color: rgb(31, 73, 125); ">How does BBF specify the CE router= gets configured to go directly to other destinations? <= /div>

It just did, = I suppose. In TR-124-something, right?

 
<bhs> Via TR-069, or manually. It would be= nice if it could also be via DHCPv4 option, but the companies asking for t= his don=92t really see the lack of a DHCPv4 option as being a showstopper.<= o:p>
 

Right, when it was added i= t to BBF docs rather than starting with the IETF, it effectively became a B= BF-only, largely TR-69-only, thing. That's fine, but that makes circling th= e requirement back around to the root, a problem. 

= - Mark



--_000_CAFD3A562F548cdonleycablelabscom_-- From bs7652@att.com Thu Dec 1 16:06:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75321F94E7 for ; Thu, 1 Dec 2011 16:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SK986ZNEWirV for ; Thu, 1 Dec 2011 16:06:13 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9004F11E8132 for ; Thu, 1 Dec 2011 16:04:57 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1322784294!3785460!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1099 invoked from network); 2 Dec 2011 00:04:55 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2011 00:04:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB203RLT011008; Thu, 1 Dec 2011 19:03:27 -0500 Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB203M4d010948; Thu, 1 Dec 2011 19:03:22 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 18:03:59 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 19:03:58 -0500 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_01CCB085.E3952624" Date: Thu, 1 Dec 2011 19:04:46 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F213AB9B1@crexc50p> In-Reply-To: <7E5672F5-9F1F-40F4-B585-17A6C70E22EF@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Section 4.4 of 6204-bis Thread-Index: AcywY1YYHMfkrIq+ShmdLEEsGU2gdQAHrJ9A References: <7BDCA7A4-515F-4C2F-B8F5-B823F2DA2619@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F213AB69F@crexc50p> <7E5672F5-9F1F-40F4-B585-17A6C70E22EF@townsley.net> From: "STARK, BARBARA H" To: "Mark Townsley" X-OriginalArrivalTime: 02 Dec 2011 00:03:58.0563 (UTC) FILETIME=[E3C8D330:01CCB085] Cc: v6ops@ietf.org Subject: Re: [v6ops] Section 4.4 of 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:06:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB085.E3952624 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Inline, marked with this time. Barbara =20 Ah, so if the router supports PPP, it MUST have manual config. If it doesn't support PPP, it really should not have manual config?=20 =20 Not quite. If it supports PPP it MUST have manual config. If it doesn't support PPP, this document makes no statement as to whether or not it should have manual config. Which means a device without PPP that has manual config would still be compliant with 6204bis. It would also be compliant if it doesn't have manual config. If you're designing a device that doesn't do PPP, you're already building a device that's "custom" to only work in DHCP environments. So I don't see why there should be a problem with saying "if you are adding PPP support to your device, add manual config for 6rd, too". If you don't want to support PPP, then don't. BTW, we already have an existing "if PPP" requirement: "WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE router MUST support IPv6 over PPP [RFC5072]." So I fail to see the problem. =20 So now the document has hidden Cable vs. DSL origin requirements, with PPP as the switch for which is being catered too.=20 =20 This kind of wiggle-wording might seem clever from the operational side, but from the vendor side it's extremely annoying if not completely out of touch. Either you guys want custom devices, in which case you really don't need well-defined standards specs, or you want standards so that we don't have to build different versions for different types of ISPs (we call that "splatter", and it's absolutely something that hurts the retail side when it comes to building these things on a budget that can work across a myriad of SP environments).=20 =20 Manual config is either a requirement or not, tying it to DHCP, PPP, 3GPP, or anything else is making this document more complex, and the job of the vendors more difficult (read: more expensive for consumers).=20 =20 >Further, if we are going to mention PPP, rather than falling back to manual only, why not allow DHCP configuration after PPP IPCP is finished? =20 Agree. Barbara can comment as well since she provided such text. =20 Nothing prohibits DHCPv4 configuration after IPCP. I don't see anything that says it's not allowed. However, it can't be assumed, since almost no PPP-based access network runs a DHCPv4 server for PPP-connected customers. And any ISP who isn't running a DHCPv4 server today, is *highly* unlikely to add one just for 6rd. Remember, the promise of 6rd is that it doesn't require upgrades to existing infrastructure in the access network. To suggest that this CE router draft somehow can require PPP access networks to add DHCPv4 servers in order to do 6rd is a non-starter. In my experience, CE router vendors are looking for realistic advice, and not purist recommendations that are not representative of the real world. =20 There is a draft on how to add this to PPP IPCP. If that's easier than DHCP, I'd like to hear it, but I usually hear that the BNG vendors can't be bothered to add a new option to IPCP. Also there is the pushback that pppext is likely to give, though I'm with you on the "realistic advice" side: if adding this to PPP IPCP will help you deploy IPv6 to more customers sooner, and your vendors will comply, let's do it. =20 BTW, BNGs can *be* the DHCP server and return a reply that consists of nothing but option 212 (and not worrying about the IP address lease part). That doesn't require new "DHCP infrastructure", at least not in the sense of new DHCP servers.=20 Not interested in upgrading the BNG. Any configuration changes and software updates to the BNG must be tested very carefully. That takes a lot of time and effort. The potential benefit does not outweigh the cost of time spent in such testing, together with the risk of bad things happening. When introducing a function into the access network that will be visible to all attached devices, you never, ever assume that everything will just work, without problem. And in this case, there is a wide variety of off-the-shelf IPv4 CE routers that are being used for this attachment. Anything that might possibly, conceivably break existing IPv4 for any of these customers has to be done very, very carefully. Risk mitigation for IPv6 and 6rd is to turn them off and go back to IPv4. Risk mitigation for broken IPv4 doesn't exist. ------_=_NextPart_001_01CCB085.E3952624 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Inline, marked with <bhs2> this time.

Barbara

 

Ah, so if the router supports PPP, = it MUST have manual config. If it doesn't support PPP, it really should = not have manual config? 

 

<bhs2> Not quite. If it supports PPP it MUST have manual = config. If it doesn’t support PPP, this document makes no = statement as to whether or not it should have manual config. Which means = a device without PPP that has manual config would still be compliant = with 6204bis. It would also be compliant if it doesn’t have manual = config. If you’re designing a device that doesn’t do PPP, = you’re already building a device that’s “custom” = to only work in DHCP environments. So I don’t see why there should = be a problem with saying “if you are adding PPP support to your = device, add manual config for 6rd, too”. If you don’t want = to support PPP, then don’t. BTW, we already have an existing = “if PPP” requirement: “WLL-2:  If the WAN = interface supports PPP encapsulation, the IPv6 = CE           router = MUST support IPv6 over PPP [RFC5072].” So I fail to see the = problem.

 

So now = the document has hidden Cable vs. DSL origin requirements, with PPP as = the switch for which is being catered = too. 

 

This kind of wiggle-wording might seem clever from the = operational side, but from the vendor side it's extremely annoying if = not completely out of touch. Either you guys want custom devices, in = which case you really don't need well-defined standards specs, or you = want standards so that we don't have to build different versions for = different types of ISPs (we call that "splatter", and it's = absolutely something that hurts the retail side when it comes to = building these things on a budget that can work across a myriad of SP = environments). 

 

Manual config is either a requirement or not, tying it = to DHCP, PPP, 3GPP, or anything else is making this document more = complex, and the job of the vendors more difficult (read: more expensive = for consumers). 



<= div>

 

>Further, if we are = going to mention PPP, rather than falling back to manual only, why not = allow DHCP configuration after PPP IPCP is = finished?

 

Agree.  Barbara can comment as well since she = provided such text.

 

<bhs> Nothing prohibits DHCPv4 configuration after IPCP. I = don’t see anything that says it’s not allowed. However, it = can’t be assumed, since almost no PPP-based access network runs a = DHCPv4 server for PPP-connected customers. And any ISP who isn’t = running a DHCPv4 server today, is *highly* unlikely to add one = just for 6rd. Remember, the promise of 6rd is that it doesn’t = require upgrades to existing infrastructure in the access network. To = suggest that this CE router draft somehow can require PPP access = networks to add DHCPv4 servers in order to do 6rd is a non-starter. In = my experience, CE router vendors are looking for realistic advice, and = not purist recommendations that are not representative of the real = world.

 

There is a draft on how to add this to PPP IPCP. If = that's easier than DHCP, I'd like to hear it, but I usually hear that = the BNG vendors can't be bothered to add a new option to IPCP. Also = there is the pushback that pppext is likely to give, though I'm with you = on the "realistic advice" side: if adding this to PPP IPCP = will help you deploy IPv6 to more customers sooner, and your vendors = will comply, let's do it.

 

BTW,  BNGs can *be* the DHCP server and return a = reply that consists of nothing but option 212 (and not worrying about = the IP address lease part). That doesn't require new "DHCP = infrastructure", at least not in the sense of new DHCP = servers. 


<bhs2> Not interested in upgrading the = BNG. Any configuration changes and software updates to the BNG must be = tested very carefully. That takes a lot of time and effort. The = potential benefit does not outweigh the cost of time spent in such = testing, together with the risk of bad things happening. When = introducing a function into the access network that will be visible to = all attached devices, you never, ever assume that everything will just = work, without problem. And in this case, there is a wide variety of = off-the-shelf IPv4 CE routers that are being used for this attachment. = Anything that might possibly, conceivably break existing IPv4 for any of = these customers has to be done very, very carefully. Risk mitigation for = IPv6 and 6rd is to turn them off and go back to IPv4. Risk mitigation = for broken IPv4 doesn’t = exist.

------_=_NextPart_001_01CCB085.E3952624-- From mark@townsley.net Thu Dec 1 16:28:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2014E21F9580 for ; Thu, 1 Dec 2011 16:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, 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 dSelft2C6whf for ; Thu, 1 Dec 2011 16:28:33 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 300C521F957A for ; Thu, 1 Dec 2011 16:28:33 -0800 (PST) Received: by eabm6 with SMTP id m6so3249499eab.31 for ; Thu, 01 Dec 2011 16:28:32 -0800 (PST) Received: by 10.180.91.137 with SMTP id ce9mr6610881wib.5.1322785712296; Thu, 01 Dec 2011 16:28:32 -0800 (PST) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dt8sm2047917wib.21.2011.12.01.16.28.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 16:28:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-26-881124850 From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com> Date: Fri, 2 Dec 2011 01:28:28 +0100 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:28:34 -0000 --Apple-Mail-26-881124850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 2, 2011, at 12:57 AM, Hemant Singh (shemant) wrote: > =20 > =20 > From: Mark Townsley [mailto:mark@townsley.net]=20 > Sent: Thursday, December 01, 2011 6:53 PM > To: Hemant Singh (shemant) > Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; = v6ops@ietf.org > Subject: Re: [v6ops] 6rd Sunsetting > =20 > =20 > >Except that RFC 5969 says: > =20 > > A typical 6rd deployment may consist of a very large number of CEs > > within the same domain. Reachability between CEs is based on IPv4 > > routing, and sending NUD or any periodic packets between 6rd CE > > devices beyond isolated troubleshooting of the 6rd mechanism is = NOT > > RECOMMENDED. > =20 > For Victor=92s use case, the source CPE using 6rd has lot network = connectivity to destination CPE. Would this network connectivity be = good to troubleshoot with NUD?=20 Troubleshoot from an admin interface, sure. Dynamically keep track of = which of the 10 million CPE are "up" and "down", no. You don't do this = with IPv4, do you? Please do not think of 6rd as a circuit.=20 - Mark > =20 > Hemant --Apple-Mail-26-881124850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 2, 2011, at 12:57 AM, Hemant = Singh (shemant) wrote:

From: Mark Townsley = [mailto:mark@townsley.net] 
Sent: Thursday, December 01, 2011 = 6:53 PM
To: Hemant Singh = (shemant)
Cc: Lorenzo Colitti; Victor = Kuarsingh; Tom Taylor; Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting
>Except that RFC 5969 = says:
>   A typical 6rd = deployment may consist of a very large number of = CEs
>   within the same =
domain.  Reachability between CEs is based on =
IPv4
>   routing, and =
sending NUD or any periodic packets between 6rd =
CE
>   devices beyond =
isolated troubleshooting of the 6rd mechanism is =
NOT
>   =
RECOMMENDED.
 
For Victor=92s use case, the = source CPE using 6rd has lot network connectivity to destination = CPE.   Would this network connectivity be good to troubleshoot = with = NUD? 
<= div>
Troubleshoot from an admin interface, sure. = Dynamically keep track of which of the 10 million CPE are "up" and = "down", no. You don't do this with IPv4, do you? Please do not think of = 6rd as a circuit. 

- = Mark


Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [v6ops] OT: Off email until Monday... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:30:21 -0000 Enjoying all the heated discussion, but I'm off on vacation now through = Monday. I'll try and catch up when I return. Cheers, - Mark= From ichiroumakino@gmail.com Thu Dec 1 23:29:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079221F98D3 for ; Thu, 1 Dec 2011 23:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 zHeWCi15L1x3 for ; Thu, 1 Dec 2011 23:29:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5CC21F98D2 for ; Thu, 1 Dec 2011 23:29:48 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so3583396bkb.31 for ; Thu, 01 Dec 2011 23:29:43 -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=3Y3nhR3kdXuaOg0YnWx0gRU6QSNPiFi0vsNhPfROqWY=; b=CB23WXE+7MSnY4K30n/OUJZa5rZdEoU+bhfBYCeim+ppoSCki4zjJsJ8GpbqpPJELG /dOgaRgjH3oaDqmrG5qpzpXJYvAnIA8pv/H9uW2pt3sODE5CrNQE+INZyhYhGNFmDuIr zGDVaKEUfw35rhWyf1lGP9/cOvrE9KbzRnTRE= Received: by 10.204.148.77 with SMTP id o13mr2854886bkv.97.1322810983469; Thu, 01 Dec 2011 23:29:43 -0800 (PST) Received: from ams3-vpn-dhcp4778.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e8sm16240231bkd.7.2011.12.01.23.29.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 23:29:42 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 1 Dec 2011 21:34:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 07:29:49 -0000 Lorenzo, > > So if you're a CE implementer, what are you supposed to put in the = routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 = routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - = 1 routes? >=20 > that's implementation specific. > put in a "fallback" route for the excluded prefix pointing to the = default for example. >=20 > And when the default changes, or you lose the default? Send the = traffic to a gateway that doesn't exist any more? Or keep monitoring the = routing table for changes so you can keep your excluded routes pointing = in the right direction? Neither of these seem reasonable things to ask = of an implementation. indirection through a default route or any less specific than the = delegated prefix. I just gave one example of how this could be = implemented, probably many other ways. this cat is out of the bag. cheers, Ole From ichiroumakino@gmail.com Thu Dec 1 23:29:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B921F98DA for ; Thu, 1 Dec 2011 23:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 Sbk14GNQicLg for ; Thu, 1 Dec 2011 23:29:52 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE021F98D7 for ; Thu, 1 Dec 2011 23:29:51 -0800 (PST) Received: by mail-bw0-f44.google.com with SMTP id zt19so3583396bkb.31 for ; Thu, 01 Dec 2011 23:29:51 -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=nzuhXRzTHtYpuBe1UT4R1W3WosurgXGGsX4NAkMF0GU=; b=lBNllUAWYzBM4oDCMGMQpWYLqtlnEBskbvPtQ5h6xWS3PYJxQ1WpyzzFc1X0kuHJ37 QXagQhe1SYdmH3HYecQcpMQAiTti2QoFEft9hN5CbS9LSerHnbH6w/TtD7oAHBHTLlf0 UjfRLIC3IueLHH0eGGjs0pLXJ1HhSzePdtQrU= Received: by 10.204.152.87 with SMTP id f23mr10436663bkw.18.1322810991346; Thu, 01 Dec 2011 23:29:51 -0800 (PST) Received: from ams3-vpn-dhcp4778.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e8sm16240231bkd.7.2011.12.01.23.29.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 23:29:50 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Fri, 2 Dec 2011 08:29:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C5ADAEB-BF94-42C5-BF4C-EF81682F477D@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 07:29:52 -0000 Lorenzo, >> So if you're a CE implementer, what are you supposed to put in the = routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 = routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - = 1 routes? >=20 > that's implementation specific. > put in a "fallback" route for the excluded prefix pointing to the = default for example. >=20 > And when the default changes, or you lose the default? Send the = traffic to a gateway that doesn't exist any more? Or keep monitoring the = routing table for changes so you can keep your excluded routes pointing = in the right direction? Neither of these seem reasonable things to ask = of an implementation. indirection through a default route or any less specific than the = delegated prefix. I just gave one example of how this could be = implemented, probably many other ways. this cat is out of the bag. cheers, Ole From ichiroumakino@gmail.com Fri Dec 2 00:09:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65D11E807F for ; Fri, 2 Dec 2011 00:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 n+h+31X3A25Q for ; Fri, 2 Dec 2011 00:09:24 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8721F9315 for ; Fri, 2 Dec 2011 00:09:24 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so3630202bkb.31 for ; Fri, 02 Dec 2011 00:09:23 -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=o+De+Da8Xuj/GyqjMfR9pqEswvFDSD/w377d1dKRN7A=; b=OhTPGHOgJ9sAjv/WKj4HFxhXcXvYydeHsTzhMkauWABwBB1boj4+Cd2WsYKoAi8L6f XXZRM2OxTjqQ9nz+5QUDVAvnS7pw9vX3z4Vji+HgqHSp05U4LxTScycLex5r1WAUwhRW 3CRepnOz+LUxFHCyVX57m7PM41lzhpbZULDY4= Received: by 10.204.152.83 with SMTP id f19mr10403021bkw.90.1322813363339; Fri, 02 Dec 2011 00:09:23 -0800 (PST) Received: from ams3-vpn-dhcp4778.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id w3sm8255078bkq.3.2011.12.02.00.09.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 00:09:22 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Fri, 2 Dec 2011 09:09:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <120A8B75-A3B1-4EA1-B6CB-825235CA6430@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 08:09:25 -0000 Lorenzo, > > But you don't want it to follow default. You want it to be an = on-link route on the interface that's connected to the BNG. Or at least, = that's the use-case that motivated the existence of this option. >=20 > the only thing the exclude option says, is that the prefix is _not_ = part of the delegation. > it may be used as the onlink prefix on the RR - DR link, if so the RR = can use SLAAC and Prefix Discovery. if it is used somewhere else, the RR = doesn't need to know about it. >=20 > But that creates an unreasonable burden on implementations. >=20 > To do this, implementations need to either a) create routes for all = excluded prefixes copying the default, and update them whenever the = default changes, or b) fully deaggregate every received prefix and = install more specifics for the ones that aren't excluded. >=20 > If you don't do either a) or b), then you're dropping traffic to = global addresses that the network has explicitly told you don't belong = to you, and that's broken. >=20 > So if you're a CE implementer, what are you supposed to put in the = routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 = routes? What if you DHCPv6 PD a /64 which excludes a /128? Create 2^64 - = 1 routes? you will end up with 15 more routes and 63 more routes respectively. how, is left as an exercise to the reader. cheers, Ole From ichiroumakino@gmail.com Fri Dec 2 00:12:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8011E8094 for ; Fri, 2 Dec 2011 00:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 NjkIwSLLLUic for ; Fri, 2 Dec 2011 00:12:30 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6930311E807F for ; Fri, 2 Dec 2011 00:12:30 -0800 (PST) Received: by lahj13 with SMTP id j13so1273118lah.31 for ; Fri, 02 Dec 2011 00:12:29 -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=a9W0Z+h9sOEmj4olgyOyKdbSdfSPOR2OsVade9p6k4o=; b=dCd1gNvcJPECuxjCFPZHzRQtv9AeRHvTSvtsZ4ItFo/b6TNruyvCPFm5qe+KPDx8EH wMCvrqCIilC90okMgaMhcjkN7LGGxZ+i4arVaU04Y3e8SPNzEgr+1fFWuGtlvdO4nCMV rmcgRuNB0Ci7f980ZabyhfsoPQG9dAhZ3XUZA= Received: by 10.152.144.136 with SMTP id sm8mr7004826lab.33.1322813549279; Fri, 02 Dec 2011 00:12:29 -0800 (PST) Received: from ams3-vpn-dhcp4778.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id nj4sm7599802lab.12.2011.12.02.00.12.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 00:12:28 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4ED7EF92.2050807@gmail.com> Date: Fri, 2 Dec 2011 09:12:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4721FB5A-67B5-48C4-81D3-78298EC4E1B4@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <4ED698D6.5090305@gmail.com> <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com> <4ED7EF92 .2050807@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 08:12:31 -0000 Brian, >> Getting that happen is quite unlikely. Rel-10 is already frozen. >=20 > So it could be fixed in Rel-11, or ignored in practice. In any case > we should not hamper the generic CPE because of this restriction > in one particular release of one particular access technology. > As I said a day or two ago, issues specific to a given access > technology should be clearly separated from the generic requirements. any IPv6 deployment 'suffers' from this problem. having all customer traffic originate from a single /56 may be simpler = for back-end systems to deal with, than customer traffic originating from a /56 and a /64. this problem originally came up independently of 3GPP when we defined = DHCPv6 PD. cheers, Ole= From jouni.nospam@gmail.com Fri Dec 2 01:21:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2676021F9939 for ; Fri, 2 Dec 2011 01:21:35 -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 FXczcAMFFUyk for ; Fri, 2 Dec 2011 01:21:34 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FC21F9938 for ; Fri, 2 Dec 2011 01:21:33 -0800 (PST) Received: by lahj13 with SMTP id j13so1305268lah.31 for ; Fri, 02 Dec 2011 01:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5uFz0HXwVDpMYjHehcQjft9QHJxiGJMRlgfF8Gjn6z0=; b=PvTwP3QUwVZmFwnoZo7ZfVcIw+BnBLiLmAJiDPVGDz4Okv4tKtD4GuCipAgBoSRJ1X Ha5O025BfkYR3SsPDrJNpNUgiXlHwV/hh8jVMDksOgkFamb8V8a3TtdY/+CjdqQ5Cyc7 CwIFA5uMMJ49n5JrkhX2zmZ+Bhv7oKYRaxgiQ= Received: by 10.152.104.6 with SMTP id ga6mr7075806lab.45.1322817691516; Fri, 02 Dec 2011 01:21:31 -0800 (PST) Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id jb5sm7787173lab.15.2011.12.02.01.21.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 01:21:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4721FB5A-67B5-48C4-81D3-78298EC4E1B4@employees.org> Date: Fri, 2 Dec 2011 11:21:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6506CA58-29A2-40BC-8A9A-E43A50546DDE@gmail.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <4ED698D6.5090305@gmail.com> <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com> <4ED7EF92 .2050807@gmail.com> <4721FB5A-67B5-48C4-81D3-78298EC4E1B4@employees.org> To: Ole Troan , Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 09:21:35 -0000 On Dec 2, 2011, at 10:12 AM, Ole Troan wrote: > Brian, >=20 >>> Getting that happen is quite unlikely. Rel-10 is already frozen. >>=20 >> So it could be fixed in Rel-11, or ignored in practice. In any case >> we should not hamper the generic CPE because of this restriction >> in one particular release of one particular access technology. >> As I said a day or two ago, issues specific to a given access >> technology should be clearly separated from the generic requirements. >=20 > any IPv6 deployment 'suffers' from this problem. > having all customer traffic originate from a single /56 may be simpler = for back-end systems to deal with, than > customer traffic originating from a /56 and a /64. >=20 > this problem originally came up independently of 3GPP when we defined = DHCPv6 PD. Exactly my words. - Jouni >=20 > cheers, > Ole From narten@us.ibm.com Fri Dec 2 06:06:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C788321F8B1B for ; Fri, 2 Dec 2011 06:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 VsR6pQvYKewA for ; Fri, 2 Dec 2011 06:06:23 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id D20AB21F8B16 for ; Fri, 2 Dec 2011 06:06:22 -0800 (PST) Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Dec 2011 09:06:22 -0500 Received: from d01relay06.pok.ibm.com (9.56.227.116) by e4.ny.us.ibm.com (192.168.1.104) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Dec 2011 09:06:09 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB2E5oi52511050 for ; Fri, 2 Dec 2011 09:05:52 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB2E5k5O001353 for ; Fri, 2 Dec 2011 09:05:47 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-83.mts.ibm.com [9.65.224.83]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pB2E5ihM000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 09:05:45 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pB2E5h8n011977; Fri, 2 Dec 2011 09:05:43 -0500 Message-Id: <201112021405.pB2E5h8n011977@cichlid.raleigh.ibm.com> To: Ole Troan In-reply-to: <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC! 8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> Comments: In-reply-to Ole Troan message dated "Thu, 01 Dec 2011 20:41:10 +0100." Date: Fri, 02 Dec 2011 09:05:43 -0500 From: Thomas Narten x-cbid: 11120214-3534-0000-0000-00000332D8E0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 14:06:23 -0000 Help me out here. I think both sides are partially right here. But it also pains me to see such long threads where it is clear folk are talking past each other. Could folk please think longer and post less often, but when they post actually be clear and thoughtful? (FWIW, I regularly delete these long threads unread because from the length and the back-and-forth nature it's clear that the Signal to noise content is probably not high.) Ole Troan writes: > Lorenzo, > > > But you don't want it to follow default. You want it to be an > > > on-link route on the interface that's connected to the BNG. Or > > > at least, that's the use-case that motivated the existence of > > > this option. Right. But the mechanism as defined in draft-ietf-dhc-pd-exclude-03.txt only says that the RR is not allowed to configure the excluded prefix on its downlink interfaces. It does not specify what, if anything else SHOULD/MUST be done with the prefix(es). For the case where the excluded prefix is to be used for the RR-DR link, a separate mechanism (e.g., RAs) must be used to assign the prefix to the interface. Pd-exclude seems to say that. If the excluded prefix is not used on the shared link, it is unspecified what happens. Are we all in agreeement on the above? I.e., that is in fact what pd-exclude specifies? > > the only thing the exclude option says, is that the prefix is > > _not_ part of the delegation. it may be used as the onlink prefix > > on the RR - DR link, if so the RR can use SLAAC and Prefix > > Discovery. if it is used somewhere else, the RR doesn't need to > > know about it. > > But that creates an unreasonable burden on implementations. > > To do this, implementations need to either a) create routes for > > all excluded prefixes copying the default, and update them > > whenever the default changes, or b) fully deaggregate every > > received prefix and install more specifics for the ones that > > aren't excluded. One key aspect is how many excluded prefixes are allowed. If it is just one, I don't think we have a big problem. I.e., the one excluded prefix is presumably assigned to the upstream link. This is the standard use case. However, are multiple prefixes allowed to be excluded? Can the DR include multiple OPTION_PD_EXCLUDE options? I can't quite tell from the pd-exclude document, but it strongly suggests the answer is yes. E.g.,: > The requesting router must create sink routes for the delegated > prefixes minus the excluded prefixes. This may be done by creating > sink routes for delegated prefixes and more specific routes for the > excluded prefixes. Note the plural use of the word "prefixes". So we are talking about one delegated prefix and one excluded prefix? Or are we talking about an arbitrary number of excluded prefixes? If the latter, I fully agree with Lorenzo's concerns. > > If you don't do either a) or b), then you're dropping traffic to > > global addresses that the network has explicitly told you don't > > belong to you, and that's broken. For the use case described, this case shouldn't happen. But the mechanism is more general than just for the one use case. I don't see how the mechanism is useful for anything other than the use case precisely for the reasons Lorenzo states. Are we agreed? > > So if you're a CE implementer, what are you supposed to put in the > > routing table if you DHCPv6 PD a /48 which excludes a /64? Create > > 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128? > > Create 2^64 - 1 routes? > that's implementation specific. And that means you may get failures once things are deployed. IMO, that is a show stopper for something that is intended for home deployments, where the clue level for dealing with such brokeness is well below 0. Is there any reason not to just say pd-exclude is only to be used for the one use case, precisely because with other use cases you will get brokeness? Or at least say that in the document? > put in a "fallback" route for the excluded prefix pointing to the > default for example. pd-exclude needs to say what should be done. Being silent, IMO, is not sufficient. Thomas From ichiroumakino@gmail.com Fri Dec 2 07:36:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711AA21F8C63 for ; Fri, 2 Dec 2011 07:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_13=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 qVU27L3TACuk for ; Fri, 2 Dec 2011 07:36:54 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2733621F8C61 for ; Fri, 2 Dec 2011 07:36:53 -0800 (PST) Received: by lahj13 with SMTP id j13so1514543lah.31 for ; Fri, 02 Dec 2011 07:36:53 -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=IQvHAVz2WB21dW13bADT+M9WrRvDqKkyMvmSGB8rtsw=; b=h+HXWvLPX+HVZvmKmzOtQysNdpc4JtrfaPbWzFf5qmvkgfuKNHejENggXtrkndRJrW vxTNmQFhI/BJvjuAZloPPvKTFiKHYhPLoWlO6ZtTX3trnceb/bENPqsIFARp0SpCSsXJ 5cBwhFCX5B0g76y4lGZU4ZBMLIpcRKKM9LKqI= Received: by 10.152.109.199 with SMTP id hu7mr8402355lab.16.1322840213044; Fri, 02 Dec 2011 07:36:53 -0800 (PST) Received: from [10.147.12.248] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id iy5sm8848214lab.16.2011.12.02.07.36.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 07:36:48 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201112021405.pB2E5h8n011977@cichlid.raleigh.ibm.com> Date: Fri, 2 Dec 2011 16:36:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5239618F-AB0B-4B9F-8DAE-80762FFF3705@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC! 8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <201112021405.pB2E5h8n011977@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:36:55 -0000 Thomas, > Help me out here. I think both sides are partially right here.=20 >=20 > But it also pains me to see such long threads where it is clear folk > are talking past each other. Could folk please think longer and post > less often, but when they post actually be clear and thoughtful? apologies for the noise. I'll do my best. will not claim that'll be = clear nor thoughtful though. > (FWIW, I regularly delete these long threads unread because from the > length and the back-and-forth nature it's clear that the Signal to > noise content is probably not high.) good advice. this thread should have been conducted in a smaller fora than the whole = v6ops list. >>>> But you don't want it to follow default. You want it to be an >>>> on-link route on the interface that's connected to the BNG. Or >>>> at least, that's the use-case that motivated the existence of >>>> this option. >=20 > Right. But the mechanism as defined in > draft-ietf-dhc-pd-exclude-03.txt only says that the RR is not allowed > to configure the excluded prefix on its downlink interfaces. It does > not specify what, if anything else SHOULD/MUST be done with the > prefix(es). >=20 > For the case where the excluded prefix is to be used for the RR-DR > link, a separate mechanism (e.g., RAs) must be used to assign the > prefix to the interface. Pd-exclude seems to say that. as an example. > If the excluded prefix is not used on the shared link, it is > unspecified what happens. no. > Are we all in agreeement on the above? I.e., that is in fact what > pd-exclude specifies? not quite. pd-exclude extends prefix delegation (RFC3633) with a way to delegate = prefixes of a different size than power of 2. specifically 2^n - 1. >>> the only thing the exclude option says, is that the prefix is >>> _not_ part of the delegation. it may be used as the onlink prefix >>> on the RR - DR link, if so the RR can use SLAAC and Prefix >>> Discovery. if it is used somewhere else, the RR doesn't need to >>> know about it. >=20 >>> But that creates an unreasonable burden on implementations. >=20 >>> To do this, implementations need to either a) create routes for >>> all excluded prefixes copying the default, and update them >>> whenever the default changes, or b) fully deaggregate every >>> received prefix and install more specifics for the ones that >>> aren't excluded. >=20 > One key aspect is how many excluded prefixes are allowed. If it is > just one, I don't think we have a big problem. I.e., the one excluded > prefix is presumably assigned to the upstream link. This is the > standard use case. >=20 > However, are multiple prefixes allowed to be excluded? Can the DR > include multiple OPTION_PD_EXCLUDE options? I can't quite tell from > the pd-exclude document, but it strongly suggests the answer is > yes. E.g.,: >=20 >> The requesting router must create sink routes for the delegated >> prefixes minus the excluded prefixes. This may be done by creating >> sink routes for delegated prefixes and more specific routes for the >> excluded prefixes. >=20 > Note the plural use of the word "prefixes". >=20 > So we are talking about one delegated prefix and one excluded > prefix? Or are we talking about an arbitrary number of excluded > prefixes? as specified the protocol mechanism supports an arbitrary number of = delegated prefixes and excluded prefixes. I do think restricting the number of excluded prefixes to 1 makes sense. > If the latter, I fully agree with Lorenzo's concerns. >=20 >>> If you don't do either a) or b), then you're dropping traffic to >>> global addresses that the network has explicitly told you don't >>> belong to you, and that's broken. >=20 > For the use case described, this case shouldn't happen. >=20 > But the mechanism is more general than just for the one use case. I > don't see how the mechanism is useful for anything other than the use > case precisely for the reasons Lorenzo states. >=20 > Are we agreed? depends on the context. if we are arguing about the pd-exclude document specifically, then that = is not the place to define how routing works. and it is certainly not the place to define routing in more detail than = what 3633 does. if that belongs in a DHCP document at all, that has to be done in an = update to 3633. >>> So if you're a CE implementer, what are you supposed to put in the >>> routing table if you DHCPv6 PD a /48 which excludes a /64? Create >>> 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128? >>> Create 2^64 - 1 routes? >=20 >> that's implementation specific. >=20 > And that means you may get failures once things are deployed. IMO, > that is a show stopper for something that is intended for home > deployments, where the clue level for dealing with such brokeness is > well below 0. RFC6204 states that the CPE must install a black-hole route for the = delegated prefix. in my view that also covers any use of the pd-exclude option. i.e. the = CPE must install a black-hole route for the delegated prefix - 1. what is the concern? that implementing a black hole route for a more = specific route is hard? and that the IETF is in the right position to specify how that should be = done in implementations? or is the concern how routing should be done for the excluded prefix? = that prefix is by definition not part of the delegation. so what more can be said that the excluded prefix must not be part of = the sink route? > Is there any reason not to just say pd-exclude is only to be used for > the one use case, precisely because with other use cases you will get > brokeness? Or at least say that in the document? do we not in the IETF specify building blocks and let others figure out = how they can be combined and used in new and unexpected ways? >> put in a "fallback" route for the excluded prefix pointing to the >> default for example. >=20 > pd-exclude needs to say what should be done. Being silent, IMO, is not > sufficient. the pd-exclude document already has the following text: "The requesting router must create sink routes for the delegated prefixes minus the excluded prefixes. This may be done by creating sink routes for delegated prefixes and more specific routes for the excluded prefixes." across an administrative boundary, an address block is delegated from = one entity to another. if the representation of the address block was "254 x /64s" instead of = "/56 - 1". would you require that there was a description in pd-exclude what the 255th /64 was used for? cheers, Ole From shemant@cisco.com Fri Dec 2 08:25:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3741D21F8C55 for ; Fri, 2 Dec 2011 08:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jPN+C9bPajS6 for ; Fri, 2 Dec 2011 08:25:09 -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 7F94321F8C44 for ; Fri, 2 Dec 2011 08:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8269; q=dns/txt; s=iport; t=1322843109; x=1324052709; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=EMSdmeUQgBhMU0IEjMzpUkwtkuy3adovoc/j3f/LmnM=; b=T72zpf2rQnvZP7AEgCw8+cddJG+ZxHUhNtPHqEsuDaMRl6/GhLMMW643 /TCppuIsaaOmEN5lqOs//8OL5fp7ZEPUFSBnG6Wki+DdvZHb9oJh0n/Kp H51YgX7pqBfBTAnSadYPU+Lr/ycjmImd3jLKq46+FfF38wTxxWLbmB0R8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosAAJn62E6tJV2d/2dsb2JhbABDgk2YGJAogQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqgNQGeUoo+YwSIK55i X-IronPort-AV: E=Sophos;i="4.71,284,1320624000"; d="scan'208,217";a="40667504" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Dec 2011 16:25:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pB2GP99H029026; Fri, 2 Dec 2011 16:25:09 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 10:25:08 -0600 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_01CCB10E.F4BA1E99" Date: Fri, 2 Dec 2011 10:25:07 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377829D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcywX2SbOwbo5BFZQNKm4oOqiuL9FgAknQZA References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DEC 865F895@ employees.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Ole Troan" X-OriginalArrivalTime: 02 Dec 2011 16:25:08.0832 (UTC) FILETIME=[F532FE00:01CCB10E] Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 16:25:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB10E.F4BA1E99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Thursday, December 01, 2011 2:28 PM To: Ole Troan Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt =20 =20 >To do this, implementations need to either a) create routes for all excluded prefixes copying the default, and update them whenever the default changes,=20 =20 There is only one excluded prefix, not "excluded prefixes". =20 >So if you're a CE implementer, what are you supposed to put in the routing table if you DHCPv6 PD a /48 which excludes a /64? Create 16383 routes? What if you >DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 routes? =20 The excluded /64 (say, this is prefix A) is configured on the DR which is the first-hop router to the RR. Then, say, there are two /64 (prefix B and prefix C) allocated from the /48 PD for two LAN interfaces of the CPE, say, E0 and E1 interfaces. The routing table on the CPE router is simple: =20 Prefix A/64 WAN interface Prefix B/64 E0 interface Prefix C/64 E1 interface Prefix PD/48 null: interface =20 Sorry, I don't see any problem with the routing table on the CPE router with the pd-exclude option. Did I miss anything? =20 Hemant =20 ------_=_NextPart_001_01CCB10E.F4BA1E99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Lorenzo Colitti
Sent: Thursday, = December 01, 2011 2:28 PM
To: Ole Troan
Cc: v6ops@ietf.org
Subject: Re: = [v6ops] I-D Action: = draft-ietf-v6ops-6204bis-03.txt

 

 

>To do = this, implementations need to either a) create routes for all = excluded prefixes copying the default, and update them whenever the = default changes,

 

There is only one excluded prefix, not = “excluded prefixes”.

 

>So if you're a CE = implementer, what are you supposed to put in the routing table if you = DHCPv6 PD a /48 which excludes a /64? Create 16383 routes? What if you = >DHCPv6 PD a /64 which excludes a /128? Create 2^64 - 1 = routes?

 

The excluded /64 (say, this is prefix A) is = configured on the DR which is the first-hop router to the RR. =   Then, say, there are two /64 (prefix B and prefix C) = allocated from the /48 PD for two LAN interfaces of the CPE, say, E0 and = E1 interfaces.  The routing table on the CPE router is = simple:

 

Prefix A/64   WAN = interface

Prefix B/64   E0 = interface

Prefix C/64   E1 = interface

Prefix PD/48  null: = interface

 

Sorry, I don’t see any problem with the = routing table on the CPE router with the pd-exclude option.  Did I = miss anything?

 

Hemant

 

------_=_NextPart_001_01CCB10E.F4BA1E99-- From lorenzo@google.com Fri Dec 2 08:37:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923251F0C3F for ; Fri, 2 Dec 2011 08:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 c1rliXtN04Fu for ; Fri, 2 Dec 2011 08:37:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0DFA21F8C88 for ; Fri, 2 Dec 2011 08:37:37 -0800 (PST) Received: by ywm13 with SMTP id 13so3532573ywm.31 for ; Fri, 02 Dec 2011 08:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2cTOscf0yVju0YFDGMN9SczISUKm2w4GAlHTUOoskc8=; b=qc4a7MPNklWG8KU9uW/ff9AXqPRhLCTdAvpkqCMGOaM7KwWUTxIAZKjIuhjLTX6Q7R XBaGI4Bu6b/vve1jKY3g== Received: by 10.236.183.52 with SMTP id p40mr20053957yhm.19.1322843857406; Fri, 02 Dec 2011 08:37:37 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr20053938yhm.19.1322843857304; Fri, 02 Dec 2011 08:37:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 08:37:16 -0800 (PST) In-Reply-To: <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 08:37:16 -0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=bcaec52c5ea9353d3204b31e9686 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 16:37:38 -0000 --bcaec52c5ea9353d3204b31e9686 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 12:34, Ole Troan wrote: > > And when the default changes, or you lose the default? Send the traffic > to a gateway that doesn't exist any more? Or keep monitoring the routing > table for changes so you can keep your excluded routes pointing in the > right direction? Neither of these seem reasonable things to ask of an > implementation. > > indirection through a default route or any less specific than the > delegated prefix. I just gave one example of how this could be implemented, > probably many other ways. this cat is out of the bag. No, the cat is not out of the bag. I think it's a bad idea. It's an unreasonable burden on implementations - you heard from a vendor on this thread who just said so - and for the only use case I've heard of so far, the information is already available in the RA. Why are we insisting on making things hard for implementers? --bcaec52c5ea9353d3204b31e9686 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 12:34, Ole Troan <otroan@employees.org<= /a>> wrote:
> And when the default changes, or you lose the d= efault? Send the traffic to a gateway that doesn't exist any more? Or k= eep monitoring the routing table for changes so you can keep your excluded = routes pointing in the right direction? Neither of these seem reasonable th= ings to ask of an implementation.

indirection through a default route or any less specific than t= he delegated prefix. I just gave one example of how this could be implement= ed, probably many other ways. this cat is out of the bag.

No, the cat is not out of the bag. I think it's a b= ad idea. It's an unreasonable burden on implementations - you heard fro= m a vendor on this thread who just said so - and for the only use case I= 9;ve heard of so far, the information is already available in the RA. Why a= re we insisting on making things hard for implementers?
--bcaec52c5ea9353d3204b31e9686-- From shemant@cisco.com Fri Dec 2 09:44:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CF611E80DD for ; Fri, 2 Dec 2011 09:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 eg4OUhv1Crv6 for ; Fri, 2 Dec 2011 09:44:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 49C6011E80D9 for ; Fri, 2 Dec 2011 09:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5218; q=dns/txt; s=iport; t=1322847840; x=1324057440; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PFpKGihv+J+m8LJugEnlTGm4I6CidX8EyEPYFSr663Y=; b=CiKd9yzYSo8tZbfhmm7jXTfFRE+v5m8eUX5EphXmJIJ/bGLOO5VDD523 VgJehKrypPLWD9oBYxAQCUWYWELj8ziZAbsYnZTQ63OYC4dv2EJKo35S2 dFbVo2Bbzp3lQQWxIBIVxc+aSgFnX+MwszA2h8Jhafsa4xqhmNMkznrjU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBABEppk6tJV2a/2dsb2JhbACCJY4gjhZ4lFWSNIYZBIZQjXmKXA X-IronPort-AV: E=Sophos;i="4.69,610,1315180800"; d="scan'208,217";a="38198572" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 02 Dec 2011 17:44:00 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB2Hhx8E018241; Fri, 2 Dec 2011 17:43:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 11:43:59 -0600 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_01CCB119.F8CEAB6F" Date: Fri, 2 Dec 2011 11:43:58 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcywiVpaul1gqcBzT8aEHXQ+jLQRHQAh0KEg References: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Mark Townsley" X-OriginalArrivalTime: 02 Dec 2011 17:43:59.0831 (UTC) FILETIME=[F9182670:01CCB119] Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 17:44:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB119.F8CEAB6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, December 01, 2011 7:28 PM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting =20 =20 >Troubleshoot from an admin interface, sure. Dynamically keep track of which of the 10 million CPE are "up" and "down", no. You don't do this with IPv4, do you? Please do not think of 6rd as a circuit.=20 =20 The 10 million number for CPE is interesting. A SP should manage their network that a single BR does not get so many CPEs to support and the BR. =20 =20 Hemant ------_=_NextPart_001_01CCB119.F8CEAB6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = Mark Townsley [mailto:mark@townsley.net]
Sent: Thursday, = December 01, 2011 7:28 PM
To: Hemant Singh = (shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; = Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd = Sunsetting

 

 

>Troubleshoot = from an admin interface, sure. Dynamically keep track of which of the 10 = million CPE are "up" and "down", no. You don't do = this with IPv4, do you? Please do not think of 6rd as a = circuit. 

 

The 10 million number for CPE is interesting.   A SP should = manage their network that a single BR does not get so many CPEs to = support and the BR.  

 

Hemant

------_=_NextPart_001_01CCB119.F8CEAB6F-- From wbeebee@cisco.com Fri Dec 2 10:34:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AA421F8C0F for ; Fri, 2 Dec 2011 10:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaJ+IkE5BEnz for ; Fri, 2 Dec 2011 10:34:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 70BAF21F8C0D for ; Fri, 2 Dec 2011 10:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1896; q=dns/txt; s=iport; t=1322850872; x=1324060472; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=pXh4IM0w6DEklRJ7qwf8lvcpvMEOUB2b/kmtBnh+Sxk=; b=hKbPxUsxIoYhhoODrltw3Q36Fa/x26pFuB+6gxpU5gVsy2sr9/sMnKaj jhdMXOxpXfU+rQJ5pN5BGXc590eiI+9tRqEILJiUE5IyTSda8neaDSz3n aZg+Yds4E0TGHqrVlw78J1943I1vPqSRCa7r04itY8komSktAVyLol+Lz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0GAE0Z2U6tJXG9/2dsb2JhbABDgk2Gf59bgQECgQWBaQUEAQEBBBIBKjwSAQgDAYEZAQEEAQ0nhSaCN5hVAZ5HiyEEiCuML41+hDQ X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208,217";a="40715585" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 02 Dec 2011 18:34:32 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB2IYViW005031; Fri, 2 Dec 2011 18:34:32 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 12:34:31 -0600 Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Dec 2011 18:34:31 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 02 Dec 2011 13:34:30 -0500 From: Wes Beebee To: "Hemant Singh (shemant)" , Mark Townsley Message-ID: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcywiVpaul1gqcBzT8aEHXQ+jLQRHQAh0KEgAAQalq4= In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3405677670_1072485" X-OriginalArrivalTime: 02 Dec 2011 18:34:31.0957 (UTC) FILETIME=[0861DC50:01CCB121] Cc: Alexandre Cassen , v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:34:33 -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_3405677670_1072485 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit >Troubleshoot from an admin interface, sure. Dynamically keep track of which of the 10 million CPE are "up" and "down", no. You don't do this with IPv4, do you? Please do not think of 6rd as a circuit. If NUD information is needed (ie. from an ICMPv6 generation standpoint), then one could consider setting REACHABLE_TIME in RFC 4861 and the Reachable Time in the RA to 1 hour. I understand that this implies a 1 hour delay before noticing that a CPE is no longer available, but it may be a good compromise. - Wes --B_3405677670_1072485 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [v6ops] 6rd Sunsetting >Troubleshoot from an admin interface, sure. Dynamically keep tra= ck of which of the 10 million CPE are "up" and "down", n= o. You don't do this with IPv4, do you? Please do not think of 6rd as a circ= uit.

If NUD information is needed (ie. from an ICMPv6 generation standpoint), th= en one could consider setting REACHABLE_TIME in RFC 4861 and the Reachable T= ime in the RA to 1 hour.  I understand that this implies a 1 hour delay= before noticing that a CPE is no longer available, but it may be a good com= promise.

- Wes --B_3405677670_1072485-- From jhw@apple.com Fri Dec 2 10:50:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DB411E80F1 for ; Fri, 2 Dec 2011 10:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0PzJl1K6cwIA for ; Fri, 2 Dec 2011 10:50:01 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9060011E80E7 for ; Fri, 2 Dec 2011 10:49:50 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bodbXtIS7hh3VhZ3EP/1zQ)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LVL00C0BAM020F0@mail-out.apple.com> for v6ops@ietf.org; Fri, 02 Dec 2011 10:49:33 -0800 (PST) X-AuditID: 11807136-b7c19ae0000072b0-7b-4ed91dbc8a69 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 1F.BA.29360.CBD19DE4; Fri, 02 Dec 2011 10:49:32 -0800 (PST) From: james woodyatt In-reply-to: <4ECEC112.6050106@gmail.com> Date: Fri, 02 Dec 2011 10:49:32 -0800 Message-id: <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUieJDXQXeP7E0/g1vPbCzaLu5jsjh9bC+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx991sxoJTlhX/Vl9jb2B8aNjFyMEhIWAi 0bWXsYuRE8gUk7hwbz1bFyMXh5DAbCaJCdemsoMkhAVcJZY+m8wGYvMKGEusufWOBcRmFkiQ eLbkP5jNJqAi8e3yXSYQm1NAU2L7wqdgvSxA8XsntjCD7GIGsv838EOMsZHY0HCdBWLXc6Bd f36zgiREgOY3dp1mhThIXqLl6x22CYx8s5CsnoVkNYStLbFs4WvmWWArdCQmL2REFYawP54/ wrSAkW0Vo2BRak5ipaGpXmJBQU6qXnJ+7iZGUIg2FJrtYNzxV+4QowAHoxIPr6XbDT8h1sSy 4srcQ4wSHMxKIryB0jf9hHhTEiurUovy44tKc1KLDzFKc7AoifMe2nbdT0ggPbEkNTs1tSC1 CCbLxMEp1cBoNkNv79X856yCpkFR++fZ1E2ZNPnawxVdr2Plpd8YJC/n52mPsba01Hc84Se/ +F4It7rxyhWqbh+uuG3bItE/0TZm7vv9Kw60RT2VfcVyvIl/0nuZo+oiyVrXAjd8jlPdde56 p+OjFg3rjzKHlm7I3vt4VdLecy3WS7nuzD54YVbkD8t5VgylSizFGYmGWsxFxYkARMXYAU0C AAA= Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:50:02 -0000 --Boundary_(ID_bodbXtIS7hh3VhZ3EP/1zQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Nov 24, 2011, at 14:11 , Brian E Carpenter wrote: > > And just maybe, that is preferable to never receiving > the ICMPv6 reply at all. This seems to be a genuine hole in > our specs. I see no problem in our specs. This is just an example of broken router implementation. If a packet arrives at my host with a link-local source address, then I had better be able to reliably assert that it originated from a host addressable in the link-local scope of the interface where it was received. When I reply to that address, I expect neighbor discovery and neighbor unreachability detection to apply to the link-local scope destination I will be using. If the host in question is actually nine hops away and the link-local address scope doesn't apply to any of my interfaces, then those routers are stepping on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT. This behavior is not allowed by our specs for very good reason. -- j h woodyatt --Boundary_(ID_bodbXtIS7hh3VhZ3EP/1zQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
And just = maybe, that is preferable to never receiving
the ICMPv6 reply at all. = This seems to be a genuine hole in
our = specs.

I see no problem in = our specs.  This is just an example of broken router = implementation.
If a packet arrives = at my host with a link-local source address, then I had better be able = to reliably assert that it originated from a host addressable in the = link-local scope of the interface where it was received.  When I = reply to that address, I expect neighbor discovery and neighbor = unreachability detection to apply to the link-local scope destination I = will be using.
If the host in = question is actually nine hops away and the link-local address scope = doesn't apply to any of my interfaces, then those routers are stepping = on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT. =  This behavior is not allowed by our specs for very good = reason.
= --Boundary_(ID_bodbXtIS7hh3VhZ3EP/1zQ)-- From narten@us.ibm.com Fri Dec 2 11:41:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D412211E80F0 for ; Fri, 2 Dec 2011 11:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 vWxDymDpUGDI for ; Fri, 2 Dec 2011 11:41:38 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id C882E11E80E5 for ; Fri, 2 Dec 2011 11:41:37 -0800 (PST) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Dec 2011 12:41:37 -0700 Received: from d03relay05.boulder.ibm.com (9.17.195.107) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Dec 2011 12:41:35 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB2JfUwZ041776 for ; Fri, 2 Dec 2011 12:41:30 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB2JfTsu029109 for ; Fri, 2 Dec 2011 12:41:29 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-83.mts.ibm.com [9.65.224.83]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pB2JfR0m028950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 12:41:28 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pB2JfQ7k014649; Fri, 2 Dec 2011 14:41:26 -0500 Message-Id: <201112021941.pB2JfQ7k014649@cichlid.raleigh.ibm.com> To: Ole Troan In-reply-to: <5239618F-AB0B-4B9F-8DAE-80762FFF3705@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC! ! 8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <201112021405.pB2E5h8n011977@cichlid.raleigh.ibm.com> <5239618F-AB0B-4B9F-8DAE-80762FFF3705@employees.org> Comments: In-reply-to Ole Troan message dated "Fri, 02 Dec 2011 16:36:46 +0100." Date: Fri, 02 Dec 2011 14:41:26 -0500 From: Thomas Narten x-cbid: 11120219-2398-0000-0000-00000276D03E Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 19:41:38 -0000 Ole Troan writes: > >>>> But you don't want it to follow default. You want it to be an > >>>> on-link route on the interface that's connected to the BNG. Or > >>>> at least, that's the use-case that motivated the existence of > >>>> this option. > > > > Right. But the mechanism as defined in > > draft-ietf-dhc-pd-exclude-03.txt only says that the RR is not allowed > > to configure the excluded prefix on its downlink interfaces. It does > > not specify what, if anything else SHOULD/MUST be done with the > > prefix(es). > > > > For the case where the excluded prefix is to be used for the RR-DR > > link, a separate mechanism (e.g., RAs) must be used to assign the > > prefix to the interface. Pd-exclude seems to say that. > as an example. OK, then we need to separate out some things. In my mind, pd-exclude as a document needs to stand out on its own. It should explain what it is intended to be used for and if there is any special processing needed, pd-exclude needs to say that. It is not OK to point to a different document (e.g., 6204 or 6204bis) and say there is text there that addresses this. Another way of saying things. pd-exclude is the general mechanism. While the IETF has a long tradition of leaving things flexible and extensible, it also doesn't just say "here is some rope, its up to you to figure out how not to hang yourself". So we need balance between the two extremes. > > If the excluded prefix is not used on the shared link, it is > > unspecified what happens. > no. Well, draft-ietf-dhc-pd-exclude-03.txt says: The requesting router must create sink routes for the delegated prefixes minus the excluded prefixes. This may be done by creating sink routes for delegated prefixes and more specific routes for the excluded prefixes. What does the above mean exactly? What is a sink route? A black hole (surely not). It says "more specific routes for the excluded prefix" but doesn't say *where* the route points to. And if it already has a route installed (e.g., learned from an RA) should it do anything??? So, IMO, it is not clearly specified how you handle the exceptions. (Please quote text from the document if I've missed something relevant). > > Are we all in agreeement on the above? I.e., that is in fact what > > pd-exclude specifies? > not quite. pd-exclude extends prefix delegation (RFC3633) with a > way to delegate prefixes of a different size than power of > 2. specifically 2^n - 1. This is saying that pd-exclude is intended to support the delegation of one (bigger) prefix, with one (smaller) prefix excluded from it. But the pd-exclude document doesn't seem to me to make this restriction. I assume the option can appear multiple times, since pd-exclude doesn't say otherwise. > > So we are talking about one delegated prefix and one excluded > > prefix? Or are we talking about an arbitrary number of excluded > > prefixes? > as specified the protocol mechanism supports an arbitrary number of > delegated prefixes and excluded prefixes. I do think restricting > the number of excluded prefixes to 1 makes sense. Do others agree? If so, that would simplify things a bunch, I think. > > If the latter, I fully agree with Lorenzo's concerns. > > > >>> If you don't do either a) or b), then you're dropping traffic to > >>> global addresses that the network has explicitly told you don't > >>> belong to you, and that's broken. > > > > For the use case described, this case shouldn't happen. > > > > But the mechanism is more general than just for the one use case. I > > don't see how the mechanism is useful for anything other than the use > > case precisely for the reasons Lorenzo states. > > > > Are we agreed? > depends on the context. if we are arguing about the pd-exclude > document specifically, then that is not the place to define how > routing works. I disagree. The specification of pd-exclude seems deficient if it doesn't say something about whether to add routes for the excluded prefixes. And note if you don't add routes for them, by default there aren't any because they are covered by the aggregate -- that is the problem. This is exactly the type of thing that should be covered by pd-exclude. If the use case for pd-exclude is really just to allow for a prefix to be assigned to the upstream link, then the RR doesn't need to do anything special. It will install a route if it gets (say) an RA from the DR. > and it is certainly not the place to define routing > in more detail than what 3633 does. if that belongs in a DHCP > document at all, that has to be done in an update to 3633. > >>> So if you're a CE implementer, what are you supposed to put in the > >>> routing table if you DHCPv6 PD a /48 which excludes a /64? Create > >>> 16383 routes? What if you DHCPv6 PD a /64 which excludes a /128? > >>> Create 2^64 - 1 routes? > > > >> that's implementation specific. > > > > And that means you may get failures once things are deployed. IMO, > > that is a show stopper for something that is intended for home > > deployments, where the clue level for dealing with such brokeness is > > well below 0. > RFC6204 states that the CPE must install a black-hole route for the > delegated prefix. in my view that also covers any use of the > pd-exclude option. i.e. the CPE must install a black-hole route for > the delegated prefix - 1. And if it then gets an RA from its upstream for the excluded route, is that supposed to override the NULL route? And if the RA later goes away and stops advertising the prefix, does the NULL route have to be restored? Is there text that says how to handle these cases? > what is the concern? that implementing a black hole route for a more specific route is hard? > and that the IETF is in the right position to specify how that should be done in implementations? > or is the concern how routing should be done for the excluded prefix? that prefix is by definition not part of the delegation. > so what more can be said that the excluded prefix must not be part of the sink route? > > Is there any reason not to just say pd-exclude is only to be used for > > the one use case, precisely because with other use cases you will get > > brokeness? Or at least say that in the document? > do we not in the IETF specify building blocks and let others figure > out how they can be combined and used in new and unexpected ways? Yes, we have a long tradition of defining rope in specs, and then recognizing later that we screwed up and the only thing people did was hang themselves, or we produced something that wasn't useable in practice because "implementations" had chosen to do different things and there was no predictability in behavior. > >> put in a "fallback" route for the excluded prefix pointing to the > >> default for example. > > > > pd-exclude needs to say what should be done. Being silent, IMO, is not > > sufficient. > the pd-exclude document already has the following text: > "The requesting router must create sink routes for the delegated > prefixes minus the excluded prefixes. This may be done by creating > sink routes for delegated prefixes and more specific routes for the > excluded prefixes." > across an administrative boundary, an address block is delegated > from one entity to another. if the representation of the address > block was "254 x /64s" instead of "/56 - 1". would you require that > there was a description in pd-exclude what the 255th /64 was used > for? No, of course not. But in that case, the 255th /64 was never mentioned, so there would be no action for it. Implementations would presumably be required to have routes only for the delegated prefixes, even if that meant installing 254 /64s. Thomas From lorenzo@google.com Fri Dec 2 11:41:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30211E80F3 for ; Fri, 2 Dec 2011 11:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 p0v0Y6nQV4gs for ; Fri, 2 Dec 2011 11:41:51 -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 0918B11E80F1 for ; Fri, 2 Dec 2011 11:41:50 -0800 (PST) Received: by yenl9 with SMTP id l9so2452159yen.31 for ; Fri, 02 Dec 2011 11:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2FrIbWw4Zgh0kW8TggABih9GAlV0TRHtXnxAgxBac50=; b=LJI636r3PSv8uFm3saXITJBSzmpuSQCIgQXL/h+U0uVYw4D15n0i+Ty7och4kweYee TNHPRQ5sI5+s5lEma6Dg== Received: by 10.236.183.52 with SMTP id p40mr21243691yhm.19.1322854909491; Fri, 02 Dec 2011 11:41:49 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr21243673yhm.19.1322854909371; Fri, 02 Dec 2011 11:41:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 11:41:28 -0800 (PST) In-Reply-To: References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 11:41:28 -0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=bcaec52c5ea9f666b804b32128b4 X-System-Of-Record: true Cc: Thomas Narten , "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 19:41:51 -0000 --bcaec52c5ea9f666b804b32128b4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 07:36, Ole Troan wrote: > RFC6204 states that the CPE must install a black-hole route for the > delegated prefix. > in my view that also covers any use of the pd-exclude option. i.e. the CPE > must install a black-hole route for the > delegated prefix - 1. > I still don't see the need for this, because: - If the requesting router is being told that the directly-connected /64 is directly-connected, via an RA with O=1, then it has already been told that the /64 is elsewhere. - If the requesting router is not being told that the directly-connected /64 is directly-connected, via an RA with O=1, then the use case doesn't work at all, and I haven't heard any other use case. That said, my main objection to the proposal is difficulty in implementation and the resulting confusion. I think my objections would mostly be resolved if the draft said that: 1. The number of excluded prefixes MUST be limited to 1. Rationale: I don't think it's reasonable to say to a requesting router "here's 2001:db8:1:10::/60, but you can't use 2001:db8:1:10::/62, 2001:db8:1:16::/63, or 2001:db8:1:18/61, so actually you only really have 2001:db8:1:14::/63 but I'm not going to tell you, sorry". 2. Traffic to the excluded prefix MUST be treated in the same way as traffic to the delegated prefix (e.g., discarded) unless the requesting router is explicitly given a route to the excluded prefix (or a more specific) via some other means (e.g., an RA, or manual config, or whatever). Rationale: it simplifies implementations, as in the common case they can simply install a discard for the whole delegated prefix. Any objections? I had a chat with Ole and if I understand correctly he sort of agrees these changes are sane. --bcaec52c5ea9f666b804b32128b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 07:36, Ole Troan <otr= oan@employees.org> wrote:
RFC6204 states that the CPE must install a black-hole route for the delegat= ed prefix.
in my view that also covers any use of the pd-exclude option. i.e. the CPE = must install a black-hole route for the
delegated prefix - 1.

I still don't= see the need for this, because:

- If the requesti= ng router is being told that the directly-connected /64 is directly-connect= ed, via an RA with O=3D1, then it has already been told that the /64 is els= ewhere.
- If the requesting router is not being told that=A0the directly-conne= cted /64 is directly-connected, via an RA with O=3D1, then the use case doe= sn't work at all, and I haven't heard any other use case.

That said, my main objection to the proposal is difficulty i= n implementation and the resulting confusion. I think my objections would m= ostly be resolved if the draft said that:

1. The n= umber of excluded prefixes MUST be limited to 1. Rationale: I don't thi= nk it's reasonable to say to a requesting router "here's 2001:= db8:1:10::/60, but you can't use 2001:db8:1:10::/62, 2001:db8:1:16::/63= , or=A02001:db8:1:18/61, so actually you only really have 2001:db8:1:14::/6= 3 but I'm not going to tell you, sorry".

2. Traffic to the excluded prefix MUST be treated in th= e same way as traffic to the delegated prefix (e.g., discarded) unless the = requesting router is explicitly given a route to the excluded prefix (or a = more specific) via some other means (e.g., an RA, or manual config, or what= ever). Rationale: it simplifies implementations, as in the common case they= can simply install a discard for the whole delegated prefix.

Any objections? I had a chat with Ole and if I understa= nd correctly he sort of agrees these changes are sane.
--bcaec52c5ea9f666b804b32128b4-- From shemant@cisco.com Fri Dec 2 12:04:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF5B1F0C5A for ; Fri, 2 Dec 2011 12:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EbEAlYQYeuwf for ; Fri, 2 Dec 2011 12:04:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A57321F0C49 for ; Fri, 2 Dec 2011 12:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6788; q=dns/txt; s=iport; t=1322856253; x=1324065853; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=z0HJmJLyTewKl6URAEVY5Y4URq7IS4eYzBBS/TPG3Fs=; b=GXfWtVXz2+akB1VbYG6NTkZqWkpBIhvEg7Bb2P9pEcldAhn8gacvH29b ClrH0iO8YTEniRe73JYj1OUOXKy9Sxg6DfR3P1dX7gB8Q2tVnMavcC6n3 MmmCoiwdWFp1LO1IDN5dXvwQLEvXBwREESWAPieG4JNTTJ2hUBiqXtDvB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAGIu2U6tJV2a/2dsb2JhbABDgk2XN5ApgQWBcgEBAQMBEgEJEQNJBQsCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodlmDMBnkOKPmMEiCueYg X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208,217";a="40727341" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 02 Dec 2011 20:04:12 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB2K4CfF001166; Fri, 2 Dec 2011 20:04:12 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 14:04:12 -0600 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_01CCB12D.8F074357" Date: Fri, 2 Dec 2011 14:04:11 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778417@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcyxKoQJMj25X2qWSb+k0e4BLD4VlAAAtH4A References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DEC 865F895@ employees.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Ole Troan" X-OriginalArrivalTime: 02 Dec 2011 20:04:12.0121 (UTC) FILETIME=[8F35BC90:01CCB12D] Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:04:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB12D.8F074357 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Friday, December 02, 2011 2:41 PM To: Ole Troan Cc: Thomas Narten; v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt =20 =20 > 1. The number of excluded prefixes MUST be limited to 1.=20 =20 See this text from the exclude draft. The exclude prefix is limited to one. =20 [This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE (TBD1), that is used to exclude exactly one prefix from a delegated prefix.] =20 Hemant ------_=_NextPart_001_01CCB12D.8F074357 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Lorenzo Colitti
Sent: Friday, December 02, 2011 2:41 = PM
To: Ole Troan
Cc: Thomas Narten; = v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6204bis-03.txt

 

 

> = 1. The = number of excluded prefixes MUST be limited to 1. 

 
See =
this text from the exclude draft.  The exclude prefix is limited to =
one.
 
[This specification defines a new DHCPv6 =
option, OPTION_PD_EXCLUDE

(TBD1), that is = used to exclude exactly one prefix from a = delegated

prefix.]

 

Hemant

------_=_NextPart_001_01CCB12D.8F074357-- From ichiroumakino@gmail.com Fri Dec 2 12:09:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1F1F0C49 for ; Fri, 2 Dec 2011 12:09:52 -0800 (PST) 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.137, 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 F59Vc5+a3zpo for ; Fri, 2 Dec 2011 12:09:51 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F87C21F8B48 for ; Fri, 2 Dec 2011 12:09:51 -0800 (PST) Received: by eaak10 with SMTP id k10so352512eaa.31 for ; Fri, 02 Dec 2011 12:09:50 -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=D/icZuaUZPt76P9hfmiFsiBn7jttXml1FiGCzF/Gnns=; b=IBZ6e/Kf5BS8pMkS6ZSD7YTsoM0wUUVUNZ3q1tPS4Zqw597WijvO9qSFEixlUr2pFZ Y6ta6qwYDz3i2hpE0CXIYuxPAX1Lrt7iSwExulTkxwQkFlZvR3Xn0gPsIVB+3lYo7gg0 CMQgl8owCyjPEEnLZNqLE9+DstQsMJFSDKBB8= Received: by 10.213.21.131 with SMTP id j3mr240677ebb.95.1322856590447; Fri, 02 Dec 2011 12:09:50 -0800 (PST) Received: from dhcp-10-55-81-140.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 8sm30598563ees.2.2011.12.02.12.09.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 12:09:49 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201112021941.pB2JfQ7k014649@cichlid.raleigh.ibm.com> Date: Fri, 2 Dec 2011 21:09:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C9C5C6F-9C8B-4609-A5F8-B5B2B62A5544@employees.org> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC! ! 8 4-4249-B93A-71DEC865F895@employees.org> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <201112021405.pB2E5h8n011977@cichlid.raleigh.ibm.com> <5239618F-AB0B-4B9F-8DAE-80762FFF3705@employees.org> <201112021941.pB2JfQ7k014649@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:09:52 -0000 Thomas, >> across an administrative boundary, an address block is delegated >> from one entity to another. if the representation of the address >> block was "254 x /64s" instead of "/56 - 1". would you require that >> there was a description in pd-exclude what the 255th /64 was used >> for? >=20 > No, of course not. But in that case, the 255th /64 was never > mentioned, so there would be no action for it. Implementations would > presumably be required to have routes only for the delegated prefixes, > even if that meant installing 254 /64s. the intention with the pd-exclude option is exactly that. consider it = the "never mentioned sub-prefix" option. the sink route / blackhole route issue is somewhat orthogonal. the = purpose of the blackhole route is to avoid a routing loop between the CPE and the ISPs router. the black-hole route must only cover the prefix that is delegated to the = CPE obviously. given that with the exclude option the delegated prefix = is no longer a power of 2. there would have to be exclude prefix length = - delegated prefix length number of black-hole routes (with high cost) = installed in the RIB. Lorenzo is saying that the complexity in adding these routes isn't worth = the added benefit of a more flexible mechanism. basically restricting = the option to be used for only the use cases given in the draft. i.e. = the excluded prefix MUST if used always be used on a directly connected = interface of the CPE. as Lorenzo said, I'm sort of fine with that restriction. cheers, Ole From narten@us.ibm.com Fri Dec 2 12:13:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D511E80A3 for ; Fri, 2 Dec 2011 12:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 0RNAvz8yEiSA for ; Fri, 2 Dec 2011 12:13:44 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7D11E8083 for ; Fri, 2 Dec 2011 12:13:44 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Dec 2011 13:13:43 -0700 Received: from d03relay04.boulder.ibm.com (9.17.195.106) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Dec 2011 13:13:41 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB2KDXRV094766 for ; Fri, 2 Dec 2011 13:13:34 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB2KDTNJ029919 for ; Fri, 2 Dec 2011 13:13:30 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-83.mts.ibm.com [9.65.224.83]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pB2KDRml029758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 13:13:28 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pB2KDPJv014952; Fri, 2 Dec 2011 15:13:25 -0500 Message-Id: <201112022013.pB2KDPJv014952@cichlid.raleigh.ibm.com> To: "Hemant Singh (shemant)" In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C303778417@XMB-RCD-109.cisco.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DE! ! C865F895@ employees.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778417@XMB-RCD-109.cisco.com> Comments: In-reply-to "Hemant Singh (shemant)" message dated "Fri, 02 Dec 2011 14:04:11 -0600." Date: Fri, 02 Dec 2011 15:13:25 -0500 From: Thomas Narten x-cbid: 11120220-4242-0000-0000-00000042864C Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:13:44 -0000 "Hemant Singh (shemant)" writes: > > 1. The number of excluded prefixes MUST be limited to 1.= > = > See this text from the exclude draft. The exclude prefix is limited to > one. > > [This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE > (TBD1), that is used to exclude exactly one prefix from a delegated > prefix.] This text refers to the actual option itself. A signle instance of the option can only be used to exclude one prefix. But can the option itself appear multiple times? The document appears to be silent on this point. But maybe we are all having a violent agreement, and the document should just be clarified to make clear that the exclude option can appear only once, and that for any delegated prefix, only one exception can be "excluded" from it. Thomas From shemant@cisco.com Fri Dec 2 12:18:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81E121F8BA8 for ; Fri, 2 Dec 2011 12:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 A+Jt20IN+1wF for ; Fri, 2 Dec 2011 12:18:37 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CE1C421F8BA4 for ; Fri, 2 Dec 2011 12:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=471; q=dns/txt; s=iport; t=1322857117; x=1324066717; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kErbYFxGXWcGDu162VYw6H0ha04HfupO8OcvtqoJFqw=; b=AnGJ2y8pmVtvUBuobEKWijOfqBMsaugUehgsg0YxfLNfRggGce2Z1yl1 AVqpQDf4SloQ8S0rZNStiYZZjeKRo/rGIxucZVMPi9RS2kgN4m2mjBqcd Rr9xEDosQfjEbsS16S7xDdhmwRSpJ2MRO2//7xJiSN7NZ61YmBkI5UjDD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAKQx2U6tJXG//2dsb2JhbABDmgSQKYEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqgFwGeQoo+YwSIK55i X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208";a="40732065" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 02 Dec 2011 20:18:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB2KIbHn019916; Fri, 2 Dec 2011 20:18:37 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 14:18:37 -0600 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: Fri, 2 Dec 2011 14:18:36 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377842E@XMB-RCD-109.cisco.com> In-Reply-To: <201112022013.pB2KDPJv014952@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcyxLt5wmJ77A6JSTryguQIRHJpEugAAJW/w References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DE! ! C865F 895@ employe es.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778417@XMB-RCD-109.cisco.com> <201112022013.pB2KDPJv014952@cichlid.raleigh.ibm.com> From: "Hemant Singh (shemant)" To: "Thomas Narten" X-OriginalArrivalTime: 02 Dec 2011 20:18:37.0138 (UTC) FILETIME=[92CCDB20:01CCB12F] Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:18:38 -0000 -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Friday, December 02, 2011 3:13 PM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Ole Troan; v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt >But can the option itself appear multiple times? The document appears >to be silent on this point. Great question. If the document does not clarify the question, the document ought to. Hemant From shemant@cisco.com Fri Dec 2 12:19:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83421F8BBC for ; Fri, 2 Dec 2011 12:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4gd1DcCZzVKj for ; Fri, 2 Dec 2011 12:19:42 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4421F8BA8 for ; Fri, 2 Dec 2011 12:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5314; q=dns/txt; s=iport; t=1322857181; x=1324066781; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=1LbfhFt7AqUjkx41+1+6fW6HJzz34Wf+t3VRMYeVUjs=; b=VojEk0o8k16Kh4PXafXrGzWjoND1GmI8P5+qg3LAL9NPgaasA4EAoy+d AeqqNRNEJtqEB8jLmsRE/kJN3CvyCvKhfMqSN8z7RYt94Qe83D91TJB8s luBXyWQtRXzh4CIkMwkvap2IkLrcKRctwFQirj/1enJ3r5XJVGlpvmbSW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAE4y2U6tJV2Z/2dsb2JhbABDgk2XN5ApgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqgGAGeQoo+YwSIK55i X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208,217";a="40746910" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 02 Dec 2011 20:19:41 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB2KJfHL018916; Fri, 2 Dec 2011 20:19:41 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 14:19:41 -0600 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_01CCB12F.B8BA9923" Date: Fri, 2 Dec 2011 14:19:40 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcyxKoQJMj25X2qWSb+k0e4BLD4VlAAA+4Og References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DEC 865F895@ employees.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Ole Troan" X-OriginalArrivalTime: 02 Dec 2011 20:19:41.0074 (UTC) FILETIME=[B8E8B720:01CCB12F] Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:19:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB12F.B8BA9923 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Friday, December 02, 2011 2:41 PM To: Ole Troan Cc: Thomas Narten; v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt =20 =20 >2. Traffic to the excluded prefix MUST be treated in the same way as traffic to the delegated prefix (e.g., discarded) unless the requesting router is explicitly given a route to >the excluded prefix (or a more specific) via some other means (e.g., an RA, or manual config, or whatever).=20 =20 The DR is using the excluded prefix. The DR is the first-hop router to the RR. Since a RR interface is facing the DR, the RR interface already has a default router whose IPv6 link-local address is known to the RR - if the RR has seen an RA from the DR with the SLLAO in the RA. =20 =20 Hemant =20 ------_=_NextPart_001_01CCB12F.B8BA9923 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Lorenzo Colitti
Sent: Friday, December 02, 2011 2:41 = PM
To: Ole Troan
Cc: Thomas Narten; = v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6204bis-03.txt

 

 

>2. Traffic to = the excluded prefix MUST be treated in the same way as traffic to the = delegated prefix (e.g., discarded) unless the requesting router is = explicitly given a route to >the = excluded prefix (or a more specific) via some other means (e.g., an RA, = or manual config, or whatever).

 

The DR is using the excluded prefix.   The DR is the = first-hop router to the RR.  Since a RR interface is facing the DR, = the RR interface already has a default router whose IPv6 link-local = address is known to the RR - if the RR has seen an RA from the DR with = the SLLAO in the RA.   

 

Hemant

 

------_=_NextPart_001_01CCB12F.B8BA9923-- From brian.e.carpenter@gmail.com Fri Dec 2 13:11:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6111E80CC for ; Fri, 2 Dec 2011 13:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 HvLlXAg-+a-1 for ; Fri, 2 Dec 2011 13:11:00 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9D11E80D0 for ; Fri, 2 Dec 2011 13:11:00 -0800 (PST) Received: by faap14 with SMTP id p14so2849070faa.31 for ; Fri, 02 Dec 2011 13:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E2z0wUEBv3xXYMAs/2l9IrzUrhw+RJX330sa78HBKpg=; b=jExC2F0HehiOFW3nYRmz2vRwz6hvbJ4wkaAfFaPGd733ASZsbe+wG9E7thbfs2PXpN pnZqvDPqYfpcKmVEQ1+c+bFaRurFVaBEjz1O3rHOFqkQWIP8c9GNx6AXa6TsETRy/BXF 3I2CufpTIQmnsZmM2ykeOrBXrcfMk0zHu/Y4w= Received: by 10.181.13.84 with SMTP id ew20mr11730864wid.58.1322860259202; Fri, 02 Dec 2011 13:10:59 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id 28sm9229258wby.3.2011.12.02.13.10.56 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 13:10:58 -0800 (PST) Message-ID: <4ED93EDC.7030007@gmail.com> Date: Sat, 03 Dec 2011 10:10:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> In-Reply-To: <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 21:11:06 -0000 On 2011-12-03 07:49, james woodyatt wrote: > On Nov 24, 2011, at 14:11 , Brian E Carpenter wrote: >> And just maybe, that is preferable to never receiving >> the ICMPv6 reply at all. This seems to be a genuine hole in >> our specs. > > I see no problem in our specs. This is just an example of broken router implementation. The choice is between not getting an ICMPv6 echo reply at all or getting one with an invalid source address. > If a packet arrives at my host with a link-local source address, then I had better be able to reliably assert that it originated from a host addressable in the link-local scope of the interface where it was received. When I reply to that address, I expect neighbor discovery and neighbor unreachability detection to apply to the link-local scope destination I will be using. This would only really matter if you were in the habit of replying to echo replies. > If the host in question is actually nine hops away and the link-local address scope doesn't apply to any of my interfaces, then those routers are stepping on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT. This behavior is not allowed by our specs for very good reason. In every case except ICMP echo reply, I agree. Brian From brian.e.carpenter@gmail.com Fri Dec 2 14:10:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2568821F8C2B for ; Fri, 2 Dec 2011 14:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SP2ZECqxrmpd for ; Fri, 2 Dec 2011 14:10:38 -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 67FDE21F8C22 for ; Fri, 2 Dec 2011 14:10:38 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1499714wgb.13 for ; Fri, 02 Dec 2011 14:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hiFTd7KP0clh2VlxYUY18lV60FtiwtwSm/Lt2bOCmeM=; b=SgL0bPBWNw9XWLzuaQOoApt4060HnqrXDdiabF8tIyA5K9FEjhyJ9DLCbBPGJprucF vK80iJnmw4bwW3r7pUDg5vnf1EEDS1tiqtqh4h+0cmOYx4dG+ej91tQ1BSftLFXjRbTA pLCOkUy8akObgPRqw+Dp70l8MN/sxZXSGP7k0= Received: by 10.216.36.9 with SMTP id v9mr27285wea.58.1322863800337; Fri, 02 Dec 2011 14:10:00 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id hq5sm4108276wib.7.2011.12.02.14.09.57 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 14:09:59 -0800 (PST) Message-ID: <4ED94CAE.4020209@gmail.com> Date: Sat, 03 Dec 2011 11:09:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni korhonen References: <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <4ED698D6.5090305@gmail.com> <93DAF1E9-349B-4F1A-A1FF-E4E0A5C958A3@gmail.com> <4ED7EF92.2050807@gmail.com> <4721FB5A-67B5-48C4-81D3-78298EC4E1B4@employees.org> <6506CA58-29A2-40BC-8A9A-E43A50546DDE@gmail.com> In-Reply-To: <6506CA58-29A2-40BC-8A9A-E43A50546DDE@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:10:39 -0000 On 2011-12-02 22:21, jouni korhonen wrote: > On Dec 2, 2011, at 10:12 AM, Ole Troan wrote: > >> Brian, >> >>>> Getting that happen is quite unlikely. Rel-10 is already frozen. >>> So it could be fixed in Rel-11, or ignored in practice. In any case >>> we should not hamper the generic CPE because of this restriction >>> in one particular release of one particular access technology. >>> As I said a day or two ago, issues specific to a given access >>> technology should be clearly separated from the generic requirements. >> any IPv6 deployment 'suffers' from this problem. >> having all customer traffic originate from a single /56 may be simpler for back-end systems to deal with, than >> customer traffic originating from a /56 and a /64. >> >> this problem originally came up independently of 3GPP when we defined DHCPv6 PD. > > Exactly my words. > > - Jouni Not disagreeing with you. One /N per subscriber where N<64 would make everything simpler. That has been known for many years. Brian From pch-b29AA871B@u-1.phicoh.com Fri Dec 2 14:13:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDBD1F0C65 for ; Fri, 2 Dec 2011 14:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 RNQuZHIDRb2Q for ; Fri, 2 Dec 2011 14:13:56 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 390181F0C3F for ; Fri, 2 Dec 2011 14:13:56 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RWbMV-0001ivC; Fri, 2 Dec 2011 23:13:43 +0100 Message-Id: To: Brian E Carpenter From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> In-reply-to: Your message of "Sat, 03 Dec 2011 10:10:52 +1300 ." <4ED93EDC.7030007@gmail.com> Date: Fri, 02 Dec 2011 23:13:31 +0100 Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:13:57 -0000 In your letter dated Sat, 03 Dec 2011 10:10:52 +1300 you wrote: >> If the host in question is actually nine hops away and the link-local addres >s scope doesn't apply to any of my interfaces, then those routers are stepping > on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT. This >behavior is not allowed by our specs for very good reason. > >In every case except ICMP echo reply, I agree. The only type I would want to receive is Packet Too Big. But for consistency reason I'd say, just keep the current rules and drop all such packets. It just violates ingress filtering if my routers would forward those packets to any of my LANs. From jouni.nospam@gmail.com Fri Dec 2 14:15:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64F011E80CE for ; Fri, 2 Dec 2011 14:15:40 -0800 (PST) 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.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 Cx-MxHvExtU3 for ; Fri, 2 Dec 2011 14:15:40 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE14111E8083 for ; Fri, 2 Dec 2011 14:15:39 -0800 (PST) Received: by lagw12 with SMTP id w12so75984lag.31 for ; Fri, 02 Dec 2011 14:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=H6sFeB4mtY6qjuXcEWruAuR7kLTYHq1J6lfOD8fEB3k=; b=Q33+bjlXlr+UsOn/ovXRFU0qannwZMWCoOWJqu+I/SH9F+lIDMRlpMqALGwc5SmJjd KAxZpuF90ess0jW35CpU2rJzn9Tmeq1755RZ0LnabHEgtm3OHWqF5mkZXZhmRcdNnwPc e8aGp7JybFnapPte6AGC4WhTLphHOvKBXGVSQ= Received: by 10.152.104.47 with SMTP id gb15mr130944lab.9.1322864138929; Fri, 02 Dec 2011 14:15:38 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id jb5sm9793480lab.15.2011.12.02.14.15.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 14:15:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <201112022013.pB2KDPJv014952@cichlid.raleigh.ibm.com> Date: Sat, 3 Dec 2011 00:15:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DE! ! C865F895@ employees.or g><074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org><748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778417@XMB-RCD-109.cisco.com> <201112022013.pB2KDPJv014952@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1251.1) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:15:40 -0000 Thomas, On Dec 2, 2011, at 10:13 PM, Thomas Narten wrote: > "Hemant Singh (shemant)" writes: >=20 >>> 1. The number of excluded prefixes MUST be limited to 1.=3D >=20 >> =3D >> See this text from the exclude draft. The exclude prefix is limited = to >> one. >>=20 >> [This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE >> (TBD1), that is used to exclude exactly one prefix from a delegated >> prefix.] >=20 > This text refers to the actual option itself. A signle instance of the > option can only be used to exclude one prefix. >=20 > But can the option itself appear multiple times? The document appears > to be silent on this point. No it's not. Section 4.1 says: IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option So if you delegate say 10 prefixes in different IA_PDs.. then you can = have multiple OPTION_PD_EXCLUDEs in one DHCP message but at most one per = delegated prefix. - Jouni > But maybe we are all having a violent agreement, and the document > should just be clarified to make clear that the exclude option can > appear only once, and that for any delegated prefix, only one > exception can be "excluded" from it. I still think per delegated prefix is ok. I see no reason to change = that. > Thomas >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Fri Dec 2 14:20:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE221F8C3D for ; Fri, 2 Dec 2011 14:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.569 X-Spam-Level: X-Spam-Status: No, score=-104.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, GB_I_LETTER=-2, 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 46YFAJe2dbaN for ; Fri, 2 Dec 2011 14:20:31 -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 28E8D21F8C3A for ; Fri, 2 Dec 2011 14:20:30 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1513057wgb.13 for ; Fri, 02 Dec 2011 14:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M57iwMjd5sJL8lLfzY19Aw0XDydr4SkfXghvLHRKBVI=; b=PkRWmonqvO29NA7dE3Twot7IG5QlC8ZKsNq/qVOYhd15uA4Ew3wX+xiDbsECTLR5mN qqvGvtfiMEUt5F4Zd922nauCV/OiRYB42NN247CFuxcJlJgj+A0d92exKwQ6uikjNMIW cZ05B6I4Pe95XLty9jxMBR1kKra8sjKVjWpx0= Received: by 10.227.205.135 with SMTP id fq7mr159540wbb.19.1322864430193; Fri, 02 Dec 2011 14:20:30 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id fg15sm12416003wbb.7.2011.12.02.14.20.27 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 14:20:29 -0800 (PST) Message-ID: <4ED94F24.2060806@gmail.com> Date: Sat, 03 Dec 2011 11:20:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Homburg References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:20:32 -0000 On 2011-12-03 11:13, Philip Homburg wrote: > In your letter dated Sat, 03 Dec 2011 10:10:52 +1300 you wrote: >>> If the host in question is actually nine hops away and the link-local addres >> s scope doesn't apply to any of my interfaces, then those routers are stepping >> on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT. This >> behavior is not allowed by our specs for very good reason. >> >> In every case except ICMP echo reply, I agree. > > The only type I would want to receive is Packet Too Big. I wonder if you've just identified another reason for PMTUD failures? A router that (correctly) drops PTB with a link local source address would break PMTUD. > But for consistency > reason I'd say, just keep the current rules and drop all such packets. > It just violates ingress filtering if my routers would forward those packets > to any of my LANs. If we go that way, there also needs to be a Router Requirement that every router MUST have at least one GUA for use as the source address in ICMPv6 messages. Brian From lorenzo@google.com Fri Dec 2 14:21:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088861F0C3F for ; Fri, 2 Dec 2011 14:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ZruSSGR0AvXD for ; Fri, 2 Dec 2011 14:21:56 -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 E31C721F8C44 for ; Fri, 2 Dec 2011 14:21:55 -0800 (PST) Received: by iaek3 with SMTP id k3so2605216iae.31 for ; Fri, 02 Dec 2011 14:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=VnvJP0Ixxt+elKTd+s8FXQONBPju+p72ueCB7H5M45U=; b=ryiZolHpGOw+fzLyhTOFkliKd7FkL3IajMyBJ949yv+bzUKHZp/S+ZPlKTeUk/wcYj 4ypA9LE2j/rq7rB/qoSQ== Received: by 10.50.158.227 with SMTP id wx3mr114737igb.52.1322864515515; Fri, 02 Dec 2011 14:21:55 -0800 (PST) Received: by 10.50.158.227 with SMTP id wx3mr114717igb.52.1322864515294; Fri, 02 Dec 2011 14:21:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.122.218 with HTTP; Fri, 2 Dec 2011 14:21:34 -0800 (PST) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 14:21:34 -0800 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=14dae9340b7f8526ec04b32365bb X-System-Of-Record: true Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:21:57 -0000 --14dae9340b7f8526ec04b32365bb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 12:19, Hemant Singh (shemant) wrote: > >2. Traffic to the excluded prefix MUST be treated in the same way as > traffic to the delegated prefix (e.g., discarded) unless the requesting > router is explicitly given a route to >the excluded prefix (or a more > specific) via some other means (e.g., an RA, or manual config, or whatever). > > ** ** > > The DR is using the excluded prefix. The DR is the first-hop router to > the RR. Since a RR interface is facing the DR, the RR interface already > has a default router whose IPv6 link-local address is known to the RR - if > the RR has seen an RA from the DR with the SLLAO in the RA. > That exactly the situation I object to. I think it's not OK to expect the RR to follow its default route to the excluded prefix. I think that for the sake of simplicity, the RR should be free to install a discard route for the whole delegated prefix, regardless of the exclusion. Thus the text "explicitly given a route to the excluded prefix". If the RR and DR are directly connected, then the DR can send the RR a router advertisement containing a PIO with that /64 and the L=1 (sorry, not O=1 as I said earlier). That counts as the RR being "explicitly given a route to the excluded prefix". --14dae9340b7f8526ec04b32365bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 12:19, Hemant Singh (shem= ant) <shemant@cis= co.com> wrote:

>2. Traffic to the = excluded prefix MUST be treated in the same way as traffic to the delegated= prefix (e.g., discarded) unless the requesting router is explicitly given = a route to >the exclude= d prefix (or a more specific) via some other means (e.g., an RA, or manual = config, or whatever).

=A0

The DR is us= ing the excluded prefix.=A0=A0 The DR is the first-hop router to the RR.=A0= Since a RR interface is facing the DR, the RR interface already has a defa= ult router whose IPv6 link-local address is known to the RR - if the RR has= seen an RA from the DR with the SLLAO in the RA. =A0=A0


That exactly the s= ituation I object to. I think it's not OK to expect the RR to follow it= s default route to the excluded prefix. I think that for the sake of simpli= city, the RR should be free to install a discard route for the whole delega= ted prefix, regardless of the exclusion. Thus the text "explicitly giv= en a route to the excluded prefix".

If the RR and DR are directly connected, then the DR ca= n send the RR a router advertisement containing a PIO with that /64 and the= L=3D1 (sorry, not O=3D1 as I said earlier). That counts as the RR being &q= uot;explicitly given a route to the excluded prefix".
--14dae9340b7f8526ec04b32365bb-- From pch-b29AA871B@u-1.phicoh.com Fri Dec 2 14:37:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CD11E80A1 for ; Fri, 2 Dec 2011 14:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 pjeN9cwwDbMc for ; Fri, 2 Dec 2011 14:37:42 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2191311E809A for ; Fri, 2 Dec 2011 14:37:42 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RWbje-0001iWC; Fri, 2 Dec 2011 23:37:38 +0100 Message-Id: To: Brian E Carpenter From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> In-reply-to: Your message of "Sat, 03 Dec 2011 11:20:20 +1300 ." <4ED94F24.2060806@gmail.com> Date: Fri, 02 Dec 2011 23:37:37 +0100 Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:37:43 -0000 In your letter dated Sat, 03 Dec 2011 11:20:20 +1300 you wrote: >I wonder if you've just identified another reason for PMTUD >failures? A router that (correctly) drops PTB with a link local >source address would break PMTUD. Yes. Though there are also routers that are broken wrt Packet Too Big messages but send fine TTL execeed messages. I have to figure out what the vendor is. >> But for consistency >> reason I'd say, just keep the current rules and drop all such packets. >> It just violates ingress filtering if my routers would forward those packets >> to any of my LANs. > >If we go that way, there also needs to be a Router Requirement that >every router MUST have at least one GUA for use as the source address >in ICMPv6 messages. I think that's the best thing to do. In theory it should only be required if the router connects link with different MTUs. From Fred.L.Templin@boeing.com Fri Dec 2 14:47:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9F211E812D for ; Fri, 2 Dec 2011 14:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 GS95wdATYpfs for ; Fri, 2 Dec 2011 14:47:44 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id C67DE11E812A for ; Fri, 2 Dec 2011 14:47:44 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pB2MlYKA010644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2011 14:47:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id pB2Mlavh028907; Fri, 2 Dec 2011 16:47:36 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pB2MlYFW028862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 2 Dec 2011 16:47:35 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 2 Dec 2011 14:47:32 -0800 From: "Templin, Fred L" To: Philip Homburg , Brian E Carpenter Date: Fri, 2 Dec 2011 14:47:30 -0800 Thread-Topic: [v6ops] Routers forwarding packet with link local source Thread-Index: AcyxQwVHxuiX9LAFSRy1g4cPiey9CQAAOssg Message-ID: References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> 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: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:47:45 -0000 > I think that's the best thing to do. In theory it should only=20 > be required if > the router connects link with different MTUs. IMHO, I believe we will be seeing more and more of that as MTU diversity continues to proliferate. Fred= From jhw@apple.com Fri Dec 2 15:44:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F191F0C5D for ; Fri, 2 Dec 2011 15:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AcJLqtjLjuJM for ; Fri, 2 Dec 2011 15:44:55 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 147BA1F0C5A for ; Fri, 2 Dec 2011 15:44:55 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_USYKz/R9VqmXolDQp3wPWg)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LVL00CCWOM62001@mail-out.apple.com> for v6ops@ietf.org; Fri, 02 Dec 2011 15:44:42 -0800 (PST) X-AuditID: 11807136-b7c19ae0000072b0-58-4ed962ea812d Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id F2.84.29360.AE269DE4; Fri, 02 Dec 2011 15:44:42 -0800 (PST) From: james woodyatt In-reply-to: <4ED94F24.2060806@gmail.com> Date: Fri, 02 Dec 2011 15:44:42 -0800 Message-id: <7BF6404F-6794-44A6-B488-3BBE4E4324B1@apple.com> References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUieJDXQfdV0k0/g9Z3vBZtF/cxWZw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mro/f2VraBdvmLbwtlMDYzTpbsYOTkkBEwk Lnyewgxhi0lcuLeerYuRi0NIYDaTxMYp9xhBEsICrhJLn01mA7F5BYwl1tx6xwJiMwskSLR8 /AhmswmoSHy7fJepi5GDg1NAU+LD1ECQMAtQeNmaDnaQMDOQ/b+BH2KKjcS/W1NZQWwhgZ/M EudnaILYIkDTG7tOs0KcIy/R8vUO2wRGvllIFs9CshjC1pZYtvA18yywDToSkxcyogpD2B/P H2FawMi2ilGwKDUnsdLQVC+xoCAnVS85P3cTIyhAGwrNdjDu+Ct3iFGAg1GJh/em7E0/IdbE suLK3EOMEhzMSiK8gdJAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryHtl33ExJITyxJzU5NLUgt gskycXBKNTAuFnqyVHZ2Dout5a7V3m8+3RSc9+n/E2vDZUEFiftuP5wwO6pwV/feNTJ1FR8f 79l85u7HO/PYGY62vlSdfvtpg4nA6e2ec1Z93X3LvKJWpWThF4Ub+QpHT83XWPvo9orezvgP +gw3D0y0Zz9+2Vdtv0Z9xrSifVOe/5407URW6lVuzjMXDz+feUCJpTgj0VCLuag4EQBu5aob TAIAAA== Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 23:44:55 -0000 --Boundary_(ID_USYKz/R9VqmXolDQp3wPWg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Dec 2, 2011, at 14:20 , Brian E Carpenter wrote: > > If we go that way, there also needs to be a Router Requirement that every router MUST have at least one GUA for use as the source address in ICMPv6 messages. ULA will work as so long as the ICMPv6 message won't transit the DFZ. -- j h woodyatt --Boundary_(ID_USYKz/R9VqmXolDQp3wPWg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
If we go that = way, there also needs to be a Router Requirement that every router = MUST have at least one GUA for use as the source address in ICMPv6 = messages.

ULA will work as so = long as the ICMPv6 message won't transit the DFZ.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_USYKz/R9VqmXolDQp3wPWg)-- From fred@cisco.com Fri Dec 2 16:32:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD0611E8083 for ; Fri, 2 Dec 2011 16:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 5b1dvDg3J6Rc for ; Fri, 2 Dec 2011 16:32:27 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B571F11E807F for ; Fri, 2 Dec 2011 16:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2074; q=dns/txt; s=iport; t=1322872346; x=1324081946; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=v5NMY7smvrOjqLeWtnBihRF4MQR0h1Q1IQMf1ERWMFY=; b=OgGjmHg1gWNV8zWFUNAgJHZFEUEP2iBGc8fRUBz18sieJ97yDbYLHf0Q BtbIU34ltvHBe7kXj4xS67dkdm9FTFQuvLrhwRzYtFfRZ6VgSq+PdUqOm cSvnReO2H9djCmeYJfDKn+vApY+jcpa+cCcBN7hPW3cXjSRMtrOFSmOS8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGFt2U6rRDoI/2dsb2JhbAA5CqougQWCCwEngX01nniBJgGeLodtglFjBIgrjC+FRIxx X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="15775422" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Dec 2011 00:32:26 +0000 Received: from Freds-Computer.local ([10.21.73.10]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB30WQ1c025507 for ; Sat, 3 Dec 2011 00:32:26 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 02 Dec 2011 16:32:26 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 02 Dec 2011 16:32:26 -0800 From: Fred Baker Date: Fri, 2 Dec 2011 16:32:15 -0800 Message-Id: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6204bis progress and way forward X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 00:32:28 -0000 The following is a problem, a suggestion, and a question. As you know, I bcc'd a number of folks on an email asking what and when = we should do with this. Joel and I got a few over 50 emails in response. = I had given a number of possible options: deliver to IESG (Ron) in = December 2011, by IETF 83 (March), by IETF 84 (July), in the later half = of 2012, or in 2013. I got answers supporting each of those options. However, there were two predominant views. View (1) says that there is a = need to push 6204bis out in December; view (2) says the same but adds = that some pet point has to be addressed. Unfortunately, it's very = difficult for me to identify a consensus on the pet points - they are = themselves all over the map. Which leaves me with a quandary. The volume of email traffic, both on = v6ops@ and on the design team's lists, tells me that we're not done. But = at the same time, I see serious scope creep - "we want to wait until 4rd = is an RFC" and similar pet projects could take an arbitrary amount of = time. I feel that it is necessary to define a scope for the current = draft, and provide a game plan for updates to it relating to the various = projects. It seems to me that the best bet would be to define that 6204bis is = essentially the document we have now (updating 6204 to include 6rd and = ds-lite, and describing a generic CPE router without specific = accomodation of Cable, DSL, Fiber, or 3GPP), publish it as updating 6204 = (the IPv6-ready logo test depends on elements of both), and let future = small memos further update it with respect to their specific interests. = If, for example, 3GPP wants to have a document that significantly = differs and addresses the tethering mode of a handset, 3GPP can submit = one, we can discuss is, and push it through as an appropriate document = for 3GPP environments. Which raises interesting questions for LTE. We may also want to add the word "wireline" to the title to clarify that = we are doing this. What do people think about this approach?= From lorenzo@google.com Fri Dec 2 16:51:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39411E80E2 for ; Fri, 2 Dec 2011 16:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AJafQrHCcDQL for ; Fri, 2 Dec 2011 16:51:44 -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 DDCD011E8083 for ; Fri, 2 Dec 2011 16:51:43 -0800 (PST) Received: by yenl9 with SMTP id l9so2648114yen.31 for ; Fri, 02 Dec 2011 16:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=yDoZlgUzZ33gSYTkB1DGYfNNdZo2/L/Fnvrg3WNkPGc=; b=XunjJeEthkk4GcTMAcc3HNRzbsDPJVZNLIG3YV4XsMTp5/UsaKq4phDdZkU116rSdL anpy33IXIMm43D6WJzzA== Received: by 10.236.131.82 with SMTP id l58mr602520yhi.36.1322873503380; Fri, 02 Dec 2011 16:51:43 -0800 (PST) Received: by 10.236.131.82 with SMTP id l58mr602510yhi.36.1322873503268; Fri, 02 Dec 2011 16:51:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 16:51:22 -0800 (PST) In-Reply-To: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 16:51:22 -0800 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=20cf3011e2033ebe1f04b3257dce X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6204bis progress and way forward X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 00:51:44 -0000 --20cf3011e2033ebe1f04b3257dce Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 16:32, Fred Baker wrote: > It seems to me that the best bet would be to define that 6204bis is > essentially the document we have now (updating 6204 to include 6rd and > ds-lite, and describing a generic CPE router without specific accomodation > of Cable, DSL, Fiber, or 3GPP), publish it as updating 6204 (the IPv6-ready > logo test depends on elements of both), and let future small memos further > update it with respect to their specific interests. It seems to me that at the moment there are a couple things that aren't fully baked yet: transition coexistence (including sunsetting, etc.) and PCP. Wasn't the consensus in Montreal to proceed only with a small document containing only updates to WAN-side and LAN-side requirements and nothing else? --20cf3011e2033ebe1f04b3257dce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 16:32, Fred Baker <fred@cisco.com> wrote:
It seems to me that the best bet would be to define that 6204bis is essenti= ally the document we have now (updating 6204 to include 6rd and ds-lite, an= d describing a generic CPE router without specific accomodation of Cable, D= SL, Fiber, or 3GPP), publish it as updating 6204 (the IPv6-ready logo test = depends on elements of both), and let future small memos further update it = with respect to their specific interests.

It seems to me that at the moment there are a couple th= ings that aren't fully baked yet: transition coexistence (including sun= setting, etc.) and PCP.=A0Wasn't the consensus in Montreal to proceed o= nly with a small document containing only updates to WAN-side and LAN-side = requirements and nothing else?
--20cf3011e2033ebe1f04b3257dce-- From lorenzo@google.com Fri Dec 2 17:43:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290961F0C54 for ; Fri, 2 Dec 2011 17:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 nt6zK2i0vv7x for ; Fri, 2 Dec 2011 17:43:44 -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 E71051F0C49 for ; Fri, 2 Dec 2011 17:43:42 -0800 (PST) Received: by yenl9 with SMTP id l9so2667043yen.31 for ; Fri, 02 Dec 2011 17:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=SPsK2mLe4/WFJRMX0eb9yPdo45eNFPDAFDkLx3joKVc=; b=HCWk2m/NQp0CupidRm7tzi1DqQqzgBjj+cMbMeXAwWK2SKFnSU0Mi0UvYPBNftrlmz 3MKPePkl91zTn6MzehJg== Received: by 10.236.128.138 with SMTP id f10mr869510yhi.2.1322876622355; Fri, 02 Dec 2011 17:43:42 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr869497yhi.2.1322876622236; Fri, 02 Dec 2011 17:43:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 17:43:21 -0800 (PST) In-Reply-To: <4ED94F24.2060806@gmail.com> References: <4ECDB09E.2090807@gmail.com> <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 17:43:21 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf3005dd90266ab504b326379b X-System-Of-Record: true Cc: Philip Homburg , IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 01:43:45 -0000 --20cf3005dd90266ab504b326379b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 14:20, Brian E Carpenter wrote: > If we go that way, there also needs to be a Router Requirement that > every router MUST have at least one GUA for use as the source address > in ICMPv6 messages. I don't think you can mandate configuration issues in node requirements docs. A conforming router is still a conforming router even if nobody configures a global unicast address on it. --20cf3005dd90266ab504b326379b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 14:20, Brian E Carpenter = <brian.= e.carpenter@gmail.com> wrote:
If we go that way, there also needs to be a Router Requir= ement that
every router MUST have at least one GUA for use as the source address
in ICMPv6 messages.

I don't think you c= an mandate configuration issues in node requirements docs. A conforming rou= ter is still a conforming router even if nobody configures a global unicast= address on it.
--20cf3005dd90266ab504b326379b-- From fred@cisco.com Fri Dec 2 18:06:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F811F0C65 for ; Fri, 2 Dec 2011 18:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 Uh2OwSFD3ulV for ; Fri, 2 Dec 2011 18:06:35 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0E1F0C45 for ; Fri, 2 Dec 2011 18:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1163; q=dns/txt; s=iport; t=1322877995; x=1324087595; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Mv8ctNgloBeapGV3E+ZikX5wM3NBeoXbzLVyYXb6xwY=; b=ViXsJYsHnawUoTW466btfIcVCWFdTbiNmHrIYCOvMgBSFi4D5hKN72j5 x8Yzk2fJ5Atx9ap0xDpjxt5i0kK6GBa9dee//fO5VvGW4ABG6qzrv4v7B FLTP8zuMvTJNc2N5bL83b+iXXLOGw05IOVvF45yr7jmsUeGt16qnekokt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALuD2U6rRDoI/2dsb2JhbABEqi2BBYFyAQEBAQIBEgEnPwULCxguVwYTIodlmDMBniqKPmMEiCuML4VFjHE X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="15785771" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Dec 2011 02:06:34 +0000 Received: from Freds-Computer.local ([10.21.73.10]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB326YrI028619; Sat, 3 Dec 2011 02:06:34 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 02 Dec 2011 18:06:34 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 02 Dec 2011 18:06:34 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 2 Dec 2011 18:06:24 -0800 Message-Id: <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6204bis progress and way forward X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 02:06:35 -0000 On Dec 2, 2011, at 4:51 PM, Lorenzo Colitti wrote: > On Fri, Dec 2, 2011 at 16:32, Fred Baker wrote: > It seems to me that the best bet would be to define that 6204bis is = essentially the document we have now (updating 6204 to include 6rd and = ds-lite, and describing a generic CPE router without specific = accomodation of Cable, DSL, Fiber, or 3GPP), publish it as updating 6204 = (the IPv6-ready logo test depends on elements of both), and let future = small memos further update it with respect to their specific interests. >=20 > It seems to me that at the moment there are a couple things that = aren't fully baked yet: transition coexistence (including sunsetting, = etc.) and PCP. Wasn't the consensus in Montreal to proceed only with a = small document containing only updates to WAN-side and LAN-side = requirements and nothing else? Yes, but the discussion since added 6rd and ds-lite. That is required by = certain ISPs, and specifically the BBF and Cable Labs, for networks = using their technology. In addition, the PCP chairs tell us that = draft-ietf-pcp-base is headed to the IESG momentarily as well.= From gert@space.net Sat Dec 3 02:43:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32321F903B for ; Sat, 3 Dec 2011 02:43:50 -0800 (PST) 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 NpNIoCTFV9mn for ; Sat, 3 Dec 2011 02:43:49 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id C32ED21F8E70 for ; Sat, 3 Dec 2011 02:43:48 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 8AA5CF8929 for ; Sat, 3 Dec 2011 11:43:45 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5089AF893D for ; Sat, 3 Dec 2011 11:43:45 +0100 (CET) Received: (qmail 18291 invoked by uid 1007); 3 Dec 2011 11:43:45 +0100 Date: Sat, 3 Dec 2011 11:43:45 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20111203104345.GR72014@Space.Net> References: <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Philip Homburg , IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 10:43:50 -0000 Hi, On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote: > I don't think you can mandate configuration issues in node requirements > docs. A conforming router is still a conforming router even if nobody > configures a global unicast address on it. If the router is not able to send required ICMPv6 error messages, it's not a conforming router. And of course the vendors *could* enforce this - like in "ipv6 forwarding is not operational unless a GUA is configured on an interface (in the same routing context)". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From pch-b29AA871B@u-1.phicoh.com Sat Dec 3 04:52:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9D21F930E for ; Sat, 3 Dec 2011 04:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 bY+W+9kFL6G6 for ; Sat, 3 Dec 2011 04:52:39 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 888E321F9296 for ; Sat, 3 Dec 2011 04:52:39 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RWp51-0001j5C; Sat, 3 Dec 2011 13:52:35 +0100 Message-Id: To: Gert Doering From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <20111124125545.GW71280@Space.Net> <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com> <4ED94F24.2060806@gmail.com> <20111203104345.GR72014@Space.Net> In-reply-to: Your message of "Sat, 3 Dec 2011 11:43:45 +0100 ." <20111203104345.GR72014@Space.Net> Date: Sat, 03 Dec 2011 13:52:28 +0100 Cc: IPv6 Operations Subject: Re: [v6ops] Routers forwarding packet with link local source X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 12:52:40 -0000 In your letter dated Sat, 3 Dec 2011 11:43:45 +0100 you wrote: >And of course the vendors *could* enforce this - like in "ipv6 forwarding >is not operational unless a GUA is configured on an interface (in the >same routing context)". Yes, I was thinking the same thing. From shemant@cisco.com Sat Dec 3 05:10:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE09921F9278 for ; Sat, 3 Dec 2011 05:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 MbjeVWgVgnwm for ; Sat, 3 Dec 2011 05:10:41 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C5EC921F90E0 for ; Sat, 3 Dec 2011 05:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5926; q=dns/txt; s=iport; t=1322917840; x=1324127440; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=yKjMlyfI2gKY+je6I83dxVYPDS0EpksWQBR8f/ZEMGw=; b=dzdQ7ae4YCByT3u9oLJ9ceEygKD6oB/Ff+qCjMyrPlRBbUC5xSFp2yVy cmUTmhQ6DutCFY/lNAh6AKURBVdY6XSCWHcrgqs0ONqXek8ydad9dum8h A6kp92TT2sdEA4c2T8KQfZCDKVAvubrXOuIQRN6YBloACtuBg8dejvYLY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAABcf2k6tJXHA/2dsb2JhbABEgk2XOpAmgQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQBEggan2wBnX2KPmMEiC2eZg X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; d="scan'208,217";a="40858907" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 03 Dec 2011 13:10:35 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pB3DAZTv025046; Sat, 3 Dec 2011 13:10:35 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Dec 2011 07:10:35 -0600 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_01CCB1BC.F17845F1" Date: Sat, 3 Dec 2011 07:10:34 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377857E@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis progress and way forward Thread-Index: AcyxVdMrvda8LVIUTEiCh5/R81JArgAYPWyg References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Fred Baker (fred)" X-OriginalArrivalTime: 03 Dec 2011 13:10:35.0364 (UTC) FILETIME=[F1AEE240:01CCB1BC] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis progress and way forward X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 13:10:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB1BC.F17845F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Friday, December 02, 2011 7:51 PM To: Fred Baker (fred) Cc: v6ops@ietf.org WG Subject: Re: [v6ops] 6204bis progress and way forward =20 >It seems to me that at the moment there are a couple things that aren't fully baked yet: transition coexistence (including sunsetting, etc.) and PCP. Wasn't the consensus in >Montreal to proceed only with a small document containing only updates to WAN-side and LAN-side requirements and nothing else? =20 We may want to check the notes and audio from v6ops session in Quebec City because I heard that the transition tech from rfc6204bis at the time should move to a shorter new rfc6204bis document and then ship so that by mid 2012 one could get CPE to support transition tech in RFC form from 2011. The two transition tech that have been included in rfc6204bis for over one year are DS-Lite and 6rd. =20 Hemant ------_=_NextPart_001_01CCB1BC.F17845F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Lorenzo Colitti
Sent: Friday, = December 02, 2011 7:51 PM
To: Fred Baker (fred)
Cc: = v6ops@ietf.org = WG
Subject: Re: [v6ops] 6204bis progress and way = forward

 

>It seems to = me that at the moment there are a couple things that aren't fully baked = yet: transition coexistence (including sunsetting, etc.) and = PCP. Wasn't the consensus in >Montreal to proceed only with a small = document containing only updates to WAN-side and LAN-side requirements = and nothing else?

 

We may want to check the notes and audio from v6ops session in Quebec = City because I heard that the transition tech from rfc6204bis at the = time should move to a shorter new rfc6204bis document and then ship so = that by mid 2012 one could get CPE to support transition tech in RFC = form from 2011.  The two transition tech that have been included in = rfc6204bis for over one year are DS-Lite and = 6rd.

 

Hemant

------_=_NextPart_001_01CCB1BC.F17845F1-- From shemant@cisco.com Sat Dec 3 05:58:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7921F8551 for ; Sat, 3 Dec 2011 05:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iVCwjZeCtNto for ; Sat, 3 Dec 2011 05:58:27 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48F21F8545 for ; Sat, 3 Dec 2011 05:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9421; q=dns/txt; s=iport; t=1322920707; x=1324130307; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=gCcCxkCxevoaO8bi+W8+dyP/vrLHyZNA5vq5+h9XpxA=; b=WKeOkss8lB470DrXUlxtT+hAJPXVKLu4ZtExORnJVOuTN8ttrHyqz+a9 R5P9PrLozrncVmCU9juR9xFXnsAawNdmxEVpueMdE5J5oMeEmEWWvOCjX E4AvkHL7SiOtlaOZboArWuDzh0MQdFwcQ91NaWtlq0VzKxdTJekGqwedW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQAACoq2k6tJXG+/2dsb2JhbABEgk2XOpAmgQWBcgEBAQEDEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIARmHbZdnAZ18ij5jBIgtnmY X-IronPort-AV: E=Sophos;i="4.71,289,1320624000"; d="scan'208,217";a="40863294" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 03 Dec 2011 13:58:26 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB3DwPwQ025761; Sat, 3 Dec 2011 13:58:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Dec 2011 07:58:25 -0600 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_01CCB1C3.A0434041" Date: Sat, 3 Dec 2011 07:58:24 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com> In-Reply-To: <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis progress and way forward Thread-Index: AcyxYDYxzedJ3jBET9uPp3ThRTQpNwAXP0wg References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "Lorenzo Colitti" X-OriginalArrivalTime: 03 Dec 2011 13:58:25.0696 (UTC) FILETIME=[A088CA00:01CCB1C3] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis progress and way forward X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 13:58:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB1C3.A0434041 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Friday, December 02, 2011 9:06 PM To: Lorenzo Colitti Cc: v6ops@ietf.org WG Subject: Re: [v6ops] 6204bis progress and way forward =20 =20 >Yes, but the discussion since added 6rd and ds-lite. That is required by certain ISPs, and specifically the BBF and Cable >Labs, for networks using their technology. In addition, the PCP chairs tell us that draft-ietf-pcp-base is headed to the >IESG momentarily as well. =20 Right on PCP. The plan of record for the rfc6204bis document is to add a requirement for a PCP client on the CPE router WAN if the PCP base document heads to the IESG and/or the rfc6204bis document is in the IESG. Pending issues for rfc6204bis are outlined below. =20 1. 6rd sunsetting requirements on the CPE router are close to being complete. Will work with MarkT and the design team to close on this one when MarkT gets back from PTO.=20 2. Coexistence will add details for DS-Lite sunsetting and flush out any other details in Coexistence. Text has already been emailed to the design team and some DS-Lite interested parties. One of the authors of the DS-Lite RFC has also worked with myself and Wes to close on the DS-Lite sunsetting text. =20 3. We have responded to all of MarkT comments and some text (mostly minor) will change in the document from his comments. 4. The WPD-7 bullet in the document is not agreeable to some DHC folks and a discussion has been initiated in the DHC WG. Please see =20 http://www.ietf.org/mail-archive/web/dhcwg/current/msg12188.html =20 =20 Thanks, =20 Hemant ------_=_NextPart_001_01CCB1C3.A0434041 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred = Baker (fred)
Sent: Friday, December 02, 2011 9:06 PM
To: Lorenzo = Colitti
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] 6204bis = progress and way forward

 

 

>Yes, = but the discussion since added 6rd and ds-lite. That is required by = certain ISPs, and specifically the BBF and Cable >Labs, for networks = using their technology. In addition, the PCP chairs tell us that = draft-ietf-pcp-base is headed to the >IESG momentarily as = well.

 

Right on PCP.  The plan of record for the = rfc6204bis document is to add a requirement for a PCP client on the CPE = router WAN if the PCP base document heads to the IESG and/or the = rfc6204bis document is in the IESG.  Pending issues for rfc6204bis = are outlined below.

 

1.  = 6rd sunsetting requirements on the CPE router are = close to being complete.  Will work with MarkT and the design team = to close on this one when MarkT gets back from PTO. =

2.  = Coexistence will add details for DS-Lite sunsetting = and flush out any other details in Coexistence.  Text has already = been emailed to the design team and some DS-Lite interested = parties.  One of the authors of the DS-Lite RFC has also worked = with myself and Wes to close on the DS-Lite sunsetting text.  =

3.  = We have responded to all of MarkT comments and some = text (mostly minor) will change in the document from his = comments.

4.  = The WPD-7 bullet in the document is not agreeable to = some DHC folks and a discussion has been initiated in the DHC WG.  = Please see

 

     http://www.ietf.org/mail-archive/web/dhcwg/current/msg12188.html

 

 

Thanks,

 

Hemant

------_=_NextPart_001_01CCB1C3.A0434041-- From shemant@cisco.com Sat Dec 3 09:24:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FCC21F9279 for ; Sat, 3 Dec 2011 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jBHBAgj15siA for ; Sat, 3 Dec 2011 09:24:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2364521F917E for ; Sat, 3 Dec 2011 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7899; q=dns/txt; s=iport; t=1322933078; x=1324142678; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=0TUqro/iUylroAPLyeNJx9RnlUg08HnLmTAj7t4AvJU=; b=ewSb4esUBnakmoIwGCdUIwsqpj7Z/kjJZHMokg/OT7KlKmoPW+1/hdJD aSI+kouN8WGnqp6IMi6ZAk0pj2Ibw6vyMrOSFJFRCDBA2QXGd3YaRvyBc bzbLKj7q3Scg0qWQ8X1kiulbQdOdM6Afl/x/anV0gk78SxIZiCGv7cjZE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQAAGBa2k6tJV2a/2dsb2JhbABDgk2XO5AmgQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqfOAGdX4o+YwSILZ5m X-IronPort-AV: E=Sophos;i="4.71,290,1320624000"; d="scan'208,217";a="40888543" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Dec 2011 17:24:37 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB3HOb5o010668; Sat, 3 Dec 2011 17:24:37 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Dec 2011 11:24:37 -0600 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_01CCB1E0.6E623344" Date: Sat, 3 Dec 2011 11:24:35 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcyxQM0OjQ8lPzi6SO6iGLrjZrtTagAnVr9Q References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 03 Dec 2011 17:24:37.0410 (UTC) FILETIME=[6EA68820:01CCB1E0] Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:24:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB1E0.6E623344 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Friday, December 02, 2011 5:22 PM To: Hemant Singh (shemant) Cc: Ole Troan; Thomas Narten; v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt =20 =20 >That exactly the situation I object to. I think it's not OK to expect the RR to follow its default route to the excluded prefix. I think that for the sake of simplicity, the RR should >be free to install a discard route for the whole delegated prefix, regardless of the exclusion. Thus the text "explicitly given a route to the excluded prefix". =20 The exclude document says the DR is next-hop away from the RR and that is the case I was replying to including the response below. So now a question on RFC 3633. Does the RFC 3633 support RR and DR being more than one hop away? If yes, the I see Lorenzo's point. =20 If the RR and DR are directly connected, then the DR can send the RR a router advertisement containing a PIO with that /64 and the L=3D1 = (sorry, not O=3D1 as I said earlier). That counts as the RR being "explicitly given a route to the excluded prefix". =20 I am not talking about default route but default router. It is likely that the RR (if directly connected to the DR) will receive an RA from the DR before the RR starts forwarding any global IPv6 destined traffic out the RR interface facing the DR. Soon as the RR has received the RA, the RR knows it's default router is the DR and the RR learns the link-layer address from the RA (if the RA includes the SLLAO). Thus soon as routing decisions are completed inside the CPE router (the RR) to ship the packet out the CPE router WAN interface (RR interface facing the DR), next-hop forwarding uses the link-layer address of the default router to forward the packet to the default router. Note you are talking about a "default route" which is a L3 and routing concept but I am talking about a "default router" and IPv6 ND (RFC 4861). =20 =20 Hemant ------_=_NextPart_001_01CCB1E0.6E623344 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, = December 02, 2011 5:22 PM
To: Hemant Singh = (shemant)
Cc: Ole Troan; Thomas Narten; = v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6204bis-03.txt

 

 

>That exactly = the situation I object to. I think it's not OK to expect the RR to = follow its default route to the excluded prefix. I think that for the = sake of simplicity, the RR should >be free to install a discard route = for the whole delegated prefix, regardless of the exclusion. Thus the = text "explicitly given a route to the excluded = prefix".

 

The exclude document says the DR is next-hop away from the RR and = that is the case I was replying to including the response below.  = So now a question on RFC 3633.  Does the RFC 3633 support RR and DR = being more than one hop away?  If yes, the I see Lorenzo’s = point.

 

If the RR = and DR are directly connected, then the DR can send the RR a router = advertisement containing a PIO with that /64 and the L=3D1 (sorry, not = O=3D1 as I said earlier). That counts as the RR being "explicitly = given a route to the excluded prefix".

 

I am not talking about default route but default router. =   It is likely that the RR (if directly connected to the DR) = will receive an RA from the DR before the RR starts forwarding any = global IPv6 destined traffic out the RR interface facing the DR.  =  Soon as the RR has received the RA, the RR knows it’s = default router is the DR and the RR learns the link-layer address from = the RA (if the RA includes the SLLAO).  Thus soon as routing = decisions are completed inside the CPE router (the RR) to ship the = packet out the CPE router WAN interface (RR interface facing the DR), = next-hop forwarding uses the link-layer address of the default router to = forward the packet to the default router.    Note you are = talking about a “default route” which is a L3 and routing = concept but I am talking about a “default router” and IPv6 = ND (RFC 4861).   

 

Hemant

------_=_NextPart_001_01CCB1E0.6E623344-- From sander@steffann.nl Sat Dec 3 09:57:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689E221F917E for ; Sat, 3 Dec 2011 09:57:05 -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=[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 2Rt6Db0RauOT for ; Sat, 3 Dec 2011 09:57:05 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id AACD221F9118 for ; Sat, 3 Dec 2011 09:57:04 -0800 (PST) Received: from [IPv6:2001:610:6ce:1:69f0:f2c3:5163:9048] (unknown [IPv6:2001:610:6ce:1:69f0:f2c3:5163:9048]) by mail.sintact.nl (Postfix) with ESMTP id 066932002; Sat, 3 Dec 2011 18:57:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_948721DA-7287-4A27-BCE0-BA7D3A024308"; protocol="application/pkcs7-signature"; micalg=sha1 From: Sander Steffann In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> Date: Sat, 3 Dec 2011 18:57:00 +0100 Message-Id: <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1251.1) Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:57:05 -0000 --Apple-Mail=_948721DA-7287-4A27-BCE0-BA7D3A024308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, First I thought the exclude-prefix option was a good idea, but the more = I think about it the more I feel that other options might be a good = idea... Can't we just solve this by specifying something like 'The RR = MUST NOT use or delegate a prefix for which it has a route in its = routing table'? That would make sure that it doesn't use a prefix if it = is also used on the uplink to the ISP, but it would also allow for = someone to announce a prefix internally through OSPF, RIP, etc. and make = sure that the RR doesn't try to use the same prefix as well. One problem = I can see is that the RR might try to use a prefix when the other route = disappears for some time, so maybe we need to add 'The RR MUST (or = SHOULD?) not use or delegate a prefix for x time after the route(s) to = that prefix has been removed from the routing table'. So, basically: don't use prefixes that you see being used by someone = else, and add a safety margin after the route disappears in case it = comes back. I think it is sensible to do this anyway, and then the exclude-prefix = option might not be necessary. Sander --Apple-Mail=_948721DA-7287-4A27-BCE0-BA7D3A024308 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4 MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1 /SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE 74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMTEyMDMxNzU3MDFaMCMGCSqGSIb3DQEJBDEWBBQ8mvlccSBWbFH2WBoDFmfTLV+GzTCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG SIb3DQEBAQUABIGAJN5xuWCLcmD+8dAMfUB4baBdzpMCOhWXx6TRx8uQNeCowGgxG0O/PLSD26mh G3J4ODV/D66ZyFmzMDYv5/hmpjpHjssgBHp7igL6sL3QNk0xLJmLspPpCwb/+IvonyVyMlURjwp8 9DMvfdD1JMw4FS55QMqjzHki32tVdjxXJssAAAAAAAA= --Apple-Mail=_948721DA-7287-4A27-BCE0-BA7D3A024308-- From Ted.Lemon@nominum.com Sat Dec 3 11:16:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3AA21F8E50 for ; Sat, 3 Dec 2011 11:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IcqYFUm4KaK5 for ; Sat, 3 Dec 2011 11:16:00 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8E21F8E41 for ; Sat, 3 Dec 2011 11:16:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTtp1Y4LH7E+F4JILE8yjECQfF29w+h+5@postini.com; Sat, 03 Dec 2011 11:16:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5AA9D1B829F for ; Sat, 3 Dec 2011 11:15:47 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BA29B190052; Sat, 3 Dec 2011 11:15:44 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 11:15:44 -0800 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAACv8iA Date: Sat, 3 Dec 2011 19:15:44 +0000 Message-ID: <23B829DB-BEEF-4BC0-8304-5ECBA69E332E@nominum.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> In-Reply-To: <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_23B829DBBEEF4BC083045ECBA69E332Enominumcom_" MIME-Version: 1.0 Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 19:16:01 -0000 --_000_23B829DBBEEF4BC083045ECBA69E332Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 3, 2011, at 12:57 PM, Sander Steffann wrote: Can't we just solve this by specifying something like 'The RR MUST NOT use = or delegate a prefix for which it has a route in its routing table'? What happens if the RA arrives after the PD, and in the meantime the RR has= allocated that prefix to some downstream network? --_000_23B829DBBEEF4BC083045ECBA69E332Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2E7B9C1F12E8664EA1378108E8F1DF4B@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 3, 2011, at 12:57 PM, Sander Steffann wrote:
Can't we just solve this by specifying something like 'The RR MUST NOT use or de= legate a prefix for which it has a route in its routing table'?

What happens if the RA arrives after the PD, and in the meantime the R= R has allocated that prefix to some downstream network?

--_000_23B829DBBEEF4BC083045ECBA69E332Enominumcom_-- From sander@steffann.nl Sat Dec 3 11:22:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2A821F90E0 for ; Sat, 3 Dec 2011 11:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-1.904, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=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 oaSndnKpqiqR for ; Sat, 3 Dec 2011 11:22:30 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id BB2A621F9118 for ; Sat, 3 Dec 2011 11:22:29 -0800 (PST) Received: from [192.168.1.111] (dhcp-095-097-176-114.chello.nl [95.97.176.114]) by mail.sintact.nl (Postfix) with ESMTP id 8F7D32002; Sat, 3 Dec 2011 20:22:27 +0100 (CET) References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <23B829DB-BEEF-4BC0-8304-5ECBA69E332E@nominum.com> In-Reply-To: <23B829DB-BEEF-4BC0-8304-5ECBA69E332E@nominum.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2BAD22A3-F2F0-41D2-9126-6A8754B25D87 Message-Id: X-Mailer: iPhone Mail (9A405) From: Sander Steffann Date: Sat, 3 Dec 2011 20:22:24 +0100 To: Ted Lemon Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 19:22:33 -0000 --Apple-Mail-2BAD22A3-F2F0-41D2-9126-6A8754B25D87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmmm... The same as would happen when the DR starts excluding a prefix after= the RR starts using it I guess. Met vriendelijke groet, Sander Steffann Op 3 dec. 2011 om 20:15 heeft Ted Lemon het volgende= geschreven: > On Dec 3, 2011, at 12:57 PM, Sander Steffann wrote: >> Can't we just solve this by specifying something like 'The RR MUST NOT us= e or delegate a prefix for which it has a route in its routing table'? >=20 > What happens if the RA arrives after the PD, and in the meantime the RR ha= s allocated that prefix to some downstream network? >=20 --Apple-Mail-2BAD22A3-F2F0-41D2-9126-6A8754B25D87 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hmmm... The same as would happen when the DR starts excluding a prefix after the RR starts using it I guess.

Met vriendelijke groet,
Sander Steffann

Op 3 dec. 2011 om 20:15 heeft Ted Lemon <Ted.Lemon@nominum.com> het volgende geschreven:

On Dec 3, 2011, at 12:57 PM, Sander Steffann wrote:
Can't we just solve this by specifying something like 'The RR MUST NOT use or delegate a prefix for which it has a route in its routing table'?

What happens if the RA arrives after the PD, and in the meantime the RR has allocated that prefix to some downstream network?

--Apple-Mail-2BAD22A3-F2F0-41D2-9126-6A8754B25D87-- From Ted.Lemon@nominum.com Sat Dec 3 11:34:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47B21F8F78 for ; Sat, 3 Dec 2011 11:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 co6gj7GYkCmF for ; Sat, 3 Dec 2011 11:34:29 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4B21F8E81 for ; Sat, 3 Dec 2011 11:34:29 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTtp5xEMYOJ0467L/fQjRK08dy1P9arVo@postini.com; Sat, 03 Dec 2011 11:34:29 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3AA221B829F for ; Sat, 3 Dec 2011 11:34:28 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2D973190052; Sat, 3 Dec 2011 11:34:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 11:34:28 -0800 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAACv8iAAAA7wQAAAGtwgA== Date: Sat, 3 Dec 2011 19:34:27 +0000 Message-ID: <04A9751F-931D-4C27-875F-8CB63769A141@nominum.com> References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <23B829DB-BEEF-4BC0-8304-5ECBA69E332E@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_04A9751F931D4C27875F8CB63769A141nominumcom_" MIME-Version: 1.0 Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 19:34:30 -0000 --_000_04A9751F931D4C27875F8CB63769A141nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 3, 2011, at 2:22 PM, Sander Steffann wrote: Hmmm... The same as would happen when the DR starts excluding a prefix afte= r the RR starts using it I guess. The point is that if the PD option contains the prefix exclude option, ther= e's no window of opportunity for this mistake to occur. --_000_04A9751F931D4C27875F8CB63769A141nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B876A7CB019F642BA856AD028F5F9A0@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 3, 2011, at 2:22 PM, Sander Steffann wrote:
Hmmm... The same as would happen when the DR starts excluding a prefix= after the RR starts using it I guess.

The point is that if the PD option contains the prefix exclude option,= there's no window of opportunity for this mistake to occur.


--_000_04A9751F931D4C27875F8CB63769A141nominumcom_-- From sander@steffann.nl Sat Dec 3 11:38:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5390F21F8D8B for ; Sat, 3 Dec 2011 11:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=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 o2MAOaxKxvwM for ; Sat, 3 Dec 2011 11:38:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37021F8C61 for ; Sat, 3 Dec 2011 11:38:35 -0800 (PST) Received: from [192.168.1.111] (dhcp-095-097-176-114.chello.nl [95.97.176.114]) by mail.sintact.nl (Postfix) with ESMTP id AFA0F2002; Sat, 3 Dec 2011 20:38:34 +0100 (CET) References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <23B829DB-BEEF-4BC0-8304-5ECBA69E332E@nominum.com> <04A9751F-931D-4C27-8 75F-8CB63769A141@nominum.com> In-Reply-To: <04A9751F-931D-4C27-875F-8CB63769A141@nominum.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5EAD0038-3D88-4B02-81FB-2D3332D41502 Message-Id: <9A39C814-A70B-42C6-9CD2-1BDA65C300A0@steffann.nl> X-Mailer: iPhone Mail (9A405) From: Sander Steffann Date: Sat, 3 Dec 2011 20:38:32 +0100 To: Ted Lemon Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 19:38:36 -0000 --Apple-Mail-5EAD0038-3D88-4B02-81FB-2D3332D41502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> Hmmm... The same as would happen when the DR starts excluding a prefix af= ter the RR starts using it I guess. >=20 > The point is that if the PD option contains the prefix exclude option, the= re's no window of opportunity for this mistake to occur. No, what I meant is that the DR can suddenly start sending the prefix exclud= e option. Receiving an RA that you haven't seen before is the same as receiv= ing a prefix exclude option that you haven't seen before. Sander --Apple-Mail-5EAD0038-3D88-4B02-81FB-2D3332D41502 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi,

Hmmm... The same as would happen when the DR starts excluding a prefix after the RR starts using it I guess.

The point is that if the PD option contains the prefix exclude option, there's no window of opportunity for this mistake to occur.

No, what I meant is that the DR can suddenly start sending the prefix exclude option. Receiving an RA that you haven't seen before is the same as receiving a prefix exclude option that you haven't seen before.

Sander

--Apple-Mail-5EAD0038-3D88-4B02-81FB-2D3332D41502-- From Ted.Lemon@nominum.com Sat Dec 3 12:00:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6960F21F8E23 for ; Sat, 3 Dec 2011 12:00:01 -0800 (PST) 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.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hjaauWhJgFII for ; Sat, 3 Dec 2011 12:00:01 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id A401521F8DA0 for ; Sat, 3 Dec 2011 12:00:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTtp/s+1UJq0hfW2sjy/3gOK4tsuP1ouR@postini.com; Sat, 03 Dec 2011 12:00:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7581B1B82B3 for ; Sat, 3 Dec 2011 11:59:47 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 13CE8190052; Sat, 3 Dec 2011 11:59:46 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 11:59:46 -0800 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAACv8iAAAA7wQAAAGtwgAAAJM4AAAC9iwA= Date: Sat, 3 Dec 2011 19:59:45 +0000 Message-ID: <36E143E2-4393-4DC8-A7F4-FD2BA228A1DC@nominum.com> In-Reply-To: <9A39C814-A70B-42C6-9CD2-1BDA65C300A0@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_36E143E243934DC8A7F4FD2BA228A1DCnominumcom_" MIME-Version: 1.0 Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 20:00:01 -0000 --_000_36E143E243934DC8A7F4FD2BA228A1DCnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 3, 2011, at 2:38 PM, Sander Steffann wrote: No, what I meant is that the DR can suddenly start sending the prefix exclu= de option. Receiving an RA that you haven't seen before is the same as rece= iving a prefix exclude option that you haven't seen before. Yes, but that's not the intended use of the prefix exclude option. Wherea= s you are proposing that using RAs to exclude prefixes should be the intend= ed use. I think you make a valid point, but it's also a point that can ea= sily be addressed in the prefix-exclude option spec. --_000_36E143E243934DC8A7F4FD2BA228A1DCnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4ACC1B97DF453C47A8BF61D23CB1C6A6@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 3, 2011, at 2:38 PM, Sander Steffann wrote:
No, what I meant is that the DR can suddenly start sending the prefix exclude = option. Receiving an RA that you haven't seen before is the same as receivi= ng a prefix exclude option that you haven't seen before.

Yes, but that's not the intended use of the prefix exclude option. &nb= sp; Whereas you are proposing that using RAs to exclude prefixes should be = the intended use.   I think you make a valid point, but it's also a po= int that can easily be addressed in the prefix-exclude option spec.

--_000_36E143E243934DC8A7F4FD2BA228A1DCnominumcom_-- From Ray.Hunter@globis.net Sat Dec 3 12:04:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E3B21F8E4E for ; Sat, 3 Dec 2011 12:04:05 -0800 (PST) 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 YBWnjS2+SVYo for ; Sat, 3 Dec 2011 12:04:04 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id ED8BB21F8E49 for ; Sat, 3 Dec 2011 12:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 37AD38700F6; Sat, 3 Dec 2011 21:04:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntw71wdMOfl3; Sat, 3 Dec 2011 21:03:57 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 050E28700BC; Sat, 3 Dec 2011 21:03:57 +0100 (CET) Message-ID: <4EDA80AC.6030907@globis.net> Date: Sat, 03 Dec 2011 21:03:56 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Sander Steffann References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> In-Reply-To: <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> Content-Type: multipart/mixed; boundary="------------040705020707090806010401" X-Mailman-Approved-At: Sat, 03 Dec 2011 12:21:40 -0800 Cc: Thomas Narten , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 20:05:04 -0000 This is a multi-part message in MIME format. --------------040705020707090806010401 Content-Type: multipart/alternative; boundary="------------000707080402080008010003" --------------000707080402080008010003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit It's really not clear to me what pressing operational problem we're trying to fix here. Thinking about how this was done in IPv4 days, we pretty much used a separate range for the site uplink / isolation LAN, as the range for numbering within the site itself. The uplinks were normally RFC1918, but not always, and were sometimes GUA. The reason for the allocation of non-overlapping ranges was that if there were any operational filters to configure at the site entrance you'd want them to be simple to define. So if there was a range X in use on the LAN, none of the range X appeared outside the LAN (simplified access-list filters for accessing the console port, routing filters etc.) As has been pointed out already, it may be convenient in one place to be able to define a simple /48 in one place on the network e.g. that a contiguous /48 is seen via the downlink from the perspective of the delegating router, but in another place you may have to define a /47+/46+/45 etc to exclude 1 /64 from a /48 range (e.g. on the console port access list of the site router). Or else a deny Y/64, permit X/48 list at this point to only allow access from the LAN ranges. What's operationally wrong with continuing to use a separate non-overlapping range for the uplink as the site delegation, thus completely obviating the need for the new DHCP option in the first place? If the objection is routing table size, and you are delegating individual /64's, you can always ensure that the uplink is allocated from an adjacent /64 to one of teh delegated /64's. So that you have a /63 route on the delegating router a /64 assigned on the inter-router link, and a /64 delegated to the LAN, plus a /64 route pointing each way on the intermediate systems (if they aren't already known as being directly connected). If the objection is routing table size, and you are delegating a /48 to a site, you can ensure that all of the local uplinks on this concentrator are allocated a 64 from a contiguous /48 block, and perform local route aggregation in the concentrator. After all that device will anyway know all of the /64's used on the inter-router links as being directly connected. From a site perspective all that router requires is a single default route pointing at the uplink, so it doesn't need any detailed routes either. So what's the use case that's so tough that it requires a new DHCP option? regards, RayH Sander Steffann wrote: > Hi, > > First I thought the exclude-prefix option was a good idea, but the more I think about it the more I feel that other options might be a good idea... Can't we just solve this by specifying something like 'The RR MUST NOT use or delegate a prefix for which it has a route in its routing table'? That would make sure that it doesn't use a prefix if it is also used on the uplink to the ISP, but it would also allow for someone to announce a prefix internally through OSPF, RIP, etc. and make sure that the RR doesn't try to use the same prefix as well. One problem I can see is that the RR might try to use a prefix when the other route disappears for some time, so maybe we need to add 'The RR MUST (or SHOULD?) not use or delegate a prefix for x time after the route(s) to that prefix has been removed from the routing table'. > > So, basically: don't use prefixes that you see being used by someone else, and add a safety margin after the route disappears in case it comes back. > > I think it is sensible to do this anyway, and then the exclude-prefix option might not be necessary. > Sander > > -- Ray Hunter Ray.Hunter@globis.net Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL, Registered at the KvK, Eindhoven, under number BV 17098279 mobile: +31 620 363864 --------------000707080402080008010003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit It's really not clear to me what pressing operational problem we're trying to fix here.

Thinking about how this was done in IPv4 days, we pretty much used a separate range for the site uplink / isolation LAN, as the range for numbering within the site itself. The uplinks were normally RFC1918, but not always, and were sometimes GUA. The reason for the allocation of non-overlapping ranges was that if there were any operational filters to configure at the site entrance you'd want them to be simple to define. So if there was a range X in use on the LAN, none of the range X appeared outside the LAN (simplified access-list filters for accessing the console port, routing filters etc.)

As has been pointed out already, it may be convenient in one place to be able to define a simple /48 in one place on the network e.g. that a contiguous /48  is seen via the downlink from the perspective of the delegating router, but in another place you may have to define a /47+/46+/45 etc to exclude 1 /64 from a /48 range (e.g. on the console port access list of the site router). Or else a deny Y/64, permit X/48 list at this point to only allow access from the LAN ranges.

What's operationally wrong with continuing to use a separate non-overlapping range for the uplink as the site delegation, thus completely obviating the need for the new DHCP option in the first place?

If the objection is routing table size, and you are delegating individual /64's, you can always ensure that the uplink is allocated from an adjacent /64 to one of teh delegated /64's. So that you have a /63 route on the delegating router a /64 assigned on the inter-router link, and a /64 delegated to the LAN, plus a /64 route pointing each way on the intermediate systems (if they aren't already known as being directly connected).

If the objection is routing table size, and you are delegating a /48 to a site, you can ensure that all of the local uplinks on this concentrator are allocated a 64 from a contiguous /48 block, and perform local route aggregation in the concentrator. After all that device will anyway know all of the /64's used on the inter-router links as being directly connected. From a site perspective all that router requires is a single default route pointing at the uplink, so it doesn't need any detailed routes either.

So what's the use case that's so tough that it requires a new DHCP option?

regards,
RayH

Sander Steffann wrote: 
Hi,

First I thought the exclude-prefix option was a good idea, but the more I think about it the more I feel that other options might be a good idea... Can't we just solve this by specifying something like 'The RR MUST NOT use or delegate a prefix for which it has a route in its routing table'? That would make sure that it doesn't use a prefix if it is also used on the uplink to the ISP, but it would also allow for someone to announce a prefix internally through OSPF, RIP, etc. and make sure that the RR doesn't try to use the same prefix as well. One problem I can see is that the RR might try to use a prefix when the other route disappears for some time, so maybe we need to add 'The RR MUST (or SHOULD?) not use or delegate a prefix for x time after the route(s) to that prefix has been removed from the routing table'.

So, basically: don't use prefixes that you see being used by someone else, and add a safety margin after the route disappears in case it comes back.

I think it is sensible to do this anyway, and then the exclude-prefix option might not be necessary.
Sander

--
Ray Hunter
Ray.Hunter@globis.net
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

--------------000707080402080008010003-- --------------040705020707090806010401 Content-Type: text/x-vcard; charset=utf-8; name="Ray_Hunter.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Ray_Hunter.vcf" YmVnaW46dmNhcmQNCmZuOlJheSBIdW50ZXINCm46SHVudGVyO1JheQ0Kb3JnOkdsb2JpcyBD b25zdWx0aW5nIEJWDQphZHI6OztGYXphbnRsYWFuMjM7RWluZGhvdmVuOzs1NjEzQ0I7VGhl IE5ldGhlcmxhbmRzDQplbWFpbDtpbnRlcm5ldDpSYXkuSHVudGVyQGdsb2Jpcy5uZXQNCnRl bDtjZWxsOiszMSA2MjAgMzYzODY0DQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0KdXJsOmh0dHA6 Ly93d3cuZ2xvYmlzLm5ldA0KdmVyc2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------040705020707090806010401-- From Ted.Lemon@nominum.com Sat Dec 3 12:36:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5934D21F9380 for ; Sat, 3 Dec 2011 12:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wqfVApdt9-sw for ; Sat, 3 Dec 2011 12:36:37 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDD21F935B for ; Sat, 3 Dec 2011 12:36:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTtqISC++Hsc7ggkVFg6VU33zkPX8smis@postini.com; Sat, 03 Dec 2011 12:36:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 005121B82B3 for ; Sat, 3 Dec 2011 12:36:23 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5D925190052; Sat, 3 Dec 2011 12:36:21 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 12:36:21 -0800 From: Ted Lemon To: Ray Hunter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAAEbt8AAAEhrgA= Date: Sat, 3 Dec 2011 20:36:20 +0000 Message-ID: <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> In-Reply-To: <4EDA80AC.6030907@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_435BDEA75582418A842A607A37FDE96Cnominumcom_" MIME-Version: 1.0 Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 20:36:38 -0000 --_000_435BDEA75582418A842A607A37FDE96Cnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 3, 2011, at 3:03 PM, Ray Hunter wrote: So what's the use case that's so tough that it requires a new DHCP option? I think this is a bad question. New DHCP options are pretty simple to add= . If we anticipated PDx causing operational problems, then I think we'd w= ant to have a really clear and substantial set of use cases to justify the = work required to deal with these problems. But AFAIK PDx doesn't cause an= y such operational problems. Right now what I see is a debate between "we could do it this way, which do= esn't require PDx, or we could do it this way that does require PDx" and no= real argument other than "PDx is a new option, and new options are bad" fo= r why to prefer one over the other. So why the heavy pushback? Do you anticipate this option causing you some= problem? If so, it would be good to get that out on the table so we coul= d evaluate it. --_000_435BDEA75582418A842A607A37FDE96Cnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <86BB18F5502A0F4D81200D276CD11A43@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 3, 2011, at 3:03 PM, Ray Hunter wrote:
So what's the use case that's so tough that it requires a new DHCP option?

I think this is a bad question.   New DHCP options are pretty sim= ple to add.   If we anticipated PDx causing operational problems, then= I think we'd want to have a really clear and substantial set of use cases = to justify the work required to deal with these problems.   But AFAIK PDx doesn't cause any such operational pr= oblems.

Right now what I see is a debate between "we could do it this way= , which doesn't require PDx, or we could do it this way that does require P= Dx" and no real argument other than "PDx is a new option, and new= options are bad" for why to prefer one over the other.

So why the heavy pushback?   Do you anticipate this option causin= g you some problem?   If so, it would be good to get that out on the t= able so we could evaluate it.

--_000_435BDEA75582418A842A607A37FDE96Cnominumcom_-- From sander@steffann.nl Sat Dec 3 12:51:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594C421F9348 for ; Sat, 3 Dec 2011 12:51:14 -0800 (PST) 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=[AWL=-1.476, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrx3jp7z3svS for ; Sat, 3 Dec 2011 12:51:14 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBCD21F9354 for ; Sat, 3 Dec 2011 12:51:13 -0800 (PST) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id ABB282002; Sat, 3 Dec 2011 21:51:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_D148C014-D348-49A5-8767-60C4DB802721"; protocol="application/pkcs7-signature"; micalg=sha1 From: Sander Steffann In-Reply-To: <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> Date: Sat, 3 Dec 2011 21:51:11 +0100 Message-Id: References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FD E96C@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: Ray Hunter , Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 20:51:14 -0000 --Apple-Mail=_D148C014-D348-49A5-8767-60C4DB802721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ted, > Right now what I see is a debate between "we could do it this way, = which doesn't require PDx, or we could do it this way that does require = PDx" and no real argument other than "PDx is a new option, and new = options are bad" for why to prefer one over the other. I don't mind a new option if it helps some use cases. I do see other = problems, like an organisation making an addressing plan, and then = having one /64 excluded so that their internal aggregation plan suddenly = doesn't work anymore, but that is a generic problem with all these = exclude mechanisms and not specifically related to the new option. > So why the heavy pushback? Do you anticipate this option causing you = some problem? If so, it would be good to get that out on the table so = we could evaluate it. I just want to avoid ending up with multiple ways to do this. (for = example: I also don't like communicating DNS resolvers in both RA and = DHCP, and I get the feeling that we are creating more and more of these = overlaps.. But that is not the topic now) If we already have to exclude = certain prefixes in the RR because it already sees them in some other = protocol (OSPF, RIP, RA, ...) then explicitly sending an option that = tells the RR (a subset of) what it already should do anyway then I think = we create difficulties. If we can assume that extra signalling is = necessary to support those other protocols / because the other protocols = can't do it properly then I don't mind introducing this option at all. I = am just wondering if the assumption is valid. - Sander --Apple-Mail=_D148C014-D348-49A5-8767-60C4DB802721 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4 MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1 /SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE 74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMTEyMDMyMDUxMTJaMCMGCSqGSIb3DQEJBDEWBBS9esnFwnvJleWEBCOIFoa910HRGzCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG SIb3DQEBAQUABIGAg0MCEAGnLXi7V421xPW+ho7gJrElG0yei+Og70HpN/mGBjcdqI4yfgyhSc6q FwAccLZzO943w5ZrQdnI6ogl1/tSIIFfIiUch7GhiwDcmoxoqet0yShsK/63uLqbvl3wq7mOfpi2 1xZjEcviE+vpJw9OFC3pIbZRHrJOSynU4oUAAAAAAAA= --Apple-Mail=_D148C014-D348-49A5-8767-60C4DB802721-- From v6ops@globis.net Sat Dec 3 13:00:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE47F21F9295 for ; Sat, 3 Dec 2011 13:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ToOyezIQFP+b for ; Sat, 3 Dec 2011 13:00:42 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F88F21F9398 for ; Sat, 3 Dec 2011 13:00:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E302B8700BC; Sat, 3 Dec 2011 22:00:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdK0KIxHGXL9; Sat, 3 Dec 2011 22:00:33 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A05B7870081; Sat, 3 Dec 2011 22:00:33 +0100 (CET) Message-ID: <4EDA8DF0.7000803@globis.net> Date: Sat, 03 Dec 2011 22:00:32 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Ted Lemon References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> In-Reply-To: <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> Content-Type: multipart/alternative; boundary="------------070506070900080102080904" Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 21:00:43 -0000 This is a multi-part message in MIME format. --------------070506070900080102080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK Operationally speaking. Not technically. It may be easy to add a new DHCP option, but it has knock on impact elsewhere. IMHO If you delegate something across an AS boundary or other administrative boundary, you delegate all of it. It's the job of someone else to manage that resource from that point on. Delegating a range based on a single prefix on a bit boundary is easy for everyone. Examples: If I delegate a /48 to you as a customer to manage, except for 1 /64 that I as an ISP need to number the uplink, what happens when I want to renumber the uplink? Do I also have to renumber your LAN? What happens if I want to add a back up link to improve your service? Can I go back to you (my customer) and say "hang on a minute, you know I said you could use 65535/65536 of that /48, well actually I need one more /64 back from you, and it has to be this one" Same story for access lists. If you manage your site router, you'll probably want an access list on your site router saying "allow all local LAN nodes access to the router's web interface and none from the WAN side" That's easier if the delegated prefix is a single prefix based on a bit boundary. Same story for multi-homing without NAT. We all want an easily identifiable range on a bit boundary that says "customer nodes" You won't want to handle exceptions. Especially multiple exclusions. Same for abuse tracking. Same for reverse DNS delegation. Same for Homenet autoconfig. It's going to be a lot easier to spot the edge of the Homenet (the interface address is not assigned from the contiguous delegated prefix => WAN link) without having to deal with complex allow/ deny match lists. I just think this is looking to me like it is going to make life operationally harder, not easier. So that's why I'm trying to understand the use case. Because someone must have thought that this was a good idea. BTW I believe he.net operates this way (2 adjacent /64's for initial allocation, followed by an additional non-overlapping /48 if you request it) regards, RayH Ted Lemon wrote: > On Dec 3, 2011, at 3:03 PM, Ray Hunter wrote: >> So what's the use case that's so tough that it requires a new DHCP >> option? > > I think this is a bad question. New DHCP options are pretty simple > to add. If we anticipated PDx causing operational problems, then I > think we'd want to have a really clear and substantial set of use > cases to justify the work required to deal with these problems. But > AFAIK PDx doesn't cause any such operational problems. > > Right now what I see is a debate between "we could do it this way, > which doesn't require PDx, or we could do it this way that does > require PDx" and no real argument other than "PDx is a new option, and > new options are bad" for why to prefer one over the other. > > So why the heavy pushback? Do you anticipate this option causing you > some problem? If so, it would be good to get that out on the table > so we could evaluate it. > --------------070506070900080102080904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OK Operationally speaking. Not technically. It may be easy to add a new DHCP option, but it has knock on impact elsewhere.

IMHO If you delegate something across an AS boundary or other administrative boundary, you delegate all of it. It's the job of someone else to manage that resource from that point on. Delegating a range based on a single prefix on a bit boundary is easy for everyone.

Examples:

If I delegate a /48 to you as a customer to manage, except for 1 /64 that I as an ISP need to number the uplink, what happens when I want to renumber the uplink? Do I also have to renumber your LAN? What happens if I want to add a back up link to improve your service? Can I go back to you (my customer) and say "hang on a minute, you know I said you could use 65535/65536 of that /48, well actually I need one more /64 back from you, and it has to be this one"

Same story for access lists. If you manage your site router, you'll probably want an access list on your site router saying "allow all local LAN nodes access to the router's web interface and none from the WAN side" That's easier if the delegated prefix is a single prefix based on a bit boundary.

Same story for multi-homing without NAT. We all want an easily identifiable range on a bit boundary that says "customer nodes" You won't want to handle exceptions. Especially multiple exclusions.

Same for abuse tracking.

Same for reverse DNS delegation.

Same for Homenet autoconfig. It's going to be a lot easier to spot the edge of the Homenet (the interface address is not assigned from the contiguous delegated prefix => WAN link) without having to deal with complex allow/ deny match lists.

I just think this is looking to me like it is going to make life operationally harder, not easier.

So that's why I'm trying to understand the use case. Because someone must have thought that this was a good idea.

BTW I believe he.net operates this way (2 adjacent /64's for initial allocation, followed by an additional non-overlapping /48 if you request it)

regards,
RayH

Ted Lemon wrote:
On Dec 3, 2011, at 3:03 PM, Ray Hunter wrote:
So what's the use case that's so tough that it requires a new DHCP option?

I think this is a bad question.   New DHCP options are pretty simple to add.   If we anticipated PDx causing operational problems, then I think we'd want to have a really clear and substantial set of use cases to justify the work required to deal with these problems.   But AFAIK PDx doesn't cause any such operational problems.

Right now what I see is a debate between "we could do it this way, which doesn't require PDx, or we could do it this way that does require PDx" and no real argument other than "PDx is a new option, and new options are bad" for why to prefer one over the other.

So why the heavy pushback?   Do you anticipate this option causing you some problem?   If so, it would be good to get that out on the table so we could evaluate it.

--------------070506070900080102080904-- From Ted.Lemon@nominum.com Sat Dec 3 13:27:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCFE21F931D for ; Sat, 3 Dec 2011 13:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 VIcafb9zB57Z for ; Sat, 3 Dec 2011 13:27:33 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D621F9313 for ; Sat, 3 Dec 2011 13:27:32 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTtqUNJ5Gcjz5h94y6kGj3DWugH5J4Xri@postini.com; Sat, 03 Dec 2011 13:27:33 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2345C1B82B3 for ; Sat, 3 Dec 2011 13:27:16 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 80CBD190052; Sat, 3 Dec 2011 13:27:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 13:27:13 -0800 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAAEbt8AAAEhrgAAAITFgP//g/Tf Date: Sat, 3 Dec 2011 21:27:12 +0000 Message-ID: <658094C2-6C7F-4A02-A744-A0EA31B669CF@nominum.com> References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FD E96C@nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 21:27:33 -0000 On Dec 3, 2011, at 3:51 PM, "Sander Steffann" wrote: >> So why the heavy pushback? Do you anticipate this option causing you s= ome problem? If so, it would be good to get that out on the table so we c= ould evaluate it. >=20 > I just want to avoid ending up with multiple ways to do this. (for exampl= e: I also don't like communicating DNS resolvers in both RA and DHCP, and I= get the feeling that we are creating more and more of these overlaps.. But= that is not the topic now) If we already have to exclude certain prefixes= in the RR because it already sees them in some other protocol (OSPF, RIP, = RA, ...) then explicitly sending an option that tells the RR (a subset of) = what it already should do anyway then I think we create difficulties. If we= can assume that extra signalling is necessary to support those other proto= cols / because the other protocols can't do it properly then I don't mind i= ntroducing this option at all. I am just wondering if the assumption is val= id. The "don't want multiple ways to do this" argument has been used a bit, and= is somewhat compelling. However, in this case I don't think it's relevan= t, because multiple ways to do this are not being seriously proposed. One= way to do this is being proposed: PDx. Now a second way has been propose= d, which has serious problems and will not work: PD + RA. Since the secon= d solution won't work, there is no conflict here. You've proposed an alternative, which is to simply not do any sort of exclu= sion. That's fine=97we already know how to do this. I don't see PDx as = being in conflict with this, or as being another way to do the same thing, = though. Rather, PDx is a tool that can be used to implement a certain sor= t of address/route allocation strategy that some participants want. Peopl= e who don't want it aren't impacted, because PDx doesn't fundamentally chan= ge how routing is done: it simply provides a way to do a certain kind of ef= ficient prefix allocation strategy, which is then layered on the exact same= technology that would be used in your proposal. From sander@steffann.nl Sat Dec 3 13:42:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E621F935B for ; Sat, 3 Dec 2011 13:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.083 X-Spam-Level: ** X-Spam-Status: No, score=2.083 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, J_CHICKENPOX_26=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 uDDRIo+0vhMX for ; Sat, 3 Dec 2011 13:42:20 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 61D9A21F9357 for ; Sat, 3 Dec 2011 13:42:20 -0800 (PST) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 3B2BC2002; Sat, 3 Dec 2011 22:42:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_B5064C55-AABD-45A8-BE0A-37E0523A2448"; protocol="application/pkcs7-signature"; micalg=sha1 From: Sander Steffann In-Reply-To: <658094C2-6C7F-4A02-A744-A0EA31B669CF@nominum.com> Date: Sat, 3 Dec 2011 22:42:18 +0100 Message-Id: References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FD E96C@nominum.com>, <658094C2-6C7F-4A02-A744-A0EA31B669CF@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: Ray Hunter , Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 21:42:21 -0000 --Apple-Mail=_B5064C55-AABD-45A8-BE0A-37E0523A2448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ted, > The "don't want multiple ways to do this" argument has been used a = bit, and is somewhat compelling. However, in this case I don't think = it's relevant, because multiple ways to do this are not being seriously = proposed. One way to do this is being proposed: PDx. Now a second = way has been proposed, which has serious problems and will not work: PD = + RA. I also mentioned other protocols (OSPF etc) that can introduce = conflicts. There are other potential sources of conflicts besides = PD+uplink. > Since the second solution won't work, there is no conflict here. I still don't see why this doesn't work. Complete the RS/RA (and/or for = example OSPF) stuff before using the delegated prefix. I think that is = necessary anyway. > You've proposed an alternative, which is to simply not do any sort of = exclusion. That's fine=97we already know how to do this. I don't see = PDx as being in conflict with this, or as being another way to do the = same thing, though. Rather, PDx is a tool that can be used to = implement a certain sort of address/route allocation strategy that some = participants want. People who don't want it aren't impacted, because = PDx doesn't fundamentally change how routing is done: it simply provides = a way to do a certain kind of efficient prefix allocation strategy, = which is then layered on the exact same technology that would be used in = your proposal. I do think that excluding a prefix from a delegation by the upstream is = a bad idea. The more I think about this, the more I think this might = make the life of the ISP a bit easier while making the life of the = customer a lot harder... This is a decision that will be made by the = ISP, so maybe we should make it possible for them, so that they then can = consciously decide not to do it ;-) Met vriendelijke groet, Sander Steffann --Apple-Mail=_B5064C55-AABD-45A8-BE0A-37E0523A2448 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4 MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1 /SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE 74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMTEyMDMyMTQyMTlaMCMGCSqGSIb3DQEJBDEWBBR4CLzangavBPvTj0WHs2ARXQKNPzCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG SIb3DQEBAQUABIGAmRRrqIoT8PMBTYZdA+vjxCGk28Inob9xBpY5U/ZCFs1ucAJHibDbZfKUhzgx a1VXzOT6xkI3xH/QdjypFoP4sOgqBf0bQ26Uj1KMgH76NMZPdkAR47EMJ5H04vl6735wscPkz7We SddbdJL8Xd6xb+YQEvypWjmYJCMjd5xIIkcAAAAAAAA= --Apple-Mail=_B5064C55-AABD-45A8-BE0A-37E0523A2448-- From Ted.Lemon@nominum.com Sat Dec 3 13:45:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A703421F8D1F for ; Sat, 3 Dec 2011 13:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 MTTKggnmaLvQ for ; Sat, 3 Dec 2011 13:45:15 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECE21F8C54 for ; Sat, 3 Dec 2011 13:45:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTtqYa2JT5C3xo89YSe0WXS6YIKs1xgvQ@postini.com; Sat, 03 Dec 2011 13:45:15 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7E41F1B8299 for ; Sat, 3 Dec 2011 13:45:14 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 60A2A190052; Sat, 3 Dec 2011 13:45:14 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 13:45:14 -0800 From: Ted Lemon To: Ray Hunter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAAEbt8AAAEhrgAAANhdAP//hmAn Date: Sat, 3 Dec 2011 21:45:13 +0000 Message-ID: <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com>, <4EDA8DF0.7000803@globis.net> In-Reply-To: <4EDA8DF0.7000803@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 21:45:16 -0000 On Dec 3, 2011, at 4:00 PM, "Ray Hunter" wrote: > IMHO If you delegate something across an AS boundary or other administrat= ive boundary, you delegate all of it. It's the job of someone else to manag= e that resource from that point on. Delegating a range based on a single pr= efix on a bit boundary is easy for everyone. Sure. So is delegating fifteen prefixes. Which is really what PDx does = (in the case of a /60, for example). > If I delegate a /48 to you as a customer to manage, except for 1 /64 that= I as an ISP need to number the uplink, what happens when I want to renumbe= r the uplink? Do I also have to renumber your LAN? What happens if I want t= o add a back up link to improve your service? Can I go back to you (my cust= omer) and say "hang on a minute, you know I said you could use 65535/65536 = of that /48, well actually I need one more /64 back from you, and it has to= be this one" How would your life be operationally simpler if you hadn't used PDx? You'= ve got the same problem=97you've just pushed it into a different router. = Plus, the scenario you describe is absurdly unlikely, and since it's really= just a question of numbering two routers' interfaces, why not number both = of them from the same prefix that you already excluded? Why do you need t= o exclude a whole additional prefix for this? > Same story for access lists. If you manage your site router, you'll proba= bly want an access list on your site router saying "allow all local LAN nod= es access to the router's web interface and none from the WAN side" That's = easier if the delegated prefix is a single prefix based on a bit boundary. It's easier to type, sure. Are we seriously proposing that this be manage= d by manual configuration? If so, then I think it's a non-issue, since yo= u won't be using DHCP. > Same story for multi-homing without NAT. We all want an easily identifiab= le range on a bit boundary that says "customer nodes" You won't want to han= dle exceptions. Especially multiple exclusions. I can't even picture what you are talking about here. In the multi-homing= situation, you have two different administrative domains. You aren't goi= ng to have "an easily identifiable range on a bit boundary" anyway. > Same for abuse tracking. No, actually in this case the problem is exactly the same whether you use P= Dx or PD, since the entire prefix, including the excluded bit, is still ass= igned to the customer; the only difference is that in the PD case, you have= an additional prefix assigned to the customer outside of the delegated pre= fix that you also have to track. > Same for reverse DNS delegation. Here again, if you are typing a configuration into your DNS server, then ad= mittedly PDx is harder, but if you're doing that, you aren't doing dynamic = configuration, so it's not an issue we need to address here. > Same for Homenet autoconfig. It's going to be a lot easier to spot the ed= ge of the Homenet (the interface address is not assigned from the contiguou= s delegated prefix =3D> WAN link) without having to deal with complex allow= / deny match lists. Sorry, I really don't see the problem here. I think you are underestimati= ng the complexity of the homenet configuration that needs to be tracked. = We have decided that in the homenet case, the entire network configuration,= including routing, has to be managed automatically without user interventi= on. So keeping track of an excluded prefix is a trivial subset of the tot= al problem, and we needn't be concerned about it. > So that's why I'm trying to understand the use case. Because someone must= have thought that this was a good idea. Yes, 3gpp thinks it's a good idea, because it results in a cleaner address = space and routing infrastructure, and is easier to manage. > BTW I believe he.net operates this way (2 adjacent /64's for initial allo= cation, followed by an additional non-overlapping /48 if you request it. HE is doing manual allocation. You have to type in the prefixes. So thi= s isn't even remotely related to what we are talking about here. From Ted.Lemon@nominum.com Sat Dec 3 13:51:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CE621F9395 for ; Sat, 3 Dec 2011 13:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_26=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 XoixNOcWpjos for ; Sat, 3 Dec 2011 13:51:33 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id EDD9021F9388 for ; Sat, 3 Dec 2011 13:51:32 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTtqZ5HhoUXv9Xbm1W0mWxtY4MMFazJUp@postini.com; Sat, 03 Dec 2011 13:51:33 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A7BA21B829F for ; Sat, 3 Dec 2011 13:51:31 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 99074190052; Sat, 3 Dec 2011 13:51:31 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sat, 3 Dec 2011 13:51:31 -0800 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAASJBiAAAn82qAACQgjoAAAPv6AAABesoAADMgb4AAQSZsAAACOC+AAABL/4AAAHQUAAAAOdEAAAGZCoAAHEzLAAAP3emAAADMJYAAAYEyAAAAdukAAAGtKAAAADKDgAAp/r4AAAZu4AAAAVWJAAAEQd8AACfrXoAAASHUAAAEbt8AAAEhrgAAAITFgP//g/TfgACKVAD//3x3ew== Date: Sat, 3 Dec 2011 21:51:31 +0000 Message-ID: References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FD E96C@nominum.com>, <658094C2-6C7F-4A02-A744-A0EA31B669CF@nominum.com>, In-Reply-To: Accept-Language: en-US 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 Cc: Ray Hunter , Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 21:51:33 -0000 On Dec 3, 2011, at 4:42 PM, "Sander Steffann" wrote: > I also mentioned other protocols (OSPF etc) that can introduce conflicts.= There are other potential sources of conflicts besides PD+uplink. Okay, can you describe these conflicts? > I still don't see why this doesn't work. Complete the RS/RA (and/or for e= xample OSPF) stuff before using the delegated prefix. I think that is neces= sary anyway. If by "using" you mean "routing on", then yes, that's correct. However, i= f by "using" you mean "allocating from," then no, that is not correct. Yo= u can perfectly well allocate from a delegated prefix before all your routi= ng is set up, and there is no RFC of which I am aware that says you shouldn= 't. So we can expect to see this in the field. Furthermore, since we ha= ve a choice of routing protocols, as you have said, it's hard to see how th= ere could be an RFC that explains how to do this in a way that would reliab= ly result in independent, interoperating implementations. > I do think that excluding a prefix from a delegation by the upstream is a= bad idea. The more I think about this, the more I think this might make th= e life of the ISP a bit easier while making the life of the customer a lot = harder... This is a decision that will be made by the ISP, so maybe we shou= ld make it possible for them, so that they then can consciously decide not = to do it ;-) I think we should base whatever decision we make as much as possible on rea= l use cases and real problem scenarios, and not on intuition. My intuitio= n is that PDx makes everybody's life a lot easier, but clearly not everyone= 's intuition agrees with mine! From sander@steffann.nl Sat Dec 3 14:07:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7721F93AA for ; Sat, 3 Dec 2011 14:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.365 X-Spam-Level: ** X-Spam-Status: No, score=2.365 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, J_CHICKENPOX_26=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 OjAHnHNBc-c7 for ; Sat, 3 Dec 2011 14:07:16 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 983F721F93A7 for ; Sat, 3 Dec 2011 14:07:15 -0800 (PST) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id A176D2002; Sat, 3 Dec 2011 23:07:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_F0FC6A68-873E-4C57-951F-1ED70B4E8372"; protocol="application/pkcs7-signature"; micalg=sha1 From: Sander Steffann In-Reply-To: Date: Sat, 3 Dec 2011 23:07:11 +0100 Message-Id: <2B59A9DB-48BE-4DBB-9216-EB5262EC4796@steffann.nl> References: <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org> <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FD E96C@nominum.com>, <658094C2-6C7F-4A02-A744-A0EA31B669CF@nominum.com>, To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: Ray Hunter , Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 22:07:16 -0000 --Apple-Mail=_F0FC6A68-873E-4C57-951F-1ED70B4E8372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> I also mentioned other protocols (OSPF etc) that can introduce = conflicts. There are other potential sources of conflicts besides = PD+uplink. >=20 > Okay, can you describe these conflicts? Someone has a router behind the RR that has a manually configured prefix = and announces this prefix with (for example) OSPF. Reasons might be that = the RR can't re-delegate a prefix to the second router, that the second = router doesn't do DHCP-PD, or some other reason. I'm not saying that = this is proper network design, but the ISP using a sub-prefix from the = delegated prefix is not nice either :) >> I still don't see why this doesn't work. Complete the RS/RA (and/or = for example OSPF) stuff before using the delegated prefix. I think that = is necessary anyway. >=20 > If by "using" you mean "routing on", then yes, that's correct. = However, if by "using" you mean "allocating from," then no, that is not = correct. You can perfectly well allocate from a delegated prefix = before all your routing is set up, and there is no RFC of which I am = aware that says you shouldn't. So we can expect to see this in the = field. Furthermore, since we have a choice of routing protocols, as = you have said, it's hard to see how there could be an RFC that explains = how to do this in a way that would reliably result in independent, = interoperating implementations. Maybe we need to to write an RFC that says 'when receiving a DHCP-PD = prefix do not allocate from that prefix until all routing protocols are = running in a stable state (converged etc)'... >> I do think that excluding a prefix from a delegation by the upstream = is a bad idea. The more I think about this, the more I think this might = make the life of the ISP a bit easier while making the life of the = customer a lot harder... This is a decision that will be made by the = ISP, so maybe we should make it possible for them, so that they then can = consciously decide not to do it ;-) >=20 > I think we should base whatever decision we make as much as possible = on real use cases and real problem scenarios, and not on intuition. My = intuition is that PDx makes everybody's life a lot easier, but clearly = not everyone's intuition agrees with mine! True :-) Met vriendelijke groet, Sander Steffann --Apple-Mail=_F0FC6A68-873E-4C57-951F-1ED70B4E8372 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4 MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1 /SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE 74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMTEyMDMyMjA3MTJaMCMGCSqGSIb3DQEJBDEWBBTfWu7g6y3lqgVI+RntZEwvmR7lHDCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG SIb3DQEBAQUABIGAE7I0ZXFGtBGA8SZItws8hCirtAu5gCTOYjjE2Kz2PaCpWFYVEfFWdwP9hxrH YvUBF9qq33g3Ka/cLhV1J9BTdkP63DKU4hqsOXr0DQ2KYFclp/FC2yGoEvOj2Y841Nqs77EjuEmS GFQfej0rovoQugp74hgSXNVwOb6kbQGM3hsAAAAAAAA= --Apple-Mail=_F0FC6A68-873E-4C57-951F-1ED70B4E8372-- From v6ops@globis.net Sat Dec 3 14:53:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41521F93A8 for ; Sat, 3 Dec 2011 14:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 8iauKD4+Psqd for ; Sat, 3 Dec 2011 14:53:08 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1A21F939F for ; Sat, 3 Dec 2011 14:53:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BDC2087008A; Sat, 3 Dec 2011 23:53:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6sLgsaKEvDY; Sat, 3 Dec 2011 23:52:57 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C1C40870081; Sat, 3 Dec 2011 23:52:57 +0100 (CET) Message-ID: <4EDAA849.40208@globis.net> Date: Sat, 03 Dec 2011 23:52:57 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Ted Lemon References: <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org> <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org> <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com>, <4EDA8DF0.7000803@globis.net> <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> In-Reply-To: <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> Content-Type: multipart/alternative; boundary="------------070109010509080307000507" Cc: Thomas Narten , "" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 22:53:09 -0000 This is a multi-part message in MIME format. --------------070109010509080307000507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Answers inline. I won't debate further to reduce list noise. But I can tell you from long operational experience that any exclusion mechanism involving carving out a portion of a larger range by using a deny X permit Y mechanism will likely have significant operational impact elsewhere where ever there are prefix matching mechanisms used. They will possibly have to be re-written to take into account "deny prefix, permit prefix" instead of "permit prefix + permit prefix + permit prefix." Ted Lemon wrote: > On Dec 3, 2011, at 4:00 PM, "Ray Hunter" wrote: > >> > IMHO If you delegate something across an AS boundary or other administrative boundary, you delegate all of it. It's the job of someone else to manage that resource from that point on. Delegating a range based on a single prefix on a bit boundary is easy for everyone. >> > > Sure. So is delegating fifteen prefixes. Which is really what PDx does (in the case of a /60, for example). > > Partially agree. The code to handle the two cases is quite different. /48 minus /64 can be a lot more complex than multiple permit X x 64. This code might be implemented in any one of a number of languages (including SQL and regexp). I guess what I'm saying is that you should think very carefully before delegating 15 /64's in your numbering plan (whether automated or manually) in the first place, as it's likely going to cause problems elsewhere in operations. You might save one route per site, but explode your access lists and pattern match lists elsewhere (which can be computationally more expensive and difficult to write). >> > If I delegate a /48 to you as a customer to manage, except for 1 /64 that I as an ISP need to number the uplink, what happens when I want to renumber the uplink? Do I also have to renumber your LAN? What happens if I want to add a back up link to improve your service? Can I go back to you (my customer) and say "hang on a minute, you know I said you could use 65535/65536 of that /48, well actually I need one more /64 back from you, and it has to be this one" >> > > How would your life be operationally simpler if you hadn't used PDx? You've got the same problem—you've just pushed it into a different router. Plus, the scenario you describe is absurdly unlikely, and since it's really just a question of numbering two routers' interfaces, why not number both of them from the same prefix that you already excluded? Why do you need to exclude a whole additional prefix for this? > > It's what he.net use as their addressing model. One /64 for the WAN link and a /64 per customer with an /48 per customer. When a customer ask for an (additional) /48 or /64, the WAN link and any monitoring tools doesn't need renumbering. And in the case of the back up link, it will terminate on another concentrator router if it's a decent backup, which will almost certainly require another prefix. That then leaves an interesting question of where you'd inject a single /48 for reliable operations. The point is I have to predict and foresee all operational changes before I delegate the first time, whatever the cause of the change. Whereas if I just completely separate ISP WAN link ranges from Customer LAN link ranges, they are not operationally linked at all. I can enter my firewall rules in on day one, and they won't change (there's no automation from PD to firewall rules yet) I guess I'm not going to be a user of PDx, because I think it's going to make life harder. But it will mean that any tooling I write will have to take the permit/deny delegation model into account. >> > Same story for access lists. If you manage your site router, you'll probably want an access list on your site router saying "allow all local LAN nodes access to the router's web interface and none from the WAN side" That's easier if the delegated prefix is a single prefix based on a bit boundary. >> > > It's easier to type, sure. Are we seriously proposing that this be managed by manual configuration? If so, then I think it's a non-issue, since you won't be using DHCP. > > Disagree. It's a lot easier to add a one line of config permit blah, than work out an exception for deny one /64 out of a permit /48. Also during changes, finding related configuration to delete. You have to do VLSM / CIDR matching on access list config to find the associated deny rules. Not all of us are as smart as you. >> > Same story for multi-homing without NAT. We all want an easily identifiable range on a bit boundary that says "customer nodes" You won't want to handle exceptions. Especially multiple exclusions. >> > > I can't even picture what you are talking about here. In the multi-homing situation, you have two different administrative domains. You aren't going to have "an easily identifiable range on a bit boundary" anyway. > > You will have two easily identifiable ranges (one from each ISP).You may want to inject a route to the customers nodes numbered from ISP1 into ISP2. You will almost certainly not want to inject a route to ISP1's WAN link into ISP2. I think our life/architecture would be clearer if we acknowledged that an end-user site is effectively a stub AS. And if you connect your end-user site to two ISP's, it makes it a multi-homed AS, and you are crossing an AS boundary, whether you use BGP to do that or not. >> > Same for abuse tracking. >> > > No, actually in this case the problem is exactly the same whether you use PDx or PD, since the entire prefix, including the excluded bit, is still assigned to the customer; the only difference is that in the PD case, you have an additional prefix assigned to the customer outside of the delegated prefix that you also have to track. > > Partially disagree. You have the customer LAN delegated prefix + a single address of the customer's WAN router (which you know) You will probably not track abuse from your ISP operated concentrator router. Pattern matching in regexp is much easier on one /48 + one single address, than one /48 - one /64. >> > Same for reverse DNS delegation. >> > > Here again, if you are typing a configuration into your DNS server, then admittedly PDx is harder, but if you're doing that, you aren't doing dynamic configuration, so it's not an issue we need to address here. > > It isn't about typing in numbers. It's about access rights. Who has the rights to change the data? On which server is the data served? The ISP will almost certainly want to manage the WAN addresses. The customer may want to manage the LAN addresses (including dynamic DNS) Again this is about the number of entries required to generate a "prefix minus" type control. For a /48 minus a single /64, I'd have have to have a whole bunch of delegation entries for /47 /46 /45 /44 etc, because DNS delegation does not provide a "deny X permit Y" type delegation. I'm sure we'll identify other areas with similar limitations in the fullness of time. >> > Same for Homenet autoconfig. It's going to be a lot easier to spot the edge of the Homenet (the interface address is not assigned from the contiguous delegated prefix => WAN link) without having to deal with complex allow/ deny match lists. >> > > Sorry, I really don't see the problem here. I think you are underestimating the complexity of the homenet configuration that needs to be tracked. We have decided that in the homenet case, the entire network configuration, including routing, has to be managed automatically without user intervention. So keeping track of an excluded prefix is a trivial subset of the total problem, and we needn't be concerned about it. > > If you say so. I still think it's much easier to track a single delegated prefix than to track a delegated prefix minus exceptions (which may change). If you number the WAN link out of the customer's space, any WAN link renumbering (ISP change) will necessarily trigger a recompute of Homenet (LAN change). >> > So that's why I'm trying to understand the use case. Because someone must have thought that this was a good idea. >> > > Yes, 3gpp thinks it's a good idea, because it results in a cleaner address space and routing infrastructure, and is easier to manage. > > Still don't get this, but I'm not a 3gpp person. I'm presuming that "most people" will anyway be performing route aggregation at several points within their network, for scalability and stability reasons. All big networks I've worked on have done that. And if they didn't, they did once they had experienced their first serious outage due to flapping routes. >> > BTW I believe he.net operates this way (2 adjacent /64's for initial allocation, followed by an additional non-overlapping /48 if you request it. >> > > HE is doing manual allocation. You have to type in the prefixes. So this isn't even remotely related to what we are talking about here. > > Of course it is. PD does little more than automating a numbering plan. Whether you type it in manually or distribute that numbering plan via PD is largely irrelevant. Again, long experience with delegated numbering plans with distributed administration tells me to keep the delegation across admin boundaries clean and simple. It's a lot easier to track access rights to data if you do not have to track exclusions. Same with firewall rules. Whatever. YMMV. --------------070109010509080307000507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Answers inline. I won't debate further to reduce list noise.

But I can tell you from long operational experience that any exclusion mechanism involving carving out a portion of a larger range by using a deny X permit Y mechanism will likely have significant operational impact elsewhere where ever there are prefix matching mechanisms used. They will possibly have to be re-written to take into account "deny prefix, permit prefix" instead of "permit prefix + permit prefix + permit prefix."

Ted Lemon wrote: 
On Dec 3, 2011, at 4:00 PM, "Ray Hunter" <v6ops@globis.net> wrote:
  
> IMHO If you delegate something across an AS boundary or other administrative boundary, you delegate all of it. It's the job of someone else to manage that resource from that point on. Delegating a range based on a single prefix on a bit boundary is easy for everyone.
    

Sure.   So is delegating fifteen prefixes.   Which is really what PDx does (in the case of a /60, for example).
Partially agree. The code to handle the two cases is quite different. /48 minus /64 can be a lot more complex than multiple permit X x 64. This code might be implemented in any one of a number of languages (including SQL and regexp). I guess what I'm saying is that you should think very carefully before delegating 15 /64's in your numbering plan (whether automated or manually) in the first place, as it's likely going to cause problems elsewhere in operations. You might save one route per site, but explode your access lists and pattern match lists elsewhere (which can be computationally more expensive and difficult to write).

  

    
> If I delegate a /48 to you as a customer to manage, except for 1 /64 that I as an ISP need to number the uplink, what happens when I want to renumber the uplink? Do I also have to renumber your LAN? What happens if I want to add a back up link to improve your service? Can I go back to you (my customer) and say "hang on a minute, you know I said you could use 65535/65536 of that /48, well actually I need one more /64 back from you, and it has to be this one"
    

  

  

How would your life be operationally simpler if you hadn't used PDx?   You've got the same problem—you've just pushed it into a different router.   Plus, the scenario you describe is absurdly unlikely, and since it's really just a question of numbering two routers' interfaces, why not number both of them from the same prefix that you already excluded?   Why do you need to exclude a whole additional prefix for this?

  

  



It's what he.net use as their addressing model. One /64 for the WAN
link and a /64 per customer with an /48 per customer.

When a customer ask for an (additional) /48 or /64, the WAN link and
any monitoring tools doesn't need renumbering.



And in the case of the back up link, it will terminate on another
concentrator router if it's a decent backup, which will almost
certainly require another prefix. That then leaves an interesting
question of where you'd inject a single /48 for reliable operations.



The point is I have to predict and foresee all operational changes
before I delegate the first time, whatever the cause of the change.
Whereas if I just completely separate ISP WAN link ranges from Customer
LAN link ranges, they are not operationally linked at all. I can enter
my firewall rules in on day one, and they won't change (there's no
automation from PD to firewall rules yet)



I guess I'm not going to be a user of PDx, because I think it's going
to make life harder. But it will mean that any tooling I write will
have to take the permit/deny delegation model into account.



  

  

  

    
> Same story for access lists. If you manage your site router, you'll probably want an access list on your site router saying "allow all local LAN nodes access to the router's web interface and none from the WAN side" That's easier if the delegated prefix is a single prefix based on a bit boundary.
    

  

  

It's easier to type, sure.   Are we seriously proposing that this be managed by manual configuration?   If so, then I think it's a non-issue, since you won't be using DHCP.

  

  



Disagree. It's a lot easier to add a one line of config permit blah,
than work out an exception for deny one /64 out of a permit /48.

Also during changes, finding related configuration to delete. You have
to do VLSM / CIDR matching on access list config to find the associated
deny rules. Not all of us are as smart as you.



  

  

  

    
> Same story for multi-homing without NAT. We all want an easily identifiable range on a bit boundary that says "customer nodes" You won't want to handle exceptions. Especially multiple exclusions.
    

  

  

I can't even picture what you are talking about here.   In the multi-homing situation, you have two different administrative domains.   You aren't going to have "an easily identifiable range on a bit boundary" anyway.

  

  



You will have two easily identifiable ranges (one from each ISP).You
may want to inject a route to the customers nodes numbered from ISP1
into ISP2. You will almost certainly not want to inject a route to
ISP1's WAN link into ISP2. I think our life/architecture would be
clearer if we acknowledged that an end-user site is effectively a stub
AS. And if you connect your end-user site to two ISP's, it makes it a
multi-homed AS, and you are crossing an AS boundary, whether you use
BGP to do that or not.



  

  

  

    
> Same for abuse tracking.
    

  

  

No, actually in this case the problem is exactly the same whether you use PDx or PD, since the entire prefix, including the excluded bit, is still assigned to the customer; the only difference is that in the PD case, you have an additional prefix assigned to the customer outside of the delegated prefix that you also have to track.

  

  



Partially disagree. You have the customer LAN delegated prefix + a
single address of the customer's WAN router (which you know) You will
probably not track abuse from your ISP operated concentrator router.
Pattern matching in regexp is much easier on one /48 + one single
address, than one /48 - one /64.



  

  

  

    
> Same for reverse DNS delegation.
    

  

  

Here again, if you are typing a configuration into your DNS server, then admittedly PDx is harder, but if you're doing that, you aren't doing dynamic configuration, so it's not an issue we need to address here.

  

  



It isn't about typing in numbers. It's about access rights. Who has the
rights to change the data? On which server is the data served?



The ISP will almost certainly want to manage the WAN addresses. The
customer may want to manage the LAN addresses (including dynamic DNS)
Again this is about the number of entries required to generate a
"prefix minus" type control. For a /48 minus a single /64, I'd have
have to have a whole bunch of delegation entries for /47 /46 /45 /44
etc, because DNS delegation does not provide a "deny X permit Y" type
delegation. I'm sure we'll identify other areas with similar
limitations in the fullness of time.



  

  

  

    
> Same for Homenet autoconfig. It's going to be a lot easier to spot the edge of the Homenet (the interface address is not assigned from the contiguous delegated prefix => WAN link) without having to deal with complex allow/ deny match lists.
    

  

  

Sorry, I really don't see the problem here.   I think you are underestimating the complexity of the homenet configuration that needs to be tracked.   We have decided that in the homenet case, the entire network configuration, including routing, has to be managed automatically without user intervention.   So keeping track of an excluded prefix is a trivial subset of the total problem, and we needn't be concerned about it.

  

  



If you say so. I still think it's much easier to track a single
delegated prefix than to track a delegated prefix minus exceptions
(which may change). If you number the WAN link out of the customer's
space, any WAN link renumbering (ISP change) will necessarily trigger a
recompute of Homenet (LAN change). 



  

  

  

    
> So that's why I'm trying to understand the use case. Because someone must have thought that this was a good idea.
    

  

  

Yes, 3gpp thinks it's a good idea, because it results in a cleaner address space and routing infrastructure, and is easier to manage.

  

  



Still don't get this, but I'm not a 3gpp person. I'm presuming that
"most people" will anyway be performing route aggregation at several
points within their network, for scalability and stability reasons. All
big networks I've worked on have done that. And if they didn't, they
did once they had experienced their first serious outage due to
flapping routes.



  

  

  

    
> BTW I believe he.net operates this way (2 adjacent /64's for initial allocation, followed by an additional non-overlapping /48 if you request it.
    

  

  

HE is doing manual allocation.   You have to type in the prefixes.   So this isn't even remotely related to what we are talking about here.

  

  



Of course it is. PD does little more than automating a numbering plan.
Whether you type it in manually or distribute that numbering plan via
PD is largely irrelevant. Again, long experience with delegated
numbering plans with distributed administration tells me to keep the
delegation across admin boundaries clean and simple. It's a lot easier
to track access rights to data if you do not have to track exclusions.
Same with firewall rules. Whatever.



YMMV.




--------------070109010509080307000507--

From shemant@cisco.com  Sat Dec  3 16:00:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867D521F92E2 for ; Sat,  3 Dec 2011 16:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.547
X-Spam-Level: 
X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EHR8Lz7u2Nuj for ; Sat,  3 Dec 2011 16:00:02 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 44ED21F0C3F for ; Sat,  3 Dec 2011 16:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=28003; q=dns/txt; s=iport; t=1322956802; x=1324166402; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=/AU16XcmlKSSuNVTHATmdfYBF+K4SiNYJp+0eKiYGt8=; b=UZE/D1g7tHb6gT6pJd2HNeGMJ4qX5CX8hhWaAokV8k6FrczTel2unQZ5 PtPCQeFmBZguT2UpgsKJq355EeKbagVpZQyzN5CgTIi6s/hidBvr7bBum VWoQVMmv1fgTZ/4CPgxYUIlddPipQydyqY5RrUF3eIZTWRerDhJFiZWWK 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AAPy22k6tJXG+/2dsb2JhbAA6CoJNlzuQJ4EFgXIBAQEDARIBCREDSQULAgEIDgMBAwEBCwYFCwcBBgFFAwYIAQEEARIIEQmHZZdzAZ1ch20Tgj5jBIgtnmY
X-IronPort-AV: E=Sophos;i="4.71,291,1320624000"; d="scan'208,217";a="40925512"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 04 Dec 2011 00:00:01 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB4001GL027192;  Sun, 4 Dec 2011 00:00:01 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 3 Dec 2011 18:00:01 -0600
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_01CCB217.AAD660D5"
Date: Sat, 3 Dec 2011 17:59:59 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>
In-Reply-To: <4EDAA849.40208@globis.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: draft-ietf-dhc-pd-exclude
Thread-Index: AcyyDlzoV9av/RKyREKVMojxAlwJUAACGftQ
References: 		<748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>		<591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>		<399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org>			<5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com>		<5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com><88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl><4EDA80AC.6030907@globis.net><435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com>, <4EDA8DF0.7000803@globis.net><6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> <4EDAA849.40208@globis.net>
From: "Hemant Singh (shemant)" 
To: "Ray Hunter" , "Ted Lemon" 
X-OriginalArrivalTime: 04 Dec 2011 00:00:01.0002 (UTC) FILETIME=[AB0364A0:01CCB217]
Cc: Thomas Narten , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 00:00:08 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB217.AAD660D5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It's high time the subject of the email changed to the pd-exclude
document rather than the rfc6204bis document for which the ship has
sailed to include the pd-exclude in.   That said, one question I had was
this.   How are network interfaces setup on the DR that is sending an RA
with one exclude prefix if the DR has 20K different IPV6 CE routers  as
RR's?  The RA is multicast and, say, reaches 40K CE routers.   How is
the exclude prefix working with the multicast RA?

=20

Hemant

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Ray Hunter
Sent: Saturday, December 03, 2011 5:53 PM
To: Ted Lemon
Cc: Thomas Narten; 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

=20

Answers inline. I won't debate further to reduce list noise.

But I can tell you from long operational experience that any exclusion
mechanism involving carving out a portion of a larger range by using a
deny X permit Y mechanism will likely have significant operational
impact elsewhere where ever there are prefix matching mechanisms used.
They will possibly have to be re-written to take into account "deny
prefix, permit prefix" instead of "permit prefix + permit prefix +
permit prefix."

Ted Lemon wrote:=20

On Dec 3, 2011, at 4:00 PM, "Ray Hunter" 
  wrote:
 =20

	> IMHO If you delegate something across an AS boundary or other
administrative boundary, you delegate all of it. It's the job of someone
else to manage that resource from that point on. Delegating a range
based on a single prefix on a bit boundary is easy for everyone.
	   =20

=20
Sure.   So is delegating fifteen prefixes.   Which is really what PDx
does (in the case of a /60, for example).
=20
 =20

Partially agree. The code to handle the two cases is quite different.
/48 minus /64 can be a lot more complex than multiple permit X x 64.
This code might be implemented in any one of a number of languages
(including SQL and regexp). I guess what I'm saying is that you should
think very carefully before delegating 15 /64's in your numbering plan
(whether automated or manually) in the first place, as it's likely going
to cause problems elsewhere in operations. You might save one route per
site, but explode your access lists and pattern match lists elsewhere
(which can be computationally more expensive and difficult to write).



	> If I delegate a /48 to you as a customer to manage, except for
1 /64 that I as an ISP need to number the uplink, what happens when I
want to renumber the uplink? Do I also have to renumber your LAN? What
happens if I want to add a back up link to improve your service? Can I
go back to you (my customer) and say "hang on a minute, you know I said
you could use 65535/65536 of that /48, well actually I need one more /64
back from you, and it has to be this one"
	   =20

=20
How would your life be operationally simpler if you hadn't used PDx?
You've got the same problem-you've just pushed it into a different
router.   Plus, the scenario you describe is absurdly unlikely, and
since it's really just a question of numbering two routers' interfaces,
why not number both of them from the same prefix that you already
excluded?   Why do you need to exclude a whole additional prefix for
this?
=20
 =20

It's what he.net use as their addressing model. One /64 for the WAN link
and a /64 per customer with an /48 per customer.
When a customer ask for an (additional) /48 or /64, the WAN link and any
monitoring tools doesn't need renumbering.

And in the case of the back up link, it will terminate on another
concentrator router if it's a decent backup, which will almost certainly
require another prefix. That then leaves an interesting question of
where you'd inject a single /48 for reliable operations.

The point is I have to predict and foresee all operational changes
before I delegate the first time, whatever the cause of the change.
Whereas if I just completely separate ISP WAN link ranges from Customer
LAN link ranges, they are not operationally linked at all. I can enter
my firewall rules in on day one, and they won't change (there's no
automation from PD to firewall rules yet)

I guess I'm not going to be a user of PDx, because I think it's going to
make life harder. But it will mean that any tooling I write will have to
take the permit/deny delegation model into account.



	> Same story for access lists. If you manage your site router,
you'll probably want an access list on your site router saying "allow
all local LAN nodes access to the router's web interface and none from
the WAN side" That's easier if the delegated prefix is a single prefix
based on a bit boundary.
	   =20

=20
It's easier to type, sure.   Are we seriously proposing that this be
managed by manual configuration?   If so, then I think it's a non-issue,
since you won't be using DHCP.
=20
 =20

Disagree. It's a lot easier to add a one line of config permit blah,
than work out an exception for deny one /64 out of a permit /48.
Also during changes, finding related configuration to delete. You have
to do VLSM / CIDR matching on access list config to find the associated
deny rules. Not all of us are as smart as you.



	> Same story for multi-homing without NAT. We all want an easily
identifiable range on a bit boundary that says "customer nodes" You
won't want to handle exceptions. Especially multiple exclusions.
	   =20

=20
I can't even picture what you are talking about here.   In the
multi-homing situation, you have two different administrative domains.
You aren't going to have "an easily identifiable range on a bit
boundary" anyway.
=20
 =20

You will have two easily identifiable ranges (one from each ISP).You may
want to inject a route to the customers nodes numbered from ISP1 into
ISP2. You will almost certainly not want to inject a route to ISP1's WAN
link into ISP2. I think our life/architecture would be clearer if we
acknowledged that an end-user site is effectively a stub AS. And if you
connect your end-user site to two ISP's, it makes it a multi-homed AS,
and you are crossing an AS boundary, whether you use BGP to do that or
not.



	> Same for abuse tracking.
	   =20

=20
No, actually in this case the problem is exactly the same whether you
use PDx or PD, since the entire prefix, including the excluded bit, is
still assigned to the customer; the only difference is that in the PD
case, you have an additional prefix assigned to the customer outside of
the delegated prefix that you also have to track.
=20
 =20

Partially disagree. You have the customer LAN delegated prefix + a
single address of the customer's WAN router (which you know) You will
probably not track abuse from your ISP operated concentrator router.
Pattern matching in regexp is much easier on one /48 + one single
address, than one /48 - one /64.



	> Same for reverse DNS delegation.
	   =20

=20
Here again, if you are typing a configuration into your DNS server, then
admittedly PDx is harder, but if you're doing that, you aren't doing
dynamic configuration, so it's not an issue we need to address here.
=20
 =20

It isn't about typing in numbers. It's about access rights. Who has the
rights to change the data? On which server is the data served?

The ISP will almost certainly want to manage the WAN addresses. The
customer may want to manage the LAN addresses (including dynamic DNS)
Again this is about the number of entries required to generate a "prefix
minus" type control. For a /48 minus a single /64, I'd have have to have
a whole bunch of delegation entries for /47 /46 /45 /44 etc, because DNS
delegation does not provide a "deny X permit Y" type delegation. I'm
sure we'll identify other areas with similar limitations in the fullness
of time.



	> Same for Homenet autoconfig. It's going to be a lot easier to
spot the edge of the Homenet (the interface address is not assigned from
the contiguous delegated prefix =3D> WAN link) without having to deal =
with
complex allow/ deny match lists.
	   =20

=20
Sorry, I really don't see the problem here.   I think you are
underestimating the complexity of the homenet configuration that needs
to be tracked.   We have decided that in the homenet case, the entire
network configuration, including routing, has to be managed
automatically without user intervention.   So keeping track of an
excluded prefix is a trivial subset of the total problem, and we needn't
be concerned about it.
=20
 =20

If you say so. I still think it's much easier to track a single
delegated prefix than to track a delegated prefix minus exceptions
(which may change). If you number the WAN link out of the customer's
space, any WAN link renumbering (ISP change) will necessarily trigger a
recompute of Homenet (LAN change).=20



	> So that's why I'm trying to understand the use case. Because
someone must have thought that this was a good idea.
	   =20

=20
Yes, 3gpp thinks it's a good idea, because it results in a cleaner
address space and routing infrastructure, and is easier to manage.
=20
 =20

Still don't get this, but I'm not a 3gpp person. I'm presuming that
"most people" will anyway be performing route aggregation at several
points within their network, for scalability and stability reasons. All
big networks I've worked on have done that. And if they didn't, they did
once they had experienced their first serious outage due to flapping
routes.



	> BTW I believe he.net operates this way (2 adjacent /64's for
initial allocation, followed by an additional non-overlapping /48 if you
request it.
	   =20

=20
HE is doing manual allocation.   You have to type in the prefixes.   So
this isn't even remotely related to what we are talking about here.
=20
 =20

Of course it is. PD does little more than automating a numbering plan.
Whether you type it in manually or distribute that numbering plan via PD
is largely irrelevant. Again, long experience with delegated numbering
plans with distributed administration tells me to keep the delegation
across admin boundaries clean and simple. It's a lot easier to track
access rights to data if you do not have to track exclusions. Same with
firewall rules. Whatever.

YMMV.


------_=_NextPart_001_01CCB217.AAD660D5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


It’s high time the subject of the email changed to the =
pd-exclude document rather than the rfc6204bis document for which the =
ship has sailed to include the pd-exclude in.   That said, one =
question I had was this.   How are network interfaces setup on =
the DR that is sending an RA with one exclude prefix if the DR has 20K =
different IPV6 CE routers  as RR’s?  The RA is multicast =
and, say, reaches 40K CE routers.   How is the exclude prefix =
working with the multicast RA?
 
Hemant
 
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf Of Ray Hunter
Sent: Saturday, December 03, 2011 =
5:53 PM
To: Ted Lemon
Cc: Thomas Narten; =
<v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: =
draft-ietf-v6ops-6204bis-03.txt
 
Answers =
inline. I won't debate further to reduce list noise.

But I can =
tell you from long operational experience that any exclusion mechanism =
involving carving out a portion of a larger range by using a deny X =
permit Y mechanism will likely have significant operational impact =
elsewhere where ever there are prefix matching mechanisms used. They =
will possibly have to be re-written to take into account "deny =
prefix, permit prefix" instead of "permit prefix + permit =
prefix + permit prefix."

Ted Lemon wrote: =

On Dec 3, 2011, at 4:00 PM, "Ray =
Hunter" <v6ops@globis.net> =
wrote:
  
> IMHO If you delegate something =
across an AS boundary or other administrative boundary, you delegate all =
of it. It's the job of someone else to manage that resource from that =
point on. Delegating a range based on a single prefix on a bit boundary =
is easy for everyone.
    =

 
Sure. =
;  So is delegating fifteen prefixes.   Which is really =
what PDx does (in the case of a /60, for =
example).
 
  =

Partially agree. The code to =
handle the two cases is quite different. /48 minus /64 can be a lot more =
complex than multiple permit X x 64. This code might be implemented in =
any one of a number of languages (including SQL and regexp). I guess =
what I'm saying is that you should think very carefully before =
delegating 15 /64's in your numbering plan (whether automated or =
manually) in the first place, as it's likely going to cause problems =
elsewhere in operations. You might save one route per site, but explode =
your access lists and pattern match lists elsewhere (which can be =
computationally more expensive and difficult to =
write).

> If I delegate a /48 to you as a =
customer to manage, except for 1 /64 that I as an ISP need to number the =
uplink, what happens when I want to renumber the uplink? Do I also have =
to renumber your LAN? What happens if I want to add a back up link to =
improve your service? Can I go back to you (my customer) and say =
"hang on a minute, you know I said you could use 65535/65536 of =
that /48, well actually I need one more /64 back from you, and it has to =
be this one"
    =

 
How would =
your life be operationally simpler if you hadn't used PDx?   =
You've got the same problem—you've just pushed it into a different =
router.   Plus, the scenario you describe is absurdly =
unlikely, and since it's really just a question of numbering two =
routers' interfaces, why not number both of them from the same prefix =
that you already excluded?   Why do you need to exclude a =
whole additional prefix for =
this?
 
  =

It's what he.net use as =
their addressing model. One /64 for the WAN link and a /64 per customer =
with an /48 per customer.
When a customer ask for an (additional) /48 =
or /64, the WAN link and any monitoring tools doesn't need =
renumbering.

And in the case of the back up link, it will =
terminate on another concentrator router if it's a decent backup, which =
will almost certainly require another prefix. That then leaves an =
interesting question of where you'd inject a single /48 for reliable =
operations.

The point is I have to predict and foresee all =
operational changes before I delegate the first time, whatever the cause =
of the change. Whereas if I just completely separate ISP WAN link ranges =
from Customer LAN link ranges, they are not operationally linked at all. =
I can enter my firewall rules in on day one, and they won't change =
(there's no automation from PD to firewall rules yet)

I guess I'm =
not going to be a user of PDx, because I think it's going to make life =
harder. But it will mean that any tooling I write will have to take the =
permit/deny delegation model into =
account.

> Same story for access lists. If you =
manage your site router, you'll probably want an access list on your =
site router saying "allow all local LAN nodes access to the =
router's web interface and none from the WAN side" That's easier if =
the delegated prefix is a single prefix based on a bit =
boundary.
    =

 
It's =
easier to type, sure.   Are we seriously proposing that this =
be managed by manual configuration?   If so, then I think it's =
a non-issue, since you won't be using =
DHCP.
 
  =

Disagree. It's a lot easier =
to add a one line of config permit blah, than work out an exception for =
deny one /64 out of a permit /48.
Also during changes, finding =
related configuration to delete. You have to do VLSM / CIDR matching on =
access list config to find the associated deny rules. Not all of us are =
as smart as you.

> Same story for multi-homing without =
NAT. We all want an easily identifiable range on a bit boundary that =
says "customer nodes" You won't want to handle exceptions. =
Especially multiple exclusions.
    =

 
I can't =
even picture what you are talking about here.   In the =
multi-homing situation, you have two different administrative =
domains.   You aren't going to have "an easily =
identifiable range on a bit boundary" =
anyway.
 
  =

You will have two easily =
identifiable ranges (one from each ISP).You may want to inject a route =
to the customers nodes numbered from ISP1 into ISP2. You will almost =
certainly not want to inject a route to ISP1's WAN link into ISP2. I =
think our life/architecture would be clearer if we acknowledged that an =
end-user site is effectively a stub AS. And if you connect your end-user =
site to two ISP's, it makes it a multi-homed AS, and you are crossing an =
AS boundary, whether you use BGP to do that or =
not.

> Same for abuse =
tracking.
    =

 
No, =
actually in this case the problem is exactly the same whether you use =
PDx or PD, since the entire prefix, including the excluded bit, is still =
assigned to the customer; the only difference is that in the PD case, =
you have an additional prefix assigned to the customer outside of the =
delegated prefix that you also have to =
track.
 
  =

Partially disagree. You have =
the customer LAN delegated prefix + a single address of the customer's =
WAN router (which you know) You will probably not track abuse from your =
ISP operated concentrator router. Pattern matching in regexp is much =
easier on one /48 + one single address, than one /48 - one =
/64.

> Same for reverse DNS =
delegation.
    =

 
Here =
again, if you are typing a configuration into your DNS server, then =
admittedly PDx is harder, but if you're doing that, you aren't doing =
dynamic configuration, so it's not an issue we need to address =
here.
 
  =

It isn't about typing in =
numbers. It's about access rights. Who has the rights to change the =
data? On which server is the data served?

The ISP will almost =
certainly want to manage the WAN addresses. The customer may want to =
manage the LAN addresses (including dynamic DNS) Again this is about the =
number of entries required to generate a "prefix minus" type =
control. For a /48 minus a single /64, I'd have have to have a whole =
bunch of delegation entries for /47 /46 /45 /44 etc, because DNS =
delegation does not provide a "deny X permit Y" type =
delegation. I'm sure we'll identify other areas with similar limitations =
in the fullness of time.

> Same for Homenet autoconfig. It's =
going to be a lot easier to spot the edge of the Homenet (the interface =
address is not assigned from the contiguous delegated prefix =3D> WAN =
link) without having to deal with complex allow/ deny match =
lists.
    =

 
Sorry, I =
really don't see the problem here.   I think you are =
underestimating the complexity of the homenet configuration that needs =
to be tracked.   We have decided that in the homenet case, the =
entire network configuration, including routing, has to be managed =
automatically without user intervention.   So keeping track of =
an excluded prefix is a trivial subset of the total problem, and we =
needn't be concerned about =
it.
 
  =

If you say so. I still think =
it's much easier to track a single delegated prefix than to track a =
delegated prefix minus exceptions (which may change). If you number the =
WAN link out of the customer's space, any WAN link renumbering (ISP =
change) will necessarily trigger a recompute of Homenet (LAN change). =


> So that's why I'm trying to =
understand the use case. Because someone must have thought that this was =
a good idea.
    =

 
Yes, 3gpp =
thinks it's a good idea, because it results in a cleaner address space =
and routing infrastructure, and is easier to =
manage.
 
  =

Still don't get this, but =
I'm not a 3gpp person. I'm presuming that "most people" will =
anyway be performing route aggregation at several points within their =
network, for scalability and stability reasons. All big networks I've =
worked on have done that. And if they didn't, they did once they had =
experienced their first serious outage due to flapping =
routes.

> BTW I believe he.net operates this =
way (2 adjacent /64's for initial allocation, followed by an additional =
non-overlapping /48 if you request =
it.
    =

 
HE is =
doing manual allocation.   You have to type in the =
prefixes.   So this isn't even remotely related to what we are =
talking about =
here.
 
  =

Of course it is. PD does =
little more than automating a numbering plan. Whether you type it in =
manually or distribute that numbering plan via PD is largely irrelevant. =
Again, long experience with delegated numbering plans with distributed =
administration tells me to keep the delegation across admin boundaries =
clean and simple. It's a lot easier to track access rights to data if =
you do not have to track exclusions. Same with firewall rules. =
Whatever.

YMMV.

------_=_NextPart_001_01CCB217.AAD660D5--

From frnkblk@iname.com  Sat Dec  3 19:07:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5400911E8090 for ; Sat,  3 Dec 2011 19:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 NYV0wbjAfYjY for ; Sat,  3 Dec 2011 19:07:54 -0800 (PST)
Received: from premieronline.net (mail.premieronline.net [96.31.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB811E807F for ; Sat,  3 Dec 2011 19:07:54 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=67.22.207.244; 
Received: from BULKFAMLAPTOP (unverified [67.22.207.244])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 34387796-1729245 for multiple; Sat, 03 Dec 2011 21:07:52 -0600
From: "Frank Bulk" 
To: "'Hemant Singh \(shemant\)'" 
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com>
Date: Sat, 3 Dec 2011 21:07:49 -0600
Message-ID: <013701ccb231$e7ca7ad0$b75f7070$@iname.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01CCB1FF.9D3206A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQA=
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=67.22.207.244
X-IP-stats: Incoming Last 0, First 38, in=32, out=0, spam=0 ip=67.22.207.244
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 03:07:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0138_01CCB1FF.9D3206A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hemant:

 

If this CPE has manually-configured 6rd configured, why would the CPE sunset
6rd at all?  Since Barbara perceives manually-configured CPE primarily in
PPP environments, how would DHCPv4 play into this situation at all?  

 

I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of native IPv6, both
in DHCPv6 and PPP environments.

 

Frank

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Hemant Singh (shemant)
Sent: Monday, November 28, 2011 1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

 

 

From: Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

 

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that the
CE be able to rationalize 6rd and native at the same time. I >don't think it
changes the requirements at all if we follow the same general principle that
the CE "does what it is told" rather than trying to enable and disable 6rd
configuration dynamically based on the >presence of native IPv6. 

 

The retail, manually-configured CPE will be fine with 6rd sunsetting based
on the rules already specified in rfc6204bis.  The rules are agnostic to a
SP-managed or a user-configured 6rd CPE router. The retail CPE will start
native IPv6 operation when cued to do so with a RA from the SP BNG and
sunset 6rd when the DHCPv4 lease_time expires and the SP does not reply to
the DHCPv4 Renew from the CPE and the SP has also changing the provisioning
system to not include the 6rd DHCPv4 option in DHCPv4 responses.

 

Thanks,

 

Hemant

 

 


------=_NextPart_000_0138_01CCB1FF.9D3206A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hemant:
 
If this CPE has manually-configured 6rd configured, why would the CPE =
sunset 6rd at all?  Since Barbara perceives manually-configured CPE =
primarily in PPP environments, how would DHCPv4 play into this situation =
at all?  
 
I’d like to hear from Barbara how she would want a CPE with =
manually-configured 6rd should function in the presence of native IPv6, =
both in DHCPv6 and PPP environments.
 
Frank
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Hemant Singh (shemant)
Sent: Monday, November 28, 2011 =
1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net]=
 
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, =
BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: =
[v6ops] 6rd Sunsetting
 
>OK, I won't =
stand in the way of including manual requirements under protest, but if =
they go in then it becomes that much more important that the CE be able =
to rationalize 6rd and native at the same time. I >don't think it changes the =
requirements at all if we follow the same general principle that the CE =
"does what it is told" rather than trying to enable and =
disable 6rd configuration dynamically based on the >presence of native =
IPv6. 
 
The retail, manually-configured CPE will be fine =
with 6rd sunsetting based on the rules already specified in =
rfc6204bis.  The rules are agnostic to a SP-managed or a =
user-configured 6rd CPE router. The retail CPE will start native IPv6 =
operation when cued to do so with a RA from the SP BNG and sunset 6rd =
when the DHCPv4 lease_time expires and the SP does not reply to the =
DHCPv4 Renew from the CPE and the SP has also changing the provisioning =
system to not include the 6rd DHCPv4 option in DHCPv4 =
responses.
 
Thanks,
 
Hemant
 
 

------=_NextPart_000_0138_01CCB1FF.9D3206A0--


From frnkblk@iname.com  Sat Dec  3 19:18:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24621F8B71 for ; Sat,  3 Dec 2011 19:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level: 
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=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 lHfMGoDnQ17U for ; Sat,  3 Dec 2011 19:18:26 -0800 (PST)
Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8260B21F8B64 for ; Sat,  3 Dec 2011 19:18:26 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=67.22.207.244; 
Received: from BULKFAMLAPTOP (unverified [67.22.207.244])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 34387892-1729245 for multiple; Sat, 03 Dec 2011 21:18:25 -0600
From: "Frank Bulk" 
To: "'STARK, BARBARA H'" , "Hemant Singh \(shemant\)" , "Hans Liu" 
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>		<5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
Date: Sat, 3 Dec 2011 21:18:22 -0600
Message-ID: <013c01ccb233$610b0490$23210db0$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAABrXfVAAA2n1sAACE9RAANnWzDA=
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=67.22.207.244
X-IP-stats: Incoming Last 0, First 38, in=33, out=0, spam=0 ip=67.22.207.244
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 03:18:27 -0000

+1

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of STARK, BARBARA H
Sent: Tuesday, November 29, 2011 1:32 PM
To: Hemant Singh (shemant); Hans Liu
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

> Specifically, the rfc6204bis document has augmented bullets from =
rfc6204 with text such as =E2=80=9Cunless configured to acquire a global =
address=E2=80=A6=E2=80=9D.  So the user of a CE is going to configure =
the CE for one specific WAN IP address acquisition behavior.  Thus  why =
not sell out the Conceptual Configuration Variables?  Further the =
unnumbered model is buried in text of rfc6204 and rfc6204bis and =
increasingly we see new readers of the documents having missed the =
unnumbered model.   Hence why not  define such variables to map out the =
total scope of the WAN IP configuration for the CE.   The variables do =
not prohibit a CE to implement automated WAN IPv6 address =
acquisition/creation.   If you want and if we define Conceptual =
Configuration Variables, we can add a line that says the WAN IPv6 =
address acquisition is automated and some guidelines are provided for =
automata in section 4.4.3. <

 No. There is no expectation that the user of the CE will configure =
it for a specific WAN. The expectation is that the CE will have a =
factory default configuration, because the particular CE is intended for =
use in a particular environment. These configuration exceptions are not =
intended for WAN-clueless CE routers. They are intended for WAN-specific =
CE routers.

The exceptions give the specifiers of WAN-specific CE routers =
(CableLabs, BBF, 3GPP) the freedom to not implement certain =
capabilities, because their WAN is known to them. The exceptions need to =
be ignored by WAN-clueless router implementers. WAN-clueless CE routers =
have no need for these configuration concepts. I don't want to give the =
impression that such configurability is needed or encouraged in =
WAN-clueless CE routers. Of course they are not prohibited from offering =
such configuration, but by remaining silent on the topic, such =
configurability is neither encouraged nor prohibited.  
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AEF11E807F for ; Sat,  3 Dec 2011 19:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=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 qo9JfvhtRXlA for ; Sat,  3 Dec 2011 19:34:59 -0800 (PST)
Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4511E8080 for ; Sat,  3 Dec 2011 19:34:58 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=67.22.207.244; 
Received: from BULKFAMLAPTOP (unverified [67.22.207.244])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 34388157-1729245 for multiple; Sat, 03 Dec 2011 21:34:58 -0600
From: "Frank Bulk" 
To: "'Maglione Roberta'" 
References: 			<2963F168-45CB-4042-8238-56DF538B0543@gmail.com>			<2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com>	<1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>	<8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>			<282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>		<282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>	 	<282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>,  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8E@GRFMBX704BA020.griffon.local>
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8E@GRFMBX704BA020.griffon.local>
Date: Sat, 3 Dec 2011 21:34:54 -0600
Message-ID: <013d01ccb235$b06cc170$11464450$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyvvqtFe71xQAubQBOgc8pspmJjdQACC1JqAJuu/eA=
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=67.22.207.244
X-IP-stats: Incoming Last 0, First 38, in=34, out=0, spam=0 ip=67.22.207.244
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 03:35:00 -0000

Roberta:

Why is this an issue for BNG's in the 3GPP world and not elsewhere?

Frank

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Maglione Roberta
Sent: Wednesday, November 30, 2011 7:16 PM
To: sarikaya@ieee.org
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Yes you can install the aggregate route but you would need either another
dhc option that tells the BNG what aggregate route needs to be installed per
each customer or you have to do by manual configuration.

In my opinion using PD-exclude is operational much simpler

Roberta
________________________________________
From: Behcet Sarikaya [sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 1:17 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta,

I don't see that a problem either because usually you can install an
aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta

> wrote:
Behcet,
  the reason why you may need to have a single prefix instead of two per
customer is in order to have just a single route to install on the BNG
instead of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya
[sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6.
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.
I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta

>> wrote:
> If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
unnumbered and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a single
prefix.

Roberta

________________________________________
From: Lorenzo Colitti
[lorenzo@google.com>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen;
v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta

>>>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than
use the PD-exclude option to tell the CPE to exclude a portion of the
delegated prefix and use it to number the point to point WAN link between
the requesting router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE
router, then the CE router already knows that the /64 is assigned to that
link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
anything.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

_______________________________________________
v6ops mailing list
v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

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



From shemant@cisco.com  Sun Dec  4 06:32:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4651721F84CC for ; Sun,  4 Dec 2011 06:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Level: 
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 N4xnFKCXfAbW for ; Sun,  4 Dec 2011 06:32:31 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9812321F84C9 for ; Sun,  4 Dec 2011 06:32:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9482; q=dns/txt; s=iport; t=1323009151; x=1324218751; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=8uZPbbwqknS3NcixaSFlpQrB2SsN04POPFPvkaY4xDE=; b=RmMh4cwoA1Mjt3RQ2UpcIoI24Z1zrsa8xo36Ll2bIw11T2zj1fffTqR3 YvvENIEpeJyJsp0yRVm1bigszBfPlllsgumsj0M67tXjkRJ12xJ2scPZg WDYAeBUeOLhrnFnCnxd0d0bM2erbdc+H7y0hum3K0WWbleOmGVWtk4dig U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcAAA2E206tJXG9/2dsb2JhbABEgk2XO5AogQWBcgEBAQQSAQkLBgNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwganxcBnVCKPmMEiC2eZg
X-IronPort-AV: E=Sophos;i="4.71,293,1320624000"; d="scan'208,217";a="41006614"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 04 Dec 2011 14:32:31 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB4EWUnT017128;  Sun, 4 Dec 2011 14:32:30 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 4 Dec 2011 08:32:30 -0600
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_01CCB291.8D912802"
Date: Sun, 4 Dec 2011 08:32:28 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785D9@XMB-RCD-109.cisco.com>
In-Reply-To: <013701ccb231$e7ca7ad0$b75f7070$@iname.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQAAF2gygA==
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com>
From: "Hemant Singh (shemant)" 
To: "Frank Bulk" 
X-OriginalArrivalTime: 04 Dec 2011 14:32:30.0671 (UTC) FILETIME=[8DD8F5F0:01CCB291]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 14:32:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB291.8D912802
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Frank,

=20

=20

From: Frank Bulk [mailto:frnkblk@iname.com]=20
Sent: Saturday, December 03, 2011 10:08 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA H
Subject: RE: [v6ops] 6rd Sunsetting

=20

=20

>If this CPE has manually-configured 6rd configured, why would the CPE
sunset 6rd at all?  Since Barbara perceives manually->configured CPE
primarily in PPP environments, how would DHCPv4 play into this situation
at all? =20

=20

If there is no DHCPv4 in the network, you are correct.   However,
consider this.  The CPE is running 6rd.  Then CPE receives an RA,
initiates DHCPv6 PD, and gets operational in native IPv6 mode.   Since
the SP issued the RA the SP has also disabled 6rd.  Now the CPE has to
send data on the 6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.
The NUD is not responded to since the SP has disabled 6rd.  On the NUD
timing out the CPE disables 6rd and just keeps protocol 41 processing
active.

=20

Having said that, I still prefer symmetry.  If DHCPv4 was used to enable
6rd, DHCPv4 should be used to disable 6rd.  Likewise if manual
configuration was used to enable 6rd, manual configuration should also
be used to disabled 6rd.   Note also, MarkT has said, 6rd in RFC 5969
was designed for SP-managed CPE and manually configured CPE is out of
scope for RFC 5969.  Likewise any manual configuration is out of scope
of rfc6204bis as well.  =20

=20

>I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of >native IPv6,
both in DHCPv6 and PPP environments.

=20

Barbara can reply to this one.

=20

Regards,

=20

Hemant


------_=_NextPart_001_01CCB291.8D912802
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Frank,
 
 
From:=
 =
Frank Bulk [mailto:frnkblk@iname.com] 
Sent: Saturday, =
December 03, 2011 10:08 PM
To: Hemant Singh =
(shemant)
Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA =
H
Subject: RE: [v6ops] 6rd =
Sunsetting
 
 
>If =
this CPE has manually-configured 6rd configured, why would the CPE =
sunset 6rd at all?  Since Barbara perceives manually->configured CPE primarily in PPP environments, how =
would DHCPv4 play into this situation at all?  =

 
If there is no DHCPv4 in the network, you are =
correct.   However, consider this.  The CPE is running =
6rd.  Then CPE receives an RA, initiates DHCPv6 PD, and gets =
operational in native IPv6 mode.   Since the SP issued the RA =
the SP has also disabled 6rd.  Now the CPE has to send data on the =
6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.  The NUD =
is not responded to since the SP has disabled 6rd.  On the NUD =
timing out the CPE disables 6rd and just keeps protocol 41 processing =
active.
 
Having said that, I still prefer symmetry.  If =
DHCPv4 was used to enable 6rd, DHCPv4 should be used to disable =
6rd.  Likewise if manual configuration was used to enable 6rd, =
manual configuration should also be used to disabled 6rd.   =
Note also, MarkT has said, 6rd in RFC 5969 was designed for SP-managed =
CPE and manually configured CPE is out of scope for RFC 5969.  =
Likewise any manual configuration is out of scope of rfc6204bis as =
well.   
 
>I’d like to hear from Barbara how she would =
want a CPE with manually-configured 6rd should function in the presence =
of >native IPv6, both in DHCPv6 and PPP =
environments.
 
Barbara can reply to this =
one.
 
Regards,
 
Hemant

------_=_NextPart_001_01CCB291.8D912802--

From mohacsi@niif.hu  Sun Dec  4 08:00:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE12E21F8538 for ; Sun,  4 Dec 2011 08:00:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.596
X-Spam-Level: 
X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=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 vDECHnEtEXMK for ; Sun,  4 Dec 2011 08:00:46 -0800 (PST)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 33F2221F8532 for ; Sun,  4 Dec 2011 08:00:46 -0800 (PST)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 5295F87893; Sun,  4 Dec 2011 17:00:40 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id OuOtFWLkyfYh; Sun,  4 Dec 2011 17:00:36 +0100 (CET)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 8B5CB8788E; Sun,  4 Dec 2011 17:00:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 892348788A; Sun,  4 Dec 2011 17:00:36 +0100 (CET)
Date: Sun, 4 Dec 2011 17:00:36 +0100 (CET)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Gert Doering 
In-Reply-To: <20111203104345.GR72014@Space.Net>
Message-ID: 
References:  <20111124125545.GW71280@Space.Net>   <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com>  <4ED94F24.2060806@gmail.com>  <20111203104345.GR72014@Space.Net>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 16:00:46 -0000

On Sat, 3 Dec 2011, Gert Doering wrote:

> Hi,
>
> On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote:
>> I don't think you can mandate configuration issues in node requirements
>> docs. A conforming router is still a conforming router even if nobody
>> configures a global unicast address on it.
>
> If the router is not able to send required ICMPv6 error messages, it's
> not a conforming router.
>
> And of course the vendors *could* enforce this - like in "ipv6 forwarding
> is not operational unless a GUA is configured on an interface (in the
> same routing context)".

I don't think this is a good idea. Several IPv6 networks are relying on 
OSPFv3 with link-local addresses on interfaces only.
- Generating ICMPv6 error with different source address scope is a bug
- Selecting GUA randonly for global desitani address is cosmetical problem
- It must be configurable to source address if it is unnumbered....

Best Regards,

 		Janos Mohacsi

>
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From gert@space.net  Sun Dec  4 09:32:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47DD21F85CE for ; Sun,  4 Dec 2011 09:32:24 -0800 (PST)
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 KWqqi8orSlHA for ; Sun,  4 Dec 2011 09:32:24 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 090F921F84CE for ; Sun,  4 Dec 2011 09:32:22 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id EB566F8956 for ; Sun,  4 Dec 2011 18:32:20 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BC2F1F8962 for ; Sun,  4 Dec 2011 18:32:20 +0100 (CET)
Received: (qmail 17577 invoked by uid 1007); 4 Dec 2011 18:32:20 +0100
Date: Sun, 4 Dec 2011 18:32:20 +0100
From: Gert Doering 
To: Mohacsi Janos 
Message-ID: <20111204173220.GY72014@Space.Net>
References:   <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com>  <4ED94F24.2060806@gmail.com>  <20111203104345.GR72014@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1uvqqKydr5GmSTA5"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 17:32:24 -0000

--1uvqqKydr5GmSTA5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Dec 04, 2011 at 05:00:36PM +0100, Mohacsi Janos wrote:
> On Sat, 3 Dec 2011, Gert Doering wrote:
>=20
> > On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote:
> >> I don't think you can mandate configuration issues in node requirements
> >> docs. A conforming router is still a conforming router even if nobody
> >> configures a global unicast address on it.
> >
> > If the router is not able to send required ICMPv6 error messages, it's
> > not a conforming router.
> >
> > And of course the vendors *could* enforce this - like in "ipv6 forwardi=
ng
> > is not operational unless a GUA is configured on an interface (in the
> > same routing context)".
>=20
> I don't think this is a good idea. Several IPv6 networks are relying on=
=20
> OSPFv3 with link-local addresses on interfaces only.

This is OK, and not a problem - but it implies that when sourcing an
ICMPv6 error destined to a GUA, it MUST use a GUA that is "borrowed"
=66rom another interface.  Sourcing from link-local is plain wrong.

> - Generating ICMPv6 error with different source address scope is a bug

I'm not exactly sure I parse this right - "different source address scope"
compared to what?  To the GUA destination address (in which case I agree)
or to the link-local address (in which case I disagree).

> - Selecting GUA randonly for global desitani address is cosmetical problem
> - It must be configurable to source address if it is unnumbered....

The problem is not "using a random GUA address" - the problem is "if the
router has no single GUA address, it can't use a GUA address as source
in this case".  And in this case it would be violating router requirements,
and shouldn't be forwarding IPv6 packets in the first place.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--1uvqqKydr5GmSTA5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTtuupKkuBuNlUUl1AQIfaQQAkPBZpjffNS7uM3sLBWR7Db5DGsrMn36x
Vqn62f+624+CynAl4s5bm11sOJy0psWLeKAMaBcGqkboKz5CsZ0uNra1pTXSV6UC
gHSzMtLUawA0EcyezDONEkV3wbW7KdGLrQ37Rwq9q2frjkTFkaaWyRmCPbxQ2Q+f
Z9C2yoqDxpc=
=+Cp5
-----END PGP SIGNATURE-----

--1uvqqKydr5GmSTA5--

From mohacsi@niif.hu  Sun Dec  4 10:02:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA4F21F8610 for ; Sun,  4 Dec 2011 10:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.296
X-Spam-Level: 
X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpmHVHQeRm+U for ; Sun,  4 Dec 2011 10:02:05 -0800 (PST)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 4295B21F85F2 for ; Sun,  4 Dec 2011 10:02:05 -0800 (PST)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id C1AFB87898; Sun,  4 Dec 2011 19:01:59 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id sBRvvrFXb3Ca; Sun,  4 Dec 2011 19:01:56 +0100 (CET)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 9AE3587893; Sun,  4 Dec 2011 19:01:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 98F5B8787B; Sun,  4 Dec 2011 19:01:56 +0100 (CET)
Date: Sun, 4 Dec 2011 19:01:56 +0100 (CET)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Gert Doering 
In-Reply-To: <20111204173220.GY72014@Space.Net>
Message-ID: 
References:   <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com>  <4ED94F24.2060806@gmail.com>  <20111203104345.GR72014@Space.Net>  <20111204173220.GY72014@Space.Net>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 18:02:06 -0000

On Sun, 4 Dec 2011, Gert Doering wrote:

> Hi,
>
> On Sun, Dec 04, 2011 at 05:00:36PM +0100, Mohacsi Janos wrote:
>> On Sat, 3 Dec 2011, Gert Doering wrote:
>>
>>> On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote:
>>>> I don't think you can mandate configuration issues in node requirements
>>>> docs. A conforming router is still a conforming router even if nobody
>>>> configures a global unicast address on it.
>>>
>>> If the router is not able to send required ICMPv6 error messages, it's
>>> not a conforming router.
>>>
>>> And of course the vendors *could* enforce this - like in "ipv6 forwarding
>>> is not operational unless a GUA is configured on an interface (in the
>>> same routing context)".
>>
>> I don't think this is a good idea. Several IPv6 networks are relying on
>> OSPFv3 with link-local addresses on interfaces only.
>
> This is OK, and not a problem - but it implies that when sourcing an
> ICMPv6 error destined to a GUA, it MUST use a GUA that is "borrowed"
> from another interface.  Sourcing from link-local is plain wrong.


Probably you statement can be misunderstood.
I understood you statement "ipv6 forwarding
is not operational unless a GUA is configured on an interface" the 
following way:
ipv6 forwarding is not operational on an interface if no GUA  is 
configured on this particular interface.

I recommend rephrase it to:

"ipv6 forwarding is not operational if no GUA is configured on any 
interface"

This may be true, however MPLS forwarding might happen. See later.

>
>> - Generating ICMPv6 error with different source address scope is a bug
>
> I'm not exactly sure I parse this right - "different source address scope"
> compared to what?  To the GUA destination address (in which case I agree)
> or to the link-local address (in which case I disagree).

Source and destination address scope must be the same.

>
>> - Selecting GUA randonly for global desitani address is cosmetical problem
>> - It must be configurable to source address if it is unnumbered....
>
> The problem is not "using a random GUA address" - the problem is "if the
> router has no single GUA address, it can't use a GUA address as source
> in this case".  And in this case it would be violating router requirements,
> and shouldn't be forwarding IPv6 packets in the first place.

Probably MPLS gurus would not accept that. Many big MPLS network does not 
cope with IPv6 inside their core network. The core network (P routers) are 
forwarding according to MPLS labels. Edge routers (PE) is dealing with 
IPv4 and IPv6 to fulfill user requirements. You can see some hops inside 
MPLS core sometimes, sometimes not:
See:
http://www.learnios.com/viewtopic.php?f=5&t=34596


Best Regards,
 		Janos Mohacsi


From brian.e.carpenter@gmail.com  Sun Dec  4 12:16:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2121F8AD2 for ; Sun,  4 Dec 2011 12:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 T0QEESVcIq31 for ; Sun,  4 Dec 2011 12:16:46 -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 205BD21F8AD1 for ; Sun,  4 Dec 2011 12:16:46 -0800 (PST)
Received: by iaek3 with SMTP id k3so5412562iae.31 for ; Sun, 04 Dec 2011 12:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b4f2HLsviQ8PUFZTf8In6i6fpirB6R86ueAuomtaDGc=; b=ZsBIbwc5autc0NkjrSxoHaZ/lxW0iqB+Moe4pTHIPHDA92mcnmeZHdHcfbyHqbgt1z gxwbXBPpffirCjjmrEPnD3obhRZfp+uUfDCTJnr0JPBZebew+9hurfJRS47tI2IWaa7z Wqn2V+yjaBKoKCkCwbrKTPju0Q+j0g2twl7Wg=
Received: by 10.42.176.8 with SMTP id bc8mr6994545icb.12.1323029805063; Sun, 04 Dec 2011 12:16:45 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ds5sm1519387ibb.5.2011.12.04.12.16.41 (version=SSLv3 cipher=OTHER); Sun, 04 Dec 2011 12:16:44 -0800 (PST)
Message-ID: <4EDBD51E.3050006@gmail.com>
Date: Mon, 05 Dec 2011 09:16:30 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mohacsi Janos 
References: 		<4ECEC112.6050106@gmail.com>	<6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com>	<4ED93EDC.7030007@gmail.com> 	<4ED94F24.2060806@gmail.com>		<20111203104345.GR72014@Space.Net>		<20111204173220.GY72014@Space.Net> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 20:16:47 -0000

Hi,

On 2011-12-05 07:01, Mohacsi Janos wrote:
> 
> 
> 
> On Sun, 4 Dec 2011, Gert Doering wrote:
> 
>> Hi,
>>
>> On Sun, Dec 04, 2011 at 05:00:36PM +0100, Mohacsi Janos wrote:
>>> On Sat, 3 Dec 2011, Gert Doering wrote:
>>>
>>>> On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote:
>>>>> I don't think you can mandate configuration issues in node
>>>>> requirements
>>>>> docs. A conforming router is still a conforming router even if nobody
>>>>> configures a global unicast address on it.
>>>>
>>>> If the router is not able to send required ICMPv6 error messages, it's
>>>> not a conforming router.
>>>>
>>>> And of course the vendors *could* enforce this - like in "ipv6
>>>> forwarding
>>>> is not operational unless a GUA is configured on an interface (in the
>>>> same routing context)".
>>>
>>> I don't think this is a good idea. Several IPv6 networks are relying on
>>> OSPFv3 with link-local addresses on interfaces only.
>>
>> This is OK, and not a problem - but it implies that when sourcing an
>> ICMPv6 error destined to a GUA, it MUST use a GUA that is "borrowed"
>> from another interface.  Sourcing from link-local is plain wrong.
> 
> 
> Probably you statement can be misunderstood.
> I understood you statement "ipv6 forwarding
> is not operational unless a GUA is configured on an interface" the
> following way:
> ipv6 forwarding is not operational on an interface if no GUA  is
> configured on this particular interface.
> 
> I recommend rephrase it to:
> 
> "ipv6 forwarding is not operational if no GUA is configured on any
> interface"
> 
> This may be true, however MPLS forwarding might happen. See later.
> 
>>
>>> - Generating ICMPv6 error with different source address scope is a bug
>>
>> I'm not exactly sure I parse this right - "different source address
>> scope"
>> compared to what?  To the GUA destination address (in which case I agree)
>> or to the link-local address (in which case I disagree).
> 
> Source and destination address scope must be the same.
> 
>>
>>> - Selecting GUA randonly for global desitani address is cosmetical
>>> problem
>>> - It must be configurable to source address if it is unnumbered....
>>
>> The problem is not "using a random GUA address" - the problem is "if the
>> router has no single GUA address, it can't use a GUA address as source
>> in this case".  And in this case it would be violating router
>> requirements,
>> and shouldn't be forwarding IPv6 packets in the first place.
> 
> Probably MPLS gurus would not accept that. Many big MPLS network does
> not cope with IPv6 inside their core network. The core network (P
> routers) are forwarding according to MPLS labels. Edge routers (PE) is
> dealing with IPv4 and IPv6 to fulfill user requirements. You can see
> some hops inside MPLS core sometimes, sometimes not:
> See:
> http://www.learnios.com/viewtopic.php?f=5&t=34596

All that doesn't matter. If a router generates a PTB it is essential that
it has a valid global source address, so that conforming routers will
forward it. No excuses. Otherwise PMTUD is broken and that is not OK.

Traceroute being broken is annoying; PTMUD being broken is unacceptable.

A BCP on making PMTUD work for v6 is probably needed.

   Brian

From gert@space.net  Sun Dec  4 13:30:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C19D21F8A7A for ; Sun,  4 Dec 2011 13:30:30 -0800 (PST)
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 r5aGUz1vByEG for ; Sun,  4 Dec 2011 13:30:29 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F521F8A67 for ; Sun,  4 Dec 2011 13:30:28 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 38DE4F8966 for ; Sun,  4 Dec 2011 22:30:27 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1E966F895E for ; Sun,  4 Dec 2011 22:30:27 +0100 (CET)
Received: (qmail 98684 invoked by uid 1007); 4 Dec 2011 22:30:26 +0100
Date: Sun, 4 Dec 2011 22:30:26 +0100
From: Gert Doering 
To: Mohacsi Janos 
Message-ID: <20111204213026.GZ72014@Space.Net>
References: <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com>  <4ED94F24.2060806@gmail.com>  <20111203104345.GR72014@Space.Net>  <20111204173220.GY72014@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="naxtj2/NhbhNgH2W"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 21:30:30 -0000

--naxtj2/NhbhNgH2W
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Dec 04, 2011 at 07:01:56PM +0100, Mohacsi Janos wrote:
> Probably you statement can be misunderstood.
> I understood you statement "ipv6 forwarding
> is not operational unless a GUA is configured on an interface" the=20
> following way:
> ipv6 forwarding is not operational on an interface if no GUA  is=20
> configured on this particular interface.

Ah.  Indeed, that can be misleading.

> I recommend rephrase it to:
>=20
> "ipv6 forwarding is not operational if no GUA is configured on any=20
> interface"

This is what I had in mind.  "... any interface in the same routing
context", to take L3 VPNs into account.

> >> - Generating ICMPv6 error with different source address scope is a bug
> >
> > I'm not exactly sure I parse this right - "different source address sco=
pe"
> > compared to what?  To the GUA destination address (in which case I agre=
e)
> > or to the link-local address (in which case I disagree).
>=20
> Source and destination address scope must be the same.

Agree.

> >> - Selecting GUA randonly for global desitani address is cosmetical pro=
blem
> >> - It must be configurable to source address if it is unnumbered....
> >
> > The problem is not "using a random GUA address" - the problem is "if the
> > router has no single GUA address, it can't use a GUA address as source
> > in this case".  And in this case it would be violating router requireme=
nts,
> > and shouldn't be forwarding IPv6 packets in the first place.
>=20
> Probably MPLS gurus would not accept that. Many big MPLS network does not=
=20
> cope with IPv6 inside their core network. The core network (P routers) ar=
e=20
> forwarding according to MPLS labels. Edge routers (PE) is dealing with=20
> IPv4 and IPv6 to fulfill user requirements. You can see some hops inside=
=20
> MPLS core sometimes, sometimes not:
> See:
> http://www.learnios.com/viewtopic.php?f=3D5&t=3D34596

Well, I don't think that 6PE over an IPv6-less core network is a=20
*particularily* good idea...  but that's a different discussion to be
held on a differnet day.

But indeed, if you build an MPLS network, have no IPv6 at all on your
P routers, and need to send back ICMPv6 error messages - then you have
a problem.  Those routers might not even have *link-local*s to source
their packets from.=20

So I'd rather focus on fixing edge cases of non-broken networks...

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--naxtj2/NhbhNgH2W
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTtvmcqkuBuNlUUl1AQJ8mQP8CbNIiCM/3jNJcDt6vDVayghApNaQ6HX3
h6U9LO3ka7msx+RFMKdvEQttMI1atxCOxZUonxHFjRlo080jh1GlEOtwEw2LAZd0
ToNAU4S5jK7DKyNLAqqIU8JrH4cV/bwfzCxKYgQm/FZNZGyiLgJ2+apYkDscZhaY
3SMW16naPf4=
=QXbp
-----END PGP SIGNATURE-----

--naxtj2/NhbhNgH2W--

From mohacsi@niif.hu  Sun Dec  4 14:11:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD3A21F8AF4 for ; Sun,  4 Dec 2011 14:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.146
X-Spam-Level: 
X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwdjPR31gAR0 for ; Sun,  4 Dec 2011 14:11:40 -0800 (PST)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3DB21F8A67 for ; Sun,  4 Dec 2011 14:11:40 -0800 (PST)
Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id AD2778788A; Sun,  4 Dec 2011 23:11:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id J38rppu-bo3L; Sun,  4 Dec 2011 23:11:30 +0100 (CET)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 44F328789F; Sun,  4 Dec 2011 23:11:30 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 3D3FD8787C; Sun,  4 Dec 2011 23:11:30 +0100 (CET)
Date: Sun, 4 Dec 2011 23:11:30 +0100 (CET)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Brian E Carpenter 
In-Reply-To: <4EDBD51E.3050006@gmail.com>
Message-ID: 
References:   <4ECEC112.6050106@gmail.com> <6D5FBB28-E435-4F3F-BAAF-F04CEDB0AC8A@apple.com> <4ED93EDC.7030007@gmail.com>  <4ED94F24.2060806@gmail.com>  <20111203104345.GR72014@Space.Net>  <20111204173220.GY72014@Space.Net>  <4EDBD51E.3050006@gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Philip Homburg , IPv6 Operations 
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Dec 2011 22:11:41 -0000

On Mon, 5 Dec 2011, Brian E Carpenter wrote:

> Hi,
>
> On 2011-12-05 07:01, Mohacsi Janos wrote:
>>
>>
>>
>> On Sun, 4 Dec 2011, Gert Doering wrote:
>>
>>> Hi,
>>>
>>> On Sun, Dec 04, 2011 at 05:00:36PM +0100, Mohacsi Janos wrote:
>>>> On Sat, 3 Dec 2011, Gert Doering wrote:
>>>>
>>>>> On Fri, Dec 02, 2011 at 05:43:21PM -0800, Lorenzo Colitti wrote:
>>>>>> I don't think you can mandate configuration issues in node
>>>>>> requirements
>>>>>> docs. A conforming router is still a conforming router even if nobody
>>>>>> configures a global unicast address on it.
>>>>>
>>>>> If the router is not able to send required ICMPv6 error messages, it's
>>>>> not a conforming router.
>>>>>
>>>>> And of course the vendors *could* enforce this - like in "ipv6
>>>>> forwarding
>>>>> is not operational unless a GUA is configured on an interface (in the
>>>>> same routing context)".
>>>>
>>>> I don't think this is a good idea. Several IPv6 networks are relying on
>>>> OSPFv3 with link-local addresses on interfaces only.
>>>
>>> This is OK, and not a problem - but it implies that when sourcing an
>>> ICMPv6 error destined to a GUA, it MUST use a GUA that is "borrowed"
>>> from another interface.  Sourcing from link-local is plain wrong.
>>
>>
>> Probably you statement can be misunderstood.
>> I understood you statement "ipv6 forwarding
>> is not operational unless a GUA is configured on an interface" the
>> following way:
>> ipv6 forwarding is not operational on an interface if no GUA  is
>> configured on this particular interface.
>>
>> I recommend rephrase it to:
>>
>> "ipv6 forwarding is not operational if no GUA is configured on any
>> interface"
>>
>> This may be true, however MPLS forwarding might happen. See later.
>>
>>>
>>>> - Generating ICMPv6 error with different source address scope is a bug
>>>
>>> I'm not exactly sure I parse this right - "different source address
>>> scope"
>>> compared to what?  To the GUA destination address (in which case I agree)
>>> or to the link-local address (in which case I disagree).
>>
>> Source and destination address scope must be the same.
>>
>>>
>>>> - Selecting GUA randonly for global desitani address is cosmetical
>>>> problem
>>>> - It must be configurable to source address if it is unnumbered....
>>>
>>> The problem is not "using a random GUA address" - the problem is "if the
>>> router has no single GUA address, it can't use a GUA address as source
>>> in this case".  And in this case it would be violating router
>>> requirements,
>>> and shouldn't be forwarding IPv6 packets in the first place.
>>
>> Probably MPLS gurus would not accept that. Many big MPLS network does
>> not cope with IPv6 inside their core network. The core network (P
>> routers) are forwarding according to MPLS labels. Edge routers (PE) is
>> dealing with IPv4 and IPv6 to fulfill user requirements. You can see
>> some hops inside MPLS core sometimes, sometimes not:
>> See:
>> http://www.learnios.com/viewtopic.php?f=5&t=34596
>
> All that doesn't matter. If a router generates a PTB it is essential that
> it has a valid global source address, so that conforming routers will
> forward it. No excuses. Otherwise PMTUD is broken and that is not OK.
>
> Traceroute being broken is annoying; PTMUD being broken is unacceptable.
>
> A BCP on making PMTUD work for v6 is probably needed.

Agreed. RFC 4890 also stating importance of proper ICMPv6 treatment.
However I am curious, if in MPLS core how often changing MTU internally. 
Or contrary relying only ingress and egress PE router to generate PTB.

Best Regards,
 		Janos Mohacsi


From internet-drafts@ietf.org  Sun Dec  4 22:04:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AADF1F0C5B; Sun,  4 Dec 2011 22:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 vyDr4GUW63wo; Sun,  4 Dec 2011 22:04:32 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81671F0C47; Sun,  4 Dec 2011 22:04:32 -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: 3.64
Message-ID: <20111205060432.31703.47987.idtracker@ietfa.amsl.com>
Date: Sun, 04 Dec 2011 22:04:32 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 06:04:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Operational Neighbor Discovery Problems
	Author(s)       : Warren Kumari
	Filename        : draft-ietf-v6ops-v6nd-problems-01.txt
	Pages           : 13
	Date            : 2011-12-04

   In IPv4, subnets are generally small, made just large enough to cover
   the actual number of machines on the subnet.  In contrast, the
   default IPv6 subnet size is a /64, a number so large it covers
   trillions of addresses, the overwhelming number of which will be
   unassigned.  Consequently, simplistic implementations of Neighbor
   Discovery can be vulnerable to deliberate or accidental denial of
   service, whereby they attempt to perform address resolution for large
   numbers of unassigned addresses.  Such denial of attacks can be
   launched intentionally (by an attacker), or result from legitimate
   operational tools or accident conditions.  As a result of these
   vulnerabilities, new devices may not be able to "join" a network, it
   may be impossible to establish new IPv6 flows, and existing ipv6
   transported flows may be interrupted.

   This document describes the potential for DOS in detail and suggests
   possible implementation improvements as well as operational
   mitigation techniques that can in some cases be used to protect
   against or at least aleviate the impact of such attacks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-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-v6ops-v6nd-problems-01.txt


From Carl.Wuyts@technicolor.com  Sun Dec  4 22:59:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385CF11E809C for ; Sun,  4 Dec 2011 22:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.935
X-Spam-Level: 
X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d52-Q6olh9B for ; Sun,  4 Dec 2011 22:59:55 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5C95221F84B0 for ; Sun,  4 Dec 2011 22:59:52 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTtxr5w3Tl3a9MwhvTGetnohWqVDyNsqO@postini.com; Sun, 04 Dec 2011 22:59:53 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 5 Dec 2011 07:56:30 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 5 Dec 2011 07:56:29 +0100
From: Wuyts Carl 
To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , Lorenzo Colitti 
Date: Mon, 5 Dec 2011 07:56:27 +0100
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyxYDYxzedJ3jBET9uPp3ThRTQpNwAXP0wgAFdidMA=
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB42FDB03@MOPESMBX01.eu.thmulti.com>
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 06:59:57 -0000

--_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: multipart/alternative;
	boundary="_000_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_"

--_000_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Well, if the RFc6204 gets replaced by RFc6204bis, then I'd say it's ok with=
 its current content, targeting global IPv6 and some tunneling (DSLIte and =
6RD).  Already dragging along PCP as well to it seems a bit too soon lookin=
g today at PCP.

Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCB323.6463EF80]
[cid:image002.gif@01CCB323.6463EF80]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCB323.6463EF80]

Help preserve the color of our world - Think before you print.





From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H=
emant Singh (shemant)
Sent: zaterdag 3 december 2011 14:58
To: Fred Baker (fred); Lorenzo Colitti
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward






-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Fred Baker (fred)
Sent: Friday, December 02, 2011 9:06 PM
To: Lorenzo Colitti
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] 6204bis progress and way forward





>Yes, but the discussion since added 6rd and ds-lite. That is required by c=
ertain ISPs, and specifically the BBF and Cable >Labs, for networks using t=
heir technology. In addition, the PCP chairs tell us that draft-ietf-pcp-ba=
se is headed to the >IESG momentarily as well.



Right on PCP.  The plan of record for the rfc6204bis document is to add a r=
equirement for a PCP client on the CPE router WAN if the PCP base document =
heads to the IESG and/or the rfc6204bis document is in the IESG.  Pending i=
ssues for rfc6204bis are outlined below.



1.  6rd sunsetting requirements on the CPE router are close to being comple=
te.  Will work with MarkT and the design team to close on this one when Mar=
kT gets back from PTO.

2.  Coexistence will add details for DS-Lite sunsetting and flush out any o=
ther details in Coexistence.  Text has already been emailed to the design t=
eam and some DS-Lite interested parties.  One of the authors of the DS-Lite=
 RFC has also worked with myself and Wes to close on the DS-Lite sunsetting=
 text.

3.  We have responded to all of MarkT comments and some text (mostly minor)=
 will change in the document from his comments.

4.  The WPD-7 bullet in the document is not agreeable to some DHC folks and=
 a discussion has been initiated in the DHC WG.  Please see



     http://www.ietf.org/mail-archive/web/dhcwg/current/msg12188.html





Thanks,



Hemant

--_000_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Well, if the RFc6204 gets replaced by RFc6204bis, then I̵=
7;d say it’s ok with its current content, targeting global IPv6 and s=
ome tunneling (DSLIte and 6RD).  Already dragging along PCP as well to=
 it seems a bit too soon looking today at PCP.  
=

 =

Carl Wuyts
GCD System Architect Networkin=
g
Connect Division
carl.wuyts@technicolor.com
tel.: +=
32 3 443 65 90
3Dtwitter
3D"Visit
Prins Boudewijnlaan 47  -  2650 Edegem&nbs=
p; -  Belgium
Technicolor Delivery =
Technologies Belgium NV
Registered office (maatschapp=
elijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernem=
ingsnummer): 0428837295 - RPR Antwerpen
 
 
From: v6ops-bounces@ietf.org [mail=
to:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: zaterdag 3 december 2011 14:58
To: Fred Baker (fred); =
Lorenzo Colitti
Cc: v6ops@ietf.org
Subject: Re: [v6ops]=
 6204bis progress and way forward
 
 
 
-----Origina=
l Message-----
From: v6ops-bou=
nces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Fred Baker (fred)
Sent: Friday, Decemb=
er 02, 2011 9:06 PM
To: Lorenzo Colitti
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] 6204bis progress and=
 way forward
 
 
>Yes, but=
 the discussion since added 6rd and ds-lite. That is required by certain IS=
Ps, and specifically the BBF and Cable >Labs, for networks using their t=
echnology. In addition, the PCP chairs tell us that draft-ietf-pcp-base is =
headed to the >IESG momentarily as well.
=
 
Right on PCP.  The plan of record for the rf=
c6204bis document is to add a requirement for a PCP client on the CPE route=
r WAN if the PCP base document heads to the IESG and/or the rfc6204bis docu=
ment is in the IESG.  Pending issues for rfc6204bis are outlined below=
.
 
1.  6rd sunsetting requirements on the CPE router are clo=
se to being complete.  Will work with MarkT and the design team to clo=
se on this one when MarkT gets back from PTO. 
  Coexistence will add details for DS-Lit=
e sunsetting and flush out any other details in Coexistence.  Text has=
 already been emailed to the design team and some DS-Lite interested partie=
s.  One of the authors of the DS-Lite RFC has also worked with myself =
and Wes to close on the DS-Lite sunsetting text.  
3.  We have responded to all of Ma=
rkT comments and some text (mostly minor) will change in the document from =
his comments.
4.  =
The WPD-7 bullet in the document is not agreeable to some DHC folks and =
a discussion has been initiated in the DHC WG.  Please see<=
/span>
 
&=
nbsp;    http://www.ietf.org/mail-archive/web/dhcwg/curren=
t/msg12188.html
 
=
 
Thanks,
 <=
/o:p>
Hemant
=

--_000_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_--

--_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=1351;
	creation-date="Mon, 05 Dec 2011 06:56:28 GMT";
	modification-date="Mon, 05 Dec 2011 06:56:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

--_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=1834;
	creation-date="Mon, 05 Dec 2011 06:56:28 GMT";
	modification-date="Mon, 05 Dec 2011 06:56:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_
Content-Type: image/gif; name="image003.gif"
Content-Description: image003.gif
Content-Disposition: inline; filename="image003.gif"; size=493;
	creation-date="Mon, 05 Dec 2011 06:56:28 GMT";
	modification-date="Mon, 05 Dec 2011 06:56:28 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0CB42FDB03MOPESMBX01eut_--

From mark@townsley.net  Mon Dec  5 01:45:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A524821F8B08 for ; Mon,  5 Dec 2011 01:45:16 -0800 (PST)
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.035,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am8aatbwxm3t for ; Mon,  5 Dec 2011 01:45:13 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 165F021F861E for ; Mon,  5 Dec 2011 01:45:12 -0800 (PST)
Received: by lagw12 with SMTP id w12so742821lag.31 for ; Mon, 05 Dec 2011 01:45:12 -0800 (PST)
Received: by 10.152.134.101 with SMTP id pj5mr5511788lab.1.1323078311938; Mon, 05 Dec 2011 01:45:11 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ni5sm17097852lab.3.2011.12.05.01.45.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 01:45:09 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-41--973761235
From: Mark Townsley 
In-Reply-To: 
Date: Mon, 5 Dec 2011 10:45:05 +0100
Message-Id: <91B34A74-1187-4273-8CDC-6572B05D12DD@townsley.net>
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 09:45:16 -0000

--Apple-Mail-41--973761235
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 2, 2011, at 7:34 PM, Wes Beebee wrote:

> >Troubleshoot from an admin interface, sure. Dynamically keep track of =
which of the 10 million CPE are "up" and "down", no. You don't do this =
with IPv4, do you? Please do not think of 6rd as a circuit.=20
>=20
> If NUD information is needed (ie. from an ICMPv6 generation =
standpoint), then one could consider setting REACHABLE_TIME in RFC 4861 =
and the Reachable Time in the RA to 1 hour.  I understand that this =
implies a 1 hour delay before noticing that a CPE is no longer =
available, but it may be a good compromise.

Still catching up, but I want to respond to this one from a least a few =
different angles.=20

The 6rd "NUD" is an individual CE troubleshooting mechanism. It is not =
an opportunity to have millions of CEs sending pings and flapping =
interfaces. You'll spend more time debugging this type of behavior than =
you will 6rd itself.=20

6rd is stateless. It's not like it can get "out of sync" like you might =
think with other tunneling protocols. Properly deployed by an ISP, it =
either works or it doesn't. Actively looking for transient behavior and =
automatically responding is a wild goose chase (with a 1 minute timer or =
a 1 hour timer, it doesn't matter).=20

Free's implementation with ~2 Million homes enabled now does not have =
any periodic timers tied to 6rd. It's working just fine for 4 years now.=20=


- Mark

>=20
> - Wes


--Apple-Mail-41--973761235
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii




Re: [v6ops] 6rd Sunsetting



>Troubleshoot from an admin =
interface, sure. Dynamically keep track of which of the 10 million CPE =
are "up" and "down", no. You don't do this with IPv4, do you? Please do =
not think of 6rd as a circuit. 



If NUD information is needed (ie. from an ICMPv6 generation standpoint), =
then one could consider setting REACHABLE_TIME in RFC 4861 and the =
Reachable Time in the RA to 1 hour.  I understand that this implies =
a 1 hour delay before noticing that a CPE is no longer available, but it =
may be a good =
compromise.

Still =
catching up, but I want to respond to this one from a least a few =
different angles. 

The 6rd "NUD" is an =
individual CE troubleshooting mechanism. It is not an opportunity to =
have millions of CEs sending pings and flapping interfaces. You'll spend =
more time debugging this type of behavior than you will 6rd =
itself. 

6rd is stateless. It's not like =
it can get "out of sync" like you might think with other tunneling =
protocols. Properly deployed by an ISP, it either works or it doesn't. =
Actively looking for transient behavior and automatically responding is =
a wild goose chase (with a 1 minute timer or a 1 hour timer, it doesn't =
matter). 

Free's implementation with ~2 =
Million homes enabled now does not have any periodic timers tied to 6rd. =
It's working just fine for 4 years now. 

- =
Mark




- Wes






=

--Apple-Mail-41--973761235--

From mark@townsley.net  Mon Dec  5 05:03:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2349221F8B15 for ; Mon,  5 Dec 2011 05:03:06 -0800 (PST)
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.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 ugbIDpZXOOxj for ; Mon,  5 Dec 2011 05:03:05 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5B21F8B33 for ; Mon,  5 Dec 2011 05:03:04 -0800 (PST)
Received: by lagw12 with SMTP id w12so842931lag.31 for ; Mon, 05 Dec 2011 05:03:03 -0800 (PST)
Received: by 10.152.106.115 with SMTP id gt19mr5920235lab.27.1323090183851; Mon, 05 Dec 2011 05:03:03 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id op2sm17623859lab.6.2011.12.05.05.03.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 05:03:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-43--961887636
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com>
Date: Mon, 5 Dec 2011 14:02:59 +0100
Message-Id: 
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 13:03:06 -0000

--Apple-Mail-43--961887636
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 3, 2011, at 2:58 PM, Hemant Singh (shemant) wrote:

> =20
> =20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Fred Baker (fred)
> Sent: Friday, December 02, 2011 9:06 PM
> To: Lorenzo Colitti
> Cc: v6ops@ietf.org WG
> Subject: Re: [v6ops] 6204bis progress and way forward
> =20
> =20
> >Yes, but the discussion since added 6rd and ds-lite. That is required =
by certain ISPs, and specifically the BBF and Cable >Labs, for networks =
using their technology. In addition, the PCP chairs tell us that =
draft-ietf-pcp-base is headed to the >IESG momentarily as well.
> =20
> Right on PCP.  The plan of record for the rfc6204bis document is to =
add a requirement for a PCP client on the CPE router WAN if the PCP base =
document heads to the IESG and/or the rfc6204bis document is in the =
IESG.  Pending issues for rfc6204bis are outlined below.
> =20
> 1.  6rd sunsetting requirements on the CPE router are close to being =
complete.  Will work with MarkT and the design team to close on this one =
when MarkT gets back from PTO.
> 2.  Coexistence will add details for DS-Lite sunsetting and flush out =
any other details in Coexistence.  Text has already been emailed to the =
design team and some DS-Lite interested parties.  One of the authors of =
the DS-Lite RFC has also worked with

You have to rationalize 6rd and native and ds-lite interfaces together. =
If the "6rd people" just look at the 6rd text and the "ds-lite people" =
just look at the ds-lite text, you'll end up with significant problems.

> myself and Wes to close on the DS-Lite sunsetting text.=20
> 3.  We have responded to all of MarkT comments and some text (mostly =
minor) will change in the document from his comments.

Please do share this minor text that addresses all my concerns. I =
haven't seen it, and I can't imagine "only minor" changes unless you are =
simply dismissing or fundamentally misunderstanding some of the concerns =
I have tried to express.=20

- Mark

> 4.  The WPD-7 bullet in the document is not agreeable to some DHC =
folks and a discussion has been initiated in the DHC WG.  Please see




> =20
>      http://www.ietf.org/mail-archive/web/dhcwg/current/msg12188.html
> =20
> =20
> Thanks,
> =20
> Hemant
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-43--961887636
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Dec 3, 2011, at 2:58 PM, Hemant =
Singh (shemant) wrote:

 
 
-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or=
g] On Behalf Of Fred Baker (fred)
Sent: Friday, December 02, 2011 =
9:06 PM
To: Lorenzo Colitti
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] =
6204bis progress and way forward
 
>Yes, but the discussion since added 6rd and ds-lite. That is =
required by certain ISPs, and specifically the BBF and Cable >Labs, =
for networks using their technology. In addition, the PCP chairs tell us =
that draft-ietf-pcp-base is headed to the >IESG momentarily as =
well.
 
Right on =
PCP.  The plan of record for the rfc6204bis document is to add a =
requirement for a PCP client on the CPE router WAN if the PCP base =
document heads to the IESG and/or the rfc6204bis document is in the =
IESG.  Pending issues for rfc6204bis are outlined =
below.
 
1.  6rd sunsetting =
requirements on the CPE router are close to being complete.  Will =
work with MarkT and the design team to close on this one when MarkT gets =
back from PTO.
2. Coexistence will =
add details for DS-Lite sunsetting and flush out any other details in =
Coexistence.  Text has already been emailed to the design team and =
some DS-Lite interested parties.  One of the authors of the DS-Lite =
RFC has also worked with =


You =
have to rationalize 6rd and native and ds-lite interfaces together. If =
the "6rd people" just look at the 6rd text and the "ds-lite people" just =
look at the ds-lite text, you'll end up with significant =
problems.

myself and Wes to =
close on the DS-Lite sunsetting text. 
3.  We have responded =
to all of MarkT comments and some text (mostly minor) will change in the =
document from his =
comments.

=
Please do share this minor text that addresses all my concerns. I =
haven't seen it, and I can't imagine "only minor" changes unless you are =
simply dismissing or fundamentally misunderstanding some of the concerns =
I have tried to express. 

- =
Mark

4.  The WPD-7 bullet in =
the document is not agreeable to some DHC folks and a discussion has =
been initiated in the DHC WG.  Please =
see




 
      

Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 13:32:39 -0000

I was referring to the Broadband scenario, not to the 3GPP world.

Roberta

-----Original Message-----
From: Frank Bulk [mailto:frnkblk@iname.com]
Sent: domenica 4 dicembre 2011 4.35
To: Maglione Roberta
Cc: v6ops@ietf.org
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta:

Why is this an issue for BNG's in the 3GPP world and not elsewhere?

Frank

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Maglione Roberta
Sent: Wednesday, November 30, 2011 7:16 PM
To: sarikaya@ieee.org
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Yes you can install the aggregate route but you would need either another
dhc option that tells the BNG what aggregate route needs to be installed pe=
r
each customer or you have to do by manual configuration.

In my opinion using PD-exclude is operational much simpler

Roberta
________________________________________
From: Behcet Sarikaya [sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 1:17 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta,

I don't see that a problem either because usually you can install an
aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta

> wrote:
Behcet,
  the reason why you may need to have a single prefix instead of two per
customer is in order to have just a single route to install on the BNG
instead of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya
[sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6.
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.
I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta

>> wrote:
> If you're not using the /64 to number the link between the BNG and the CE=
,
then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered=
.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
unnumbered and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a singl=
e
prefix.

Roberta

________________________________________
From: Lorenzo Colitti
[lorenzo@google.com>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen;
v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta

>>>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than
use the PD-exclude option to tell the CPE to exclude a portion of the
delegated prefix and use it to number the point to point WAN link between
the requesting router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE
router, then the CE router already knows that the /64 is assigned to that
link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
anything.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intende=
d
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

_______________________________________________
v6ops mailing list
v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intende=
d
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intende=
d
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

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



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From shemant@cisco.com  Mon Dec  5 06:08:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6448C21F8BA0 for ; Mon,  5 Dec 2011 06:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 8av27i81GVME for ; Mon,  5 Dec 2011 06:08:50 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7420621F8922 for ; Mon,  5 Dec 2011 06:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5222; q=dns/txt; s=iport; t=1323094130; x=1324303730; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=DeJuOF58ysv3F/Uu5qpYKlMgtYi+48myuRTVOulrfRE=; b=NFVz+4E6DyVecrG9soolqhYpyJxCUaQ+4K2+OhB9Jnt0W6TW5vx9FxcD upEcBw4siQTNW6Fgn2kXh9Jz3WAkC3L1eWXKl1H86Yrav74vYbxKDph8I 2g7UTrqrOjKJCgkJnPlfGzQXbuoe3KK5eGj8PGyzATAQtO6L06jxlsKxM w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoQAAHnP3E6tJXG8/2dsb2JhbABEgk2XRZAqgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIGp5nAZ4jij5jBIgtnmY
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; d="scan'208,217";a="41204162"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2011 14:08:50 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB5E8o1x019870;  Mon, 5 Dec 2011 14:08:50 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 08:08:49 -0600
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_01CCB357.68AA47CD"
Date: Mon, 5 Dec 2011 08:08:48 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377869F@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyzTjqHOZd0oUtwTtSva2nlREKP3gACK1SQ
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 05 Dec 2011 14:08:49.0057 (UTC) FILETIME=[68E9A110:01CCB357]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 14:08:51 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB357.68AA47CD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, December 05, 2011 8:03 AM
To: Hemant Singh (shemant)
Cc: Fred Baker (fred); Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward

=20

>You have to rationalize 6rd and native and ds-lite interfaces together.
If the "6rd people" just look at the 6rd text and the "ds-lite people"
just look at the ds-lite text, you'll end >up with significant problems.

=20

The CE router design team has folks in the 6rd and DS-Lite camps.   We
will also send the text for review to v6ops when the design team review
is completed.  =20

=20

Hemant





=20


------_=_NextPart_001_01CCB357.68AA47CD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, =
December 05, 2011 8:03 AM
To: Hemant Singh =
(shemant)
Cc: Fred Baker (fred); Lorenzo Colitti; =
v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way =
forward
 
>You have to =
rationalize 6rd and native and ds-lite interfaces together. If the =
"6rd people" just look at the 6rd text and the "ds-lite =
people" just look at the ds-lite text, you'll end >up with significant =
problems.
 
The CE router design team has folks in the 6rd and DS-Lite camps. =
  We will also send the text for review to v6ops when the =
design team review is completed.   
 
Hemant


 

------_=_NextPart_001_01CCB357.68AA47CD--

From C.Donley@cablelabs.com  Mon Dec  5 07:32:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C4B21F8B67 for ; Mon,  5 Dec 2011 07:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.484
X-Spam-Level: 
X-Spam-Status: No, score=-0.484 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Fg6EqGiRAWGi for ; Mon,  5 Dec 2011 07:32:26 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0BC21F8B6B for ; Mon,  5 Dec 2011 07:32:26 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pB5FWLVq030231; Mon, 5 Dec 2011 08:32:21 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 5 Dec 2011 08:32:20 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 5 Dec 2011 08:32:21 -0700
From: Chris Donley 
To: "Hemant Singh (shemant)" , Mark Townsley , "v6ops@ietf.org" 
Date: Mon, 5 Dec 2011 08:33:39 -0700
Thread-Topic: [v6ops] Section 4.4 of 6204-bis
Thread-Index: AcyzYxP0WPa1zasdQtiakaKQ8FY2ew==
Message-ID: 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE3D8@XMB-RCD-109.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CAFE478B2F92Ecdonleycablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [v6ops] Section 4.4 of 6204-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 15:32:28 -0000

--_000_CAFE478B2F92Ecdonleycablelabscom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Please see in-line (marked with [CD]).


Chris

From: Hemant Singh >
Date: Thu, 1 Dec 2011 09:45:57 -0700
To: Mark Townsley >, "v6ops@iet=
f.org" >
Cc: Chris Donley >, L=
orenzo Colitti >, "STARK, BAR=
BARA H" >
Subject: RE: [v6ops] Section 4.4 of 6204-bis

Mark,

Thanks for the review.  Comments below.  Chris, Barbara, and Lorenzo, pleas=
e see some responses below that you could also reply to.

From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Section 4.4 of 6204-bis







>4.4.1.  6rd





 >  The IPv6 CE Router can be used to offer IPv6 service to a LAN, even

 >  when the WAN access network only supports IPv4.  One technology that

 >  supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment

 >  (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside

 >  IPv4 at the IPv6 CE Router and sends it to a Service Provider Border

 >  Relay (BR).  The IPv6 CE Router calculates a 6rd delegated IPv6

 >  prefix during 6rd configuration, and sub-delegates the 6rd delegated

 >  prefix to devices in the LAN.

>IMHO, the above is just making the document longer. You can simply include=
 the sentence below. RFC 5969 is a normative, so you can rely on the reader=
 to go read >it.
[CD] Since 6RD is a "SHOULD", we're trying to provide some context for vend=
ors who might not closely follow the IETF as to why they might want to impl=
ement this and how. Same with DS-Lite below.


>   The IPv6 CE Router SHOULD implement 6rd functionality as specified in

>   [RFC5969].



This is an editorial nit.  Chris Donley added the text to give some perspec=
tive to the CPE router vendor.   =93Just making the document longer=94 is a=
 nit as well.   I am open either way.





>   6rd requirements:



>   6RD-1:  If the IPv6 CE Router implements 6rd functionality, the CE

>           Router WAN interface MUST support at least one 6rd Virtual

>           Interface.

>6rd is implemented with a "6rd virtual interface" (see terminology section=
 of RFC 5969) which is not bound to a WAN interface as you are suggesting i=
n this >requirement. I would remove the requirement >altogether, as it is p=
art of RFC 5969 anyway, and by re-specifying we run the risk of introducing=
 inconsistencies.

The WAN keyword is used to point out that the CE router does not initiate 6=
rd in the LAN segment.   It is crystal clear the 6rd virtual interface is a=
 virtual network interface and such an interface is not bound to any physic=
al interface.  However, the traffic from the 6rd virtual interface uses the=
 WAN physical interface to reach the SP.   Thus I think this is a nit and t=
he text in rfc6204bis stays.


>   6RD-2:  If the IPv6 CE router implements 6rd functionality, it MUST

>           support 6rd configuration via the 6rd DHCPv4 Option (212) and

>           if the IPv6 CE router is capable of automated configuration

>           of IPv4 through IPCP (i.e., over a PPP connection), it MUST

>           support user-entered configuration of 6rd.

>Why not just say it MUST support DHCPv4 option 212 and Manual configuratio=
n and stop at that? If we are going to include manual config, it is effecti=
vely >*always* an option, not just for PPP or any other >type of access lin=
k. Just make it a MUST and be done.

>Further, if we are going to mention PPP, rather than falling back to manua=
l only, why not allow DHCP configuration after PPP IPCP is finished?

Agree.  Barbara can comment as well since she provided such text.

>From RFC2131: "DHCPINFORM   -  Client to server, asking only for local con=
figuration parameters; client already has externally configured network add=
ress."

>Back when the PPP folks actively decided to stop duplicating DHCP function=
ality in IPCP, this was the recommended approach (and Windows stacks and th=
e like actually try to obtain additional >parameters for PPP connections af=
ter IPCP comes up, though often the network does not have any additional pa=
rameters to give...). This gives PPP connections a pretty decent chance to =
work with 6rd >automatically, using the same DHCP configuration as non-PPP.

Agree.




>   6RD-3:  If the CE router implements 6rd functionality, it MUST allow

>           the user to specify whether all IPv6 traffic goes to the 6rd

>           Border Relay, or whether IPv6 traffic to other destinations

>           within the same 6rd domain are routed directly to those







>Singh, et al.             Expires May 25, 2012                 [Page 13]

 

>Internet-Draft         IPv6 CE Router Requirements         November 2011





>           destinations.  The CE router MAY use other mechanisms to

>           configure this.  Such mechanisms are outside the scope of

>           this document.

>Do you really mean the "user" is supposed to be able to specify whether IP=
v6 traffic always going through the BR, or the "operator" is supposed to be=
 able to >specify this?

>This behavior, while straight-forward to implement as it is effectively re=
moving a more-specific route on the 6rd virtual interface, is out of scope =
of RFC 5969 >as currently defined. There is no way to specify this in DHCPv=
4 configuration. One might be able to configure this from the network with =
PIO or DHCPv6 route >options in a general manner, but this hasn't been spec=
ified anywhere that I am aware of within the context of 6rd. I understand t=
he BBF has included some >specifics around this, and perhaps it is best if =
those requirements stay in the BBF or at least we provide a reference to th=
em from here. Otherwise, this >requirement remains under-specified as writt=
en, and if expounded would effectively be an update (in the formal sense) t=
o RFC 5969.

How does BBF specify the CE router gets configured to go directly to other =
destinations?


>   6RD-4:  If 6rd is operational on the IPv6 CE Router, multicast data

>           MUST NOT be sent on any 6rd tunnel.

>As long as the high-level requirement is RFC 5969 only, there is no need t=
o mention multicast. If in the future someone implements 6rd multicast (the=
re are >drafts on it), why stop them? Best to just remove >this (non-)requi=
rement from the document.

When the future mcast over 6rd document gets to be an RFC, the CPE router d=
ocument also changes.  Till that happens, this bullet stays.


>   6RD-5:  The CE Router MUST NOT forward 6RD traffic over a DS-Lite

>           ([RFC6333]) tunnel.

>Again, why over-specify? Sure, the operational steps you take should not l=
ead you down this path, but if the router is following a logical set of rou=
ting and >virtual interface constructs, this would just work.  Why make the=
 CE vendor go out of their way to check to see if this is happening and dro=
p packets?

Implementations do stupid things and thus it=92s good to specify such text.=
  At the Taipei IETF during a hallway conversation between myself, Lorenzo,=
 Ole, and some others, I heard Lorenzo say, =93it=92s good to include rules=
 such as this one.=94  Lorenzo can keep me honest.

[CD] Right. In our lab, I've seen too many times that such strange feature =
interactions do occur.  I can foresee a device that gets both 6rd and ds-li=
te configuration, tries to bring up both tunnels, and sets up routes so tha=
t one tunnel will flow through the other.  I heard of an implementation tha=
t shuts down the native interface when it gets a tunnel config. If such a t=
hing were to happen, I want to avoid the conversation of "where in 6204bis =
does it say we shouldn't forward 6rd through ds-lite (or vice-versa)."
>4.4.2.  Dual-Stack Lite(DS-Lite)





>   Even as users migrate from IPv4 to IPv6 addressing, a significant

>   percentage of Internet resources and content will remain accessible

>   only through IPv4.  Also, many end-user devices will only support

>   IPv4.  As a consequence, Service Providers require mechanisms to

>   allow customers to continue to access content and resources using

>   IPv4 even after the last IPv4 allocations have been fully depleted.

>   One technology that can be used for IPv4 address extension is DS-

>   Lite.



>   DS-Lite enables a Service Provider to share IPv4 addresses among

>   multiple customers by combining two well-known technologies: IP in IP

>   (IPv4-in-IPv6) tunneling and Carrier Grade NAT.  More specifically,

>   Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at

>   the IPv6 CE Router and sends it to a Service Provider Address Family

>   Transition Router (AFTR).  Configuration of the IPv6 CE Router to

>   support IPv4 LAN traffic is outside the scope of this document.



>IMHO - As with the 6rd "summary" text, I think the most important line is =
the following one, and the previous paragraphs may be omitted or shrunk to =
one or two >lines at best.




>   The IPv6 CE Router SHOULD implement DS-Lite functionality as

>   specified in [RFC6333].



Same reply as above.  Am open to change.  Chris added such text.  He can re=
ply.

[CD] Same as above =96 for people who don't regularly follow RFCs, this pro=
vides context as to why a vendor might want to implement DS-Lite (and yes, =
there are questions).



>   WAN requirements:



>   DLW-1:  To facilitate IPv4 extension over an IPv6 network, if the CE

>           Router supports DS-Lite functionality, the CE Router WAN

>           interface MUST implement a B4 Interface as specified in

>           [RFC6333].

>As with the "6rd interface" case, this really seems repetitive. It should =
be sufficient to say "implement DS-Lite" ... Also, virtual interfaces are n=
ot tied to >any physical interfaces per se, they exist independently. They =
may be used for WAN connectivity, but they are a fully separate interface i=
n terms of the RIB and >such.

Same response as earlier about the same comment for 6rd text.   WAN separat=
es from the LAN of the CPE.  Text stays.

I and reply to other comments in another set of emails.

Thanks,

Hemant







--_000_CAFE478B2F92Ecdonleycablelabscom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Please see in-line (m=
arked with [CD]).

=

<=
font class=3D"Apple-style-span" face=3D"Calibri">
Chris

From:  Hemant Singh <shemant@cisco.com>
Date:  Thu, 1 Dec 2011 09:45:57 -0700
To:  Mark Townsley <mark@townsley.net>, "v6ops@ietf.org" <v6o=
ps@ietf.org>
Cc:  Chris D=
onley <c.donley@cablelabs.com<=
/a>>, Lorenzo Colitti <lorenzo@=
google.com>, "STARK, BARBARA H" <bs7652@att.com>
Subj=
ect:  RE: [v6ops] Section 4.4 of 6204-bis

Mark,
 
Thank=
s for the review.  Comments below.  Chris, Barbara, and Lorenzo, =
please see some responses below that you could also reply to.
 
From: v6ops-bounc=
es@ietf.org [mailto:v6ops-bou=
nces@ietf.org] On Behalf Of Mark Townsley
Sent: Thursd=
ay, December 01, 2011 6:22 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Section 4.4 of =
6204-bis
 
<=
div>
 
 
 
>4.4.1.  6rd
&=
nbsp;
 
 >  The IPv6 CE Router can be =
used to offer IPv6 service to a LAN, even
 >  when the=
 WAN access network only supports IPv4.  One technology that
 >  supports IPv6 service over an IPv4 network is IPv6 Rapid De=
ployment
 ><=
span style=3D"color:black">  (6rd). 6rd encapsulates IPv6 traffic from=
 the end user LAN inside
 >  IPv4 at the IPv6 CE Route=
r and sends it to a Service Provider Border
 >  Relay =
(BR).  The IPv6 CE Router calculates a 6rd delegated IPv6
 >  prefix during 6rd configuration, and sub-delegates the 6rd del=
egated
 >  prefix to devices in the LAN.
 
>IMHO, the above is just making the document longer. Y=
ou can simply include the sentence below. RFC 5969 is a normative, so you c=
an rely on the reader to go read >i=
t. 
[CD] Since 6RD is a "SHO=
ULD", we're trying to provide some context for vendors who might not c=
losely follow the IETF as to why they might want to implement this and how.=
 Same with DS-Lite below.

>  =
 The IPv6 CE Router SHOULD implement 6rd functionality as specified in=

>   [RFC5969].
 
This is an editorial nit.&nb=
sp; Chris Donley added the text to give some perspective to the CPE router =
vendor.   =93Just making the document longer=94 is a nit as well.=
   I am open either way.   
&nbs=
p;
 
>   6rd requirements:
 
>   6RD-1:  If the I=
Pv6 CE Router implements 6rd functionality, the CE
<=
pre style=3D"page-break-before:always">>       =
    Router WAN interface MUST support at least one 6rd Virtu=
al
>  &nb=
sp;        Interface.<=
/pre>
 
>6rd is implemented with a "6rd virtual interface"=
; (see terminology section of RFC 5969) which is not bound to a WAN interfa=
ce as you are suggesting in this >r=
equirement. I would remove the requirement &g=
t;altogether, as it is part of RFC 5969 anyway, and by re-specifying=
 we run the risk of introducing inconsistencies. 
 
The WAN keyword is used to point out that the CE router doe=
s not initiate 6rd in the LAN segment.   It is crystal clear the =
6rd virtual interface is a virtual network interface and such an interface =
is not bound to any physical interface.  However, the traffic from the=
 6rd virtual interface uses the WAN physical interface to reach the SP.&nbs=
p;  Thus I think this is a nit and the text in rfc6204bis stays.

>   6RD-2:  If the IPv6 CE router i=
mplements 6rd functionality, it MUST
>         &n=
bsp; support 6rd configuration via the 6rd DHCPv4 Option (212) and
>    &n=
bsp;      if the IPv6 CE router is capable of auto=
mated configuration
>           of IPv4 thro=
ugh IPCP (i.e., over a PPP connection), it MUST
>       &nb=
sp;   support user-entered configuration of 6rd.  
 
>Why not just say it MUST support DHCPv4 option 21=
2 and Manual configuration and stop at that? If we are going to includ=
e manual config, it is effectively >*always* an option, not just for PPP or any other >type of access link. Just make it a MUST and be done.=

 
>Further, if we are going to mention PPP,=
 rather than falling back to manual only, why not allow DHCP configuration =
after PPP IPCP is finished?
>   6RD-3:  If the CE=
 router implements 6rd functionality, it MUST allow=

><=
/span>       =
;    the user to specify whether all IPv6 traffic goes to th=
e 6rd
>  =
         Border Relay, or whether I=
Pv6 traffic to other destinations
>         &nbs=
p; within the same 6rd domain are routed directly to those
=
 
 
 
>Singh, et al.&n=
bsp;            Expi=
res May 25, 2012          &nbs=
p;      [Page 13]
 <=
/a>
>=
Internet-Draft    =
     IPv6 CE Router Requirements    =
;     November 2011
 
 
>=
      &nbs=
p;    destinations.  The CE router MAY use other mechan=
isms to
> &nbs=
p;         configure this.  Su=
ch mechanisms are outside the scope of
>         =
  this document.
 
>Do you really mean=
 the "user" is supposed to be able to specify whether IPv6 traffi=
c always going through the BR, or the "operator" is supposed to b=
e able to >specify this?=

 
>This behavior, while straight-forward to imple=
ment as it is effectively removing a more-specific route on the 6rd virtual=
 interface, is out of scope of RFC 5969 ><=
/span>as currently defined. There is no way to specify this in DHCPv4 confi=
guration. One might be able to configure this from the network with PIO or =
DHCPv6 route >options in a general =
manner, but this hasn't been specified anywhere that I am aware of within t=
he context of 6rd. I understand the BBF has included some >specifics around this, and perhaps it is best if th=
ose requirements stay in the BBF or at least we provide a reference to them=
 from here. Otherwise, this >requir=
ement remains under-specified as written, and if expounded would effectivel=
y be an update (in the formal sense) to RFC 5969. 

How does BBF specify th=
e CE router gets configured to go directly to other destinations?  
 
>   6RD-4:  If 6rd is operational on th=
e IPv6 CE Router, multicast data
>         &nbs=
p; MUST NOT be sent on any 6rd tunnel.
>A=
s long as the high-level requirement is RFC 5969 only, there is no need to =
mention multicast. If in the future someone implements 6rd multicast (there=
 are >drafts on it), why stop them?=
 Best to just remove >this (non-)re=
quirement from the document.

When the future mcast over 6rd document gets to be=
 an RFC, the CPE router document also changes.  Till that happens, thi=
s bullet stays.
 
>   6RD-5:  The CE Ro=
uter MUST NOT forward 6RD traffic over a DS-Lite
>       &n=
bsp;   ([RFC6333]) tunnel.
 <=
/o:p>
>Again, why over=
-specify? Sure, the operational steps you take should not lead you down thi=
s path, but if the router is following a logical set of routing and >virtual interface constructs, this would =
just work.  Why make the CE vendo=
r go out of their way to check to see if this is happening and drop packets=
? 

Implementations do stupid things and thus it=92s good to specify such t=
ext.  At the Taipei IETF during a hallway conversation between myself,=
 Lorenzo, Ole, and some others, I heard Lorenzo say, =93it=92s good to incl=
ude rules such as this one.=94  Lorenzo can keep me honest.

[CD] Right. In ou=
r lab, I've seen too many times that such strange feature interactions do o=
ccur.  I can foresee a device that gets both 6rd and ds-lite configura=
tion, tries to bring up both tunnels, and sets up routes so that one tunnel=
 will flow through the other.  I heard of an implementation that shuts=
 down the native interface when it gets a tunnel config. If such a thing we=
re to happen, I want to avoid the conversation of "where in 6204bis do=
es it say we shouldn't forward 6rd through ds-lite (or vice-versa)."
>4.4.2.  Dual-=
Stack Lite(DS-Lite)
 
 =

>   Even as users m=
igrate from IPv4 to IPv6 addressing, a significant
<=
pre style=3D"page-break-before:always">>   percentage of Internet resour=
ces and content will remain accessible
>   only through IPv4.  Also, many end-u=
ser devices will only support
>   IPv4.  As a consequence, Service Providers re=
quire mechanisms to
>   allow customers to continue to access content and resources =
using
>  =
 IPv4 even after the last IPv4 allocations have been fully depleted.
>   One technol=
ogy that can be used for IPv4 address extension is DS-
&g=
t;   Lite.
 
>   D=
S-Lite enables a Service Provider to share IPv4 addresses among<=
/span>
>   multiple custome=
rs by combining two well-known technologies: IP in IP
>=
;   (IPv4-in-IPv6) tunneling a=
nd Carrier Grade NAT.  More specifically,
>   Dual-Stack-Lite encapsulates IPv4=
 traffic inside an IPv6 tunnel at
>   the IPv6 CE Router and sends it to a Service =
Provider Address Family
>   Transition Router (AFTR).  Configuration of the IPv=
6 CE Router to
>&nb=
sp;  support IPv4 LAN traffic is outside the scope of this document.
 
=
 
>IMHO - As with t=
he 6rd "summary" text, I think the most important line is the fol=
lowing one, and the previous paragraphs may be omitted or shrunk to one or =
two >lines at best. 
 
>   The IPv6 CE Router SHO=
ULD implement DS-Lite functionality as
>   specified in [RFC6333].
 =

Same reply as above.  Am open to change.  Chris add=
ed such text.  He can reply.
[CD] Same as above =96 for people who don't regularly follow RFCs, t=
his provides context as to why a vendor might want to implement DS-Lite (an=
d yes, there are questions).
 
>   WAN requirements:
 =

>   DLW-1:  To=
 facilitate IPv4 extension over an IPv6 network, if the CE
>     &nbs=
p;     Router supports DS-Lite functionality, the CE Ro=
uter WAN
> &nb=
sp;         interface MUST implemen=
t a B4 Interface as specified in
>         &nbs=
p; [RFC6333]=
.
 
<=
div>
>As with the "6rd interface" =
case, this really seems repetitive. It should be sufficient to say "im=
plement DS-Lite" ... Also, virtual interfaces are not tied to >any physical interfaces per se, they exist=
 independently. They may be used for WAN connectivity, but they are a fully=
 separate interface in terms of the RIB and &=
gt;such. 

Same response as earlier about the same comment for 6rd =
text.   WAN separates from the LAN of the CPE.  Text stays.<=
/span>
&=
nbsp;
I and reply =
to other comments in another set of emails.
 
Thanks,
 
Hemant
 
 
 
=



--_000_CAFE478B2F92Ecdonleycablelabscom_--

From mark@townsley.net  Mon Dec  5 07:40:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69C21F8C0F for ; Mon,  5 Dec 2011 07:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.402
X-Spam-Level: 
X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.196,  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 krtVLi8g5kjo for ; Mon,  5 Dec 2011 07:40:26 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8455621F8BEF for ; Mon,  5 Dec 2011 07:40:25 -0800 (PST)
Received: by eekd4 with SMTP id d4so462154eek.31 for ; Mon, 05 Dec 2011 07:40:24 -0800 (PST)
Received: by 10.14.3.222 with SMTP id 70mr1026138eeh.29.1323099624465; Mon, 05 Dec 2011 07:40:24 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id zv9sm14275748bkb.0.2011.12.05.07.40.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 07:40:13 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--952457013
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com>
Date: Mon, 5 Dec 2011 16:40:10 +0100
Message-Id: <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 15:40:26 -0000

--Apple-Mail-1--952457013
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 2, 2011, at 6:43 PM, Hemant Singh (shemant) wrote:

> =20
> From: Mark Townsley [mailto:mark@townsley.net]=20
> Sent: Thursday, December 01, 2011 7:28 PM
> To: Hemant Singh (shemant)
> Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; =
v6ops@ietf.org
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> >Troubleshoot from an admin interface, sure. Dynamically keep track of =
which of the 10 million CPE are "up" and "down", no. You don't do this =
with IPv4, do you? Please do not think of 6rd as a circuit.=20
> =20
> The 10 million number for CPE is interesting.   A SP should manage =
their network that a single BR does not get so many CPEs to support and =
the BR. =20

You mean the SP should manage their network so that a given BR doesn't =
get more traffic than it can handle. The BRs have no concept of how many =
CPEs they support.=20

- Mark


> =20
> Hemant


--Apple-Mail-1--952457013
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Dec 2, 2011, at 6:43 PM, Hemant =
Singh (shemant) wrote:

From: Mark Townsley =
[mailto:mark@townsley.net] 
Sent: Thursday, December 01, 2011 =
7:28 PM
To: Hemant Singh =
(shemant)
Cc: Lorenzo Colitti; Victor =
Kuarsingh; Tom Taylor; Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
>Troubleshoot from an admin interface, =
sure. Dynamically keep track of which of the 10 million CPE are "up" and =
"down", no. You don't do this with IPv4, do you? Please do not think of =
6rd as a circuit. 
The =
10 million number for CPE is interesting.   A SP should manage =
their network that a single BR does not get so many CPEs to support and =
the =
BR.  

You mean the SP should manage their network so that a =
given BR doesn't get more traffic than it can handle. The BRs have no =
concept of how many CPEs they support. 

- =
Mark



In-Reply-To: <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyzZDSXfOAC7dsdTGia8UkRp8vnjAAAeCMA
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 05 Dec 2011 15:56:34.0658 (UTC) FILETIME=[76B60C20:01CCB366]
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 15:56:47 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB366.760C8DF7
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, December 05, 2011 10:40 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>You mean the SP should manage their network so that a given BR doesn't =
get more traffic than it can handle. The BRs have no concept of how many =
CPEs they support.=20

=20

Na=EFve BR implementation.   Any sensible device should be coded =
defensively to not serve any more 6rd CE if the BR cpu is say, at 50%.  =
Further, why can't the SP manage their network to load balance between =
BRs? =20

=20

Hemant


------_=_NextPart_001_01CCB366.760C8DF7
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, =
December 05, 2011 10:40 AM
To: Hemant Singh =
(shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; =
Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>You mean the =
SP should manage their network so that a given BR doesn't get more =
traffic than it can handle. The BRs have no concept of how many CPEs =
they support. 
 
Na=EFve BR implementation.=A0=A0 Any sensible device should be coded =
defensively to not serve any more 6rd CE if the BR cpu is say, at =
50%.=A0 Further, why can’t the SP manage their network to load =
balance between BRs?=A0 
 
Hemant

------_=_NextPart_001_01CCB366.760C8DF7--

From gert@space.net  Mon Dec  5 08:03:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422821F8C39 for ; Mon,  5 Dec 2011 08:03:49 -0800 (PST)
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=[AWL=0.000,  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 OjBi5M+VOlBD for ; Mon,  5 Dec 2011 08:03:49 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0321F8C35 for ; Mon,  5 Dec 2011 08:03:48 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1F103F895B for ; Mon,  5 Dec 2011 17:03:47 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 07861F894D for ; Mon,  5 Dec 2011 17:03:47 +0100 (CET)
Received: (qmail 6750 invoked by uid 1007); 5 Dec 2011 17:03:46 +0100
Date: Mon, 5 Dec 2011 17:03:46 +0100
From: Gert Doering 
To: "Hemant Singh \(shemant\)" 
Message-ID: <20111205160346.GI72014@Space.Net>
References:  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30377872D@XMB-RCD-109.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30377872D@XMB-RCD-109.cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 16:03:49 -0000

Hi,

On Mon, Dec 05, 2011 at 09:56:33AM -0600, Hemant Singh (shemant) wrote:
> Naïve BR implementation.   Any sensible device should be coded defensively to not serve any more 6rd CE if the BR cpu is say, at 50%.  

Now I'm seriously curious how you think this would be done.

Like, with the non-existing negotiation protocol between BR and CPEs, 
which the CPEs do not use to request 6rd service from the BR, which 
could then prompt the BR to check it's non-existing state database to 
see whether it would like to handle more CPEs, whose *number* would
not have any effect on its load anyway.

> Further, why can't the SP manage their network to load balance between BRs?  

Of course they can.  Which is the upside of the stateless nature of the BR.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From wbeebee@cisco.com  Mon Dec  5 08:11:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6021F8C6E for ; Mon,  5 Dec 2011 08:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.659
X-Spam-Level: 
X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZzWTI0ycz+G for ; Mon,  5 Dec 2011 08:11:47 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9A21F8C6A for ; Mon,  5 Dec 2011 08:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1649; q=dns/txt; s=iport; t=1323101507; x=1324311107; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=l6eS0V/XIUs7bWbVZlcCnmPUtfoi8eLJmlxGwbnyZuE=; b=hmDWp1EywCKJflEXycKn0/ylbuVZavVDw7mtFRjD7LLjcv8eHgCXciuc mzhqFIHQBJnM38dT92A0lPWZkGVz+NjViuPLiNHRewhyszdgM8uAF7fGA WHILnEHzGxtotcwfEEoqRfO4lFt5dNctvYocFx7LdY3L1ccw76zSyHJ40 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0HALTs3E6tJXG//2dsb2JhbABEgk2HAJ9qgQQCgQWBaQkBAQEDARIBKjwFDQEIAwGBGQEBBAENJ4dlllIBnjuLIQSHeTSML44ChDQ
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; d="scan'208,217";a="41231720"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 05 Dec 2011 16:11:46 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB5GBjE5003331;  Mon, 5 Dec 2011 16:11:46 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 10:11:45 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Mon,  5 Dec 2011 16:11:45 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 05 Dec 2011 11:11:44 -0500
From: Wes Beebee 
To: Mark Townsley , "Hemant Singh   (shemant)" 
Message-ID: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyzaJS4QNfM85Arl0a32Mzh10Tx3w==
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3405928304_604872"
X-OriginalArrivalTime: 05 Dec 2011 16:11:45.0057 (UTC) FILETIME=[9559E910:01CCB368]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 16:11:48 -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_3405928304_604872
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

> You have to rationalize 6rd and native and ds-lite interfaces together. I=
f the
"6rd people" just look at the 6rd text and the "ds-lite people" just look a=
t the
ds-lite text, you'll end up with significant problems.

Which is precisely why we=B9re addressing coexistence of both 6rd and ds-lite
in the same document - 6204bis.  Simply having just a =B36rd sunsetting
document=B2 alone is not sufficient to address the problems a CPE router
vendor will face.

- Wes

--B_3405928304_604872
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



Re: [v6ops] 6204bis progress and way forward


> You have to rationalize 6rd and native and ds-lite interfaces togethe=
r. If the "6rd people" just look at the 6rd text and the "ds-=
lite people" just look at the ds-lite text, you'll end up with signific=
ant problems.



Which is precisely why we’re addressing coexistence of both 6rd and d=
s-lite in the same document - 6204bis.  Simply having just a “6rd=
 sunsetting document” alone is not sufficient to address the problems =
a CPE router vendor will face.



- Wes




--B_3405928304_604872--


From shemant@cisco.com  Mon Dec  5 08:12:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0421F8C8E for ; Mon,  5 Dec 2011 08:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level: 
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 CwxwvQasHnTk for ; Mon,  5 Dec 2011 08:12:34 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAA21F8C83 for ; Mon,  5 Dec 2011 08:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4924; q=dns/txt; s=iport; t=1323101554; x=1324311154; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=83Gw/itciLxrp3C/zKqAS/37ubI4E3GANRvGNfqBceM=; b=YvsRFsDESEhEj+Zv6WpJY9vNN8E3C0IpTkklKlL+Wr6hl1/xat4ZsT1T k8wfN4JJSLHClX/5jlpEA9HQnn00Ea1LnxoY1qHvaAGlyIFasgwVU+LOg D0MNbQ/nG+fBLsgMlL0FHdkOjEdlMwkoKe9nYDTWkbzhTF730oJh1UgKH 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIAADvs3E6tJXG//2dsb2JhbABEgk2XR5ApgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIGp46AZ47ij5jBIgtnmY
X-IronPort-AV: E=Sophos;i="4.71,299,1320624000"; d="scan'208,217";a="41253869"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2011 16:12:33 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB5GCXLM004023;  Mon, 5 Dec 2011 16:12:33 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 10:12:32 -0600
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_01CCB368.B171EDFF"
Date: Mon, 5 Dec 2011 10:12:32 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778757@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyzTjqHOZd0oUtwTtSva2nlREKP3gAGkOAw
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303778583@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 05 Dec 2011 16:12:32.0442 (UTC) FILETIME=[B19849A0:01CCB368]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 16:12:35 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB368.B171EDFF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, December 05, 2011 8:03 AM
To: Hemant Singh (shemant)
Cc: Fred Baker (fred); Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward

=20

>Please do share this minor text that addresses all my concerns. I
haven't seen it, and I can't imagine "only minor" changes unless you are
simply dismissing or fundamentally misunderstanding some of the
>concerns I have tried to express.=20

=20

Please see my replies to you review in several emails sent to v6ops.  My
responses do say when I thought your comment was a nit.

=20

Hemant


------_=_NextPart_001_01CCB368.B171EDFF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, =
December 05, 2011 8:03 AM
To: Hemant Singh =
(shemant)
Cc: Fred Baker (fred); Lorenzo Colitti; =
v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way =
forward
 
>Please do =
share this minor text that addresses all my concerns. I haven't seen it, =
and I can't imagine "only minor" changes unless you are simply =
dismissing or fundamentally misunderstanding some of the >concerns I have tried to =
express. 
 
Please see my replies to you review in several emails sent to =
v6ops.  My responses do say when I thought your comment was a =
nit.
 
Hemant

------_=_NextPart_001_01CCB368.B171EDFF--

From shemant@cisco.com  Mon Dec  5 08:57:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12521F8BE8 for ; Mon,  5 Dec 2011 08:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.533
X-Spam-Level: 
X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ETCyTXyTuPLd for ; Mon,  5 Dec 2011 08:57:19 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFDC21F8BA9 for ; Mon,  5 Dec 2011 08:57:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5914; q=dns/txt; s=iport; t=1323104239; x=1324313839; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=HDjeaJf5NTleA/ExL/PppPW7C6T025EECemF8B0TW3c=; b=d5IBXkH7SJgNKQwgSBoPm/4v0rkBJTUjuQY/DaDFUs2gRIHjPYRShsiP uLEZe27+EXz6btpBqQg6sSfhQpmJTTMMbC16dockuD1mGeDGcN3qHG0WT i5848QqWQaQTEOi6aFsV3LEu9uzT7RsN3qtxz56FA00Gg4o9rQM1U2iVI w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEBABEppk6tJXG+/2dsb2JhbACCJY4gjhZ4lFWSNIYZBIZQjXmKXA
X-IronPort-AV: E=Sophos;i="4.69,625,1315180800"; d="scan'208,217";a="38753920"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Dec 2011 16:57:19 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB5GvI2g006095;  Mon, 5 Dec 2011 16:57:18 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 10:57:17 -0600
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_01CCB36E.F1FB46F8"
Date: Mon, 5 Dec 2011 10:57:17 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3037787A9@XMB-RCD-109.cisco.com>
In-Reply-To: <20111205160346.GI72014@Space.Net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyzZ3nAtiSk7sYGQdCC/5EKAnVnugABqEaQ
References:  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE684@XMB-RCD-109.cisco.com> <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30377872D@XMB-RCD-109.cisco.com> <20111205160346.GI72014@Space.Net>
From: "Hemant Singh (shemant)" 
To: "Gert Doering" 
X-OriginalArrivalTime: 05 Dec 2011 16:57:17.0773 (UTC) FILETIME=[F22D47D0:01CCB36E]
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 16:57:20 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB36E.F1FB46F8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: Gert Doering [mailto:gert@space.net]=20
Sent: Monday, December 05, 2011 11:04 AM
To: Hemant Singh (shemant)
Cc: Mark Townsley; Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

 =20

>Now I'm seriously curious how you think this would be done.

=20

>Like, with the non-existing negotiation protocol between BR and CPEs,=20

>which the CPEs do not use to request 6rd service from the BR, which=20

>could then prompt the BR to check it's non-existing state database to=20

>see whether it would like to handle more CPEs, whose *number* would

>not have any effect on its load anyway.

=20

=20

What metric is used to load-balance 6rd between two BR's?  Use the same
metric as internal code in a single BR and also make sure the BR cpu
does not go over a certain x% load.  If the load is exceeded, the BR
drops data.

=20

Hemant

=20

=20


------_=_NextPart_001_01CCB36E.F1FB46F8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
-----Original Message-----
From: Gert Doering =
[mailto:gert@space.net] 
Sent: Monday, December 05, 2011 11:04 =
AM
To: Hemant Singh (shemant)
Cc: Mark Townsley; Alexandre Cassen; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
  
>Now I'm =
seriously curious how you think this would be =
done.
 
>Like, with the =
non-existing negotiation protocol between BR and CPEs, =

>which the CPEs =
do not use to request 6rd service from the BR, which =

>could then =
prompt the BR to check it's non-existing state database to =

>see whether it =
would like to handle more CPEs, whose *number* =
would
>not have any =
effect on its load anyway.
 
 
What =
metric is used to load-balance 6rd between two BR’s?  Use the =
same metric as internal code in a single BR and also make sure the BR =
cpu does not go over a certain x% load.  If the load is exceeded, =
the BR drops data.
 
Hemant
 
 

------_=_NextPart_001_01CCB36E.F1FB46F8--

From Tina.Tsou.Zouting@huawei.com  Mon Dec  5 09:55:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4B21F8C43 for ; Mon,  5 Dec 2011 09:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.47
X-Spam-Level: 
X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Y7JKWA+E3FDl for ; Mon,  5 Dec 2011 09:55:34 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68621F8C4F for ; Mon,  5 Dec 2011 09:55:33 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVQ003GISGC0X@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 06 Dec 2011 01:55:24 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVQ00LQTSGBHS@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 06 Dec 2011 01:55:24 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFK74074; Tue, 06 Dec 2011 01:55:23 +0800
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Dec 2011 01:55:21 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 06 Dec 2011 01:55:14 +0800
Date: Mon, 05 Dec 2011 17:55:13 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: "Hemant Singh (shemant)" , "frnkblk@iname.com" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_ppxawAAmbQa+DqLy1MQchw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AcyjbMdriVaVmflTEk2DrH6PcFso4QAOym+wAYlntHD//6cCgIAAJMWAgAgTXICAAARqgIAAAiwAgAhc2YCAAL9KAIABhI9p//88p4D//nDHUA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3037785D9@XMB-RCD-109.cisco.com>  
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 17:55:36 -0000

--Boundary_(ID_ppxawAAmbQa+DqLy1MQchw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Please see comments inline.

Thanks,
Tina
From: "Hemant Singh (shemant)" >
Date: December 4, 2011 6:32:28 AM PST
To: Frank Bulk >
Cc: >
Subject: Re: [v6ops] 6rd Sunsetting
Frank,


From: Frank Bulk [mailto:frnkblk@iname.com]
Sent: Saturday, December 03, 2011 10:08 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA H
Subject: RE: [v6ops] 6rd Sunsetting


>If this CPE has manually-configured 6rd configured, why would the CPE sunset 6rd at all?  Since Barbara perceives manually->configured CPE primarily in PPP environments, how would DHCPv4 play into this situation at all?

If there is no DHCPv4 in the network, you are correct.   However, consider this.  The CPE is running 6rd.  Then CPE receives an RA, initiates DHCPv6 PD, and gets operational in native IPv6 mode.   Since the SP issued the RA the SP has also disabled 6rd.  Now the CPE has to send data on the 6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.  The NUD is not responded to since the SP has disabled 6rd.  On the NUD timing out the CPE disables 6rd and just keeps protocol 41 processing active.
 >>>>>>>>>>>>>>>>>>>I have a doubt here....
>>>>>>>>>>>>>>>>>>>>>if native link is active and since we have given higher priority to using the native interface....the CPE will send data through 6rd tunnel only if native is inactive or it cannot reach a destination over the native path. So one possibility I think if I have to disable 6rd manually ,I can simply remove the route for 6rd from the FIB.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Having said that, I still prefer symmetry.  If DHCPv4 was used to enable 6rd, DHCPv4 should be used to disable 6rd.  Likewise if manual configuration was used to enable 6rd, manual configuration should also be used to disabled 6rd.   Note also, MarkT has said, 6rd in RFC 5969 was designed for SP-managed CPE and manually configured CPE is out of scope for RFC 5969.  Likewise any manual configuration is out of scope of rfc6204bis as well.

>I'd like to hear from Barbara how she would want a CPE with manually-configured 6rd should function in the presence of >native IPv6, both in DHCPv6 and PPP environments.

Barbara can reply to this one.

Regards,

Hemant

--Boundary_(ID_ppxawAAmbQa+DqLy1MQchw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













Please see comments inline.


 


Thanks,




Tina








From: "Hemant Singh (shemant)" <shemant@cisco.com>

Date: December 4, 2011 6:32:28 AM PST

To: Frank Bulk <frnkblk@iname.com>

Cc: <v6ops@ietf.org>

Subject: Re: [v6ops] 6rd Sunsetting












Frank,


 


 






From: Frank Bulk [mailto:frnkblk@iname.com]


Sent: Saturday, December 03, 2011 10:08 PM

To: Hemant Singh (shemant)

Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA H

Subject: RE: [v6ops] 6rd Sunsetting






 


 


>If this CPE has manually-configured 6rd configured, why would the CPE sunset 6rd at all?  Since Barbara perceives
 manually->configured CPE primarily in PPP environments, how would DHCPv4 play into this situation at all? 



 


If there is no DHCPv4 in the network, you are correct.   However, consider this.  The CPE is running 6rd. 
 Then CPE receives an RA, initiates DHCPv6 PD, and gets operational in native IPv6 mode.   Since the SP issued the RA the SP has also disabled 6rd.  Now the CPE has to send data on the 6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.  The NUD is not responded
 to since the SP has disabled 6rd.  On the NUD timing out the CPE disables 6rd and just keeps protocol 41 processing active.


 >>>>>>>>>>>>>>>>>>>I have a doubt here….


>>>>>>>>>>>>>>>>>>>>>if native link is active and since we have given higher priority to using the native
 interface….the CPE will send data through 6rd tunnel only if native is inactive or it cannot reach a destination over the native path. So one possibility I think if I have to disable 6rd manually ,I can simply remove the route for 6rd from the FIB.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 


Having said that, I still prefer symmetry.  If DHCPv4 was used to enable 6rd, DHCPv4 should be used to disable
 6rd.  Likewise if manual configuration was used to enable 6rd, manual configuration should also be used to disabled 6rd.   Note also, MarkT has said, 6rd in RFC 5969 was designed for SP-managed CPE and manually configured CPE is out of scope for RFC 5969. 
 Likewise any manual configuration is out of scope of rfc6204bis as well.   



 


>I’d like to hear from Barbara how she would want a CPE with manually-configured 6rd should function in the
 presence of >native IPv6, both in DHCPv6 and PPP environments.


 


Barbara can reply to this one.


 


Regards,


 


Hemant












--Boundary_(ID_ppxawAAmbQa+DqLy1MQchw)--

From gert@space.net  Mon Dec  5 10:20:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64E21F85B9 for ; Mon,  5 Dec 2011 10:20:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_BREAS=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 SCNy2scK-KAL for ; Mon,  5 Dec 2011 10:20:03 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC221F8B03 for ; Mon,  5 Dec 2011 10:20:02 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E848EF894D for ; Mon,  5 Dec 2011 19:20:00 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D4ACBF8959 for ; Mon,  5 Dec 2011 19:20:00 +0100 (CET)
Received: (qmail 43153 invoked by uid 1007); 5 Dec 2011 19:20:00 +0100
Date: Mon, 5 Dec 2011 19:20:00 +0100
From: Gert Doering 
To: "Hemant Singh \(shemant\)" 
Message-ID: <20111205182000.GO72014@Space.Net>
References: <0B7A389A-C076-4C95-832B-B477DDCC4DFE@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE69F@XMB-RCD-109.cisco.com> <87E59480-8F9A-4ABE-8C6F-24BE31DD3F67@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE6AF@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778337@XMB-RCD-109.cisco.com> <99E91F55-E289-41A4-B046-374A782DC8D7@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30377872D@XMB-RCD-109.cisco.com> <20111205160346.GI72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3037787A9@XMB-RCD-109.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zo9hx/lCachKIinp"
Content-Disposition: inline
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3037787A9@XMB-RCD-109.cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 18:20:04 -0000

--Zo9hx/lCachKIinp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Dec 05, 2011 at 10:57:17AM -0600, Hemant Singh (shemant) wrote:
> What metric is used to load-balance 6rd between two BR's? =20

There is no well-defined metric, except for "looking at the box and=20
noticing that you need a bigger one". =20

The load-balacing would be done with basic routing - send half the=20
traffic this way, half the traffic the other way.

Or anycast BR - send whatever comes in from west coast to BR-west,=20
whatever comes from the east coast to BR-east.

("basic routing" will not work for CPE->BR, you need either anycast BR
or 'send different BR address to different clients' here).

As the thing is stateless, it scales great, and will also handle routing
asymmetry (Internet->BR1->CPE and CPE->BR2->Internet) perfectly wel.


> Use the same
> metric as internal code in a single BR and also make sure the BR cpu
> does not go over a certain x% load.  If the load is exceeded, the BR
> drops data.

Indeed, that's what happens - if 100% load is exceeded, the BR drops
data.

Maybe it's just a language issue, but I'm not sure I understand your
thoughts about the BR's workings - the BR is (by design) completely
stateless, and there are no protocols whatsoever except basic routing
that can influence the traffic level the BR sees.  There is no negotiation
with any other network element.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--Zo9hx/lCachKIinp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTt0LUKkuBuNlUUl1AQK3awQAuv6QslvxAL1kdfdnUomcPsSijimotFL0
paU7wgsDVxD7UZ0vn8sGiDB3c1/hJhqDMflYdRbvKpZWBZNANPM7X+UBNCoIvt9g
WGqXYwjrWO0G8oy+4VTRf77wAn23WDDA51s/XnOngP6Mbxv5Xo90ucskrp5Uk+f1
g8zPhrxO5GI=
=VU8A
-----END PGP SIGNATURE-----

--Zo9hx/lCachKIinp--

From bs7652@att.com  Mon Dec  5 10:56:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC3211E80A2 for ; Mon,  5 Dec 2011 10:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.48
X-Spam-Level: 
X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mdUc3Pq5cywa for ; Mon,  5 Dec 2011 10:55:58 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9011E8083 for ; Mon,  5 Dec 2011 10:55:57 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-15.tower-119.messagelabs.com!1323111356!4300300!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15902 invoked from network); 5 Dec 2011 18:55:56 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Dec 2011 18:55:56 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5IsSjR002432; Mon, 5 Dec 2011 13:54:29 -0500
Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5IsOse002276; Mon, 5 Dec 2011 13:54:24 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 12:55:00 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 13:55:00 -0500
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_01CCB37F.63B828C1"
Date: Mon, 5 Dec 2011 13:55:49 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F214FB693@crexc50p>
In-Reply-To: <013701ccb231$e7ca7ad0$b75f7070$@iname.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQAASz63MA==
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com>
From: "STARK, BARBARA H" 
To: "Frank Bulk" , "Hemant Singh (shemant)" 
X-OriginalArrivalTime: 05 Dec 2011 18:55:00.0184 (UTC) FILETIME=[63B3AD80:01CCB37F]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 18:56:01 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB37F.63B828C1
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I would expect a manually-configured CE router to behave as we've
discussed:

If the prefix received in a IA_PD is different than the one derived from
6rd (6rd configuration + WAN IPv4 address), then the CE router should
immediately tell the LAN that the 6rd prefix is not preferred, and not
valid (of course there will be the 2 hour window when this is expressed
in RA to the LAN).

=20

If the prefix received in IA_PD is the same, then we will rely on this
"administrative distance" thing to keep traffic away from the 6rd BR.=20

=20

I don't think it's a good idea to make the 6rd BR immediately
unavailable after sending RAs. Flash cuts are to be avoided, especially
flash cuts that assume, for example, 100k CE routers transitioning at
the same time. Which means that manual, DHCPv4, and TR-069 configured
6rd implementations should all be prepared to gracefully handle having
both. I don't see why transition from manual is so vastly different, at
the point where a device determines it has both 6rd and native
interfaces. Where it differs, is in the ease of *removing* 6rd
configuration from the device. Even with TR-069, we'd probably want a
soak period before disabling 6rd. So manual configuration soaks a little
(or a lot) longer than the others.=20

=20

And to respond to the suggestion that retail CE routers support TR-069:
with my consumer hat on, I say no way, no how - it's *my* router, and no
service provider is going to be allowed to so intrusively manage *my*
router. With my service provider hat on, I say no way - we don't do it
today, and adding such support just for 6rd is out of the question - too
costly, every way you look at it. Again, the goal is to keep it
reasonably simple for service providers, vendors, and the tech-savvy
people who can't stand the idea of service-provider-managed CE routers
in their home network. 

Barbara

=20

=20

From: Frank Bulk [mailto:frnkblk@iname.com]=20
Sent: Saturday, December 03, 2011 10:08 PM
To: 'Hemant Singh (shemant)'
Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA H
Subject: RE: [v6ops] 6rd Sunsetting

=20

Hemant:

=20

If this CPE has manually-configured 6rd configured, why would the CPE
sunset 6rd at all?  Since Barbara perceives manually-configured CPE
primarily in PPP environments, how would DHCPv4 play into this situation
at all? =20

=20

I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of native IPv6,
both in DHCPv6 and PPP environments.

=20

Frank

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Hemant Singh (shemant)
Sent: Monday, November 28, 2011 1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that
the CE be able to rationalize 6rd and native at the same time. I >don't
think it changes the requirements at all if we follow the same general
principle that the CE "does what it is told" rather than trying to
enable and disable 6rd configuration dynamically based on the >presence
of native IPv6.=20

=20

The retail, manually-configured CPE will be fine with 6rd sunsetting
based on the rules already specified in rfc6204bis.  The rules are
agnostic to a SP-managed or a user-configured 6rd CPE router. The retail
CPE will start native IPv6 operation when cued to do so with a RA from
the SP BNG and sunset 6rd when the DHCPv4 lease_time expires and the SP
does not reply to the DHCPv4 Renew from the CPE and the SP has also
changing the provisioning system to not include the 6rd DHCPv4 option in
DHCPv4 responses.

=20

Thanks,

=20

Hemant

=20

=20


------_=_NextPart_001_01CCB37F.63B828C1
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


I would expect a manually-configured CE router to behave as =
we’ve discussed:
If the prefix received in a IA_PD is different than the one derived =
from 6rd (6rd configuration + WAN IPv4 address), then the CE router =
should immediately tell the LAN that the 6rd prefix is not preferred, =
and not valid (of course there will be the 2 hour window when this is =
expressed in RA to the LAN).
 
If the prefix received in IA_PD is the same, then we will rely on =
this “administrative distance” thing to keep traffic away =
from the 6rd BR. 
 
I don’t think it’s a good idea to make the 6rd BR =
immediately unavailable after sending RAs. Flash cuts are to be avoided, =
especially flash cuts that assume, for example, 100k CE routers =
transitioning at the same time. Which means that manual, DHCPv4, and =
TR-069 configured 6rd implementations should all be prepared to =
gracefully handle having both. I don’t see why transition from =
manual is so vastly different, at the point where a device determines it =
has both 6rd and native interfaces. Where it differs, is in the ease of =
*removing* 6rd configuration from the device. Even with TR-069, =
we’d probably want a soak period before disabling 6rd. So manual =
configuration soaks a little (or a lot) longer than the others. =

 
And to respond to the suggestion that retail CE routers support =
TR-069: with my consumer hat on, I say no way, no how – it’s =
*my* router, and no service provider is going to be allowed to so =
intrusively manage *my* router. With my service provider hat on, =
I say no way – we don’t do it today, and adding such support =
just for 6rd is out of the question – too costly, every way you =
look at it. Again, the goal is to keep it reasonably simple for service =
providers, vendors, and the tech-savvy people who can’t stand the =
idea of service-provider-managed CE routers in their home network. =
<personal disclosure: I do not have a service provider managed CE =
router in my home; I know what they’re capable of, and don’t =
want such a thing on my home network; fortunately, my service provider =
is fine with this, so long as I accept responsibility for my =
router’s operation; I also never use ISP-provided (or CE router =
vendor provided) setup CDs, which load applications that I personally =
don’t trust onto PCs, instead preferring to *manually =
configure* my browser, email client, Wi-Fi, etc.; I believe that all =
people who are willing to go to this trouble should be afforded this =
freedom; for those who are not, I will work on standards and =
applications that allow service providers to do everything for their =
customers >
Barbara
 
 
From:=
 =
Frank Bulk [mailto:frnkblk@iname.com] 
Sent: Saturday, =
December 03, 2011 10:08 PM
To: 'Hemant Singh =
(shemant)'
Cc: v6ops@ietf.org; Mark Townsley; STARK, BARBARA =
H
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Hemant:
 
If this CPE has manually-configured 6rd configured, why would the CPE =
sunset 6rd at all?  Since Barbara perceives manually-configured CPE =
primarily in PPP environments, how would DHCPv4 play into this situation =
at all?  
 
I’d like to hear from Barbara how she would want a CPE with =
manually-configured 6rd should function in the presence of native IPv6, =
both in DHCPv6 and PPP environments.
 
Frank
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Hemant Singh (shemant)
Sent: Monday, November 28, 2011 =
1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net]=
 
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, =
BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: =
[v6ops] 6rd Sunsetting
 
>OK, I won't =
stand in the way of including manual requirements under protest, but if =
they go in then it becomes that much more important that the CE be able =
to rationalize 6rd and native at the same time. I >don't think it changes the =
requirements at all if we follow the same general principle that the CE =
"does what it is told" rather than trying to enable and =
disable 6rd configuration dynamically based on the >presence of native =
IPv6. 
 
The retail, manually-configured CPE will be fine =
with 6rd sunsetting based on the rules already specified in =
rfc6204bis.  The rules are agnostic to a SP-managed or a =
user-configured 6rd CPE router. The retail CPE will start native IPv6 =
operation when cued to do so with a RA from the SP BNG and sunset 6rd =
when the DHCPv4 lease_time expires and the SP does not reply to the =
DHCPv4 Renew from the CPE and the SP has also changing the provisioning =
system to not include the 6rd DHCPv4 option in DHCPv4 =
responses.
 
Thanks,
 
Hemant
 
 

------_=_NextPart_001_01CCB37F.63B828C1--

From shemant@cisco.com  Mon Dec  5 11:20:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF0011E80CD for ; Mon,  5 Dec 2011 11:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.535
X-Spam-Level: 
X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LSfDcg7BdiLj for ; Mon,  5 Dec 2011 11:20:28 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D1D7B11E80D5 for ; Mon,  5 Dec 2011 11:20:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14208; q=dns/txt; s=iport; t=1323112828; x=1324322428; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=anQyMbXm31x4MqExzaEfwC50LVS5fXelpayEWg7Fumw=; b=H3fp7YTWAB9evm5E9AODr65zf0NRsYNvukgYgqs1v44wTJ5IMZzNRxc1 WnYRBYZUnfzJsfcGl5UTH2+mE1YQLxOzXYaOrfxPPRwNnWfjg+8B6hpnH Ljq98Jqx0mlH8Gd/eG+EzuuujA+RJ+B8BLnNFOtkkAPP/nl+/UJkZERd6 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIAAE0Y3U6tJV2Z/2dsb2JhbABEgk2XTJApgQWBcgEBAQMBEgEJEQNJBQsCAQgRBAEBCwYXAQYBRQkIAQEEARIIARmHZQiWRgGeS4o+YwSILZ5m
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; d="scan'208,217";a="41288070"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Dec 2011 19:20:26 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB5JKQgF003760;  Mon, 5 Dec 2011 19:20:26 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 13:20:25 -0600
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_01CCB382.F07ACC88"
Date: Mon, 5 Dec 2011 13:20:25 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377889D@XMB-RCD-109.cisco.com>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F214FB693@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQAASz63MAAIoliQ
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB693@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , "Frank Bulk" 
X-OriginalArrivalTime: 05 Dec 2011 19:20:25.0107 (UTC) FILETIME=[F0A07630:01CCB382]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 19:20:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB382.F07ACC88
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Barbara,

=20

Thanks for the reply.  Please see below.

=20

From: STARK, BARBARA H [mailto:bs7652@att.com]=20
Sent: Monday, December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

=20

=20

>I don't think it's a good idea to make the 6rd BR immediately
unavailable after sending RAs. Flash cuts are to be avoided, especially
flash cuts >that assume, for example, 100k CE routers transitioning at
the same time. Which means that manual, DHCPv4, and TR-069 configured
6rd >implementations should all be prepared to gracefully handle having
both. I don't see why transition from manual is so vastly different, at
the >point where a device determines it has both 6rd and native
interfaces. Where it differs, is in the ease of *removing* 6rd
configuration from the >device. Even with TR-069, we'd probably want a
soak period before disabling 6rd. So manual configuration soaks a little
(or a lot) longer than the >others.=20

=20

I, MarkT and you are in agreement with what you say above.  However,
please see this email during an exchange with Victor on his screw case
with 6rd sunsetting.

=20

http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html

=20

See the text below from the email URL above between squared braces.

=20

[>=20

> Again, I would prefer a cut over from one interface to the other=20

> (virtual to native).  This is what I would ask my vendor to implement.


> Once I add in Native to a capable CPE, I would expect the CPE to go=20

> native. I am hoping there is an option for this within all the
proposals.

=20

I don't want to limit the ability for you to move a customer from 6rd to
native immediately, but I want others to be able to do it incrementally
as well. If you want to move them immediately, all you need to do is
provision DHCPv6 PD at the same time you deprovision the 6rd option in
DHCPv4 and be sure you use a different prefix for native than 6rd. Once
the home router reboots or the DHCPv4 lease and associated 6rd delegated
prefix lifetime times out, the 6rd and its associated prefix will be
gone never to return.=20

=20

- Mark]

=20

>And to respond to the suggestion that retail CE routers support TR-069:
with my consumer hat on, I say no way, no how - it's *my* router, and no
>service provider is going to be allowed to so intrusively manage *my*
router.=20

=20

So please provide guidance on how is 6rd disabled on the retail router
if 6rd was enabled manually on the retail router?   For a manually
configured retail router, one can run into concurrent DS-Lite and 6rd
operation and then the CE router is totally confused why the router
should not run in native dual-stack mode.   =20

=20

Hemant


------_=_NextPart_001_01CCB382.F07ACC88
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Barbara,
 
Thanks for the reply.  Please see below.
 
From:=
 =
STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, =
December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh =
(shemant)
Cc: v6ops@ietf.org; Mark Townsley
Subject: =
RE: [v6ops] 6rd Sunsetting
 
 
>I =
don’t think it’s a good idea to make the 6rd BR immediately =
unavailable after sending RAs. Flash cuts are to be avoided, especially =
flash cuts >that =
assume, for example, 100k CE routers transitioning at the same time. =
Which means that manual, DHCPv4, and TR-069 configured 6rd >implementations should all be prepared to gracefully =
handle having both. I don’t see why transition from manual is so =
vastly different, at the >point =
where a device determines it has both 6rd and native interfaces. Where =
it differs, is in the ease of *removing* 6rd configuration from =
the >device. Even with TR-069, we’d probably want a =
soak period before disabling 6rd. So manual configuration soaks a little =
(or a lot) longer than the >others. 
 
I, MarkT and you are in agreement with what you say =
above.  However, please see this email during an exchange with =
Victor on his screw case with 6rd sunsetting.
 
http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html
 
See the text below from the email URL above between =
squared braces.
 
[> =

> Again, I would =
prefer a cut over from one interface to the other =

> (virtual to =
native).  This is what I would ask my vendor to implement.  =

> Once I add in =
Native to a capable CPE, I would expect the CPE to go =

> native. I am =
hoping there is an option for this within all the =
proposals.
 
I don't want to =
limit the ability for you to move a customer from 6rd to native =
immediately, but I want others to be able to do it incrementally as =
well. If you want to move them immediately, all you need to do is =
provision DHCPv6 PD at the same time you deprovision the 6rd option in =
DHCPv4 and be sure you use a different prefix for native than 6rd. Once =
the home router reboots or the DHCPv4 lease and associated 6rd delegated =
prefix lifetime times out, the 6rd and its associated prefix will be =
gone never to return. 
 
- =
Mark]
 
>And =
to respond to the suggestion that retail CE routers support TR-069: with =
my consumer hat on, I say no way, no how – it’s *my* =
router, and no >service provider is going to be allowed to so =
intrusively manage *my* router. 
 
So please provide guidance on how is 6rd disabled on the retail =
router if 6rd was enabled manually on the retail router?   For =
a manually configured retail router, one can run into concurrent DS-Lite =
and 6rd operation and then the CE router is totally confused why the =
router should not run in native dual-stack mode.   =
 
 
Hemant

------_=_NextPart_001_01CCB382.F07ACC88--

From bs7652@att.com  Mon Dec  5 11:24:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476821F8AF0 for ; Mon,  5 Dec 2011 11:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.495
X-Spam-Level: 
X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 KYwmT6YNRwEr for ; Mon,  5 Dec 2011 11:24:10 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCEF21F8AE9 for ; Mon,  5 Dec 2011 11:24:10 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-10.tower-120.messagelabs.com!1323113048!39202933!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10331 invoked from network); 5 Dec 2011 19:24:09 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Dec 2011 19:24:09 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5JMeXY013783; Mon, 5 Dec 2011 14:22:41 -0500
Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5JJheV009122; Mon, 5 Dec 2011 14:22:35 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 13:20:57 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 14:20:56 -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: Mon, 5 Dec 2011 14:21:44 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F214FB6D6@crexc50p>
In-Reply-To: <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyxYBsY+NKVvNQJTTKAFP25LagUlQCIWYqQ
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> <4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com>
From: "STARK, BARBARA H" 
To: "Fred Baker" , "Lorenzo Colitti" 
X-OriginalArrivalTime: 05 Dec 2011 19:20:56.0010 (UTC) FILETIME=[030BE2A0:01CCB383]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 19:24:11 -0000

> In addition, the PCP chairs tell us that draft-
> ietf-pcp-base is headed to the IESG momentarily as well.

If PCP is still being considered for inclusion, I'd really like to see
some recommended text. I don't recall having seen anything, yet, that
provided a complete but concise description of the desired functions, in
requirements format. As discussed previously, a blanket "must support
PCP" is insufficient. I think we left off at a general understanding of
"must support PCP IPv4 client to the WAN" and some UPnP IGD PortMapping
to PCP interworking function. But I really don't know. In the absence of
proposed text, I would assume that PCP is not in.
Barbara

From shemant@cisco.com  Mon Dec  5 11:45:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9F21F8C07 for ; Mon,  5 Dec 2011 11:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.236
X-Spam-Level: 
X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 jsPDQOPbaE78 for ; Mon,  5 Dec 2011 11:45:23 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D321F8BEF for ; Mon,  5 Dec 2011 11:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1193; q=dns/txt; s=iport; t=1323114322; x=1324323922; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MCPxhcmCzwsmS36iLcwyBBSCk2HLHJZGuJF9wvUdw9Y=; b=jvoutNm9KhJm2BDw05WvTLyXn9fuYYEUGqh3CEoFcJxGA4tkZvMEB9q1 TA9AplIxnyvlgtCJroDf0tQrSWBY+vvQKc4wEKnflkJTPZjYUsS6O2EsE Yoq9APlWaE/yMw7s94Ari7nqS0ZvIj9/VZshqsIvuxliqLNCqbBNkHwCJ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIAAHIe3U6tJXG9/2dsb2JhbABEmhmQKYEFgXIBAQEDAQEBAQ8BHQo0CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodlCJZOAZ5MBIo+YwSILZ5m
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; d="scan'208";a="41306959"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Dec 2011 19:45:22 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB5JjLGB008262;  Mon, 5 Dec 2011 19:45:21 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 13:45:20 -0600
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: Mon, 5 Dec 2011 13:45:20 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3037788CE@XMB-RCD-109.cisco.com>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F214FB6D6@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyxYBsY+NKVvNQJTTKAFP25LagUlQCIWYqQAAEY+iA=
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com><4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB6D6@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , "Fred Baker (fred)" ,  "Lorenzo Colitti" 
X-OriginalArrivalTime: 05 Dec 2011 19:45:20.0652 (UTC) FILETIME=[6C0A84C0:01CCB386]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 19:45:26 -0000

W-x: The CE router WAN interface SHOULD support a PCP client as
specified in [PCP-base].

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of STARK, BARBARA H
Sent: Monday, December 05, 2011 2:22 PM
To: Fred Baker (fred); Lorenzo Colitti
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward

> In addition, the PCP chairs tell us that draft-
> ietf-pcp-base is headed to the IESG momentarily as well.

If PCP is still being considered for inclusion, I'd really like to see
some recommended text. I don't recall having seen anything, yet, that
provided a complete but concise description of the desired functions, in
requirements format. As discussed previously, a blanket "must support
PCP" is insufficient. I think we left off at a general understanding of
"must support PCP IPv4 client to the WAN" and some UPnP IGD PortMapping
to PCP interworking function. But I really don't know. In the absence of
proposed text, I would assume that PCP is not in.
Barbara
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From bs7652@att.com  Mon Dec  5 12:09:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8921F8B48 for ; Mon,  5 Dec 2011 12:09:43 -0800 (PST)
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 qp2Q6c3AgaZi for ; Mon,  5 Dec 2011 12:09:43 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 661E921F8B0B for ; Mon,  5 Dec 2011 12:09:43 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-5.tower-119.messagelabs.com!1323115781!4320223!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 5 Dec 2011 20:09:41 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Dec 2011 20:09:41 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5K8Dcj026622; Mon, 5 Dec 2011 15:08:14 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5K84Ys026382; Mon, 5 Dec 2011 15:08:04 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 14:08:40 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 15:08:41 -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: Mon, 5 Dec 2011 15:09:29 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F214FB760@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3037788CE@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyxYBsY+NKVvNQJTTKAFP25LagUlQCIWYqQAAEY+iAAAOYG0A==
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com><4537A4F5-EDD7-4478-8904-67A82FD10DF6@cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB6D6@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3037788CE@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , "Lorenzo Colitti" 
X-OriginalArrivalTime: 05 Dec 2011 20:08:41.0219 (UTC) FILETIME=[AED81530:01CCB389]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 20:09:44 -0000

> W-x: The CE router WAN interface SHOULD support a PCP client as
> specified in [PCP-base].

Wouldn't this also mean that the CE router would have to support PCP
client for IPv6? Does that make sense? I thought it was only needed for
IPv4.
Barbara

From john_brzozowski@cable.comcast.com  Mon Dec  5 12:11:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D94B11E80DF for ; Mon,  5 Dec 2011 12:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.495
X-Spam-Level: 
X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.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 0-7dZ283WJJd for ; Mon,  5 Dec 2011 12:11:54 -0800 (PST)
Received: from cable.comcast.com (unknown [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E037721F8BF7 for ; Mon,  5 Dec 2011 12:11:53 -0800 (PST)
Received: from ([24.40.55.41]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.806350; Mon, 05 Dec 2011 13:05:39 -0700
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Mon, 5 Dec 2011 15:11:45 -0500
From: "Brzozowski, John" 
To: Fred Baker , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AQHMs4ocG8PMsR6KUEKdVMZ3Zl2CJQ==
Date: Mon, 5 Dec 2011 20:11:45 +0000
Message-ID: 
In-Reply-To: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.125.11]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 20:11:55 -0000

It seems to me there is consensus at a fundamental level and that is to
move RFC6204bis forward.  I think we should be careful not to mistake
email volume on subjects that are of interest to individuals as a lack of
consensus.  Further, delaying the progress that several of us are strongly
in favor of because of miscellaneous email volume hardly seems appropriate.

I recommend that we evaluate the email threads and distill these down to
some high level topics that can be prioritized and addressed
systematically over time.

It seems to me that we are in the midst of an email DoS that is delaying
events that the majority desire.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 12/2/11 7:32 PM, "Fred Baker"  wrote:

>The following is a problem, a suggestion, and a question.
>
>As you know, I bcc'd a number of folks on an email asking what and when
>we should do with this. Joel and I got a few over 50 emails in response.
>I had given a number of possible options: deliver to IESG (Ron) in
>December 2011, by IETF 83 (March), by IETF 84 (July), in the later half
>of 2012, or in 2013. I got answers supporting each of those options.
>
>However, there were two predominant views. View (1) says that there is a
>need to push 6204bis out in December; view (2) says the same but adds
>that some pet point has to be addressed. Unfortunately, it's very
>difficult for me to identify a consensus on the pet points - they are
>themselves all over the map.
>
>Which leaves me with a quandary. The volume of email traffic, both on
>v6ops@ and on the design team's lists, tells me that we're not done. But
>at the same time, I see serious scope creep - "we want to wait until 4rd
>is an RFC" and similar pet projects could take an arbitrary amount of
>time. I feel that it is necessary to define a scope for the current
>draft, and provide a game plan for updates to it relating to the various
>projects.
>
>It seems to me that the best bet would be to define that 6204bis is
>essentially the document we have now (updating 6204 to include 6rd and
>ds-lite, and describing a generic CPE router without specific
>accomodation of Cable, DSL, Fiber, or 3GPP), publish it as updating 6204
>(the IPv6-ready logo test depends on elements of both), and let future
>small memos further update it with respect to their specific interests.
>If, for example, 3GPP wants to have a document that significantly differs
>and addresses the tethering mode of a handset, 3GPP can submit one, we
>can discuss is, and push it through as an appropriate document for 3GPP
>environments. Which raises interesting questions for LTE.
>
>We may also want to add the word "wireline" to the title to clarify that
>we are doing this.
>
>What do people think about this approach?
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From shemant@cisco.com  Mon Dec  5 12:24:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCA21F8C70 for ; Mon,  5 Dec 2011 12:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.232
X-Spam-Level: 
X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 t4fH3M4FVv-R for ; Mon,  5 Dec 2011 12:24:41 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 58D8011E80CF for ; Mon,  5 Dec 2011 12:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3776; q=dns/txt; s=iport; t=1323116678; x=1324326278; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bzn+2IYadLEq2uAMkmvOYKf53VqNMrVGFVgSnoUR4jo=; b=YCcKOV1SC+ulbkyfuUodtxPO/w/1ETEG1HiFdAq0TVYDHNqAORJnKwp3 kl6xzj7CZUKLxejVCv6iy7HtO0Jx5haTY98BXI4eY/SNQHr9yoIQ3VdNq dYYzSjcahpHZfBL+X0cmweD4CdLyRIj2UlVk5529HURS3JuE8Utf8/u3C E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAIUn3U6tJV2a/2dsb2JhbAA6BwOaGZApgQWBcgEBAQQBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHbZZHAZ5Wh20agjdjBIgtnmY
X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; d="scan'208";a="41306519"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 05 Dec 2011 20:24:38 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB5KObo3007526;  Mon, 5 Dec 2011 20:24:37 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 14:24:37 -0600
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: Mon, 5 Dec 2011 14:24:36 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377890F@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AQHMs4ocG8PMsR6KUEKdVMZ3Zl2CJZXNsKRw
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Brzozowski, John" , "Fred Baker (fred)" , 
X-OriginalArrivalTime: 05 Dec 2011 20:24:37.0994 (UTC) FILETIME=[E9205CA0:01CCB38B]
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 20:24:46 -0000

+1 to John's comments.   Thanks, John.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Brzozowski, John
Sent: Monday, December 05, 2011 3:12 PM
To: Fred Baker (fred); v6ops@ietf.org WG
Subject: Re: [v6ops] 6204bis progress and way forward

It seems to me there is consensus at a fundamental level and that is to
move RFC6204bis forward.  I think we should be careful not to mistake
email volume on subjects that are of interest to individuals as a lack
of
consensus.  Further, delaying the progress that several of us are
strongly
in favor of because of miscellaneous email volume hardly seems
appropriate.

I recommend that we evaluate the email threads and distill these down to
some high level topics that can be prioritized and addressed
systematically over time.

It seems to me that we are in the midst of an email DoS that is delaying
events that the majority desire.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 12/2/11 7:32 PM, "Fred Baker"  wrote:

>The following is a problem, a suggestion, and a question.
>
>As you know, I bcc'd a number of folks on an email asking what and when
>we should do with this. Joel and I got a few over 50 emails in
response.
>I had given a number of possible options: deliver to IESG (Ron) in
>December 2011, by IETF 83 (March), by IETF 84 (July), in the later half
>of 2012, or in 2013. I got answers supporting each of those options.
>
>However, there were two predominant views. View (1) says that there is
a
>need to push 6204bis out in December; view (2) says the same but adds
>that some pet point has to be addressed. Unfortunately, it's very
>difficult for me to identify a consensus on the pet points - they are
>themselves all over the map.
>
>Which leaves me with a quandary. The volume of email traffic, both on
>v6ops@ and on the design team's lists, tells me that we're not done.
But
>at the same time, I see serious scope creep - "we want to wait until
4rd
>is an RFC" and similar pet projects could take an arbitrary amount of
>time. I feel that it is necessary to define a scope for the current
>draft, and provide a game plan for updates to it relating to the
various
>projects.
>
>It seems to me that the best bet would be to define that 6204bis is
>essentially the document we have now (updating 6204 to include 6rd and
>ds-lite, and describing a generic CPE router without specific
>accomodation of Cable, DSL, Fiber, or 3GPP), publish it as updating
6204
>(the IPv6-ready logo test depends on elements of both), and let future
>small memos further update it with respect to their specific interests.
>If, for example, 3GPP wants to have a document that significantly
differs
>and addresses the tethering mode of a handset, 3GPP can submit one, we
>can discuss is, and push it through as an appropriate document for 3GPP
>environments. Which raises interesting questions for LTE.
>
>We may also want to add the word "wireline" to the title to clarify
that
>we are doing this.
>
>What do people think about this approach?
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops

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

From brian.e.carpenter@gmail.com  Mon Dec  5 12:34:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77311E80C4 for ; Mon,  5 Dec 2011 12:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.299
X-Spam-Level: 
X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 aKQHH-gbURb7 for ; Mon,  5 Dec 2011 12:34:42 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F111E80AC for ; Mon,  5 Dec 2011 12:34:32 -0800 (PST)
Received: by eaak10 with SMTP id k10so1706365eaa.31 for ; Mon, 05 Dec 2011 12:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y/AGDduPeZL/ymHOJjs1Lmglf6tvspOPYIHPaKUGaFg=; b=OLY5GXv5k6uq2b9DX4l69SKZrSd6kqy8JgpOqsYddNbQbrbhjCtJnzFleYL46AWaDZ 1Z//n1N6XmYDY4lYPdEV8XIiPF/j1kOpqn7SOZJahVNBOH0hmdo885di66WkC++38KxQ fEchum4H0Gaq9ABivoeUCVBnyiguqkGx+0sHU=
Received: by 10.213.7.214 with SMTP id e22mr657606ebe.125.1323117271963; Mon, 05 Dec 2011 12:34:31 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id n14sm14992472bkn.13.2011.12.05.12.34.28 (version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 12:34:31 -0800 (PST)
Message-ID: <4EDD2ACC.6060403@gmail.com>
Date: Tue, 06 Dec 2011 09:34:20 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Hemant Singh (shemant)" 
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com>	 <5B6B2B64C9FE2A489045EEEADDAFF2C30377890F@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30377890F@XMB-RCD-109.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 20:34:46 -0000

Please let's see a new draft ASAP, so that we can all look at the
exact diffs. It's the WG that decides, not the DT.

Regards
   Brian

On 2011-12-06 09:24, Hemant Singh (shemant) wrote:
> +1 to John's comments.   Thanks, John.
> 
> Hemant
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brzozowski, John
> Sent: Monday, December 05, 2011 3:12 PM
> To: Fred Baker (fred); v6ops@ietf.org WG
> Subject: Re: [v6ops] 6204bis progress and way forward
> 
> It seems to me there is consensus at a fundamental level and that is to
> move RFC6204bis forward.  I think we should be careful not to mistake
> email volume on subjects that are of interest to individuals as a lack
> of
> consensus.  Further, delaying the progress that several of us are
> strongly
> in favor of because of miscellaneous email volume hardly seems
> appropriate.
> 
> I recommend that we evaluate the email threads and distill these down to
> some high level topics that can be prioritized and addressed
> systematically over time.
> 
> It seems to me that we are in the midst of an email DoS that is delaying
> events that the majority desire.
> 
> John
> =========================================
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozowski@cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =========================================
> 
> 
> 
> 
> On 12/2/11 7:32 PM, "Fred Baker"  wrote:
> 
>> The following is a problem, a suggestion, and a question.
>>
>> As you know, I bcc'd a number of folks on an email asking what and when
>> we should do with this. Joel and I got a few over 50 emails in
> response.
>> I had given a number of possible options: deliver to IESG (Ron) in
>> December 2011, by IETF 83 (March), by IETF 84 (July), in the later half
>> of 2012, or in 2013. I got answers supporting each of those options.
>>
>> However, there were two predominant views. View (1) says that there is
> a
>> need to push 6204bis out in December; view (2) says the same but adds
>> that some pet point has to be addressed. Unfortunately, it's very
>> difficult for me to identify a consensus on the pet points - they are
>> themselves all over the map.
>>
>> Which leaves me with a quandary. The volume of email traffic, both on
>> v6ops@ and on the design team's lists, tells me that we're not done.
> But
>> at the same time, I see serious scope creep - "we want to wait until
> 4rd
>> is an RFC" and similar pet projects could take an arbitrary amount of
>> time. I feel that it is necessary to define a scope for the current
>> draft, and provide a game plan for updates to it relating to the
> various
>> projects.
>>
>> It seems to me that the best bet would be to define that 6204bis is
>> essentially the document we have now (updating 6204 to include 6rd and
>> ds-lite, and describing a generic CPE router without specific
>> accomodation of Cable, DSL, Fiber, or 3GPP), publish it as updating
> 6204
>> (the IPv6-ready logo test depends on elements of both), and let future
>> small memos further update it with respect to their specific interests.
>> If, for example, 3GPP wants to have a document that significantly
> differs
>> and addresses the tethering mode of a handset, 3GPP can submit one, we
>> can discuss is, and push it through as an appropriate document for 3GPP
>> environments. Which raises interesting questions for LTE.
>>
>> We may also want to add the word "wireline" to the title to clarify
> that
>> we are doing this.
>>
>> What do people think about this approach?
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

From bs7652@att.com  Mon Dec  5 12:43:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C170921F852E for ; Mon,  5 Dec 2011 12:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.515
X-Spam-Level: 
X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sYziitQu66yX for ; Mon,  5 Dec 2011 12:43:16 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 530921F0C60 for ; Mon,  5 Dec 2011 12:43:16 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-3.tower-120.messagelabs.com!1323117794!52325605!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12992 invoked from network); 5 Dec 2011 20:43:14 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Dec 2011 20:43:14 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5KfkWJ015058; Mon, 5 Dec 2011 15:41:47 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1-v2.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pB5KXEK7002459; Mon, 5 Dec 2011 15:41:41 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 14:41:11 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 15:41:10 -0500
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_01CCB38E.38B09F3B"
Date: Mon, 5 Dec 2011 15:41:59 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F214FB7D9@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30377889D@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQAASz63MAAIoliQAAJaeXA=
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB693@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C30377889D@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Frank Bulk" 
X-OriginalArrivalTime: 05 Dec 2011 20:41:10.0449 (UTC) FILETIME=[38ACFA10:01CCB38E]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 20:43:19 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB38E.38B09F3B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I interpreted "stop doing 6rd" as being similar in function to "not
sending any traffic over the 6rd interface". From the outside, it looks
the same. I tend to be more concerned with externally discernible
behavior, than with internal implementation. If (in the case of
different prefixes) the CE router immediately makes IPv6 addresses on
the LAN from the 6rd prefix to be not preferred and not valid, then this
accomplishes that goal. If (for same prefix) the CE router prefers to
send traffic over the native interface, then this also accomplishes the
goal.

=20

Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and
manual configuration) there is a period of time where both are available
to the CE router, unless you try some sort of flash cut. The CE router
must be able to deal with this. And the preference is that it deal with
this by getting as much traffic as possible to go over the native
interface, as soon as possible.

=20

If no traffic is going over the 6rd interface, and the CE router is able
to function with both configured, what is it going to hurt, however long
the manual configuration stays? And the way to disable it is for the
very same user who manually configured it, to go in and manually disable
it. As long as things don't break, it shouldn't really matter. Of
course, I would prefer for the user to disable it sooner rather than
later. But we've dealt with similar transitions before (IP to PPPoE,
PPPoE to IP, PPPoA to PPPoE, TDMA to GSM, IPv4 to IPv6, etc.). It's
do-able. Some users hang on for a long time. Most respond quickly. It's
manageable, as long as things don't break when faced with both.

=20

As for concurrent 6rd and DS-Lite, I really don't care what rules are
created. The situation is only relevant to providers who actually intend
to offer both to the same CE routers. If a provider doesn't offer
DS-Lite DHCPv6 options, then the danger of dealing with CE routers that
have trouble deciding what to do is pretty low.

Barbara

=20

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20
Sent: Monday, December 05, 2011 2:20 PM
To: STARK, BARBARA H; Frank Bulk
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

=20

Barbara,

=20

Thanks for the reply.  Please see below.

=20

From: STARK, BARBARA H [mailto:bs7652@att.com]=20
Sent: Monday, December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

=20

=20

>I don't think it's a good idea to make the 6rd BR immediately
unavailable after sending RAs. Flash cuts are to be avoided, especially
flash cuts >that assume, for example, 100k CE routers transitioning at
the same time. Which means that manual, DHCPv4, and TR-069 configured
6rd >implementations should all be prepared to gracefully handle having
both. I don't see why transition from manual is so vastly different, at
the >point where a device determines it has both 6rd and native
interfaces. Where it differs, is in the ease of *removing* 6rd
configuration from the >device. Even with TR-069, we'd probably want a
soak period before disabling 6rd. So manual configuration soaks a little
(or a lot) longer than the >others.=20

=20

I, MarkT and you are in agreement with what you say above.  However,
please see this email during an exchange with Victor on his screw case
with 6rd sunsetting.

=20

http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html

=20

See the text below from the email URL above between squared braces.

=20

[>=20

> Again, I would prefer a cut over from one interface to the other=20

> (virtual to native).  This is what I would ask my vendor to implement.


> Once I add in Native to a capable CPE, I would expect the CPE to go=20

> native. I am hoping there is an option for this within all the
proposals.

=20

I don't want to limit the ability for you to move a customer from 6rd to
native immediately, but I want others to be able to do it incrementally
as well. If you want to move them immediately, all you need to do is
provision DHCPv6 PD at the same time you deprovision the 6rd option in
DHCPv4 and be sure you use a different prefix for native than 6rd. Once
the home router reboots or the DHCPv4 lease and associated 6rd delegated
prefix lifetime times out, the 6rd and its associated prefix will be
gone never to return.=20

=20

- Mark]

=20

>And to respond to the suggestion that retail CE routers support TR-069:
with my consumer hat on, I say no way, no how - it's *my* router, and no
>service provider is going to be allowed to so intrusively manage *my*
router.=20

=20

So please provide guidance on how is 6rd disabled on the retail router
if 6rd was enabled manually on the retail router?   For a manually
configured retail router, one can run into concurrent DS-Lite and 6rd
operation and then the CE router is totally confused why the router
should not run in native dual-stack mode.   =20

=20

Hemant


------_=_NextPart_001_01CCB38E.38B09F3B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


I interpreted “stop doing 6rd” as being similar in =
function to “not sending any traffic over the 6rd =
interface”. From the outside, it looks the same. I tend to be more =
concerned with externally discernible behavior, than with internal =
implementation. If (in the case of different prefixes) the CE router =
immediately makes IPv6 addresses on the LAN from the 6rd prefix to be =
not preferred and not valid, then this accomplishes that goal. If (for =
same prefix) the CE router prefers to send traffic over the native =
interface, then this also accomplishes the goal.
 
Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and =
manual configuration) there is a period of time where both are available =
to the CE router, unless you try some sort of flash cut. The CE router =
must be able to deal with this. And the preference is that it deal with =
this by getting as much traffic as possible to go over the native =
interface, as soon as possible.
 
If no traffic is going over the 6rd interface, and the CE router is =
able to function with both configured, what is it going to hurt, however =
long the manual configuration stays? And the way to disable it is for =
the very same user who manually configured it, to go in and manually =
disable it. As long as things don’t break, it shouldn’t =
really matter. Of course, I would prefer for the user to disable it =
sooner rather than later. But we’ve dealt with similar transitions =
before (IP to PPPoE, PPPoE to IP, PPPoA to PPPoE, TDMA to GSM, IPv4 to =
IPv6, etc.). It’s do-able. Some users hang on for a long time. =
Most respond quickly. It’s manageable, as long as things =
don’t break when faced with both.
 
As for concurrent 6rd and DS-Lite, I really don’t care what =
rules are created. The situation is only relevant to providers who =
actually intend to offer both to the same CE routers. If a provider =
doesn’t offer DS-Lite DHCPv6 options, then the danger of dealing =
with CE routers that have trouble deciding what to do is pretty =
low.
Barbara
 
From:=
 =
Hemant Singh (shemant) [mailto:shemant@cisco.com] 
Sent: =
Monday, December 05, 2011 2:20 PM
To: STARK, BARBARA H; Frank =
Bulk
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: =
[v6ops] 6rd Sunsetting
 
Barbara,
 
Thanks for the reply.  Please see below.
 
From:=
 =
STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, =
December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh =
(shemant)
Cc: v6ops@ietf.org; Mark Townsley
Subject: =
RE: [v6ops] 6rd Sunsetting
 
 
>I don’t think it’s a good idea to =
make the 6rd BR immediately unavailable after sending RAs. Flash cuts =
are to be avoided, especially flash cuts >that assume, for example, =
100k CE routers transitioning at the same time. Which means that manual, =
DHCPv4, and TR-069 configured 6rd >implementations should all be =
prepared to gracefully handle having both. I don’t see why =
transition from manual is so vastly different, at the >point where a =
device determines it has both 6rd and native interfaces. Where it =
differs, is in the ease of *removing* 6rd configuration from the =
>device. Even with TR-069, we’d probably want a soak period =
before disabling 6rd. So manual configuration soaks a little (or a lot) =
longer than the >others. 
 
I, MarkT and you are in agreement with what you say =
above.  However, please see this email during an exchange with =
Victor on his screw case with 6rd sunsetting.
 
http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html
 
See the text below from the email URL above between =
squared braces.
 
[> =

> Again, I would =
prefer a cut over from one interface to the other =

> (virtual to =
native).  This is what I would ask my vendor to implement.  =

> Once I add in =
Native to a capable CPE, I would expect the CPE to go =

> native. I am =
hoping there is an option for this within all the =
proposals.
 
I don't want to =
limit the ability for you to move a customer from 6rd to native =
immediately, but I want others to be able to do it incrementally as =
well. If you want to move them immediately, all you need to do is =
provision DHCPv6 PD at the same time you deprovision the 6rd option in =
DHCPv4 and be sure you use a different prefix for native than 6rd. Once =
the home router reboots or the DHCPv4 lease and associated 6rd delegated =
prefix lifetime times out, the 6rd and its associated prefix will be =
gone never to return. 
 
- =
Mark]
 
>And to respond to the suggestion that retail CE =
routers support TR-069: with my consumer hat on, I say no way, no how =
– it’s *my* router, and no >service provider is =
going to be allowed to so intrusively manage *my* router. =

 
So please provide guidance on how is 6rd disabled on the retail =
router if 6rd was enabled manually on the retail router?   For =
a manually configured retail router, one can run into concurrent DS-Lite =
and 6rd operation and then the CE router is totally confused why the =
router should not run in native dual-stack mode.   =
 
 
Hemant

------_=_NextPart_001_01CCB38E.38B09F3B--

From internet-drafts@ietf.org  Mon Dec  5 13:43:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618B111E80AF; Mon,  5 Dec 2011 13:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 O5lJuXM7gbul; Mon,  5 Dec 2011 13:43:03 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE61411E8081; Mon,  5 Dec 2011 13:43:02 -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: 3.64
Message-ID: <20111205214302.25836.28905.idtracker@ietfa.amsl.com>
Date: Mon, 05 Dec 2011 13:43:02 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 21:43:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Basic Requirements for IPv6 Customer Edge Routers
	Author(s)       : Hemant Singh
                          Wes Beebee
                          Chris Donley
                          Barbara Stark
                          Ole Troan
	Filename        : draft-ietf-v6ops-6204bis-04.txt
	Pages           : 23
	Date            : 2011-12-05

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers IP transition
   technologies and transition technologies coexistence.  Two transition
   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
   the document.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-04.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-v6ops-6204bis-04.txt


From shemant@cisco.com  Mon Dec  5 13:44:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B195D11E80B0 for ; Mon,  5 Dec 2011 13:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075,  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 orv43UDAsk+t for ; Mon,  5 Dec 2011 13:44:56 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D280311E8081 for ; Mon,  5 Dec 2011 13:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=682; q=dns/txt; s=iport; t=1323121493; x=1324331093; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9RZGXQM/IsuqWEJxiwb1b3DBFwja4hz+AifrpI7jf28=; b=kPqwlFAfRhbW+k3Q7lFoRCvrXIpTd9WuJdCRaXLeacL/xgzFtms4gwIy OWq+9eOUSgVu79OhTmgZwx9xQvm/ccwQfIEWXcF5TptsiEy+pJT25xiXO 6ol53L9HMSAJvHpbXRDAb0nFRA2a7zvqemfP3ToD7wOE7+T9qWdtryLND E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQAAFk63U6tJXG9/2dsb2JhbABEhQWVFI8agQ+BBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBHyUJCAEBBBMIGp4xAYxbkgCBMIhbM2MEiC2XD4dX
X-IronPort-AV: E=Sophos;i="4.71,301,1320624000"; d="scan'208";a="41324586"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 05 Dec 2011 21:44:52 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB5LiqMk030505;  Mon, 5 Dec 2011 21:44:52 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 15:44:52 -0600
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, 5 Dec 2011 15:44:51 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778977@XMB-RCD-109.cisco.com>
In-Reply-To: <4EDD2ACC.6060403@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6204bis progress and way forward
Thread-Index: AcyzjUvkrZGLqYpnQl2lUH3xnPg35QACcGfQ
References: <7DAC5598-0FBD-4F2F-AC65-4E56380F942B@cisco.com>	 <5B6B2B64C9FE2A489045EEEADDAFF2C30377890F@XMB-RCD-109.cisco.com> <4EDD2ACC.6060403@gmail.com>
From: "Hemant Singh (shemant)" 
To: "Brian E Carpenter" 
X-OriginalArrivalTime: 05 Dec 2011 21:44:52.0179 (UTC) FILETIME=[1E9AB230:01CCB397]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6204bis progress and way forward
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 21:44:56 -0000

QnJpYW4sDQoNCkp1c3QgcG9zdGVkIGEgbmV3IGNvcHkuICBBbiBlbWFpbCBzaG91bGQgYXJyaXZl
IHNob3J0bHkuDQoNCkhlbWFudA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
QnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0K
U2VudDogTW9uZGF5LCBEZWNlbWJlciAwNSwgMjAxMSAzOjM0IFBNDQpUbzogSGVtYW50IFNpbmdo
IChzaGVtYW50KQ0KQ2M6IEJyem96b3dza2ksIEpvaG47IEZyZWQgQmFrZXIgKGZyZWQpOyB2Nm9w
c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gNjIwNGJpcyBwcm9ncmVzcyBhbmQgd2F5
IGZvcndhcmQNCg0KUGxlYXNlIGxldCdzIHNlZSBhIG5ldyBkcmFmdCBBU0FQLCBzbyB0aGF0IHdl
IGNhbiBhbGwgbG9vayBhdCB0aGUNCmV4YWN0IGRpZmZzLiBJdCdzIHRoZSBXRyB0aGF0IGRlY2lk
ZXMsIG5vdCB0aGUgRFQuDQoNClJlZ2FyZHMNCiAgIEJyaWFuDQoNCg==

From shemant@cisco.com  Mon Dec  5 13:46:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A98D11E80B0 for ; Mon,  5 Dec 2011 13:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.225
X-Spam-Level: 
X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tIebiDWmHd6y for ; Mon,  5 Dec 2011 13:46:54 -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 19F6711E8081 for ; Mon,  5 Dec 2011 13:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1949; q=dns/txt; s=iport; t=1323121614; x=1324331214; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AgJOIw3QDKfP5sh1Xmj2Tv6yQRY9iah2XB94KM29gd8=; b=IL9Ba1bVVuWqtl0mf7g/Zun77r1PK99l7T30bda/0oLeeDlbAZCpHV3z ePifBFI0qrsXwVeFgLK2xoWeYgvtDdK/a8+g/mcyEhH6wel3OSnDgWG+q L2gV6wYT10xHyOvPPRmkJg/+Y6KCUwlAQ86JaszC4KMMXduiuoffaCvkK A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAHQ73U6tJV2b/2dsb2JhbABEmhmQKYEFgXIBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEEwgBGYdtlj8BnluIDIIyYwSILZ5m
X-IronPort-AV: E=Sophos;i="4.71,301,1320624000"; d="scan'208";a="41325620"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 05 Dec 2011 21:46:53 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB5LkruN023817 for ; Mon, 5 Dec 2011 21:46:53 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 15:46:52 -0600
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: Mon, 5 Dec 2011 15:46:53 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30377897B@XMB-RCD-109.cisco.com>
In-Reply-To: <20111205214302.25836.28905.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-04.txt
Thread-Index: Acyzlwr7Oz/2biq1S8aOuD9cvmrtNAAABdBQ
References: <20111205214302.25836.28905.idtracker@ietfa.amsl.com>
From: "Hemant Singh (shemant)" 
To: 
X-OriginalArrivalTime: 05 Dec 2011 21:46:52.0580 (UTC) FILETIME=[665E6E40:01CCB397]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 21:46:54 -0000

Folks,

DS-Lite sunsetting is a new Appendix in this version of the doc.  Please
see Appendix A and review.  After review and discussion we plan to
change the Coexistence section to merge with DS-lite sunsetting.=20

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of internet-drafts@ietf.org
Sent: Monday, December 05, 2011 4:43 PM
To: i-d-announce@ietf.org
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPv6 Operations Working
Group of the IETF.

	Title           : Basic Requirements for IPv6 Customer Edge
Routers
	Author(s)       : Hemant Singh
                          Wes Beebee
                          Chris Donley
                          Barbara Stark
                          Ole Troan
	Filename        : draft-ietf-v6ops-6204bis-04.txt
	Pages           : 23
	Date            : 2011-12-05

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers IP transition
   technologies and transition technologies coexistence.  Two transition
   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
   the document.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-04.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-v6ops-6204bis-04.txt

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

From brian.e.carpenter@gmail.com  Mon Dec  5 14:36:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9CB11E80E2 for ; Mon,  5 Dec 2011 14:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.58
X-Spam-Level: 
X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 PXVedwjr03pY for ; Mon,  5 Dec 2011 14:36:58 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5C9A21F8BCD for ; Mon,  5 Dec 2011 14:36:57 -0800 (PST)
Received: by ghrr18 with SMTP id r18so5796660ghr.31 for ; Mon, 05 Dec 2011 14:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=fk7muyARuS8G4No4trpS8MvWQrD0KOysi/D3/2GrNQ8=; b=oMDa1F3IfV4cYVnAyozbA5qbDLqpwd+dBgdc26fzA57LofYxe2au0xovGTmC19Vct2 822w1sutYkOrU/HLaM98VyO1fo4voM3UhCaj6uQJT7DhZhCVANsIeEcYePD0V+bJVHTb yGCorc9G7d3vwVtk+JqXq0C22XBKbiiu50GOQ=
Received: by 10.50.135.71 with SMTP id pq7mr2941376igb.26.1323124615479; Mon, 05 Dec 2011 14:36:55 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id e2sm81599082ibe.0.2011.12.05.14.36.53 (version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 14:36:54 -0800 (PST)
Message-ID: <4EDD4786.30500@gmail.com>
Date: Tue, 06 Dec 2011 11:36:54 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IPv6 Operations 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-guidance-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 22:36:58 -0000

Hi,

This has been updated following the comments received so far. As
discussed in Taipei, we are requesting reviews from the WG. Additional
authors with personal expertise would be welcome too.

   Brian and Sheng.

-------- Original Message --------
Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-01.txt
Date: Mon, 05 Dec 2011 14:33:13 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IPv6 Guidance for Internet Content and Application Service Providers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-carpenter-v6ops-icp-guidance-01.txt
	Pages           : 16
	Date            : 2011-12-05

   This document provides guidance and suggestions for Internet Content
   Providers and Application Service Providers who wish to offer their
   service to both IPv6 and IPv4 customers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-01.txt



From lorenzo@google.com  Mon Dec  5 14:52:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6854321F86A0 for ; Mon,  5 Dec 2011 14:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.896
X-Spam-Level: 
X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 WgkhZy152MHi for ; Mon,  5 Dec 2011 14:52:21 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E221F85B1 for ; Mon,  5 Dec 2011 14:52:21 -0800 (PST)
Received: by ywm13 with SMTP id 13so5685970ywm.31 for ; Mon, 05 Dec 2011 14:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=VRoYdILbPLdNCX+fj4toFOY068PxyWiJ1hWKD3uZkjg=; b=A+EkH7R7x+jlBPpM89/qAWwRWk0c0/d/sMDHB1RgfsNsPxWUPWoZVr/nTcQzsYvA1X syiXVohNwK71QT3m07oQ==
Received: by 10.236.75.167 with SMTP id z27mr16104042yhd.53.1323125541258; Mon, 05 Dec 2011 14:52:21 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr16104026yhd.53.1323125541155; Mon, 05 Dec 2011 14:52:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 5 Dec 2011 14:51:59 -0800 (PST)
In-Reply-To: <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com>
References:  <074C587F-8D6F-4C5E-85CE-6137FF15E61A@employees.org>  <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>  <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>  <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org>   <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> <4EDA8DF0.7000803@globis.net> <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com>
From: Lorenzo Colitti 
Date: Mon, 5 Dec 2011 14:51:59 -0800
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf3005dde6dfb1e804b3602b1e
X-System-Of-Record: true
Cc: Thomas Narten , Ray Hunter , "" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 22:52:22 -0000

--20cf3005dde6dfb1e804b3602b1e
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Dec 3, 2011 at 13:45, Ted Lemon  wrote:
>
> Sorry, I really don't see the problem here.   I think you are
> underestimating the complexity of the homenet configuration that needs to
> be tracked.   We have decided that in the homenet case, the entire network
> configuration, including routing, has to be managed automatically without
> user intervention.   So keeping track of an excluded prefix is a trivial
> subset of the total problem, and we needn't be concerned about it.
>

If we use something like Jari's automatic prefix assignment mechanism, then
all a homenet border router has to do is inject its aggregate (e.g., a /48)
into the mesh to have other routers autoconfigure their interfaces from it.
That's simple, well-understood and elegant, and it matches other use cases
such flooding the homenet ULA.

If we need to support PD exclude we need to add an "aggregate with excluded
prefix(es)" attribute that has to be carrier around in the mesh. So it is
more complex to implement.

--20cf3005dde6dfb1e804b3602b1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sat, Dec 3, 2011 at 13:45, Ted Lemon <Ted.Lemon@nominum.co=
m> wrote:



Sorry, I really don't see the problem here. =A0 I thi=
nk you are underestimating the complexity of the homenet configuration that=
 needs to be tracked. =A0 We have decided that in the homenet case, the ent=
ire network configuration, including routing, has to be managed automatical=
ly without user intervention. =A0 So keeping track of an excluded prefix is=
 a trivial subset of the total problem, and we needn't be concerned abo=
ut it.




If we use something like Jari's automa=
tic prefix assignment mechanism, then all a homenet border router has to do=
 is inject its aggregate (e.g., a /48) into the mesh to have other routers =
autoconfigure their interfaces from it. That's simple, well-understood =
and elegant, and it matches other use cases such flooding the homenet ULA.<=
/div>



If we need to support PD exclude we need to add an &quo=
t;aggregate with excluded prefix(es)" attribute that has to be carrier=
 around in the mesh. So it is more complex to implement.


--20cf3005dde6dfb1e804b3602b1e--

From shemant@cisco.com  Tue Dec  6 07:17:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8821F8BB2 for ; Tue,  6 Dec 2011 07:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level: 
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 E9qZsUHbMvfg for ; Tue,  6 Dec 2011 07:17:26 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3190321F8BA9 for ; Tue,  6 Dec 2011 07:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5507; q=dns/txt; s=iport; t=1323184646; x=1324394246; h=mime-version:subject:date:message-id:from:to; bh=3T99zNwuhbBEL49s1PSqsxPGqqil7ZlGxM/MmXb2cJU=; b=PyHkQvIoUPNiXuy8emlr04ciScfua0+weTyPj66I6PoIP4sFIFipLDx4 cNr4OO7pPdHqfrfdCStG9j4oEkXpXS+0+YP1AyCnbA7hprHGGRoJBi4Zw Mky16D4ucTSEpHCHXpjl+FZyAdnrfmyPSc3pwisq4RhUN9YdFs/GPPLHP g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJUx3k6tJXHB/2dsb2JhbABEgk2oD4EFgXQBAQMSAQkRA1sBKgYYB1cBBBsanSiBJgGecYgagjVjBIgunnc
X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; d="scan'208,217";a="41540561"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 06 Dec 2011 15:17:25 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pB6FHPpN011555 for ; Tue, 6 Dec 2011 15:17:25 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Dec 2011 09:17:25 -0600
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_01CCB42A.28BD0B52"
Date: Tue, 6 Dec 2011 09:17:24 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778B60@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: pending items for rfc6204bis
Thread-Index: Acy0Kig/qVQT8BBwRQaj77Qeow6EZw==
From: "Hemant Singh (shemant)" 
To: 
X-OriginalArrivalTime: 06 Dec 2011 15:17:25.0296 (UTC) FILETIME=[28CB9B00:01CCB42A]
Subject: [v6ops] pending items for rfc6204bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 15:17:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB42A.28BD0B52
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

1.	WPD-7 bullet needs closure from the DHC WG as to what should be
the text for this bullet.=20
2.	If the DS-Lite DLW-4 bullet includes a SHOULD, additional text
around the bullet is needed to explain the SHOULD.    This is typical
IETF procedure when text includes a SHOULD.    All other text in
sections 4.4.1 and 4.4.2 stays.
3.	Merge DS-Lite sunsetting in Appendix A (interested DS-Lite
parties, please review the Appendix A or rfc6204bis -04) with the
Coexistence section.  Manual configuration is out of scope for the CE
router document and hence also the Coexistence section.
4.	6rd sunsetting: MarkT said bullet 5 of the Coexistence section
is almost there.   MarkT please let us know what specifc text we can
add.
5.	6rd sunsetting:  What clarification can bullet 6 of the
Coexistence section  make?

=20

Hemant

=20


------_=_NextPart_001_01CCB42A.28BD0B52
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
  1. WPD-7 bullet needs closure from the DHC WG as to what should be =
the text for this bullet. 
  2. If the DS-Lite DLW-4 bullet includes a =
SHOULD, additional text around the bullet is needed to explain the =
SHOULD.    This is typical IETF procedure when text =
includes a SHOULD.    All other text in sections 4.4.1 =
and 4.4.2 stays.
  3. Merge DS-Lite sunsetting in Appendix A =
(interested DS-Lite parties, please review the Appendix A or =
rfc6204bis -04) with the Coexistence section.  Manual =
configuration is out of scope for the CE router document and hence also =
the Coexistence section.
  4. 6rd sunsetting: MarkT said bullet 5 of =
the Coexistence section is almost there.   MarkT please let us =
know what specifc text we can add.
  5. 6rd sunsetting:  What =
clarification can bullet 6 of the Coexistence section  =
make?
 
Hemant
 

------_=_NextPart_001_01CCB42A.28BD0B52--

From victor.kuarsingh@gmail.com  Tue Dec  6 19:09:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DD021F8B0B for ; Tue,  6 Dec 2011 19:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.522
X-Spam-Level: 
X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.920, BAYES_50=0.001, 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 cZO6VolZA7yI for ; Tue,  6 Dec 2011 19:09:25 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3185621F8B08 for ; Tue,  6 Dec 2011 19:09:12 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so76907vbb.31 for ; Tue, 06 Dec 2011 19:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=IskgYuIsJpSm9ODNgU0cRUVVWo8Xzfnh81pzTyCf+UQ=; b=IFKGPwROgFKsIE2/cSqjtZA6SIajTaUym8ijUWudbIXwTdEYxUKcgnrYtTjYzg5GIf 2euwmEWJIOgwJFP8PvYQ8r9xvaeq/2SvVf154ZgI8JstrJYoi0YCR0MHcLJHxJAvmWQW zAK4wQQ/fn1EuGRQSeenGIN1ddnUG/hZSpSuM=
Received: by 10.52.68.240 with SMTP id z16mr9517122vdt.120.1323227351223; Tue, 06 Dec 2011 19:09:11 -0800 (PST)
Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id em3sm277785vdc.10.2011.12.06.19.09.09 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 19:09:10 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Tue, 06 Dec 2011 22:09:06 -0500
From: Victor Kuarsingh 
To: 
Message-ID: 
Thread-Topic: Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3406054149_32594175"
Subject: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 03:09:27 -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_3406054149_32594175
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

v6ops group,

To help guide and facilitate feedback, I would like to highlight some of th=
e
discussion points which were made prior and in the last WG meeting (Taipei)
and see where various members of the group sit on a number of subjects to
help improve and guide the document.

1. Document Objective
The document's objective was to provide an operational view as to how to
enable IPv6 by analyzing the main [now] commercial options and show an
incremental way of enabling and improving IPv6 services.  The document also
sets out to explain that not all phases are needed (operator by operator
environment) and calls out some of the main considerations.  The other main
point is that this document is also targeted at "in-servcie" networks which
are IPv4-only today and which need to move to IPv6.  Greenfield is not a
target (which may have very different options and considerations).  This
document is also intended to meet the sprit of the normative referenced
document - draft=ADietf-v6ops-v4v6tran-framework.

2. Updates Since IETF82

The document's text has been improved and made a bit more concise.  I have
also added in more text calling out that not all phases were required
depending on the operator's network conditions.

3. Considered Technologies

Based on previous feedback (pre-IETF82) we added specific explanation for
why NAT64, although a valid technology, was not as viable for in-servie
networks due to the need to support IPv4 devices in the home.  We did not
include many of the other numerous technologies as they are still very much
in discussion.  The point was not to be all things to everybody, but be
valuable to many.

4. Strong Emphasis on IPv6

For obvious reasons there is a strong focus get IPv6 into the network and
optimize the connection over time when possible.

Questions to the Group:

1. Considered Technologies =AD Are they other technologies to consider are
very important (respondent should be clear why it's so important and should
remember the document's objective =AD add IPv6, in-service networks, IPv4 is
there now.)
2. Position on IPv4 and IPv6.  Should there be a shift in the document's
tone to be more progressive on movement to IPv6? (I would also ask a
respondent that says yes to this explain how this can be accomplished in a
practical way considering that most services on the Net and in an operators
network are IPv4 now).  We would need to explain how the evolution of tools=
,
management and other related functions can be moved along and work hand in
hand (since without this an operator has no "service").  I have had some
feedback on this key point and would like to see how others see this point.
Thanks for your feedback,

Regards,

Victor K








--B_3406054149_32594175
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


v6ops group,

<=
/div>
To help guide and facilitate feedback, I would like to highlight s=
ome of the discussion points which were made prior and in the last WG meetin=
g (Taipei) and see where various members of the group sit on a number of sub=
jects to help improve and guide the document.

  1. Do=
cument Objective
The document's objective was to provide an op=
erational view as to how to enable IPv6 by analyzing the main [now] commerci=
al options and show an incremental way of enabling and improving IPv6 servic=
es.  The document also sets out to explain that not all phases are need=
ed (operator by operator environment) and calls out some of the main conside=
rations.  The other main point is that this document is also targeted a=
t "in-servcie" networks which are IPv4-only today and which need to move to =
IPv6.  Greenfield is not a target (which may have very different option=
s and considerations).  This document is also intended to meet the spri=
t of the normative referenced document - draft–ietf-v6ops-v4v6tran-fra=
mework.

2. Updates Since IETF82

The document's text has been improved and made a bit more concise. &nb=
sp;I have also added in more text calling out that not all phases were requi=
red depending on the operator's network conditions.

3. Considered Technologies

Based on previous feedb=
ack (pre-IETF82) we added specific explanation for why NAT64, although a val=
id technology, was not as viable for in-servie networks due to the need to s=
upport IPv4 devices in the home.  We did not include many of the other =
numerous technologies as they are still very much in discussion.  The p=
oint was not to be all things to everybody, but be valuable to many.

4. Strong Emphasis on IPv6

For ob=
vious reasons there is a strong focus get IPv6 into the network and optimize=
 the connection over time when possible.  

Que=
stions to the Group:

  1. Considered Technologies =
211; Are they other technologies to consider are very important (respondent =
should be clear why it's so important and should remember the document's obj=
ective – add IPv6, in-service networks, IPv4 is there now.)
  2. Po=
sition on IPv4 and IPv6.  Should there be a shift in the document's ton=
e to be more progressive on movement to IPv6? (I would also ask a respondent=
 that says yes to this explain how this can be accomplished in a practical w=
ay considering that most services on the Net and in an operators network are=
 IPv4 now).  We would need to explain how the evolution of tools, manag=
ement and other related functions can be moved along and work hand in hand (=
since without this an operator has no "service").  I have had some feed=
back on this key point and would like to see how others see this point.
    3. =

Thanks for your feedback,

Regards,
<=
div>
Victor K







--B_3406054149_32594175--



From jouni.nospam@gmail.com  Tue Dec  6 22:58:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77821F8505 for ; Tue,  6 Dec 2011 22:58:39 -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=[AWL=0.000,  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 1W1gVbefbHMR for ; Tue,  6 Dec 2011 22:58:39 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44D21F8500 for ; Tue,  6 Dec 2011 22:58:38 -0800 (PST)
Received: by laap9 with SMTP id p9so84477laa.31 for ; Tue, 06 Dec 2011 22:58:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=95NlTJB6d0LuAt13AUX4IvY2FZGngLuK14xRoRViZH8=; b=UXcHipBBrOXvZojsMpQI0K/lyQxJpBg5TJElf9fKwgQ/zqhQPwesuW2ar6n8EQDOW8 sXlqd4CzGOCBV63pmOa+kF9kr895sFlVxAnMSrycfXg4GbMXifwIMG28bRNc5JibJdd1 u0/J/lw1H9yt+2dx0DhPmjNJ3mhNv6cMyyL7Y=
Received: by 10.152.104.198 with SMTP id gg6mr10917314lab.23.1323241117396; Tue, 06 Dec 2011 22:58:37 -0800 (PST)
Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id op2sm696675lab.6.2011.12.06.22.58.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 22:58:35 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: jouni korhonen 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>
Date: Wed, 7 Dec 2011 08:58:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 		<748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>		<591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>		<399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org>			<5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com>		<5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com><88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl><4EDA80AC.6030907@globis.net><435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com>, <4EDA8DF0.7000803@globis.net><6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> <4EDAA849.40208@globis.net> < 5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 06:58:39 -0000

Hemant,

On Dec 4, 2011, at 1:59 AM, Hemant Singh (shemant) wrote:

> It=92s high time the subject of the email changed to the pd-exclude =
document rather than the rfc6204bis document for which the ship has =
sailed to include the pd-exclude in.   That said, one question I had was =
this.   How are network interfaces

IMHO it is too early to state that the ship has sailed for RFC6204bis =
already.

> setup on the DR that is sending an RA with one exclude prefix if the =
DR has 20K different IPV6 CE routers  as RR=92s?  The RA is multicast =
and, say, reaches 40K CE routers.   How is the exclude prefix working =
with the multicast RA?

Is this a real deployment scenario you are designing or already having =
where you intend to use pd-exclude? My question regarding this specific =
example is why you would use RAs & SLAAC to configure 40K CE routers' =
WAN links attached to a single link (with one prefix) and then try to =
apply pd-exclude in the first place?=20

- JOuni


> =20
> Hemant
> =20

[snip]=

From shemant@cisco.com  Wed Dec  7 05:41:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5891321F8B95 for ; Wed,  7 Dec 2011 05:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.526
X-Spam-Level: 
X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K9Yr0r1L6grL for ; Wed,  7 Dec 2011 05:41:00 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6621F8BE4 for ; Wed,  7 Dec 2011 05:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6086; q=dns/txt; s=iport; t=1323265260; x=1324474860; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=V3SIpw6FWSzKCq6ZW67uRig43srEUSrqbwpnu20dRTk=; b=aWc7EprTxKHuSaEh9JVuu8qnUMAaJOmqjijHifJCH64HG/2rxaPcXGFM YDJ/F0VC+5DfGWM1MFOOhAhI8uAKHsn+jzqmBYoAwWzAEwwFNnayNG7D/ JYrhHrf7Hb54HUUeGRGPb7XoxpV1lRn15x2ZL2jfVgC2t9b2S3Bs4aIph 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQAAJhs306tJXG+/2dsb2JhbABDgk2XVJAxgQWBcgEBAQMBEgEJEQNJBQcEAgEIEQQBAQsGFwEGASAlCQgBAQQTCBqHZZgFAZ4jilFjBIgulySHWw
X-IronPort-AV: E=Sophos;i="4.71,313,1320624000"; d="scan'208,217";a="41868187"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 07 Dec 2011 13:40:59 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB7Dex65029702;  Wed, 7 Dec 2011 13:40:59 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Dec 2011 07:40:59 -0600
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_01CCB4E5.DA9157C3"
Date: Wed, 7 Dec 2011 07:40:58 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy0raWlG0rISBgKTlajqoiwYcpCdAAN1USA
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" 
X-OriginalArrivalTime: 07 Dec 2011 13:40:59.0803 (UTC) FILETIME=[DAC92EB0:01CCB4E5]
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 13:41:01 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB4E5.DA9157C3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, December 07, 2011 1:59 AM
Cc: Ray Hunter; Ted Lemon; Thomas Narten; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20

=20

> setup on the DR that is sending an RA with one exclude prefix if the
DR has 20K different IPV6 CE routers  as RR's?  The RA >is multicast
and, say, reaches 40K CE routers.   How is the exclude prefix working
with the multicast RA?

=20

>Is this a real deployment scenario you are designing or already having
where you intend to use pd-exclude? My question >regarding this specific
example is why you would use RAs & SLAAC to configure 40K CE routers'
WAN links attached to a single >link (with one prefix) and then try to
apply pd-exclude in the first place?=20

=20

I do have a cable deployment where I can have the access concentrator
serving 100K PD clients.  The network would like to use the pd-exclude.
The reason I asked my question because one person already said, the DR
can use the RA so that the DR can address it's interface with SLAAC.
There are two choices for such a deployment and that is why I asked the
question.  Either the same exclude /64 is given to each of the 100K
clients or the network uses unicast RA.  Some IETF document has already
defined a unicast.=20

=20

Hemant

=20


------_=_NextPart_001_01CCB4E5.DA9157C3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
-----Original Message-----
From: jouni korhonen =
[mailto:jouni.nospam@gmail.com] 
Sent: Wednesday, December 07, 2011 =
1:59 AM
Cc: Ray Hunter; Ted Lemon; Thomas Narten; =
v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
 
 
> setup on the DR that is sending =
an RA with one exclude prefix if the DR has 20K different IPV6 CE =
routers  as RR’s?  The RA >is multicast and, say, =
reaches 40K CE routers.   How is the exclude prefix working =
with the multicast RA?
 
>Is this a real deployment =
scenario you are designing or already having where you intend to use =
pd-exclude? My question >regarding this specific example is why you =
would use RAs & SLAAC to configure 40K CE routers' WAN links =
attached to a single >link (with one prefix) and then try to apply =
pd-exclude in the first place? 
 
I do have a cable =
deployment where I can have the access concentrator serving 100K PD =
clients.  The network would like to use the pd-exclude.  The =
reason I asked my question because one person already said, the DR can =
use the RA so that the DR can address it’s interface with =
SLAAC.  There are two choices for such a deployment and that is why =
I asked the question.  Either the same exclude /64 is given to each =
of the 100K clients or the network uses unicast RA.  Some IETF =
document has already defined a unicast. 
 
Hemant
 

------_=_NextPart_001_01CCB4E5.DA9157C3--

From wesley.george@twcable.com  Wed Dec  7 08:02:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051721F8C76 for ; Wed,  7 Dec 2011 08:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.483
X-Spam-Level: 
X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ell1hfr-Y7DL for ; Wed,  7 Dec 2011 08:02:11 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A80B421F8C88 for ; Wed,  7 Dec 2011 08:02:11 -0800 (PST)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000"; d="scan'208";a="291678620"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Dec 2011 10:56:00 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 7 Dec 2011 11:02:10 -0500
From: "George, Wes" 
To: Victor Kuarsingh , "v6ops@ietf.org" 
Date: Wed, 7 Dec 2011 11:02:09 -0500
Thread-Topic: Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
Thread-Index: Acy0jaaaS7rfFtIKRH6P67XysnJ9qAAYeM/g
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
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:02:12 -0000

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of V=
ictor Kuarsingh

> Questions to the Group:

> Position on IPv4 and IPv6. Should there be a shift in the document's tone
> to be more progressive on movement to IPv6?

WEG] I'm reproducing and refining some feedback I've given the authors offl=
ine already so that those on-list can agree/disagree.

By the time this document is published as RFCXXXX, I expect that one or mor=
e of the planned sequels to World IPv6 Day will have generated a non-trivia=
l deployment in last-mile access, as well as many content providers making =
the decision to enable IPv6 permanently. Therefore, I disagree with your fo=
undational assertion that "most services/operators are IPv4."
Plenty of IPv6 documents have already been written with that assumption in =
mind, and IMO it's time to start moving away from that. We should be assumi=
ng that IPv6 traffic is likely to be non-trivial on day 1 for those only de=
ploying now, and treat our recommendations and considerations accordingly. =
We should make it clear that they *are* behind on IPv6 deployment if they h=
aven't started yet, not to browbeat them, but to discuss the ramifications =
of that delay.
There is a legitimate complaint that SPs and vendors have not taken IPv6 se=
riously and even when they deploy/implement it, it ends up being a second-c=
lass service, either because it's being done using different topology, redu=
ced peering capacity and diversity, on elements that can't scale to "real" =
levels, it's encapsulated, or the support structure and processes aren't in=
 place yet (supported by a team of 3 people). I think that in a lot of case=
s, this is being perpetuated by the notion that you can start with "trainin=
g wheels" on your IPv6 deployment because it isn't carrying enough traffic =
to matter, and at this point that notion is probably doing more harm than g=
ood.

One note of specific feedback on this regard, rather than treating the disc=
ussion evenly and saying "avoid using a transition/encaps technology on you=
r primary traffic path..." say something clearer about making sure that you=
r IPv6 traffic path is first-class. That doesn't mean do something to make =
IPv4 worse, but I think that making IPv6 equivalent or better should be a s=
tated goal.

Second, I think we should tighten the scope of this document to explicitly =
exclude any consideration of IPv4.
Something equivalent to - "This document makes no recommendation on when (o=
r if) a given network can move away from IPv4. It assumes that the network =
in question already has a functional IPv4 solution that will coexist with t=
he chosen IPv6 deployment. Further, it does not discuss any methods of IPv4=
 extension/service continuity, because it is purely focusing on the practic=
al considerations of deploying IPv6 support within an existing network. Oth=
er documents exist which discuss and compare options for IPv4 extension tec=
hnologies in great detail [reference, reference, reference] and this can be=
 evaluated independently of the IPv6 deployment strategy." - it may be that=
 the separation isn't quite that clean, since you may have to note areas wh=
ere coexistence isn't complete or other interaction considerations, but I t=
hink that should be the primary philosophy when determining the scope of an=
y IPv4 discussion in this document.

Put another way, single-stack IPv6 is the end goal, and I don't think that'=
s as outlandish or unreachable as it sounds as a premise for this document.=
 Single-stack IPv6 and dual-stack are not that much different, except for t=
hat fact that a single-stack IPv6 network has to ensure that all of its anc=
illary control-path things (not just data forwarding) are capable of functi=
oning properly without IPv4 configured. Therefore I don't think it's too ag=
gressive to treat this document as a comprehensive recommendation on how to=
 deploy a single-stack IPv6 network, with the acknowledgement that IPv4 may=
 coexist and make it a dual-stack network and nothing (or not much) has to =
change. This gives the benefit of ensuring that the network itself is ready=
 to move to single-stack whenever there is not an appreciable amount of IPv=
4 traffic being carried anymore. You could then prioritize the items to IPv=
6-enable given the assumption that everything except IPv6 forwarding works =
via the existing IPv4 network, meaning that the network doesn't have to go =
single-stack all at once.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From cb.list6@gmail.com  Wed Dec  7 08:18:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE30521F867F for ; Wed,  7 Dec 2011 08:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.401
X-Spam-Level: 
X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 vqGuymLTV+1D for ; Wed,  7 Dec 2011 08:18:33 -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 9DC7621F85EF for ; Wed,  7 Dec 2011 08:18:33 -0800 (PST)
Received: by dajz8 with SMTP id z8so983390daj.31 for ; Wed, 07 Dec 2011 08:18:33 -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=ekp+svGdGUI+oKgKGfNXJxwxj/FL7Zjuin9vFVfL7to=; b=id7ws3Rq8g5g/ZriCUUs+7bgxVHiYRtUs+LvBGL6/Cuv9h7FuqXpZT9HyIA5LXSGpj 3zq9fneEqbWGaVSsZcc3lRzPmydWSS1KKaTcey0YYyyPVnrjCQ770OrlvIVc1vS0bWN3 DqYoZlLzREE0JHP8FGVVPg8ZLgpYt2NhkIEGU=
MIME-Version: 1.0
Received: by 10.68.55.103 with SMTP id r7mr6888277pbp.41.1323274712217; Wed, 07 Dec 2011 08:18:32 -0800 (PST)
Received: by 10.142.43.11 with HTTP; Wed, 7 Dec 2011 08:18:32 -0800 (PST)
Received: by 10.142.43.11 with HTTP; Wed, 7 Dec 2011 08:18:32 -0800 (PST)
In-Reply-To: 
References:  
Date: Wed, 7 Dec 2011 08:18:32 -0800
Message-ID: 
From: Cameron Byrne 
To: "George, Wes" 
Content-Type: multipart/alternative; boundary=bcaec53aeec429771204b382e749
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:18:34 -0000

--bcaec53aeec429771204b382e749
Content-Type: text/plain; charset=ISO-8859-1

On Dec 7, 2011 8:02 AM, "George, Wes"  wrote:
>
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Victor Kuarsingh
>
> > Questions to the Group:
>
> > Position on IPv4 and IPv6. Should there be a shift in the document's
tone
> > to be more progressive on movement to IPv6?
>
> WEG] I'm reproducing and refining some feedback I've given the authors
offline already so that those on-list can agree/disagree.
>
> By the time this document is published as RFCXXXX, I expect that one or
more of the planned sequels to World IPv6 Day will have generated a
non-trivial deployment in last-mile access, as well as many content
providers making the decision to enable IPv6 permanently. Therefore, I
disagree with your foundational assertion that "most services/operators are
IPv4."
> Plenty of IPv6 documents have already been written with that assumption
in mind, and IMO it's time to start moving away from that. We should be
assuming that IPv6 traffic is likely to be non-trivial on day 1 for those
only deploying now, and treat our recommendations and considerations
accordingly. We should make it clear that they *are* behind on IPv6
deployment if they haven't started yet, not to browbeat them, but to
discuss the ramifications of that delay.
> There is a legitimate complaint that SPs and vendors have not taken IPv6
seriously and even when they deploy/implement it, it ends up being a
second-class service, either because it's being done using different
topology, reduced peering capacity and diversity, on elements that can't
scale to "real" levels, it's encapsulated, or the support structure and
processes aren't in place yet (supported by a team of 3 people). I think
that in a lot of cases, this is being perpetuated by the notion that you
can start with "training wheels" on your IPv6 deployment because it isn't
carrying enough traffic to matter, and at this point that notion is
probably doing more harm than good.
>
> One note of specific feedback on this regard, rather than treating the
discussion evenly and saying "avoid using a transition/encaps technology on
your primary traffic path..." say something clearer about making sure that
your IPv6 traffic path is first-class. That doesn't mean do something to
make IPv4 worse, but I think that making IPv6 equivalent or better should
be a stated goal.
>

+1 to non-trivial potential day one loads and treating the traffic first
class.

> Second, I think we should tighten the scope of this document to
explicitly exclude any consideration of IPv4.
> Something equivalent to - "This document makes no recommendation on when
(or if) a given network can move away from IPv4. It assumes that the
network in question already has a functional IPv4 solution that will
coexist with the chosen IPv6 deployment. Further, it does not discuss any
methods of IPv4 extension/service continuity, because it is purely focusing
on the practical considerations of deploying IPv6 support within an
existing network. Other documents exist which discuss and compare options
for IPv4 extension technologies in great detail [reference, reference,
reference] and this can be evaluated independently of the IPv6 deployment
strategy." - it may be that the separation isn't quite that clean, since
you may have to note areas where coexistence isn't complete or other
interaction considerations, but I think that should be the primary
philosophy when determining the scope of any IPv4 discussion in this
document.
>
> Put another way, single-stack IPv6 is the end goal, and I don't think
that's as outlandish or unreachable as it sounds as a premise for this
document. Single-stack IPv6 and dual-stack are not that much different,
except for that fact that a single-stack IPv6 network has to ensure that
all of its ancillary control-path things (not just data forwarding) are
capable of functioning properly without IPv4 configured. Therefore I don't
think it's too aggressive to treat this document as a comprehensive
recommendation on how to deploy a single-stack IPv6 network, with the
acknowledgement that IPv4 may coexist and make it a dual-stack network and
nothing (or not much) has to change. This gives the benefit of ensuring
that the network itself is ready to move to single-stack whenever there is
not an appreciable amount of IPv4 traffic being carried anymore. You could
then prioritize the items to IPv6-enable given the assumption that
everything except IPv6 forwarding works via the existin
>  g IPv4 network, meaning that the network doesn't have to go single-stack
all at once.
>

+1 for clearly articulating single stack v6 as the attainable end state
goal.

Cb

> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--bcaec53aeec429771204b382e749
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Dec 7, 2011 8:02 AM, "George, Wes" <wesley.george@twcable.com> wrote:

>

> From: v6ops-bounces@ietf.org=
 [mailto:v6ops-bounces@ietf.o=
rg] On Behalf Of Victor Kuarsingh

>

> > Questions to the Group:

>

> > Position on IPv4 and IPv6. Should there be a shift in the documen=
t's tone

> > to be more progressive on movement to IPv6?

>

> WEG] I'm reproducing and refining some feedback I've given the=
 authors offline already so that those on-list can agree/disagree.

>

> By the time this document is published as RFCXXXX, I expect that one o=
r more of the planned sequels to World IPv6 Day will have generated a non-t=
rivial deployment in last-mile access, as well as many content providers ma=
king the decision to enable IPv6 permanently. Therefore, I disagree with yo=
ur foundational assertion that "most services/operators are IPv4."=
;


> Plenty of IPv6 documents have already been written with that assumptio=
n in mind, and IMO it's time to start moving away from that. We should =
be assuming that IPv6 traffic is likely to be non-trivial on day 1 for thos=
e only deploying now, and treat our recommendations and considerations acco=
rdingly. We should make it clear that they *are* behind on IPv6 deployment =
if they haven't started yet, not to browbeat them, but to discuss the r=
amifications of that delay.


> There is a legitimate complaint that SPs and vendors have not taken IP=
v6 seriously and even when they deploy/implement it, it ends up being a sec=
ond-class service, either because it's being done using different topol=
ogy, reduced peering capacity and diversity, on elements that can't sca=
le to "real" levels, it's encapsulated, or the support struct=
ure and processes aren't in place yet (supported by a team of 3 people)=
. I think that in a lot of cases, this is being perpetuated by the notion t=
hat you can start with "training wheels" on your IPv6 deployment =
because it isn't carrying enough traffic to matter, and at this point t=
hat notion is probably doing more harm than good.


>

> One note of specific feedback on this regard, rather than treating the=
 discussion evenly and saying "avoid using a transition/encaps technol=
ogy on your primary traffic path..." say something clearer about makin=
g sure that your IPv6 traffic path is first-class. That doesn't mean do=
 something to make IPv4 worse, but I think that making IPv6 equivalent or b=
etter should be a stated goal.


>


+1 to non-trivial potential day one loads and treating the traffic first=
 class. 


> Second, I think we should tighten the scope of this document to exp=
licitly exclude any consideration of IPv4.

> Something equivalent to - "This document makes no recommendation =
on when (or if) a given network can move away from IPv4. It assumes that th=
e network in question already has a functional IPv4 solution that will coex=
ist with the chosen IPv6 deployment. Further, it does not discuss any metho=
ds of IPv4 extension/service continuity, because it is purely focusing on t=
he practical considerations of deploying IPv6 support within an existing ne=
twork. Other documents exist which discuss and compare options for IPv4 ext=
ension technologies in great detail [reference, reference, reference] and t=
his can be evaluated independently of the IPv6 deployment strategy." -=
 it may be that the separation isn't quite that clean, since you may ha=
ve to note areas where coexistence isn't complete or other interaction =
considerations, but I think that should be the primary philosophy when dete=
rmining the scope of any IPv4 discussion in this document.


>

> Put another way, single-stack IPv6 is the end goal, and I don't th=
ink that's as outlandish or unreachable as it sounds as a premise for t=
his document. Single-stack IPv6 and dual-stack are not that much different,=
 except for that fact that a single-stack IPv6 network has to ensure that a=
ll of its ancillary control-path things (not just data forwarding) are capa=
ble of functioning properly without IPv4 configured. Therefore I don't =
think it's too aggressive to treat this document as a comprehensive rec=
ommendation on how to deploy a single-stack IPv6 network, with the acknowle=
dgement that IPv4 may coexist and make it a dual-stack network and nothing =
(or not much) has to change. This gives the benefit of ensuring that the ne=
twork itself is ready to move to single-stack whenever there is not an appr=
eciable amount of IPv4 traffic being carried anymore. You could then priori=
tize the items to IPv6-enable given the assumption that everything except I=
Pv6 forwarding works via the existin


> =A0g IPv4 network, meaning that the network doesn't have to go sin=
gle-stack all at once.

>


+1 for clearly articulating single stack v6 as the attainable end state =
goal. 


Cb


> Wes George

>

> This E-mail and any of its attachments may contain Time Warner Cable p=
roprietary information, which is privileged, confidential, or subject to co=
pyright belonging to Time Warner Cable. This E-mail is intended solely for =
the use of the individual or entity to which it is addressed. If you are no=
t the intended recipient of this E-mail, you are hereby notified that any d=
issemination, distribution, copying, or action taken in relation to the con=
tents of and attachments to this E-mail is strictly prohibited and may be u=
nlawful. If you have received this E-mail in error, please notify the sende=
r immediately and permanently delete the original and any copy of this E-ma=
il and any printout.


> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--bcaec53aeec429771204b382e749--

From victor.kuarsingh@gmail.com  Wed Dec  7 08:44:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1021F8B74 for ; Wed,  7 Dec 2011 08:44:46 -0800 (PST)
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.765,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 wI1Qtierqof6 for ; Wed,  7 Dec 2011 08:44:45 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1051521F8B6E for ; Wed,  7 Dec 2011 08:44:40 -0800 (PST)
Received: by ggnk5 with SMTP id k5so997511ggn.31 for ; Wed, 07 Dec 2011 08:44:37 -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=GAtTQUffSv2eHlFYT2RNGl3Szx0Yibpidkuu5979vb0=; b=Ck5tlbAsmiEVjjnz5fqU70z6U+ZSpK0hXCD7aUGGY44Xwk1yDTLLF9/woQkYtHZOUS 5J77SzCu41Mw+AAoM7uIj5gkhk4+BN+c04u+JKkBCv3jAE/TSk/gSbhlectPRLm55fYE 48sY3WcSvxIQrKdRHk5UiiKlvitG4pFVkykC0=
MIME-Version: 1.0
Received: by 10.68.52.193 with SMTP id v1mr6644274pbo.120.1323276276931; Wed, 07 Dec 2011 08:44:36 -0800 (PST)
Received: by 10.68.64.162 with HTTP; Wed, 7 Dec 2011 08:44:36 -0800 (PST)
In-Reply-To: 
References:   
Date: Wed, 7 Dec 2011 11:44:36 -0500
Message-ID: 
From: Victor Kuarsingh 
To: Cameron Byrne 
Content-Type: multipart/alternative; boundary=bcaec5430bda6d1c4304b38344e0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:44:46 -0000

--bcaec5430bda6d1c4304b38344e0
Content-Type: text/plain; charset=ISO-8859-1

Wes/Cameron,

To be clear, we can we define what we mean by "single stack" IPv6.  In my
mind this means things like DS-Lite and not NAT64 (as the latter would
define a IPv6 only home network which I don't think is feasible in the
mid-term future).

I am assuming that NAT46 (home gateway) is not in the cards since I see not
drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network (to
round out my previous statement).

Further to this, then we would need to beef up the considerations for IPv6
single stack since it's vast.

regards,

Victor K

On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne  wrote:

>
> On Dec 7, 2011 8:02 AM, "George, Wes"  wrote:
> >
> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Victor Kuarsingh
> >
> > > Questions to the Group:
> >
> > > Position on IPv4 and IPv6. Should there be a shift in the document's
> tone
> > > to be more progressive on movement to IPv6?
> >
> > WEG] I'm reproducing and refining some feedback I've given the authors
> offline already so that those on-list can agree/disagree.
> >
> > By the time this document is published as RFCXXXX, I expect that one or
> more of the planned sequels to World IPv6 Day will have generated a
> non-trivial deployment in last-mile access, as well as many content
> providers making the decision to enable IPv6 permanently. Therefore, I
> disagree with your foundational assertion that "most services/operators are
> IPv4."
> > Plenty of IPv6 documents have already been written with that assumption
> in mind, and IMO it's time to start moving away from that. We should be
> assuming that IPv6 traffic is likely to be non-trivial on day 1 for those
> only deploying now, and treat our recommendations and considerations
> accordingly. We should make it clear that they *are* behind on IPv6
> deployment if they haven't started yet, not to browbeat them, but to
> discuss the ramifications of that delay.
> > There is a legitimate complaint that SPs and vendors have not taken IPv6
> seriously and even when they deploy/implement it, it ends up being a
> second-class service, either because it's being done using different
> topology, reduced peering capacity and diversity, on elements that can't
> scale to "real" levels, it's encapsulated, or the support structure and
> processes aren't in place yet (supported by a team of 3 people). I think
> that in a lot of cases, this is being perpetuated by the notion that you
> can start with "training wheels" on your IPv6 deployment because it isn't
> carrying enough traffic to matter, and at this point that notion is
> probably doing more harm than good.
> >
> > One note of specific feedback on this regard, rather than treating the
> discussion evenly and saying "avoid using a transition/encaps technology on
> your primary traffic path..." say something clearer about making sure that
> your IPv6 traffic path is first-class. That doesn't mean do something to
> make IPv4 worse, but I think that making IPv6 equivalent or better should
> be a stated goal.
> >
>
> +1 to non-trivial potential day one loads and treating the traffic first
> class.
>
> > Second, I think we should tighten the scope of this document to
> explicitly exclude any consideration of IPv4.
> > Something equivalent to - "This document makes no recommendation on when
> (or if) a given network can move away from IPv4. It assumes that the
> network in question already has a functional IPv4 solution that will
> coexist with the chosen IPv6 deployment. Further, it does not discuss any
> methods of IPv4 extension/service continuity, because it is purely focusing
> on the practical considerations of deploying IPv6 support within an
> existing network. Other documents exist which discuss and compare options
> for IPv4 extension technologies in great detail [reference, reference,
> reference] and this can be evaluated independently of the IPv6 deployment
> strategy." - it may be that the separation isn't quite that clean, since
> you may have to note areas where coexistence isn't complete or other
> interaction considerations, but I think that should be the primary
> philosophy when determining the scope of any IPv4 discussion in this
> document.
> >
> > Put another way, single-stack IPv6 is the end goal, and I don't think
> that's as outlandish or unreachable as it sounds as a premise for this
> document. Single-stack IPv6 and dual-stack are not that much different,
> except for that fact that a single-stack IPv6 network has to ensure that
> all of its ancillary control-path things (not just data forwarding) are
> capable of functioning properly without IPv4 configured. Therefore I don't
> think it's too aggressive to treat this document as a comprehensive
> recommendation on how to deploy a single-stack IPv6 network, with the
> acknowledgement that IPv4 may coexist and make it a dual-stack network and
> nothing (or not much) has to change. This gives the benefit of ensuring
> that the network itself is ready to move to single-stack whenever there is
> not an appreciable amount of IPv4 traffic being carried anymore. You could
> then prioritize the items to IPv6-enable given the assumption that
> everything except IPv6 forwarding works via the existin
> >  g IPv4 network, meaning that the network doesn't have to go
> single-stack all at once.
> >
>
> +1 for clearly articulating single stack v6 as the attainable end state
> goal.
>
> Cb
>
> > Wes George
> >
> > This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>

--bcaec5430bda6d1c4304b38344e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Wes/Cameron,

To be clear, we can we define what we mean by "sin=
gle stack" IPv6.=A0 In my mind this means things like DS-Lite and not =
NAT64 (as the latter would define a IPv6 only home network which I don'=
t think is feasible in the mid-term future).


I am assuming that NAT46 (home gateway) is not in the cards since I see=
 not drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/netwo=
rk (to round out my previous statement).

Further to this, then we wo=
uld need to beef up the considerations for IPv6 single stack since it's=
 vast.


regards,

Victor K

On Wed, Dec =
7, 2011 at 11:18 AM, Cameron Byrne <cb.list6@gmail.com> wrote:




On Dec 7, 2011 8:02 AM, "George, Wes" <wesley.george@twcable.com> w=
rote:

>

> From: v6op=
s-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor Kuarsingh
>

> > Questions to the Group:

>

> > Position on IPv4 and IPv6. Should there be a shift in the documen=
t's tone

> > to be more progressive on movement to IPv6?

>

> WEG] I'm reproducing and refining some feedback I've given the=
 authors offline already so that those on-list can agree/disagree.

>

> By the time this document is published as RFCXXXX, I expect that one o=
r more of the planned sequels to World IPv6 Day will have generated a non-t=
rivial deployment in last-mile access, as well as many content providers ma=
king the decision to enable IPv6 permanently. Therefore, I disagree with yo=
ur foundational assertion that "most services/operators are IPv4."=
;



> Plenty of IPv6 documents have already been written with that assumptio=
n in mind, and IMO it's time to start moving away from that. We should =
be assuming that IPv6 traffic is likely to be non-trivial on day 1 for thos=
e only deploying now, and treat our recommendations and considerations acco=
rdingly. We should make it clear that they *are* behind on IPv6 deployment =
if they haven't started yet, not to browbeat them, but to discuss the r=
amifications of that delay.



> There is a legitimate complaint that SPs and vendors have not taken IP=
v6 seriously and even when they deploy/implement it, it ends up being a sec=
ond-class service, either because it's being done using different topol=
ogy, reduced peering capacity and diversity, on elements that can't sca=
le to "real" levels, it's encapsulated, or the support struct=
ure and processes aren't in place yet (supported by a team of 3 people)=
. I think that in a lot of cases, this is being perpetuated by the notion t=
hat you can start with "training wheels" on your IPv6 deployment =
because it isn't carrying enough traffic to matter, and at this point t=
hat notion is probably doing more harm than good.



>

> One note of specific feedback on this regard, rather than treating the=
 discussion evenly and saying "avoid using a transition/encaps technol=
ogy on your primary traffic path..." say something clearer about makin=
g sure that your IPv6 traffic path is first-class. That doesn't mean do=
 something to make IPv4 worse, but I think that making IPv6 equivalent or b=
etter should be a stated goal.



>


+1 to non-trivial potential day one loads and treating the traffic=
 first class. 


> Second, I think we should tighten the scope of this document to exp=
licitly exclude any consideration of IPv4.

> Something equivalent to - "This document makes no recommendation =
on when (or if) a given network can move away from IPv4. It assumes that th=
e network in question already has a functional IPv4 solution that will coex=
ist with the chosen IPv6 deployment. Further, it does not discuss any metho=
ds of IPv4 extension/service continuity, because it is purely focusing on t=
he practical considerations of deploying IPv6 support within an existing ne=
twork. Other documents exist which discuss and compare options for IPv4 ext=
ension technologies in great detail [reference, reference, reference] and t=
his can be evaluated independently of the IPv6 deployment strategy." -=
 it may be that the separation isn't quite that clean, since you may ha=
ve to note areas where coexistence isn't complete or other interaction =
considerations, but I think that should be the primary philosophy when dete=
rmining the scope of any IPv4 discussion in this document.



>

> Put another way, single-stack IPv6 is the end goal, and I don't th=
ink that's as outlandish or unreachable as it sounds as a premise for t=
his document. Single-stack IPv6 and dual-stack are not that much different,=
 except for that fact that a single-stack IPv6 network has to ensure that a=
ll of its ancillary control-path things (not just data forwarding) are capa=
ble of functioning properly without IPv4 configured. Therefore I don't =
think it's too aggressive to treat this document as a comprehensive rec=
ommendation on how to deploy a single-stack IPv6 network, with the acknowle=
dgement that IPv4 may coexist and make it a dual-stack network and nothing =
(or not much) has to change. This gives the benefit of ensuring that the ne=
twork itself is ready to move to single-stack whenever there is not an appr=
eciable amount of IPv4 traffic being carried anymore. You could then priori=
tize the items to IPv6-enable given the assumption that everything except I=
Pv6 forwarding works via the existin



> =A0g IPv4 network, meaning that the network doesn't have to go sin=
gle-stack all at once.

>


+1 for clearly articulating single stack v6 as the attainable end =
state goal. 


Cb


> Wes George

>

> This E-mail and any of its attachments may contain Time Warner Cable p=
roprietary information, which is privileged, confidential, or subject to co=
pyright belonging to Time Warner Cable. This E-mail is intended solely for =
the use of the individual or entity to which it is addressed. If you are no=
t the intended recipient of this E-mail, you are hereby notified that any d=
issemination, distribution, copying, or action taken in relation to the con=
tents of and attachments to this E-mail is strictly prohibited and may be u=
nlawful. If you have received this E-mail in error, please notify the sende=
r immediately and permanently delete the original and any copy of this E-ma=
il and any printout.




> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org=


> https://www.ietf.org/mailman/listinfo/v6ops







--bcaec5430bda6d1c4304b38344e0--

From wesley.george@twcable.com  Wed Dec  7 09:20:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68AB21F8C84 for ; Wed,  7 Dec 2011 09:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.982
X-Spam-Level: 
X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=0.480,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  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 yOhiFrpBWDTK for ; Wed,  7 Dec 2011 09:20:25 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id BD2BE21F8C81 for ; Wed,  7 Dec 2011 09:20:24 -0800 (PST)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,313,1320642000";  d="scan'208,217";a="307219351"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Dec 2011 12:15:12 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 7 Dec 2011 12:20:23 -0500
From: "George, Wes" 
To: Victor Kuarsingh , Cameron Byrne 
Date: Wed, 7 Dec 2011 12:20:22 -0500
Thread-Topic: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
Thread-Index: Acy0/4/d/etxluv0Sf63NNhXIhfZvAAAFlzQ
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: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD46569377914531E0E99PRVPEXVS03cor_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 17:20:27 -0000

--_000_DCC302FAA9FE5F4BBA4DCAD46569377914531E0E99PRVPEXVS03cor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]

To be clear, we can we define what we mean by "single stack" IPv6.  In my m=
ind this means things like DS-Lite and not NAT64 (as the latter would defin=
e a IPv6 only home network which I don't think is feasible in the mid-term =
future).

I am assuming that NAT46 (home gateway) is not in the cards since I see not=
 drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network (to=
 round out my previous statement).
[WEG] I think you're conflating a few things that shouldn't be and that's c=
reating confusion. I don't mean single-stack + transition technologies, so =
let's put DSLite, et. al aside for the moment. At its simplest, what I'm re=
ferring to as single-stack IPv6  is a network that is capable of accepting =
IPv6 packets at one end and pushing them out on the other end *without* req=
uiring IPv4 to serve as a transport layer or control plane (via tunnels/tra=
nslation/veg-o-matic) anywhere in the middle. That has no bearing on whethe=
r there that network *also* is capable of accepting IPv4 packets at one end=
 and pushing them out at the other, nor what method it uses to accomplish m=
oving IPv4 traffic around.
In other words, this is the highest exponent of the "ships in the night" me=
taphor that is used to describe IPv4 and IPv6 coexistence. A single-stack I=
Pv6 *network* enables devices and endpoints that speak IPv6 to do so. It do=
es not do anything with IPv4. If there is a need to support IPv4 (and I'm a=
greeing that there is), then the network would be considered dual-stack, bu=
t the method for accomplishing such is largely orthogonal to the IPv6 imple=
mentation. Yes, something like DSLite might make sense since you would be d=
eploying an IPv6 infrastructure, but since your doc is assuming that this i=
s not a Greenfield deployment, it's easier for us to simply assume that the=
 IPv4 support is black-box. It's there or it's not, it has enough addresses=
 or it doesn't, but for the purposes of this discussion, we simply don't ca=
re. We'd be explaining how to deploy IPv6 such that it'll work by itself, w=
ith the idea that eventually you might want to turn off IPv4, and you'd rat=
her not have to re-architect your management, monitoring, and control plane=
 to make that work. Making IPv4 work and making IPv6 work are essentially t=
wo variables in the same equation. Your current draft tries to solve for X =
and Y. I'm recommending that you only solve for Y, since multiple people ha=
ve already solved for X, and there's not necessarily a dependency between t=
he two. Similarly, I don't think that you need to expend a lot of time disc=
ussing/comparing different methods to jump across IPv4-only islands (6rd, e=
tc) other than to note that they exist and refer to other existing comparis=
ons of those transition and tunneling technologies. Native IPv6 (or as clos=
e as you can get) should be the goal, but acknowledging that it may not be =
possible to do it that purely at first can make the document more pragmatic=
 without moving towards recommending that as an end-state solution.

Further to this, then we would need to beef up the considerations for IPv6 =
single stack since it's vast.
[WEG] That's sorta my point - there's not a lot of info out there on how to=
 truly build a network that isn't reliant on IPv4, because pretty much all =
of them (with a few notable exceptions) are some flavor of dual-stack and c=
an therefore rely on IPv4 to fill in the gaps where IPv6 doesn't "do that" =
for some values of do and that. We can probably build on some existing info=
, but I am not aware of anything that really covers all of the things that =
an ISP must consider to really dual-stack their *network* and not simply th=
e forwarding path.
Hope that helps...
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_DCC302FAA9FE5F4BBA4DCAD46569377914531E0E99PRVPEXVS03cor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]









To be clear, we can we define what we mean by "single stack" IPv6=
.  In my mind this means things like DS-Lite and not NAT64 (as the lat=
ter would define a IPv6 only home network which I don't think is feasible i=
n the mid-term future).



I am assuming that NAT46 (home gateway) is not in the cards since I see not=
 drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/networ=
k (to round out my previous statement).=



[WEG] I think you’re conflating a few things that shouldn=
’t be and that’s creating confusion. I don’t mean single-=
stack +
 transition technologies, so let’s put DSLite, et. al aside for the m=
oment. At its simplest, what I’m referring to as single-stack IPv6 &n=
bsp;is a network that is capable of accepting IPv6 packets at one end and p=
ushing them out on the other end *without* requiring
 IPv4 to serve as a transport layer or control plane (via tunnels/translati=
on/veg-o-matic) anywhere in the middle. That has no bearing on whether ther=
e that network *also* is capable of accepting IPv4 packets at one end and p=
ushing them out at the other, nor
 what method it uses to accomplish moving IPv4 traffic around. <=
/span>


In other words, this is the highest exponent of the “ship=
s in the night” metaphor that is used to describe IPv4 and IPv6
 coexistence. A single-stack IPv6 *network* enables devices and endpoints t=
hat speak IPv6 to do so. It does not do anything with IPv4. If there is a n=
eed to support IPv4 (and I’m agreeing that there is), then the networ=
k would be considered dual-stack, but
 the method for accomplishing such is largely orthogonal to the IPv6 implem=
entation. Yes, something like DSLite might make sense since you would be de=
ploying an IPv6 infrastructure, but since your doc is assuming that this is=
 not a Greenfield deployment, it’s
 easier for us to simply assume that the IPv4 support is black-box. It̵=
7;s there or it’s not, it has enough addresses or it doesn’t, b=
ut for the purposes of this discussion, we simply don’t care. We̵=
7;d be explaining how to deploy IPv6 such that it’ll work by itself,
 with the idea that eventually you might want to turn off IPv4, and youR=
17;d rather not have to re-architect your management, monitoring, and contr=
ol plane to make that work. Making IPv4 work and making IPv6 work are essen=
tially two variables in the same equation.
 Your current draft tries to solve for X and Y. I’m recommending that=
 you only solve for Y, since multiple people have already solved for X, and=
 there’s not necessarily a dependency between the two. Similarly, I d=
on’t think that you need to expend a lot of
 time discussing/comparing different methods to jump across IPv4-only islan=
ds (6rd, etc) other than to note that they exist and refer to other existin=
g comparisons of those transition and tunneling technologies. Native IPv6 (=
or as close as you can get) should
 be the goal, but acknowledging that it may not be possible to do it that p=
urely at first can make the document more pragmatic without moving towards =
recommending that as an end-state solution.



Further to this, then we would need to beef up the considerations for IPv6 =
single stack since it's vast.


[WEG] That’s sorta my point – there’s not a l=
ot of info out there on how to truly build a network that isn’t relia=
nt on IPv4,
 because pretty much all of them (with a few notable exceptions) are some f=
lavor of dual-stack and can therefore rely on IPv4 to fill in the gaps wher=
e IPv6 doesn’t “do that” for some values of do and that. =
We can probably build on some existing info, but I
 am not aware of anything that really covers all of the things that an ISP =
must consider to really dual-stack their *network* and not simply the forwa=
rding path.



Hope that helps…


Wes George=










This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.





--_000_DCC302FAA9FE5F4BBA4DCAD46569377914531E0E99PRVPEXVS03cor_--

From cb.list6@gmail.com  Wed Dec  7 11:04:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8B21F8BF4 for ; Wed,  7 Dec 2011 11:04:59 -0800 (PST)
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.372, BAYES_00=-2.599, J_CHICKENPOX_13=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 kFKfS8bgLlNC for ; Wed,  7 Dec 2011 11:04:58 -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 CA29C21F8BEB for ; Wed,  7 Dec 2011 11:04:58 -0800 (PST)
Received: by dajz8 with SMTP id z8so1158454daj.31 for ; Wed, 07 Dec 2011 11:04:58 -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=yBCgPHSTC5mLFLQaboJI4DkYaOBDeqR4iISWUdsU1zw=; b=cwPSlS+vXdoZOuWarfF4mMJji4acjdz5CWV8DO8rBtn6oyWUZQ2jkyckAEN2KV+up/ oFfpCjZa9ZhnVAZ/cqFPdkBFmyusSD/Jot+oYjWKv47pRsrDyPzTN6+oCL5IeIbaY+Qb oOi8MWapGfk7ca/HtYLSisSuxaGI2I165Pkpw=
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr7745067pbh.75.1323284698538; Wed, 07 Dec 2011 11:04:58 -0800 (PST)
Received: by 10.142.43.11 with HTTP; Wed, 7 Dec 2011 11:04:58 -0800 (PST)
In-Reply-To: 
References:    
Date: Wed, 7 Dec 2011 11:04:58 -0800
Message-ID: 
From: Cameron Byrne 
To: Victor Kuarsingh 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 19:04:59 -0000

On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
 wrote:
> Wes/Cameron,
>
> To be clear, we can we define what we mean by "single stack" IPv6.=A0 In =
my
> mind this means things like DS-Lite and not NAT64 (as the latter would
> define a IPv6 only home network which I don't think is feasible in the
> mid-term future).
>
> I am assuming that NAT46 (home gateway) is not in the cards since I see n=
ot
> drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/network =
(to
> round out my previous statement).
>

NAT46 in the home  gateway draft
http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02

> Further to this, then we would need to beef up the considerations for IPv=
6
> single stack since it's vast.
>
> regards,
>
> Victor K
>
>
> On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne  wrote=
:
>>
>>
>> On Dec 7, 2011 8:02 AM, "George, Wes"  wrote:
>> >
>> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> > Of Victor Kuarsingh
>> >
>> > > Questions to the Group:
>> >
>> > > Position on IPv4 and IPv6. Should there be a shift in the document's
>> > > tone
>> > > to be more progressive on movement to IPv6?
>> >
>> > WEG] I'm reproducing and refining some feedback I've given the authors
>> > offline already so that those on-list can agree/disagree.
>> >
>> > By the time this document is published as RFCXXXX, I expect that one o=
r
>> > more of the planned sequels to World IPv6 Day will have generated a
>> > non-trivial deployment in last-mile access, as well as many content
>> > providers making the decision to enable IPv6 permanently. Therefore, I
>> > disagree with your foundational assertion that "most services/operator=
s are
>> > IPv4."
>> > Plenty of IPv6 documents have already been written with that assumptio=
n
>> > in mind, and IMO it's time to start moving away from that. We should b=
e
>> > assuming that IPv6 traffic is likely to be non-trivial on day 1 for th=
ose
>> > only deploying now, and treat our recommendations and considerations
>> > accordingly. We should make it clear that they *are* behind on IPv6
>> > deployment if they haven't started yet, not to browbeat them, but to d=
iscuss
>> > the ramifications of that delay.
>> > There is a legitimate complaint that SPs and vendors have not taken IP=
v6
>> > seriously and even when they deploy/implement it, it ends up being a
>> > second-class service, either because it's being done using different
>> > topology, reduced peering capacity and diversity, on elements that can=
't
>> > scale to "real" levels, it's encapsulated, or the support structure an=
d
>> > processes aren't in place yet (supported by a team of 3 people). I thi=
nk
>> > that in a lot of cases, this is being perpetuated by the notion that y=
ou can
>> > start with "training wheels" on your IPv6 deployment because it isn't
>> > carrying enough traffic to matter, and at this point that notion is pr=
obably
>> > doing more harm than good.
>> >
>> > One note of specific feedback on this regard, rather than treating the
>> > discussion evenly and saying "avoid using a transition/encaps technolo=
gy on
>> > your primary traffic path..." say something clearer about making sure =
that
>> > your IPv6 traffic path is first-class. That doesn't mean do something =
to
>> > make IPv4 worse, but I think that making IPv6 equivalent or better sho=
uld be
>> > a stated goal.
>> >
>>
>> +1 to non-trivial potential day one loads and treating the traffic first
>> class.
>>
>> > Second, I think we should tighten the scope of this document to
>> > explicitly exclude any consideration of IPv4.
>> > Something equivalent to - "This document makes no recommendation on wh=
en
>> > (or if) a given network can move away from IPv4. It assumes that the n=
etwork
>> > in question already has a functional IPv4 solution that will coexist w=
ith
>> > the chosen IPv6 deployment. Further, it does not discuss any methods o=
f IPv4
>> > extension/service continuity, because it is purely focusing on the pra=
ctical
>> > considerations of deploying IPv6 support within an existing network. O=
ther
>> > documents exist which discuss and compare options for IPv4 extension
>> > technologies in great detail [reference, reference, reference] and thi=
s can
>> > be evaluated independently of the IPv6 deployment strategy." - it may =
be
>> > that the separation isn't quite that clean, since you may have to note=
 areas
>> > where coexistence isn't complete or other interaction considerations, =
but I
>> > think that should be the primary philosophy when determining the scope=
 of
>> > any IPv4 discussion in this document.
>> >
>> > Put another way, single-stack IPv6 is the end goal, and I don't think
>> > that's as outlandish or unreachable as it sounds as a premise for this
>> > document. Single-stack IPv6 and dual-stack are not that much different=
,
>> > except for that fact that a single-stack IPv6 network has to ensure th=
at all
>> > of its ancillary control-path things (not just data forwarding) are ca=
pable
>> > of functioning properly without IPv4 configured. Therefore I don't thi=
nk
>> > it's too aggressive to treat this document as a comprehensive recommen=
dation
>> > on how to deploy a single-stack IPv6 network, with the acknowledgement=
 that
>> > IPv4 may coexist and make it a dual-stack network and nothing (or not =
much)
>> > has to change. This gives the benefit of ensuring that the network its=
elf is
>> > ready to move to single-stack whenever there is not an appreciable amo=
unt of
>> > IPv4 traffic being carried anymore. You could then prioritize the item=
s to
>> > IPv6-enable given the assumption that everything except IPv6 forwardin=
g
>> > works via the existin
>> > =A0g IPv4 network, meaning that the network doesn't have to go
>> > single-stack all at once.
>> >
>>
>> +1 for clearly articulating single stack v6 as the attainable end state
>> goal.
>>
>> Cb
>>
>> > Wes George
>> >
>> > This E-mail and any of its attachments may contain Time Warner Cable
>> > proprietary information, which is privileged, confidential, or subject=
 to
>> > copyright belonging to Time Warner Cable. This E-mail is intended sole=
ly for
>> > the use of the individual or entity to which it is addressed. If you a=
re not
>> > the intended recipient of this E-mail, you are hereby notified that an=
y
>> > dissemination, distribution, copying, or action taken in relation to t=
he
>> > contents of and attachments to this E-mail is strictly prohibited and =
may be
>> > unlawful. If you have received this E-mail in error, please notify the
>> > sender immediately and permanently delete the original and any copy of=
 this
>> > E-mail and any printout.
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>
>

From victor.kuarsingh@gmail.com  Wed Dec  7 11:08:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4658421F8BEB for ; Wed,  7 Dec 2011 11:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=0.912,  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 8eRqVSxo0nwQ for ; Wed,  7 Dec 2011 11:08:00 -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 402E621F8BE8 for ; Wed,  7 Dec 2011 11:08:00 -0800 (PST)
Received: by dajz8 with SMTP id z8so1161354daj.31 for ; Wed, 07 Dec 2011 11:08:00 -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=enSCKLgoboOoQ80RpOx6lO5hHE20xaTeazMCAkkT4Z8=; b=a9JB1Shq/7nZnrYRok+AMNxTHTralp86FN5ag1gq6E3esnVKmrzoHIOgesvcrmRbOE rXWpnEil82zgdmWbVKFLcTIFyXRYEbsS9pMv4YUeLfvLLH6PnKfSSKSX8UvqAhQ7PlvG S+g6WdUAhsIzOsVe+/Yv5Y8PO+wf0rHD3XhJM=
MIME-Version: 1.0
Received: by 10.68.52.193 with SMTP id v1mr7627221pbo.120.1323284880020; Wed, 07 Dec 2011 11:08:00 -0800 (PST)
Received: by 10.68.64.162 with HTTP; Wed, 7 Dec 2011 11:07:59 -0800 (PST)
In-Reply-To: 
References:     
Date: Wed, 7 Dec 2011 14:07:59 -0500
Message-ID: 
From: Victor Kuarsingh 
To: "George, Wes" 
Content-Type: multipart/alternative; boundary=bcaec5430bda35d40f04b3854502
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 19:08:01 -0000

--bcaec5430bda35d40f04b3854502
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Wes,

On Wed, Dec 7, 2011 at 12:20 PM, George, Wes wro=
te:

>    *From:* Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] ****
>
>
> To be clear, we can we define what we mean by "single stack" IPv6.  In my
> mind this means things like DS-Lite and not NAT64 (as the latter would
> define a IPv6 only home network which I don't think is feasible in the
> mid-term future).
>
> I am assuming that NAT46 (home gateway) is not in the cards since I see
> not drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/networ=
k
> (to round out my previous statement).**
>
> *[WEG] I think you=92re conflating a few things that shouldn=92t be and
> that=92s creating confusion. I don=92t mean single-stack + transition
> technologies, so let=92s put DSLite, et. al aside for the moment. At its
> simplest, what I=92m referring to as single-stack IPv6  is a network that=
 is
> capable of accepting IPv6 packets at one end and pushing them out on the
> other end *without* requiring IPv4 to serve as a transport layer or contr=
ol
> plane (via tunnels/translation/veg-o-matic) anywhere in the middle. That
> has no bearing on whether there that network *also* is capable of accepti=
ng
> IPv4 packets at one end and pushing them out at the other, nor what metho=
d
> it uses to accomplish moving IPv4 traffic around. *
>
Ok, I understand what you are saying.. makes sense. I agree with your
statements.



> **
>
> *In other words, this is the highest exponent of the =93ships in the nigh=
t=94
> metaphor that is used to describe IPv4 and IPv6 coexistence. A single-sta=
ck
> IPv6 *network* enables devices and endpoints that speak IPv6 to do so. It
> does not do anything with IPv4. If there is a need to support IPv4 (and I=
=92m
> agreeing that there is), then the network would be considered dual-stack,
> but the method for accomplishing such is largely orthogonal to the IPv6
> implementation. Yes, something like DSLite might make sense since you wou=
ld
> be deploying an IPv6 infrastructure, but since your doc is assuming that
> this is not a Greenfield deployment, it=92s easier for us to simply assum=
e
> that the IPv4 support is black-box. It=92s there or it=92s not, it has en=
ough
> addresses or it doesn=92t, but for the purposes of this discussion, we si=
mply
> don=92t care. We=92d be explaining how to deploy IPv6 such that it=92ll w=
ork by
> itself, with the idea that eventually you might want to turn off IPv4, an=
d
> you=92d rather not have to re-architect your management, monitoring, and
> control plane to make that work. Making IPv4 work and making IPv6 work ar=
e
> essentially two variables in the same equation. Your current draft tries =
to
> solve for X and Y. I=92m recommending that you only solve for Y, since
> multiple people have already solved for X, and there=92s not necessarily =
a
> dependency between the two. Similarly, I don=92t think that you need to
> expend a lot of time discussing/comparing different methods to jump acros=
s
> IPv4-only islands (6rd, etc) other than to note that they exist and refer
> to other existing comparisons of those transition and tunneling
> technologies. Native IPv6 (or as close as you can get) should be the goal=
,
> but acknowledging that it may not be possible to do it that purely at fir=
st
> can make the document more pragmatic without moving towards recommending
> that as an end-state solution.*
>

What would you propose we diminish?  Would this then devalue it's
applicability for some Wireline provides who will depend on IPv4 over IPv6
(6rd) for the next while (i.e. Access Network Constraints?).

If so, could we point them (at least) to the place where they can seek this
information?  (i.e. other drafts/RFCs which discuss such points including
deployment considerations).


Victor K

**

>
> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified th=
at
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy o=
f
> this E-mail and any printout.
>

--bcaec5430bda35d40f04b3854502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Wes,

On Wed, Dec 7, 2011 at 12:20 PM, Geo=
rge, Wes <wesley.george@twcable.com> wrote:


















From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]









To be clear, we can we define what we mean by "single stack" IPv6=
.=A0 In my mind this means things like DS-Lite and not NAT64 (as the latter=
 would define a IPv6 only home network which I don't think is feasible =
in the mid-term future).




I am assuming that NAT46 (home gateway) is not in the cards since I see not=
 drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/network (=
to round out my previous statement).=




[WEG] I think you=92re conflating a few things that shoul=
dn=92t be and that=92s creating confusion. I don=92t mean single-stack +
 transition technologies, so let=92s put DSLite, et. al aside for the momen=
t. At its simplest, what I=92m referring to as single-stack IPv6 =A0is a ne=
twork that is capable of accepting IPv6 packets at one end and pushing them=
 out on the other end *without* requiring
 IPv4 to serve as a transport layer or control plane (via tunnels/translati=
on/veg-o-matic) anywhere in the middle. That has no bearing on whether ther=
e that network *also* is capable of accepting IPv4 packets at one end and p=
ushing them out at the other, nor
 what method it uses to accomplish moving IPv4 traffic around. <=
/b>
Ok, I understand what you are sa=
ying.. makes sense. I agree with your statements.

=A0






In other words, this is the highest exponent of the =93ships in=
 the night=94 metaphor that is used to describe IPv4 and IPv6
 coexistence. A single-stack IPv6 *network* enables devices and endpoints t=
hat speak IPv6 to do so. It does not do anything with IPv4. If there is a n=
eed to support IPv4 (and I=92m agreeing that there is), then the network wo=
uld be considered dual-stack, but
 the method for accomplishing such is largely orthogonal to the IPv6 implem=
entation. Yes, something like DSLite might make sense since you would be de=
ploying an IPv6 infrastructure, but since your doc is assuming that this is=
 not a Greenfield deployment, it=92s
 easier for us to simply assume that the IPv4 support is black-box. It=92s =
there or it=92s not, it has enough addresses or it doesn=92t, but for the p=
urposes of this discussion, we simply don=92t care. We=92d be explaining ho=
w to deploy IPv6 such that it=92ll work by itself,
 with the idea that eventually you might want to turn off IPv4, and you=92d=
 rather not have to re-architect your management, monitoring, and control p=
lane to make that work. Making IPv4 work and making IPv6 work are essential=
ly two variables in the same equation.
 Your current draft tries to solve for X and Y. I=92m recommending that you=
 only solve for Y, since multiple people have already solved for X, and the=
re=92s not necessarily a dependency between the two. Similarly, I don=92t t=
hink that you need to expend a lot of
 time discussing/comparing different methods to jump across IPv4-only islan=
ds (6rd, etc) other than to note that they exist and refer to other existin=
g comparisons of those transition and tunneling technologies. Native IPv6 (=
or as close as you can get) should
 be the goal, but acknowledging that it may not be possible to do it that p=
urely at first can make the document more pragmatic without moving towards =
recommending that as an end-state solution.



What would you propose we diminish?=A0 Would th=
is then devalue it's applicability for some Wireline provides who will =
depend on IPv4 over IPv6 (6rd) for the next while (i.e. Access Network Cons=
traints?).=A0 


If so, could we point them (at least) to the place where they can seek =
this information?=A0 (i.e. other drafts/RFCs which discuss such points incl=
uding deployment considerations).


Victor K













This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.










--bcaec5430bda35d40f04b3854502--

From victor.kuarsingh@gmail.com  Wed Dec  7 11:11:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05821F8C0C for ; Wed,  7 Dec 2011 11:11:48 -0800 (PST)
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.460,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 6vPEvO7q0L57 for ; Wed,  7 Dec 2011 11:11:47 -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 EDA7021F8BE5 for ; Wed,  7 Dec 2011 11:11:46 -0800 (PST)
Received: by dajz8 with SMTP id z8so1165205daj.31 for ; Wed, 07 Dec 2011 11:11:46 -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=HpYKnS6X8ldwamDg+GAYVrarzwQfsSEBb2exyaUnmsQ=; b=iWULVssJpx38I4VX7hdIp0MF/3zhJC/fJ1DiCy5bY9jFX38yeDjU+kszJMDLE0RGiN VC61NMEKIvJ1T0LpEuu3A4SriUQOeQZhdklAHrsKtw1NzjpFJHf8FALAi9lxB12Y7Er6 thFz6G4xsGVqlB9WByLNs2Y4Fq9D32dm2OjOM=
MIME-Version: 1.0
Received: by 10.68.5.41 with SMTP id p9mr7724081pbp.86.1323285106697; Wed, 07 Dec 2011 11:11:46 -0800 (PST)
Received: by 10.68.64.162 with HTTP; Wed, 7 Dec 2011 11:11:46 -0800 (PST)
In-Reply-To: 
References:     
Date: Wed, 7 Dec 2011 14:11:46 -0500
Message-ID: 
From: Victor Kuarsingh 
To: Cameron Byrne 
Content-Type: multipart/alternative; boundary=bcaec5215b0fb8a50a04b38552fa
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 19:11:48 -0000

--bcaec5215b0fb8a50a04b38552fa
Content-Type: text/plain; charset=ISO-8859-1

Cameron,

On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne  wrote:

> On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
>  wrote:
> > Wes/Cameron,
> >
> > To be clear, we can we define what we mean by "single stack" IPv6.  In my
> > mind this means things like DS-Lite and not NAT64 (as the latter would
> > define a IPv6 only home network which I don't think is feasible in the
> > mid-term future).
> >
> > I am assuming that NAT46 (home gateway) is not in the cards since I see
> not
> > drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network
> (to
> > round out my previous statement).
> >
>
> NAT46 in the home  gateway draft
> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02
>
>
Thanks for the reference.  Will review.  We have previously stated that we
wanted to keep the technologies in consideration to running code with
commercial availability.  Where is this with respect to that type of
position?

Victor K


> > Further to this, then we would need to beef up the considerations for
> IPv6
> > single stack since it's vast.
> >
> > regards,
> >
> > Victor K
> >
> >
> > On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne 
> wrote:
> >>
> >>
> >> On Dec 7, 2011 8:02 AM, "George, Wes" 
> wrote:
> >> >
> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> Behalf
> >> > Of Victor Kuarsingh
> >> >
> >> > > Questions to the Group:
> >> >
> >> > > Position on IPv4 and IPv6. Should there be a shift in the document's
> >> > > tone
> >> > > to be more progressive on movement to IPv6?
> >> >
> >> > WEG] I'm reproducing and refining some feedback I've given the authors
> >> > offline already so that those on-list can agree/disagree.
> >> >
> >> > By the time this document is published as RFCXXXX, I expect that one
> or
> >> > more of the planned sequels to World IPv6 Day will have generated a
> >> > non-trivial deployment in last-mile access, as well as many content
> >> > providers making the decision to enable IPv6 permanently. Therefore, I
> >> > disagree with your foundational assertion that "most
> services/operators are
> >> > IPv4."
> >> > Plenty of IPv6 documents have already been written with that
> assumption
> >> > in mind, and IMO it's time to start moving away from that. We should
> be
> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1 for
> those
> >> > only deploying now, and treat our recommendations and considerations
> >> > accordingly. We should make it clear that they *are* behind on IPv6
> >> > deployment if they haven't started yet, not to browbeat them, but to
> discuss
> >> > the ramifications of that delay.
> >> > There is a legitimate complaint that SPs and vendors have not taken
> IPv6
> >> > seriously and even when they deploy/implement it, it ends up being a
> >> > second-class service, either because it's being done using different
> >> > topology, reduced peering capacity and diversity, on elements that
> can't
> >> > scale to "real" levels, it's encapsulated, or the support structure
> and
> >> > processes aren't in place yet (supported by a team of 3 people). I
> think
> >> > that in a lot of cases, this is being perpetuated by the notion that
> you can
> >> > start with "training wheels" on your IPv6 deployment because it isn't
> >> > carrying enough traffic to matter, and at this point that notion is
> probably
> >> > doing more harm than good.
> >> >
> >> > One note of specific feedback on this regard, rather than treating the
> >> > discussion evenly and saying "avoid using a transition/encaps
> technology on
> >> > your primary traffic path..." say something clearer about making sure
> that
> >> > your IPv6 traffic path is first-class. That doesn't mean do something
> to
> >> > make IPv4 worse, but I think that making IPv6 equivalent or better
> should be
> >> > a stated goal.
> >> >
> >>
> >> +1 to non-trivial potential day one loads and treating the traffic first
> >> class.
> >>
> >> > Second, I think we should tighten the scope of this document to
> >> > explicitly exclude any consideration of IPv4.
> >> > Something equivalent to - "This document makes no recommendation on
> when
> >> > (or if) a given network can move away from IPv4. It assumes that the
> network
> >> > in question already has a functional IPv4 solution that will coexist
> with
> >> > the chosen IPv6 deployment. Further, it does not discuss any methods
> of IPv4
> >> > extension/service continuity, because it is purely focusing on the
> practical
> >> > considerations of deploying IPv6 support within an existing network.
> Other
> >> > documents exist which discuss and compare options for IPv4 extension
> >> > technologies in great detail [reference, reference, reference] and
> this can
> >> > be evaluated independently of the IPv6 deployment strategy." - it may
> be
> >> > that the separation isn't quite that clean, since you may have to
> note areas
> >> > where coexistence isn't complete or other interaction considerations,
> but I
> >> > think that should be the primary philosophy when determining the
> scope of
> >> > any IPv4 discussion in this document.
> >> >
> >> > Put another way, single-stack IPv6 is the end goal, and I don't think
> >> > that's as outlandish or unreachable as it sounds as a premise for this
> >> > document. Single-stack IPv6 and dual-stack are not that much
> different,
> >> > except for that fact that a single-stack IPv6 network has to ensure
> that all
> >> > of its ancillary control-path things (not just data forwarding) are
> capable
> >> > of functioning properly without IPv4 configured. Therefore I don't
> think
> >> > it's too aggressive to treat this document as a comprehensive
> recommendation
> >> > on how to deploy a single-stack IPv6 network, with the
> acknowledgement that
> >> > IPv4 may coexist and make it a dual-stack network and nothing (or not
> much)
> >> > has to change. This gives the benefit of ensuring that the network
> itself is
> >> > ready to move to single-stack whenever there is not an appreciable
> amount of
> >> > IPv4 traffic being carried anymore. You could then prioritize the
> items to
> >> > IPv6-enable given the assumption that everything except IPv6
> forwarding
> >> > works via the existin
> >> >  g IPv4 network, meaning that the network doesn't have to go
> >> > single-stack all at once.
> >> >
> >>
> >> +1 for clearly articulating single stack v6 as the attainable end state
> >> goal.
> >>
> >> Cb
> >>
> >> > Wes George
> >> >
> >> > This E-mail and any of its attachments may contain Time Warner Cable
> >> > proprietary information, which is privileged, confidential, or
> subject to
> >> > copyright belonging to Time Warner Cable. This E-mail is intended
> solely for
> >> > the use of the individual or entity to which it is addressed. If you
> are not
> >> > the intended recipient of this E-mail, you are hereby notified that
> any
> >> > dissemination, distribution, copying, or action taken in relation to
> the
> >> > contents of and attachments to this E-mail is strictly prohibited and
> may be
> >> > unlawful. If you have received this E-mail in error, please notify the
> >> > sender immediately and permanently delete the original and any copy
> of this
> >> > E-mail and any printout.
> >> > _______________________________________________
> >> > v6ops mailing list
> >> > v6ops@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
>

--bcaec5215b0fb8a50a04b38552fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Cameron,

On Wed, Dec 7, 2011 at 2:04 PM, =
Cameron Byrne <c=
b.list6@gmail.com> wrote:


On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh

<victor.kuarsingh@gmail.co=
m> wrote:

> Wes/Cameron,

>

> To be clear, we can we define what we mean by "single stack"=
 IPv6.=A0 In my

> mind this means things like DS-Lite and not NAT64 (as the latter would=


> define a IPv6 only home network which I don't think is feasible in=
 the

> mid-term future).

>

> I am assuming that NAT46 (home gateway) is not in the cards since I se=
e not

> drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/netwo=
rk (to

> round out my previous statement).

>




NAT46 in the home =A0gateway draft

http://tools.ietf.org/html/draft-mawatari-softwire-464xlat=
-02



<=
br>Thanks for the reference.=A0 Will review.=A0 We have previously stated t=
hat we wanted to keep the technologies in consideration to running code wit=
h commercial availability.=A0 Where is this with respect to that type of po=
sition?


Victor K
=A0

> Further to this, then we would need to beef up the considerations for =
IPv6

> single stack since it's vast.

>

> regards,

>

> Victor K

>

>

> On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne <cb.list6@gmail.com> wrote:

>>

>>

>> On Dec 7, 2011 8:02 AM, "George, Wes" <wesley.george@twcable.com> wrote:

>> >

>> > From: v6ops-bounces=
@ietf.org [mailto:v6ops-bounc=
es@ietf.org] On Behalf

>> > Of Victor Kuarsingh

>> >

>> > > Questions to the Group:

>> >

>> > > Position on IPv4 and IPv6. Should there be a shift in th=
e document's

>> > > tone

>> > > to be more progressive on movement to IPv6?

>> >

>> > WEG] I'm reproducing and refining some feedback I've =
given the authors

>> > offline already so that those on-list can agree/disagree.

>> >

>> > By the time this document is published as RFCXXXX, I expect t=
hat one or

>> > more of the planned sequels to World IPv6 Day will have gener=
ated a

>> > non-trivial deployment in last-mile access, as well as many c=
ontent

>> > providers making the decision to enable IPv6 permanently. The=
refore, I

>> > disagree with your foundational assertion that "most ser=
vices/operators are

>> > IPv4."

>> > Plenty of IPv6 documents have already been written with that =
assumption

>> > in mind, and IMO it's time to start moving away from that=
. We should be

>> > assuming that IPv6 traffic is likely to be non-trivial on day=
 1 for those

>> > only deploying now, and treat our recommendations and conside=
rations

>> > accordingly. We should make it clear that they *are* behind o=
n IPv6

>> > deployment if they haven't started yet, not to browbeat t=
hem, but to discuss

>> > the ramifications of that delay.

>> > There is a legitimate complaint that SPs and vendors have not=
 taken IPv6

>> > seriously and even when they deploy/implement it, it ends up =
being a

>> > second-class service, either because it's being done usin=
g different

>> > topology, reduced peering capacity and diversity, on elements=
 that can't

>> > scale to "real" levels, it's encapsulated, or t=
he support structure and

>> > processes aren't in place yet (supported by a team of 3 p=
eople). I think

>> > that in a lot of cases, this is being perpetuated by the noti=
on that you can

>> > start with "training wheels" on your IPv6 deploymen=
t because it isn't

>> > carrying enough traffic to matter, and at this point that not=
ion is probably

>> > doing more harm than good.

>> >

>> > One note of specific feedback on this regard, rather than tre=
ating the

>> > discussion evenly and saying "avoid using a transition/e=
ncaps technology on

>> > your primary traffic path..." say something clearer abou=
t making sure that

>> > your IPv6 traffic path is first-class. That doesn't mean =
do something to

>> > make IPv4 worse, but I think that making IPv6 equivalent or b=
etter should be

>> > a stated goal.

>> >

>>

>> +1 to non-trivial potential day one loads and treating the traffic=
 first

>> class.

>>

>> > Second, I think we should tighten the scope of this document =
to

>> > explicitly exclude any consideration of IPv4.

>> > Something equivalent to - "This document makes no recomm=
endation on when

>> > (or if) a given network can move away from IPv4. It assumes t=
hat the network

>> > in question already has a functional IPv4 solution that will =
coexist with

>> > the chosen IPv6 deployment. Further, it does not discuss any =
methods of IPv4

>> > extension/service continuity, because it is purely focusing o=
n the practical

>> > considerations of deploying IPv6 support within an existing n=
etwork. Other

>> > documents exist which discuss and compare options for IPv4 ex=
tension

>> > technologies in great detail [reference, reference, reference=
] and this can

>> > be evaluated independently of the IPv6 deployment strategy.&q=
uot; - it may be

>> > that the separation isn't quite that clean, since you may=
 have to note areas

>> > where coexistence isn't complete or other interaction con=
siderations, but I

>> > think that should be the primary philosophy when determining =
the scope of

>> > any IPv4 discussion in this document.

>> >

>> > Put another way, single-stack IPv6 is the end goal, and I don=
't think

>> > that's as outlandish or unreachable as it sounds as a pre=
mise for this

>> > document. Single-stack IPv6 and dual-stack are not that much =
different,

>> > except for that fact that a single-stack IPv6 network has to =
ensure that all

>> > of its ancillary control-path things (not just data forwardin=
g) are capable

>> > of functioning properly without IPv4 configured. Therefore I =
don't think

>> > it's too aggressive to treat this document as a comprehen=
sive recommendation

>> > on how to deploy a single-stack IPv6 network, with the acknow=
ledgement that

>> > IPv4 may coexist and make it a dual-stack network and nothing=
 (or not much)

>> > has to change. This gives the benefit of ensuring that the ne=
twork itself is

>> > ready to move to single-stack whenever there is not an apprec=
iable amount of

>> > IPv4 traffic being carried anymore. You could then prioritize=
 the items to

>> > IPv6-enable given the assumption that everything except IPv6 =
forwarding

>> > works via the existin

>> > =A0g IPv4 network, meaning that the network doesn't have =
to go

>> > single-stack all at once.

>> >

>>

>> +1 for clearly articulating single stack v6 as the attainable end =
state

>> goal.

>>

>> Cb

>>

>> > Wes George

>> >

>> > This E-mail and any of its attachments may contain Time Warne=
r Cable

>> > proprietary information, which is privileged, confidential, o=
r subject to

>> > copyright belonging to Time Warner Cable. This E-mail is inte=
nded solely for

>> > the use of the individual or entity to which it is addressed.=
 If you are not

>> > the intended recipient of this E-mail, you are hereby notifie=
d that any

>> > dissemination, distribution, copying, or action taken in rela=
tion to the

>> > contents of and attachments to this E-mail is strictly prohib=
ited and may be

>> > unlawful. If you have received this E-mail in error, please n=
otify the

>> > sender immediately and permanently delete the original and an=
y copy of this

>> > E-mail and any printout.

>> > _______________________________________________

>> > v6ops mailing list

>> > v6ops@ietf.org

>> > https://www.ietf.org/mailman/listinfo/v6ops

>

>





--bcaec5215b0fb8a50a04b38552fa--

From shemant@cisco.com  Wed Dec  7 11:19:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B3521F8C15 for ; Wed,  7 Dec 2011 11:19:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.228
X-Spam-Level: 
X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 nU1JsvOlqPIc for ; Wed,  7 Dec 2011 11:19:10 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E916D21F8BE4 for ; Wed,  7 Dec 2011 11:19:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=21663; q=dns/txt; s=iport; t=1323285550; x=1324495150; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NAiuGhk9yz7GRgyoyOpgzUhre1C02lbdDRgj+hFwRHc=; b=nChaGBHWTJZDUG7yGh6uHWh5URwWen0CG1JXTPM5EQhB4DsSoPruuEJy 03H9z6+o7xptZHi45c4hrEjpK5zOxdxlYKgY0RYDJ2Z3ZyJIwYRAsYeEA PvOqTuqT5MBxtJlZOvLkb57akiLrwCbCAFSckK+oWlcFPHoej8zmR+6LX 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnIAABW8306tJXG9/2dsb2JhbABDgk2XVognAYgKgQWBcgEBAQMBAQEBDwEJEQM3BwQHBQsCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIEwEGh2UImEUBniqKUWMEiC6XJIdb
X-IronPort-AV: E=Sophos;i="4.71,315,1320624000"; d="scan'208,217";a="41993720"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 07 Dec 2011 19:18:59 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB7JIxlQ021350;  Wed, 7 Dec 2011 19:18:59 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Dec 2011 13:18:59 -0600
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_01CCB515.11F93EE5"
Date: Wed, 7 Dec 2011 13:18:57 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303828B23@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
Thread-Index: Acy1FBcAdXq51sMrTd+mIJz0ihGKfgAAKHgw
References:  
From: "Hemant Singh (shemant)" 
To: "Victor Kuarsingh" , "Cameron Byrne" 
X-OriginalArrivalTime: 07 Dec 2011 19:18:59.0033 (UTC) FILETIME=[12261C90:01CCB515]
Cc: v6ops@ietf.org, Alain Durand 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 19:19:11 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB515.11F93EE5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

RFC 6204 and rfc6204bis for the IETF IPv6 CE router document could not
get consensus to add NAT64 or NAT46 to the CE router.    Alain may
remember when NAT64 was discussed in v6ops at a past IETF during the
IPv6 CE router presentation.

=20

Hemant

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Victor Kuarsingh
Sent: Wednesday, December 07, 2011 2:12 PM
To: Cameron Byrne
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Feedback on
draft-ietf-v6ops-wireline-incremental-ipv6

=20

Cameron,

On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne 
wrote:

On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
 wrote:
> Wes/Cameron,
>
> To be clear, we can we define what we mean by "single stack" IPv6.  In
my
> mind this means things like DS-Lite and not NAT64 (as the latter would
> define a IPv6 only home network which I don't think is feasible in the
> mid-term future).
>
> I am assuming that NAT46 (home gateway) is not in the cards since I
see not
> drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network
(to
> round out my previous statement).
>

NAT46 in the home  gateway draft
http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02

=20


Thanks for the reference.  Will review.  We have previously stated that
we wanted to keep the technologies in consideration to running code with
commercial availability.  Where is this with respect to that type of
position?

Victor K
=20

	> Further to this, then we would need to beef up the
considerations for IPv6
	> single stack since it's vast.
	>
	> regards,
	>
	> Victor K
	>
	>
	> On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne
 wrote:
	>>
	>>
	>> On Dec 7, 2011 8:02 AM, "George, Wes"
 wrote:
	>> >
	>> > From: v6ops-bounces@ietf.org
[mailto:v6ops-bounces@ietf.org] On Behalf
	>> > Of Victor Kuarsingh
	>> >
	>> > > Questions to the Group:
	>> >
	>> > > Position on IPv4 and IPv6. Should there be a shift in the
document's
	>> > > tone
	>> > > to be more progressive on movement to IPv6?
	>> >
	>> > WEG] I'm reproducing and refining some feedback I've given
the authors
	>> > offline already so that those on-list can agree/disagree.
	>> >
	>> > By the time this document is published as RFCXXXX, I expect
that one or
	>> > more of the planned sequels to World IPv6 Day will have
generated a
	>> > non-trivial deployment in last-mile access, as well as many
content
	>> > providers making the decision to enable IPv6 permanently.
Therefore, I
	>> > disagree with your foundational assertion that "most
services/operators are
	>> > IPv4."
	>> > Plenty of IPv6 documents have already been written with
that assumption
	>> > in mind, and IMO it's time to start moving away from that.
We should be
	>> > assuming that IPv6 traffic is likely to be non-trivial on
day 1 for those
	>> > only deploying now, and treat our recommendations and
considerations
	>> > accordingly. We should make it clear that they *are* behind
on IPv6
	>> > deployment if they haven't started yet, not to browbeat
them, but to discuss
	>> > the ramifications of that delay.
	>> > There is a legitimate complaint that SPs and vendors have
not taken IPv6
	>> > seriously and even when they deploy/implement it, it ends
up being a
	>> > second-class service, either because it's being done using
different
	>> > topology, reduced peering capacity and diversity, on
elements that can't
	>> > scale to "real" levels, it's encapsulated, or the support
structure and
	>> > processes aren't in place yet (supported by a team of 3
people). I think
	>> > that in a lot of cases, this is being perpetuated by the
notion that you can
	>> > start with "training wheels" on your IPv6 deployment
because it isn't
	>> > carrying enough traffic to matter, and at this point that
notion is probably
	>> > doing more harm than good.
	>> >
	>> > One note of specific feedback on this regard, rather than
treating the
	>> > discussion evenly and saying "avoid using a
transition/encaps technology on
	>> > your primary traffic path..." say something clearer about
making sure that
	>> > your IPv6 traffic path is first-class. That doesn't mean do
something to
	>> > make IPv4 worse, but I think that making IPv6 equivalent or
better should be
	>> > a stated goal.
	>> >
	>>
	>> +1 to non-trivial potential day one loads and treating the
traffic first
	>> class.
	>>
	>> > Second, I think we should tighten the scope of this
document to
	>> > explicitly exclude any consideration of IPv4.
	>> > Something equivalent to - "This document makes no
recommendation on when
	>> > (or if) a given network can move away from IPv4. It assumes
that the network
	>> > in question already has a functional IPv4 solution that
will coexist with
	>> > the chosen IPv6 deployment. Further, it does not discuss
any methods of IPv4
	>> > extension/service continuity, because it is purely focusing
on the practical
	>> > considerations of deploying IPv6 support within an existing
network. Other
	>> > documents exist which discuss and compare options for IPv4
extension
	>> > technologies in great detail [reference, reference,
reference] and this can
	>> > be evaluated independently of the IPv6 deployment
strategy." - it may be
	>> > that the separation isn't quite that clean, since you may
have to note areas
	>> > where coexistence isn't complete or other interaction
considerations, but I
	>> > think that should be the primary philosophy when
determining the scope of
	>> > any IPv4 discussion in this document.
	>> >
	>> > Put another way, single-stack IPv6 is the end goal, and I
don't think
	>> > that's as outlandish or unreachable as it sounds as a
premise for this
	>> > document. Single-stack IPv6 and dual-stack are not that
much different,
	>> > except for that fact that a single-stack IPv6 network has
to ensure that all
	>> > of its ancillary control-path things (not just data
forwarding) are capable
	>> > of functioning properly without IPv4 configured. Therefore
I don't think
	>> > it's too aggressive to treat this document as a
comprehensive recommendation
	>> > on how to deploy a single-stack IPv6 network, with the
acknowledgement that
	>> > IPv4 may coexist and make it a dual-stack network and
nothing (or not much)
	>> > has to change. This gives the benefit of ensuring that the
network itself is
	>> > ready to move to single-stack whenever there is not an
appreciable amount of
	>> > IPv4 traffic being carried anymore. You could then
prioritize the items to
	>> > IPv6-enable given the assumption that everything except
IPv6 forwarding
	>> > works via the existin
	>> >  g IPv4 network, meaning that the network doesn't have to
go
	>> > single-stack all at once.
	>> >
	>>
	>> +1 for clearly articulating single stack v6 as the attainable
end state
	>> goal.
	>>
	>> Cb
	>>
	>> > Wes George
	>> >
	>> > This E-mail and any of its attachments may contain Time
Warner Cable
	>> > proprietary information, which is privileged, confidential,
or subject to
	>> > copyright belonging to Time Warner Cable. This E-mail is
intended solely for
	>> > the use of the individual or entity to which it is
addressed. If you are not
	>> > the intended recipient of this E-mail, you are hereby
notified that any
	>> > dissemination, distribution, copying, or action taken in
relation to the
	>> > contents of and attachments to this E-mail is strictly
prohibited and may be
	>> > unlawful. If you have received this E-mail in error, please
notify the
	>> > sender immediately and permanently delete the original and
any copy of this
	>> > E-mail and any printout.
	>> > _______________________________________________
	>> > v6ops mailing list
	>> > v6ops@ietf.org
	>> > https://www.ietf.org/mailman/listinfo/v6ops
	>
	>

=20


------_=_NextPart_001_01CCB515.11F93EE5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


RFC 6204 and rfc6204bis for the IETF IPv6 CE router document could =
not get consensus to add NAT64 or NAT46 to the CE router.   =
 Alain may remember when NAT64 was discussed in v6ops at a past =
IETF during the IPv6 CE router presentation.
 
Hemant
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Victor Kuarsingh
Sent: Wednesday, December 07, 2011 2:12 =
PM
To: Cameron Byrne
Cc: =
v6ops@ietf.org
Subject: Re: [v6ops] Feedback on =
draft-ietf-v6ops-wireline-incremental-ipv6
 
Cameron,
On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne <cb.list6@gmail.com> =
wrote:
On Wed, Dec 7, 2011 at 8:44 AM, Victor =
Kuarsingh
<victor.kuarsingh@gmail.com=
> wrote:
> Wes/Cameron,
>
> To be clear, we can we =
define what we mean by "single stack" IPv6.  In =
my
> mind this means things like DS-Lite and not NAT64 (as the =
latter would
> define a IPv6 only home network which I don't think =
is feasible in the
> mid-term future).
>
> I am =
assuming that NAT46 (home gateway) is not in the cards since I see =
not
> drafts or RFCs on that.  Hence NAT64 assumes all IPv6 =
endpoint/network (to
> round out my previous =
statement).
>
NAT46 in =
the home  gateway draft
http://tools.ietf.org/html/draft-mawatari-softwire-464x=
lat-02
 

Thanks for the reference.  Will review.  =
We have previously stated that we wanted to keep the technologies in =
consideration to running code with commercial availability.  Where =
is this with respect to that type of position?

Victor =
K
 
> Further to this, then we would need to beef up =
the considerations for IPv6
> single stack since it's =
vast.
>
> regards,
>
> Victor =
K
>
>
> On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne =
<cb.list6@gmail.com> =
wrote:
>>
>>
>> On Dec 7, 2011 8:02 AM, =
"George, Wes" <wesley.george@twcable.com&g=
t; wrote:
>> >
>> > From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On =
Behalf
>> > Of Victor Kuarsingh
>> >
>> =
> > Questions to the Group:
>> >
>> > > =
Position on IPv4 and IPv6. Should there be a shift in the =
document's
>> > > tone
>> > > to be more =
progressive on movement to IPv6?
>> >
>> > WEG] =
I'm reproducing and refining some feedback I've given the =
authors
>> > offline already so that those on-list can =
agree/disagree.
>> >
>> > By the time this =
document is published as RFCXXXX, I expect that one or
>> > =
more of the planned sequels to World IPv6 Day will have generated =
a
>> > non-trivial deployment in last-mile access, as well =
as many content
>> > providers making the decision to enable =
IPv6 permanently. Therefore, I
>> > disagree with your =
foundational assertion that "most services/operators =
are
>> > IPv4."
>> > Plenty of IPv6 =
documents have already been written with that assumption
>> =
> in mind, and IMO it's time to start moving away from that. We =
should be
>> > assuming that IPv6 traffic is likely to be =
non-trivial on day 1 for those
>> > only deploying now, and =
treat our recommendations and considerations
>> > =
accordingly. We should make it clear that they *are* behind on =
IPv6
>> > deployment if they haven't started yet, not to =
browbeat them, but to discuss
>> > the ramifications of that =
delay.
>> > There is a legitimate complaint that SPs and =
vendors have not taken IPv6
>> > seriously and even when =
they deploy/implement it, it ends up being a
>> > =
second-class service, either because it's being done using =
different
>> > topology, reduced peering capacity and =
diversity, on elements that can't
>> > scale to =
"real" levels, it's encapsulated, or the support structure =
and
>> > processes aren't in place yet (supported by a team =
of 3 people). I think
>> > that in a lot of cases, this is =
being perpetuated by the notion that you can
>> > start with =
"training wheels" on your IPv6 deployment because it =
isn't
>> > carrying enough traffic to matter, and at this =
point that notion is probably
>> > doing more harm than =
good.
>> >
>> > One note of specific feedback on =
this regard, rather than treating the
>> > discussion evenly =
and saying "avoid using a transition/encaps technology =
on
>> > your primary traffic path..." say something =
clearer about making sure that
>> > your IPv6 traffic path =
is first-class. That doesn't mean do something to
>> > make =
IPv4 worse, but I think that making IPv6 equivalent or better should =
be
>> > a stated goal.
>> =
>
>>
>> +1 to non-trivial potential day one loads =
and treating the traffic first
>> =
class.
>>
>> > Second, I think we should tighten =
the scope of this document to
>> > explicitly exclude any =
consideration of IPv4.
>> > Something equivalent to - =
"This document makes no recommendation on when
>> > (or =
if) a given network can move away from IPv4. It assumes that the =
network
>> > in question already has a functional IPv4 =
solution that will coexist with
>> > the chosen IPv6 =
deployment. Further, it does not discuss any methods of IPv4
>> =
> extension/service continuity, because it is purely focusing on the =
practical
>> > considerations of deploying IPv6 support =
within an existing network. Other
>> > documents exist which =
discuss and compare options for IPv4 extension
>> > =
technologies in great detail [reference, reference, reference] and this =
can
>> > be evaluated independently of the IPv6 deployment =
strategy." - it may be
>> > that the separation isn't =
quite that clean, since you may have to note areas
>> > =
where coexistence isn't complete or other interaction considerations, =
but I
>> > think that should be the primary philosophy when =
determining the scope of
>> > any IPv4 discussion in this =
document.
>> >
>> > Put another way, =
single-stack IPv6 is the end goal, and I don't think
>> > =
that's as outlandish or unreachable as it sounds as a premise for =
this
>> > document. Single-stack IPv6 and dual-stack are not =
that much different,
>> > except for that fact that a =
single-stack IPv6 network has to ensure that all
>> > of its =
ancillary control-path things (not just data forwarding) are =
capable
>> > of functioning properly without IPv4 =
configured. Therefore I don't think
>> > it's too aggressive =
to treat this document as a comprehensive recommendation
>> =
> on how to deploy a single-stack IPv6 network, with the =
acknowledgement that
>> > IPv4 may coexist and make it a =
dual-stack network and nothing (or not much)
>> > has to =
change. This gives the benefit of ensuring that the network itself =
is
>> > ready to move to single-stack whenever there is not =
an appreciable amount of
>> > IPv4 traffic being carried =
anymore. You could then prioritize the items to
>> > =
IPv6-enable given the assumption that everything except IPv6 =
forwarding
>> > works via the existin
>> > =
 g IPv4 network, meaning that the network doesn't have to =
go
>> > single-stack all at once.
>> =
>
>>
>> +1 for clearly articulating single stack v6 =
as the attainable end state
>> goal.
>>
>> =
Cb
>>
>> > Wes George
>> >
>> =
> This E-mail and any of its attachments may contain Time Warner =
Cable
>> > proprietary information, which is privileged, =
confidential, or subject to
>> > copyright belonging to Time =
Warner Cable. This E-mail is intended solely for
>> > the =
use of the individual or entity to which it is addressed. If you are =
not
>> > the intended recipient of this E-mail, you are =
hereby notified that any
>> > dissemination, distribution, =
copying, or action taken in relation to the
>> > contents of =
and attachments to this E-mail is strictly prohibited and may =
be
>> > unlawful. If you have received this E-mail in error, =
please notify the
>> > sender immediately and permanently =
delete the original and any copy of this
>> > E-mail and any =
printout.
>> > =
_______________________________________________
>> > v6ops =
mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>=

>
 

------_=_NextPart_001_01CCB515.11F93EE5--

From cb.list6@gmail.com  Wed Dec  7 11:21:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BAB11E809B for ; Wed,  7 Dec 2011 11:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.344
X-Spam-Level: 
X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, J_CHICKENPOX_13=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 gf9HwgbQX+9x for ; Wed,  7 Dec 2011 11:21:52 -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 92F9411E80A1 for ; Wed,  7 Dec 2011 11:21:52 -0800 (PST)
Received: by dajz8 with SMTP id z8so1177238daj.31 for ; Wed, 07 Dec 2011 11:21:52 -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=E6VrIP5B2DcERIBLgphdb+tvAvV+UCZOEL2n7bJALck=; b=NCJCEkCDq9aX8LayFnFqOatJmJCR5Rtru3Ka+bQt63FPSdTcPEpFQBPFry57lEmr6U 4hnteOzyVHHZo2XgAQNHTfI99Y0bt76hFpEsdd0BWYOmOhVKeX4REAKlEHCbMLH8PbKS Xxun695Gl/EX8+ouV/IZvSr99rf2ZwI94IrwA=
MIME-Version: 1.0
Received: by 10.68.10.138 with SMTP id i10mr7915198pbb.92.1323285712269; Wed, 07 Dec 2011 11:21:52 -0800 (PST)
Received: by 10.142.43.11 with HTTP; Wed, 7 Dec 2011 11:21:52 -0800 (PST)
In-Reply-To: 
References:      
Date: Wed, 7 Dec 2011 11:21:52 -0800
Message-ID: 
From: Cameron Byrne 
To: Victor Kuarsingh 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 19:21:53 -0000

On Wed, Dec 7, 2011 at 11:11 AM, Victor Kuarsingh
 wrote:
> Cameron,
>
> On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne  wrote:
>>
>> On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
>>  wrote:
>> > Wes/Cameron,
>> >
>> > To be clear, we can we define what we mean by "single stack" IPv6.=A0 =
In
>> > my
>> > mind this means things like DS-Lite and not NAT64 (as the latter would
>> > define a IPv6 only home network which I don't think is feasible in the
>> > mid-term future).
>> >
>> > I am assuming that NAT46 (home gateway) is not in the cards since I se=
e
>> > not
>> > drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/netwo=
rk
>> > (to
>> > round out my previous statement).
>> >
>>
>> NAT46 in the home =A0gateway draft
>> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02
>>
>
> Thanks for the reference.=A0 Will review.=A0 We have previously stated th=
at we
> wanted to keep the technologies in consideration to running code with
> commercial availability.=A0 Where is this with respect to that type of
> position?
>

There is running code for home gatetway NAT46 from NEC and the Nokia
N900 does NAT46 as well.

So, running code is there.  Have a look at
https://sites.google.com/site/tmoipv6/82nd_IETF_Softwire_464XLAT.pdf

CB


> Victor K
>
>>
>> > Further to this, then we would need to beef up the considerations for
>> > IPv6
>> > single stack since it's vast.
>> >
>> > regards,
>> >
>> > Victor K
>> >
>> >
>> > On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne 
>> > wrote:
>> >>
>> >>
>> >> On Dec 7, 2011 8:02 AM, "George, Wes" 
>> >> wrote:
>> >> >
>> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
>> >> > Behalf
>> >> > Of Victor Kuarsingh
>> >> >
>> >> > > Questions to the Group:
>> >> >
>> >> > > Position on IPv4 and IPv6. Should there be a shift in the
>> >> > > document's
>> >> > > tone
>> >> > > to be more progressive on movement to IPv6?
>> >> >
>> >> > WEG] I'm reproducing and refining some feedback I've given the
>> >> > authors
>> >> > offline already so that those on-list can agree/disagree.
>> >> >
>> >> > By the time this document is published as RFCXXXX, I expect that on=
e
>> >> > or
>> >> > more of the planned sequels to World IPv6 Day will have generated a
>> >> > non-trivial deployment in last-mile access, as well as many content
>> >> > providers making the decision to enable IPv6 permanently. Therefore=
,
>> >> > I
>> >> > disagree with your foundational assertion that "most
>> >> > services/operators are
>> >> > IPv4."
>> >> > Plenty of IPv6 documents have already been written with that
>> >> > assumption
>> >> > in mind, and IMO it's time to start moving away from that. We shoul=
d
>> >> > be
>> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1 for
>> >> > those
>> >> > only deploying now, and treat our recommendations and consideration=
s
>> >> > accordingly. We should make it clear that they *are* behind on IPv6
>> >> > deployment if they haven't started yet, not to browbeat them, but t=
o
>> >> > discuss
>> >> > the ramifications of that delay.
>> >> > There is a legitimate complaint that SPs and vendors have not taken
>> >> > IPv6
>> >> > seriously and even when they deploy/implement it, it ends up being =
a
>> >> > second-class service, either because it's being done using differen=
t
>> >> > topology, reduced peering capacity and diversity, on elements that
>> >> > can't
>> >> > scale to "real" levels, it's encapsulated, or the support structure
>> >> > and
>> >> > processes aren't in place yet (supported by a team of 3 people). I
>> >> > think
>> >> > that in a lot of cases, this is being perpetuated by the notion tha=
t
>> >> > you can
>> >> > start with "training wheels" on your IPv6 deployment because it isn=
't
>> >> > carrying enough traffic to matter, and at this point that notion is
>> >> > probably
>> >> > doing more harm than good.
>> >> >
>> >> > One note of specific feedback on this regard, rather than treating
>> >> > the
>> >> > discussion evenly and saying "avoid using a transition/encaps
>> >> > technology on
>> >> > your primary traffic path..." say something clearer about making su=
re
>> >> > that
>> >> > your IPv6 traffic path is first-class. That doesn't mean do somethi=
ng
>> >> > to
>> >> > make IPv4 worse, but I think that making IPv6 equivalent or better
>> >> > should be
>> >> > a stated goal.
>> >> >
>> >>
>> >> +1 to non-trivial potential day one loads and treating the traffic
>> >> first
>> >> class.
>> >>
>> >> > Second, I think we should tighten the scope of this document to
>> >> > explicitly exclude any consideration of IPv4.
>> >> > Something equivalent to - "This document makes no recommendation on
>> >> > when
>> >> > (or if) a given network can move away from IPv4. It assumes that th=
e
>> >> > network
>> >> > in question already has a functional IPv4 solution that will coexis=
t
>> >> > with
>> >> > the chosen IPv6 deployment. Further, it does not discuss any method=
s
>> >> > of IPv4
>> >> > extension/service continuity, because it is purely focusing on the
>> >> > practical
>> >> > considerations of deploying IPv6 support within an existing network=
.
>> >> > Other
>> >> > documents exist which discuss and compare options for IPv4 extensio=
n
>> >> > technologies in great detail [reference, reference, reference] and
>> >> > this can
>> >> > be evaluated independently of the IPv6 deployment strategy." - it m=
ay
>> >> > be
>> >> > that the separation isn't quite that clean, since you may have to
>> >> > note areas
>> >> > where coexistence isn't complete or other interaction consideration=
s,
>> >> > but I
>> >> > think that should be the primary philosophy when determining the
>> >> > scope of
>> >> > any IPv4 discussion in this document.
>> >> >
>> >> > Put another way, single-stack IPv6 is the end goal, and I don't thi=
nk
>> >> > that's as outlandish or unreachable as it sounds as a premise for
>> >> > this
>> >> > document. Single-stack IPv6 and dual-stack are not that much
>> >> > different,
>> >> > except for that fact that a single-stack IPv6 network has to ensure
>> >> > that all
>> >> > of its ancillary control-path things (not just data forwarding) are
>> >> > capable
>> >> > of functioning properly without IPv4 configured. Therefore I don't
>> >> > think
>> >> > it's too aggressive to treat this document as a comprehensive
>> >> > recommendation
>> >> > on how to deploy a single-stack IPv6 network, with the
>> >> > acknowledgement that
>> >> > IPv4 may coexist and make it a dual-stack network and nothing (or n=
ot
>> >> > much)
>> >> > has to change. This gives the benefit of ensuring that the network
>> >> > itself is
>> >> > ready to move to single-stack whenever there is not an appreciable
>> >> > amount of
>> >> > IPv4 traffic being carried anymore. You could then prioritize the
>> >> > items to
>> >> > IPv6-enable given the assumption that everything except IPv6
>> >> > forwarding
>> >> > works via the existin
>> >> > =A0g IPv4 network, meaning that the network doesn't have to go
>> >> > single-stack all at once.
>> >> >
>> >>
>> >> +1 for clearly articulating single stack v6 as the attainable end sta=
te
>> >> goal.
>> >>
>> >> Cb
>> >>
>> >> > Wes George
>> >> >
>> >> > This E-mail and any of its attachments may contain Time Warner Cabl=
e
>> >> > proprietary information, which is privileged, confidential, or
>> >> > subject to
>> >> > copyright belonging to Time Warner Cable. This E-mail is intended
>> >> > solely for
>> >> > the use of the individual or entity to which it is addressed. If yo=
u
>> >> > are not
>> >> > the intended recipient of this E-mail, you are hereby notified that
>> >> > any
>> >> > dissemination, distribution, copying, or action taken in relation t=
o
>> >> > the
>> >> > contents of and attachments to this E-mail is strictly prohibited a=
nd
>> >> > may be
>> >> > unlawful. If you have received this E-mail in error, please notify
>> >> > the
>> >> > sender immediately and permanently delete the original and any copy
>> >> > of this
>> >> > E-mail and any printout.
>> >> > _______________________________________________
>> >> > v6ops mailing list
>> >> > v6ops@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >
>
>

From sarikaya2012@gmail.com  Wed Dec  7 13:54:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22C711E8097 for ; Wed,  7 Dec 2011 13:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=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 4CZajd70XV8z for ; Wed,  7 Dec 2011 13:54:22 -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 EBB8411E8073 for ; Wed,  7 Dec 2011 13:54:21 -0800 (PST)
Received: by yenm7 with SMTP id m7so1022646yen.31 for ; Wed, 07 Dec 2011 13:54:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Mbja0mOS0d6W+0HnF1m0F+9BpmFjxVO5VFS/g05H5+w=; b=AywwXA1YW6oHySxIyqmHtkNYuteaYTHnhAwZNASYT6UDrBe39j73hLf9FOEfGWZBxs W/R5KGmTqi2g1YcwqUNHqGkpI/i0eSCrtQVIGRLrnjYOaANDGH36etW4YgMXd3lvqo7X hDK+T+yqLuX53x4wLOIslFLN2u1VmXTcQL5B4=
MIME-Version: 1.0
Received: by 10.236.186.2 with SMTP id v2mr539311yhm.83.1323294861455; Wed, 07 Dec 2011 13:54:21 -0800 (PST)
Received: by 10.236.125.201 with HTTP; Wed, 7 Dec 2011 13:54:21 -0800 (PST)
In-Reply-To: 
References:      
Date: Wed, 7 Dec 2011 15:54:21 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Victor Kuarsingh 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 21:54:23 -0000

Hi Victor,

For NAT64, the host need not be single stack IPv6, it could have IPv4
stack but simply not used.
This is what happens when you connect to IPv6-only ssid in IETF
meetings with Windows 7 PC or with smart phones with iOS or Android.

Regards,

Behcet

On Wed, Dec 7, 2011 at 1:11 PM, Victor Kuarsingh
 wrote:
> Cameron,
>
> On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne  wrote:
>>
>> On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
>>  wrote:
>> > Wes/Cameron,
>> >
>> > To be clear, we can we define what we mean by "single stack" IPv6.=A0 =
In
>> > my
>> > mind this means things like DS-Lite and not NAT64 (as the latter would
>> > define a IPv6 only home network which I don't think is feasible in the
>> > mid-term future).
>> >
>> > I am assuming that NAT46 (home gateway) is not in the cards since I se=
e
>> > not
>> > drafts or RFCs on that.=A0 Hence NAT64 assumes all IPv6 endpoint/netwo=
rk
>> > (to
>> > round out my previous statement).
>> >
>>
>> NAT46 in the home =A0gateway draft
>> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02
>>
>
> Thanks for the reference.=A0 Will review.=A0 We have previously stated th=
at we
> wanted to keep the technologies in consideration to running code with
> commercial availability.=A0 Where is this with respect to that type of
> position?
>
> Victor K
>
>>
>> > Further to this, then we would need to beef up the considerations for
>> > IPv6
>> > single stack since it's vast.
>> >
>> > regards,
>> >
>> > Victor K
>> >
>> >
>> > On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne 
>> > wrote:
>> >>
>> >>
>> >> On Dec 7, 2011 8:02 AM, "George, Wes" 
>> >> wrote:
>> >> >
>> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
>> >> > Behalf
>> >> > Of Victor Kuarsingh
>> >> >
>> >> > > Questions to the Group:
>> >> >
>> >> > > Position on IPv4 and IPv6. Should there be a shift in the
>> >> > > document's
>> >> > > tone
>> >> > > to be more progressive on movement to IPv6?
>> >> >
>> >> > WEG] I'm reproducing and refining some feedback I've given the
>> >> > authors
>> >> > offline already so that those on-list can agree/disagree.
>> >> >
>> >> > By the time this document is published as RFCXXXX, I expect that on=
e
>> >> > or
>> >> > more of the planned sequels to World IPv6 Day will have generated a
>> >> > non-trivial deployment in last-mile access, as well as many content
>> >> > providers making the decision to enable IPv6 permanently. Therefore=
,
>> >> > I
>> >> > disagree with your foundational assertion that "most
>> >> > services/operators are
>> >> > IPv4."
>> >> > Plenty of IPv6 documents have already been written with that
>> >> > assumption
>> >> > in mind, and IMO it's time to start moving away from that. We shoul=
d
>> >> > be
>> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1 for
>> >> > those
>> >> > only deploying now, and treat our recommendations and consideration=
s
>> >> > accordingly. We should make it clear that they *are* behind on IPv6
>> >> > deployment if they haven't started yet, not to browbeat them, but t=
o
>> >> > discuss
>> >> > the ramifications of that delay.
>> >> > There is a legitimate complaint that SPs and vendors have not taken
>> >> > IPv6
>> >> > seriously and even when they deploy/implement it, it ends up being =
a
>> >> > second-class service, either because it's being done using differen=
t
>> >> > topology, reduced peering capacity and diversity, on elements that
>> >> > can't
>> >> > scale to "real" levels, it's encapsulated, or the support structure
>> >> > and
>> >> > processes aren't in place yet (supported by a team of 3 people). I
>> >> > think
>> >> > that in a lot of cases, this is being perpetuated by the notion tha=
t
>> >> > you can
>> >> > start with "training wheels" on your IPv6 deployment because it isn=
't
>> >> > carrying enough traffic to matter, and at this point that notion is
>> >> > probably
>> >> > doing more harm than good.
>> >> >
>> >> > One note of specific feedback on this regard, rather than treating
>> >> > the
>> >> > discussion evenly and saying "avoid using a transition/encaps
>> >> > technology on
>> >> > your primary traffic path..." say something clearer about making su=
re
>> >> > that
>> >> > your IPv6 traffic path is first-class. That doesn't mean do somethi=
ng
>> >> > to
>> >> > make IPv4 worse, but I think that making IPv6 equivalent or better
>> >> > should be
>> >> > a stated goal.
>> >> >
>> >>
>> >> +1 to non-trivial potential day one loads and treating the traffic
>> >> first
>> >> class.
>> >>
>> >> > Second, I think we should tighten the scope of this document to
>> >> > explicitly exclude any consideration of IPv4.
>> >> > Something equivalent to - "This document makes no recommendation on
>> >> > when
>> >> > (or if) a given network can move away from IPv4. It assumes that th=
e
>> >> > network
>> >> > in question already has a functional IPv4 solution that will coexis=
t
>> >> > with
>> >> > the chosen IPv6 deployment. Further, it does not discuss any method=
s
>> >> > of IPv4
>> >> > extension/service continuity, because it is purely focusing on the
>> >> > practical
>> >> > considerations of deploying IPv6 support within an existing network=
.
>> >> > Other
>> >> > documents exist which discuss and compare options for IPv4 extensio=
n
>> >> > technologies in great detail [reference, reference, reference] and
>> >> > this can
>> >> > be evaluated independently of the IPv6 deployment strategy." - it m=
ay
>> >> > be
>> >> > that the separation isn't quite that clean, since you may have to
>> >> > note areas
>> >> > where coexistence isn't complete or other interaction consideration=
s,
>> >> > but I
>> >> > think that should be the primary philosophy when determining the
>> >> > scope of
>> >> > any IPv4 discussion in this document.
>> >> >
>> >> > Put another way, single-stack IPv6 is the end goal, and I don't thi=
nk
>> >> > that's as outlandish or unreachable as it sounds as a premise for
>> >> > this
>> >> > document. Single-stack IPv6 and dual-stack are not that much
>> >> > different,
>> >> > except for that fact that a single-stack IPv6 network has to ensure
>> >> > that all
>> >> > of its ancillary control-path things (not just data forwarding) are
>> >> > capable
>> >> > of functioning properly without IPv4 configured. Therefore I don't
>> >> > think
>> >> > it's too aggressive to treat this document as a comprehensive
>> >> > recommendation
>> >> > on how to deploy a single-stack IPv6 network, with the
>> >> > acknowledgement that
>> >> > IPv4 may coexist and make it a dual-stack network and nothing (or n=
ot
>> >> > much)
>> >> > has to change. This gives the benefit of ensuring that the network
>> >> > itself is
>> >> > ready to move to single-stack whenever there is not an appreciable
>> >> > amount of
>> >> > IPv4 traffic being carried anymore. You could then prioritize the
>> >> > items to
>> >> > IPv6-enable given the assumption that everything except IPv6
>> >> > forwarding
>> >> > works via the existin
>> >> > =A0g IPv4 network, meaning that the network doesn't have to go
>> >> > single-stack all at once.
>> >> >
>> >>
>> >> +1 for clearly articulating single stack v6 as the attainable end sta=
te
>> >> goal.
>> >>
>> >> Cb
>> >>
>> >> > Wes George
>> >> >
>> >> > This E-mail and any of its attachments may contain Time Warner Cabl=
e
>> >> > proprietary information, which is privileged, confidential, or
>> >> > subject to
>> >> > copyright belonging to Time Warner Cable. This E-mail is intended
>> >> > solely for
>> >> > the use of the individual or entity to which it is addressed. If yo=
u
>> >> > are not
>> >> > the intended recipient of this E-mail, you are hereby notified that
>> >> > any
>> >> > dissemination, distribution, copying, or action taken in relation t=
o
>> >> > the
>> >> > contents of and attachments to this E-mail is strictly prohibited a=
nd
>> >> > may be
>> >> > unlawful. If you have received this E-mail in error, please notify
>> >> > the
>> >> > sender immediately and permanently delete the original and any copy
>> >> > of this
>> >> > E-mail and any printout.
>> >> > _______________________________________________
>> >> > v6ops mailing list
>> >> > v6ops@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From lorenzo@google.com  Wed Dec  7 14:35:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9300421F84CE for ; Wed,  7 Dec 2011 14:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.906
X-Spam-Level: 
X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KLnNI7-d+RQj for ; Wed,  7 Dec 2011 14:35:49 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F35A221F84CC for ; Wed,  7 Dec 2011 14:35:48 -0800 (PST)
Received: by ggnk5 with SMTP id k5so1368563ggn.31 for ; Wed, 07 Dec 2011 14:35:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wmy3yl72ooaiSFunnOyhyxAaLLXL3fFFgCxzhOUsxgg=; b=P/+ALL+Ne1+mK7lkSimjqKrSGF5OMwWnitWwkttgPHvbbieiqN7QNk+kHcPnY2gd7b y0pnB/Y+M9EInltb7tHQ==
Received: by 10.182.156.11 with SMTP id wa11mr109507obb.18.1323297348310; Wed, 07 Dec 2011 14:35:48 -0800 (PST)
Received: by 10.182.156.11 with SMTP id wa11mr109499obb.18.1323297348216; Wed, 07 Dec 2011 14:35:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.121.36 with HTTP; Wed, 7 Dec 2011 14:35:28 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com>
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com>
From: Lorenzo Colitti 
Date: Wed, 7 Dec 2011 14:35:28 -0800
Message-ID: 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=f46d0444ed355f67e704b3882ca9
X-System-Of-Record: true
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 22:35:49 -0000

--f46d0444ed355f67e704b3882ca9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 7, 2011 at 05:40, Hemant Singh (shemant) wro=
te:

> I do have a cable deployment where I can have the access concentrator
> serving 100K PD clients.  The network would like to use the pd-exclude.
> The reason I asked my question because one person already said, the DR ca=
n
> use the RA so that the DR can address it=92s interface with SLAAC.  There=
 are
> two choices for such a deployment and that is why I asked the question.
> Either the same exclude /64 is given to each of the 100K clients or the
> network uses unicast RA.  Some IETF document has already defined a unicas=
t.
>
Wait, what?

You have a set of PD clients on the same link and want to exclude the same
/64 from each of the PDs you hand out? That doesn't make sense. Since each
of the PD clients will get its own prefix (say, a /60) and they won't
overlap (since they're different customers), only at most one of the PDs
will include the /64. So there's no need to exclude anything for the others=
.

--f46d0444ed355f67e704b3882ca9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Wed, Dec 7, 2011 at 05:40, Hemant Singh (shem=
ant) <shemant@cis=
co.com> wrote:



<=
p>I do have a cable de=
ployment where I can have the access concentrator serving 100K PD clients. =
=A0The network would like to use the pd-exclude.=A0 The reason I asked my q=
uestion because one person already said, the DR can use the RA so that the =
DR can address it=92s interface with SLAAC.=A0 There are two choices for su=
ch a deployment and that is why I asked the question.=A0 Either the same ex=
clude /64 is given to each of the 100K clients or the network uses unicast =
RA.=A0 Some IETF document has already defined a unicast.



Wait, what?

Yo=
u have a set of PD clients on the same link and want to exclude the same /6=
4 from each of the PDs you hand out? That doesn't make sense. Since eac=
h of the PD clients will get its own prefix (say, a /60) and they won't=
 overlap (since they're different customers), only at most one of the P=
Ds will include the /64. So there's no need to exclude anything for the=
 others.





--f46d0444ed355f67e704b3882ca9--

From victor.kuarsingh@gmail.com  Wed Dec  7 18:08:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1675C21F8A96 for ; Wed,  7 Dec 2011 18:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.419,  BAYES_00=-2.599, J_CHICKENPOX_13=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 lv+If3r9re8y for ; Wed,  7 Dec 2011 18:08:11 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D46E521F8A66 for ; Wed,  7 Dec 2011 18:08:10 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so1125131vbb.31 for ; Wed, 07 Dec 2011 18:08:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=ES7gKLK/MMRZB31o5QORyDZ9qUpn5H+xOt3mXPXiM8w=; b=MiAqLXstiba/McAV2dNWY8IOVTZ7VX3lm4xdJNmRH07B6U69qeGtyTD75vPPB3qPuW 8YnFhF+r/fReqNHuI0c5MqewvHdBLR4kF76fPH8Yg4rYYP/JWtWht2lUhH/KwdQVR9HB uqjgL79O5t7lUucethlVwB4wDcwWVWFRDuWv4=
Received: by 10.52.174.46 with SMTP id bp14mr559761vdc.107.1323310089275; Wed, 07 Dec 2011 18:08:09 -0800 (PST)
Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id c7sm3151349vdh.12.2011.12.07.18.08.05 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 18:08:07 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Wed, 07 Dec 2011 21:08:02 -0500
From: Victor Kuarsingh 
To: 
Message-ID: 
Thread-Topic: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 02:08:12 -0000

Behcet,

On 11-12-07 4:54 PM, "Behcet Sarikaya"  wrote:

>Hi Victor,
>
>For NAT64, the host need not be single stack IPv6, it could have IPv4
>stack but simply not used.
>This is what happens when you connect to IPv6-only ssid in IETF
>meetings with Windows 7 PC or with smart phones with iOS or Android.

I agree that a given device in the home can be IPv6 single stack, but the
overall home would need IPv4 of some form to service the TVs (with IP),
NAS, Printers, Older OSs, Older Security equipment etc.

This particular draft has a focus on wireline.  Some use cases would
include a directly attached PC which would at times be Win7/Vista, MACOSX
sporting IPv6 capabilities (I cannot guarantee that all the apps will
comply with IPv6 - the general computing world is hard to control and
there are so many applications that customers will use... Not sure how
confident I will be that all of them would support IPv6 for a while - some
may disagree).  Lorenzo brought this up in Taipei as a point of discussion.

So on the NAT46 side, what is the likely hood we will see this in actual
retail and OEM products soon?  I know that 6RD and DS-Lite is now out
there.. I have not seen NAT46 personally (although it has been highlighted
to me that there are some products out..).  Availability of these in the
mass market is a key consideration for technologies to include (given the
operator focus I was trying to achieve here).  I think a practical,
attainable result is a benefit to operators here.

If we have consensus in the WG that NAT46 with single stack IPv6 on WAN is
a valid option for the currently labelled phase 3, we can add it in as an
option.  But, as noted to Wes, we would need to expand the considerations
section (which we would likely do anyway if we put more focus on the IPv6
single stack [on WAN] result).

Sorry, talked to a few points here...

Victor K


>
>Regards,
>
>Behcet
>
>On Wed, Dec 7, 2011 at 1:11 PM, Victor Kuarsingh
> wrote:
>> Cameron,
>>
>> On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne 
>>wrote:
>>>
>>> On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
>>>  wrote:
>>> > Wes/Cameron,
>>> >
>>> > To be clear, we can we define what we mean by "single stack" IPv6.
>>>In
>>> > my
>>> > mind this means things like DS-Lite and not NAT64 (as the latter
>>>would
>>> > define a IPv6 only home network which I don't think is feasible in
>>>the
>>> > mid-term future).
>>> >
>>> > I am assuming that NAT46 (home gateway) is not in the cards since I
>>>see
>>> > not
>>> > drafts or RFCs on that.  Hence NAT64 assumes all IPv6
>>>endpoint/network
>>> > (to
>>> > round out my previous statement).
>>> >
>>>
>>> NAT46 in the home  gateway draft
>>> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02
>>>
>>
>> Thanks for the reference.  Will review.  We have previously stated that
>>we
>> wanted to keep the technologies in consideration to running code with
>> commercial availability.  Where is this with respect to that type of
>> position?
>>
>> Victor K
>>
>>>
>>> > Further to this, then we would need to beef up the considerations for
>>> > IPv6
>>> > single stack since it's vast.
>>> >
>>> > regards,
>>> >
>>> > Victor K
>>> >
>>> >
>>> > On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne 
>>> > wrote:
>>> >>
>>> >>
>>> >> On Dec 7, 2011 8:02 AM, "George, Wes" 
>>> >> wrote:
>>> >> >
>>> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
>>> >> > Behalf
>>> >> > Of Victor Kuarsingh
>>> >> >
>>> >> > > Questions to the Group:
>>> >> >
>>> >> > > Position on IPv4 and IPv6. Should there be a shift in the
>>> >> > > document's
>>> >> > > tone
>>> >> > > to be more progressive on movement to IPv6?
>>> >> >
>>> >> > WEG] I'm reproducing and refining some feedback I've given the
>>> >> > authors
>>> >> > offline already so that those on-list can agree/disagree.
>>> >> >
>>> >> > By the time this document is published as RFCXXXX, I expect that
>>>one
>>> >> > or
>>> >> > more of the planned sequels to World IPv6 Day will have generated
>>>a
>>> >> > non-trivial deployment in last-mile access, as well as many
>>>content
>>> >> > providers making the decision to enable IPv6 permanently.
>>>Therefore,
>>> >> > I
>>> >> > disagree with your foundational assertion that "most
>>> >> > services/operators are
>>> >> > IPv4."
>>> >> > Plenty of IPv6 documents have already been written with that
>>> >> > assumption
>>> >> > in mind, and IMO it's time to start moving away from that. We
>>>should
>>> >> > be
>>> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1
>>>for
>>> >> > those
>>> >> > only deploying now, and treat our recommendations and
>>>considerations
>>> >> > accordingly. We should make it clear that they *are* behind on
>>>IPv6
>>> >> > deployment if they haven't started yet, not to browbeat them, but
>>>to
>>> >> > discuss
>>> >> > the ramifications of that delay.
>>> >> > There is a legitimate complaint that SPs and vendors have not
>>>taken
>>> >> > IPv6
>>> >> > seriously and even when they deploy/implement it, it ends up
>>>being a
>>> >> > second-class service, either because it's being done using
>>>different
>>> >> > topology, reduced peering capacity and diversity, on elements that
>>> >> > can't
>>> >> > scale to "real" levels, it's encapsulated, or the support
>>>structure
>>> >> > and
>>> >> > processes aren't in place yet (supported by a team of 3 people). I
>>> >> > think
>>> >> > that in a lot of cases, this is being perpetuated by the notion
>>>that
>>> >> > you can
>>> >> > start with "training wheels" on your IPv6 deployment because it
>>>isn't
>>> >> > carrying enough traffic to matter, and at this point that notion
>>>is
>>> >> > probably
>>> >> > doing more harm than good.
>>> >> >
>>> >> > One note of specific feedback on this regard, rather than treating
>>> >> > the
>>> >> > discussion evenly and saying "avoid using a transition/encaps
>>> >> > technology on
>>> >> > your primary traffic path..." say something clearer about making
>>>sure
>>> >> > that
>>> >> > your IPv6 traffic path is first-class. That doesn't mean do
>>>something
>>> >> > to
>>> >> > make IPv4 worse, but I think that making IPv6 equivalent or better
>>> >> > should be
>>> >> > a stated goal.
>>> >> >
>>> >>
>>> >> +1 to non-trivial potential day one loads and treating the traffic
>>> >> first
>>> >> class.
>>> >>
>>> >> > Second, I think we should tighten the scope of this document to
>>> >> > explicitly exclude any consideration of IPv4.
>>> >> > Something equivalent to - "This document makes no recommendation
>>>on
>>> >> > when
>>> >> > (or if) a given network can move away from IPv4. It assumes that
>>>the
>>> >> > network
>>> >> > in question already has a functional IPv4 solution that will
>>>coexist
>>> >> > with
>>> >> > the chosen IPv6 deployment. Further, it does not discuss any
>>>methods
>>> >> > of IPv4
>>> >> > extension/service continuity, because it is purely focusing on the
>>> >> > practical
>>> >> > considerations of deploying IPv6 support within an existing
>>>network.
>>> >> > Other
>>> >> > documents exist which discuss and compare options for IPv4
>>>extension
>>> >> > technologies in great detail [reference, reference, reference] and
>>> >> > this can
>>> >> > be evaluated independently of the IPv6 deployment strategy." - it
>>>may
>>> >> > be
>>> >> > that the separation isn't quite that clean, since you may have to
>>> >> > note areas
>>> >> > where coexistence isn't complete or other interaction
>>>considerations,
>>> >> > but I
>>> >> > think that should be the primary philosophy when determining the
>>> >> > scope of
>>> >> > any IPv4 discussion in this document.
>>> >> >
>>> >> > Put another way, single-stack IPv6 is the end goal, and I don't
>>>think
>>> >> > that's as outlandish or unreachable as it sounds as a premise for
>>> >> > this
>>> >> > document. Single-stack IPv6 and dual-stack are not that much
>>> >> > different,
>>> >> > except for that fact that a single-stack IPv6 network has to
>>>ensure
>>> >> > that all
>>> >> > of its ancillary control-path things (not just data forwarding)
>>>are
>>> >> > capable
>>> >> > of functioning properly without IPv4 configured. Therefore I don't
>>> >> > think
>>> >> > it's too aggressive to treat this document as a comprehensive
>>> >> > recommendation
>>> >> > on how to deploy a single-stack IPv6 network, with the
>>> >> > acknowledgement that
>>> >> > IPv4 may coexist and make it a dual-stack network and nothing (or
>>>not
>>> >> > much)
>>> >> > has to change. This gives the benefit of ensuring that the network
>>> >> > itself is
>>> >> > ready to move to single-stack whenever there is not an appreciable
>>> >> > amount of
>>> >> > IPv4 traffic being carried anymore. You could then prioritize the
>>> >> > items to
>>> >> > IPv6-enable given the assumption that everything except IPv6
>>> >> > forwarding
>>> >> > works via the existin
>>> >> >  g IPv4 network, meaning that the network doesn't have to go
>>> >> > single-stack all at once.
>>> >> >
>>> >>
>>> >> +1 for clearly articulating single stack v6 as the attainable end
>>>state
>>> >> goal.
>>> >>
>>> >> Cb
>>> >>
>>> >> > Wes George
>>> >> >
>>> >> > This E-mail and any of its attachments may contain Time Warner
>>>Cable
>>> >> > proprietary information, which is privileged, confidential, or
>>> >> > subject to
>>> >> > copyright belonging to Time Warner Cable. This E-mail is intended
>>> >> > solely for
>>> >> > the use of the individual or entity to which it is addressed. If
>>>you
>>> >> > are not
>>> >> > the intended recipient of this E-mail, you are hereby notified
>>>that
>>> >> > any
>>> >> > dissemination, distribution, copying, or action taken in relation
>>>to
>>> >> > the
>>> >> > contents of and attachments to this E-mail is strictly prohibited
>>>and
>>> >> > may be
>>> >> > unlawful. If you have received this E-mail in error, please notify
>>> >> > the
>>> >> > sender immediately and permanently delete the original and any
>>>copy
>>> >> > of this
>>> >> > E-mail and any printout.
>>> >> > _______________________________________________
>>> >> > v6ops mailing list
>>> >> > v6ops@ietf.org
>>> >> > https://www.ietf.org/mailman/listinfo/v6ops
>>> >
>>> >
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>



From frnkblk@iname.com  Wed Dec  7 20:19:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0DC21F8541 for ; Wed,  7 Dec 2011 20:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 jbyWXBwAsDpO for ; Wed,  7 Dec 2011 20:19:44 -0800 (PST)
Received: from premieronline.net (smtp2-1.premieronline.net [96.31.0.26]) by ietfa.amsl.com (Postfix) with ESMTP id D9C7A21F8560 for ; Wed,  7 Dec 2011 20:19:43 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from BULKFAMLAPTOP (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 7669762-1729245 for multiple; Wed, 07 Dec 2011 22:19:41 -0600
From: "Frank Bulk" 
To: 
References: 	<750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>	<82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>	 <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD73C@XMB-RCD-109.cisco.com> <013701ccb231$e7ca7ad0$b75f7070$@iname.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB693@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C30377889D@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F214FB7D9@crexc50p>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F214FB7D9@crexc50p>
Date: Wed, 7 Dec 2011 22:19:39 -0600
Message-ID: <001b01ccb560$9a2e8690$ce8b93b0$@iname.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CCB52E.4F96D5B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWgAQudWQAASz63MAAIoliQAAJaeXAAdWNQ8A==
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=26 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 1002, in=2319, out=0, spam=0 ip=199.120.69.4
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 04:19:47 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001C_01CCB52E.4F96D5B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sounds like we're hashing out the 6rd sunsetting concerns related to manual
configuration.  

 

I'm not really keen about focusing on externally discernible behavior - in
this case I think we need to specify what the router should do, making sure
we've done our homework by considering the many possible state transitions
that involve DHCPv4 and 6rd.  If we can't figure out an approach that works
across all possible state transitions, then we should probably define a
subset of situations that lead to the desired behavior.

 

Frank

 

From: STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, December 05, 2011 2:42 PM
To: Hemant Singh (shemant); Frank Bulk
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

 

I interpreted "stop doing 6rd" as being similar in function to "not sending
any traffic over the 6rd interface". From the outside, it looks the same. I
tend to be more concerned with externally discernible behavior, than with
internal implementation. If (in the case of different prefixes) the CE
router immediately makes IPv6 addresses on the LAN from the 6rd prefix to be
not preferred and not valid, then this accomplishes that goal. If (for same
prefix) the CE router prefers to send traffic over the native interface,
then this also accomplishes the goal.

 

Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and manual
configuration) there is a period of time where both are available to the CE
router, unless you try some sort of flash cut. The CE router must be able to
deal with this. And the preference is that it deal with this by getting as
much traffic as possible to go over the native interface, as soon as
possible.

 

If no traffic is going over the 6rd interface, and the CE router is able to
function with both configured, what is it going to hurt, however long the
manual configuration stays? And the way to disable it is for the very same
user who manually configured it, to go in and manually disable it. As long
as things don't break, it shouldn't really matter. Of course, I would prefer
for the user to disable it sooner rather than later. But we've dealt with
similar transitions before (IP to PPPoE, PPPoE to IP, PPPoA to PPPoE, TDMA
to GSM, IPv4 to IPv6, etc.). It's do-able. Some users hang on for a long
time. Most respond quickly. It's manageable, as long as things don't break
when faced with both.

 

As for concurrent 6rd and DS-Lite, I really don't care what rules are
created. The situation is only relevant to providers who actually intend to
offer both to the same CE routers. If a provider doesn't offer DS-Lite
DHCPv6 options, then the danger of dealing with CE routers that have trouble
deciding what to do is pretty low.

Barbara

 

From: Hemant Singh (shemant) [mailto:shemant@cisco.com] 
Sent: Monday, December 05, 2011 2:20 PM
To: STARK, BARBARA H; Frank Bulk
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

 

Barbara,

 

Thanks for the reply.  Please see below.

 

From: STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

 

 

>I don't think it's a good idea to make the 6rd BR immediately unavailable
after sending RAs. Flash cuts are to be avoided, especially flash cuts >that
assume, for example, 100k CE routers transitioning at the same time. Which
means that manual, DHCPv4, and TR-069 configured 6rd >implementations should
all be prepared to gracefully handle having both. I don't see why transition
from manual is so vastly different, at the >point where a device determines
it has both 6rd and native interfaces. Where it differs, is in the ease of
*removing* 6rd configuration from the >device. Even with TR-069, we'd
probably want a soak period before disabling 6rd. So manual configuration
soaks a little (or a lot) longer than the >others. 

 

I, MarkT and you are in agreement with what you say above.  However, please
see this email during an exchange with Victor on his screw case with 6rd
sunsetting.

 

http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html

 

See the text below from the email URL above between squared braces.

 

[> 

> Again, I would prefer a cut over from one interface to the other 

> (virtual to native).  This is what I would ask my vendor to implement.  

> Once I add in Native to a capable CPE, I would expect the CPE to go 

> native. I am hoping there is an option for this within all the proposals.

 

I don't want to limit the ability for you to move a customer from 6rd to
native immediately, but I want others to be able to do it incrementally as
well. If you want to move them immediately, all you need to do is provision
DHCPv6 PD at the same time you deprovision the 6rd option in DHCPv4 and be
sure you use a different prefix for native than 6rd. Once the home router
reboots or the DHCPv4 lease and associated 6rd delegated prefix lifetime
times out, the 6rd and its associated prefix will be gone never to return. 

 

- Mark]

 

>And to respond to the suggestion that retail CE routers support TR-069:
with my consumer hat on, I say no way, no how - it's *my* router, and no
>service provider is going to be allowed to so intrusively manage *my*
router. 

 

So please provide guidance on how is 6rd disabled on the retail router if
6rd was enabled manually on the retail router?   For a manually configured
retail router, one can run into concurrent DS-Lite and 6rd operation and
then the CE router is totally confused why the router should not run in
native dual-stack mode.    

 

Hemant


------=_NextPart_000_001C_01CCB52E.4F96D5B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Sounds like we’re hashing out the 6rd sunsetting concerns =
related to manual configuration.  
 
I’m not really keen about focusing on externally discernible =
behavior – in this case I think we need to specify what the router =
should do, making sure we’ve done our homework by considering the =
many possible state transitions that involve DHCPv4 and 6rd.  If we =
can’t figure out an approach that works across all possible state =
transitions, then we should probably define a subset of situations that =
lead to the desired behavior.
 
Frank
 
From:=
 =
STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, =
December 05, 2011 2:42 PM
To: Hemant Singh (shemant); Frank =
Bulk
Cc: v6ops@ietf.org; Mark Townsley
Subject: RE: =
[v6ops] 6rd Sunsetting
 
I interpreted “stop doing 6rd” as being similar in =
function to “not sending any traffic over the 6rd =
interface”. From the outside, it looks the same. I tend to be more =
concerned with externally discernible behavior, than with internal =
implementation. If (in the case of different prefixes) the CE router =
immediately makes IPv6 addresses on the LAN from the 6rd prefix to be =
not preferred and not valid, then this accomplishes that goal. If (for =
same prefix) the CE router prefers to send traffic over the native =
interface, then this also accomplishes the goal.
 
Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and =
manual configuration) there is a period of time where both are available =
to the CE router, unless you try some sort of flash cut. The CE router =
must be able to deal with this. And the preference is that it deal with =
this by getting as much traffic as possible to go over the native =
interface, as soon as possible.
 
If no traffic is going over the 6rd interface, and the CE router is =
able to function with both configured, what is it going to hurt, however =
long the manual configuration stays? And the way to disable it is for =
the very same user who manually configured it, to go in and manually =
disable it. As long as things don’t break, it shouldn’t =
really matter. Of course, I would prefer for the user to disable it =
sooner rather than later. But we’ve dealt with similar transitions =
before (IP to PPPoE, PPPoE to IP, PPPoA to PPPoE, TDMA to GSM, IPv4 to =
IPv6, etc.). It’s do-able. Some users hang on for a long time. =
Most respond quickly. It’s manageable, as long as things =
don’t break when faced with both.
 
As for concurrent 6rd and DS-Lite, I really don’t care what =
rules are created. The situation is only relevant to providers who =
actually intend to offer both to the same CE routers. If a provider =
doesn’t offer DS-Lite DHCPv6 options, then the danger of dealing =
with CE routers that have trouble deciding what to do is pretty =
low.
Barbara
 
From:=
 =
Hemant Singh (shemant) [mailto:shemant@cisco.com]=
 
Sent: Monday, December 05, 2011 2:20 PM
To: STARK, =
BARBARA H; Frank Bulk
Cc: v6ops@ietf.org; Mark =
Townsley
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Barbara,
 
Thanks for the reply.  Please see below.
 
From:=
 =
STARK, BARBARA H [mailto:bs7652@att.com] =

Sent: Monday, December 05, 2011 1:56 PM
To: Frank =
Bulk; Hemant Singh (shemant)
Cc: v6ops@ietf.org; Mark =
Townsley
Subject: RE: [v6ops] 6rd =
Sunsetting
 
 
>I don’t think it’s a good idea to =
make the 6rd BR immediately unavailable after sending RAs. Flash cuts =
are to be avoided, especially flash cuts >that assume, for example, =
100k CE routers transitioning at the same time. Which means that manual, =
DHCPv4, and TR-069 configured 6rd >implementations should all be =
prepared to gracefully handle having both. I don’t see why =
transition from manual is so vastly different, at the >point where a =
device determines it has both 6rd and native interfaces. Where it =
differs, is in the ease of *removing* 6rd configuration from the =
>device. Even with TR-069, we’d probably want a soak period =
before disabling 6rd. So manual configuration soaks a little (or a lot) =
longer than the >others. 
 
I, MarkT and you are in agreement with what you say =
above.  However, please see this email during an exchange with =
Victor on his screw case with 6rd sunsetting.
 
http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html
 
See the text below from the email URL above between =
squared braces.
 
[> =

> Again, I would =
prefer a cut over from one interface to the other =

> (virtual to =
native).  This is what I would ask my vendor to implement.  =

> Once I add in =
Native to a capable CPE, I would expect the CPE to go =

> native. I am =
hoping there is an option for this within all the =
proposals.
 
I don't want to =
limit the ability for you to move a customer from 6rd to native =
immediately, but I want others to be able to do it incrementally as =
well. If you want to move them immediately, all you need to do is =
provision DHCPv6 PD at the same time you deprovision the 6rd option in =
DHCPv4 and be sure you use a different prefix for native than 6rd. Once =
the home router reboots or the DHCPv4 lease and associated 6rd delegated =
prefix lifetime times out, the 6rd and its associated prefix will be =
gone never to return. 
 
- =
Mark]
 
>And to respond to the suggestion that retail CE =
routers support TR-069: with my consumer hat on, I say no way, no how =
– it’s *my* router, and no >service provider is =
going to be allowed to so intrusively manage *my* router. =

 
So please provide guidance on how is 6rd disabled on the retail =
router if 6rd was enabled manually on the retail router?   For =
a manually configured retail router, one can run into concurrent DS-Lite =
and 6rd operation and then the CE router is totally confused why the =
router should not run in native dual-stack mode.   =
 
 
Hemant

------=_NextPart_000_001C_01CCB52E.4F96D5B0--


From ales.vizdal@t-mobile.cz  Thu Dec  8 01:57:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC4C21F8B0B for ; Thu,  8 Dec 2011 01:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 p9dBiFCohukL for ; Thu,  8 Dec 2011 01:57:58 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 35D2B21F867F for ; Thu,  8 Dec 2011 01:57:57 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C0D58285832; Thu,  8 Dec 2011 10:57:53 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Thu, 8 Dec 2011 10:57:53 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: jouni korhonen , Hemant Singh 
Date: Thu, 8 Dec 2011 10:57:56 +0100
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy0rcGjdEw4bWiXQW2opG1RBZVTjAA3gCKQ
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E99F82D1@SRVHKE02.rdm.cz>
References:   <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>  <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>  <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org>   <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com><88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl><4EDA80AC.6030907@globis.net><435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com>, <4EDA8DF0.7000803@globis.net><6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> <4EDAA849.40208@globis.net> < 5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com> 
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-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Thomas Narten , Ray Hunter , "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 09:57:59 -0000

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=
 jouni
> korhonen
> Sent: Wednesday, December 07, 2011 7:59 AM
> To: Hemant Singh
> Cc: Thomas Narten; Ray Hunter; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
>=20
> Hemant,
>=20
> On Dec 4, 2011, at 1:59 AM, Hemant Singh (shemant) wrote:
>=20
> > It's high time the subject of the email changed to the pd-exclude docum=
ent rather
> than the rfc6204bis document for which the ship has sailed to include the=
 pd-exclude
> in.   That said, one question I had was this.   How are network interface=
s
>=20
> IMHO it is too early to state that the ship has sailed for RFC6204bis alr=
eady.

[snip]

+1

What is preventing pd-exclude to be referenced in the 6240bis draft?

The consequence of pd-exclude not being considered will result in a safe mo=
de
operation mode in the scenarios relying on pd-exclude (e.g. Prefix Delegati=
on in 3GPP)=20
where the customer will be allocated a prefix, but just a half (the one exc=
luding /64 used for=20
the wan link) of it will be delegated to be compliant with RFC3633.

Is it wise ignoring this consequence?
What needs to be done for the support of pd-exclude in the draft?

Ales

> - JOuni
>=20
>=20
> >
> > Hemant
> >
>=20
> [snip]

From tsavo.stds@gmail.com  Thu Dec  8 02:35:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E649721F87D9 for ; Thu,  8 Dec 2011 02:35:11 -0800 (PST)
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_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 wPi7Hul2xZZN for ; Thu,  8 Dec 2011 02:35:11 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9E421F87D3 for ; Thu,  8 Dec 2011 02:35:11 -0800 (PST)
Received: by ggnk5 with SMTP id k5so2090721ggn.31 for ; Thu, 08 Dec 2011 02:35:10 -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=gjq8xKX5RPhmNpT2StSiIgZ2g6729CVFCqPkglM7EWY=; b=V7PVovvjUtXPfba8GzVqOtm4kLAIcvp8gYQItos/LDYQrRyoWYk7E41fcAZRxFQse1 4hEjXY7CgH9mfchJZSMQHVvE0Ng9Xzd8mKCFWApFKPxXKtwiupOS6YqXeMmpg+6HT4hQ G7MOjxCCJOD2ScIwDYobmktTAw8qIN6ltOhjE=
MIME-Version: 1.0
Received: by 10.182.45.102 with SMTP id l6mr550491obm.0.1323340510710; Thu, 08 Dec 2011 02:35:10 -0800 (PST)
Received: by 10.182.43.8 with HTTP; Thu, 8 Dec 2011 02:35:10 -0800 (PST)
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E99F82D1@SRVHKE02.rdm.cz>
References:   <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org>  <591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org>  <399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org>   <5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com> <88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl> <4EDA80AC.6030907@globis.net> <435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com> <4EDA8DF0.7000803@globis.net> <6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com> <4EDAA849.40208@globis.net>  <1808340F7EC362469DDFFB112B37E2FCC5E99F82D1@SRVHKE02.rdm.cz>
Date: Thu, 8 Dec 2011 12:35:10 +0200
Message-ID: 
From: Teemu Savolainen 
To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= 
Content-Type: multipart/alternative; boundary=f46d0444ef0b0eca6f04b39239d4
Cc: Thomas Narten , Ray Hunter , "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 10:35:12 -0000

--f46d0444ef0b0eca6f04b39239d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

I also want to state my support here in v6ops list for including the PD
exclude option into 6204bis.

In the past we discussed about potential need to include proxy ND
functionality in this document, mostly for cellular use-cases when network
does not support PD, but we agreed that is not needed. We don't need to
discuss that, but just wanted to make sure for you that it was different
discussion than this one.

>From browsing through the 100+ emails on this topic I could not see clear
reason why to not include PD exclude.

Best regards,

Teemu

2011/12/8 V=C3=ADzdal Ale=C5=A1 

> > -----Original Message-----
> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of jouni
> > korhonen
> > Sent: Wednesday, December 07, 2011 7:59 AM
> > To: Hemant Singh
> > Cc: Thomas Narten; Ray Hunter; v6ops@ietf.org
> > Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
> >
> > Hemant,
> >
> > On Dec 4, 2011, at 1:59 AM, Hemant Singh (shemant) wrote:
> >
> > > It's high time the subject of the email changed to the pd-exclude
> document rather
> > than the rfc6204bis document for which the ship has sailed to include
> the pd-exclude
> > in.   That said, one question I had was this.   How are network
> interfaces
> >
> > IMHO it is too early to state that the ship has sailed for RFC6204bis
> already.
>
> [snip]
>
> +1
>
> What is preventing pd-exclude to be referenced in the 6240bis draft?
>
> The consequence of pd-exclude not being considered will result in a safe
> mode
> operation mode in the scenarios relying on pd-exclude (e.g. Prefix
> Delegation in 3GPP)
> where the customer will be allocated a prefix, but just a half (the one
> excluding /64 used for
> the wan link) of it will be delegated to be compliant with RFC3633.
>
> Is it wise ignoring this consequence?
> What needs to be done for the support of pd-exclude in the draft?
>
> Ales
>
> > - JOuni
> >
> >
> > >
> > > Hemant
> > >
> >
> > [snip]
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--f46d0444ef0b0eca6f04b39239d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 

I also want to state my support here in v6ops list for including=
 the PD exclude option into 6204bis.

In the past we discussed about =
potential need to include proxy ND functionality in this document, mostly f=
or cellular use-cases when network does not support PD, but we agreed that =
is not needed. We don't need to discuss that, but just wanted to make s=
ure for you that it was different discussion than this one.


From browsing through the 100+ emails on this topic I could not see cle=
ar reason why to not include PD exclude.

Best regards,

Teemu<=
br>
2011/12/8 V=C3=ADzdal Ale=C5=A1 <ales.vizdal@t-mobil=
e.cz>


> -----Original Message-----

> From: v6ops-bounces@ietf.org=
 [mailto:v6ops-bounces@ietf.o=
rg] On Behalf Of jouni

> korhonen

> Sent: Wednesday, December 07, 2011 7:59 AM

> To: Hemant Singh

> Cc: Thomas Narten; Ray Hunter; v6ops=
@ietf.org

> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

>


> Hemant,

>

> On Dec 4, 2011, at 1:59 AM, Hemant Singh (shemant) wrote:

>

> > It's high time the subject of the email changed to the pd-exc=
lude document rather

> than the rfc6204bis document for which the ship has sailed to include =
the pd-exclude

> in. =C2=A0 That said, one question I had was this. =C2=A0 How are netw=
ork interfaces

>

> IMHO it is too early to state that the ship has sailed for RFC6204bis =
already.




[snip]



+1



What is preventing pd-exclude to be referenced in the 6240bis draft?



The consequence of pd-exclude not being considered will result in a safe mo=
de

operation mode in the scenarios relying on pd-exclude (e.g. Prefix Delegati=
on in 3GPP)

where the customer will be allocated a prefix, but just a half (the one exc=
luding /64 used for

the wan link) of it will be delegated to be compliant with RFC3633.



Is it wise ignoring this consequence?

What needs to be done for the support of pd-exclude in the draft?



Ales




> - JOuni

>

>

> >

> > Hemant

> >

>

> [snip]

_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--f46d0444ef0b0eca6f04b39239d4--

From fred@cisco.com  Thu Dec  8 07:06:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7AC21F8ABD for ; Thu,  8 Dec 2011 07:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level: 
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qlXPiELmhjcG for ; Thu,  8 Dec 2011 07:06:14 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 174F321F8ABB for ; Thu,  8 Dec 2011 07:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2220; q=dns/txt; s=iport; t=1323356774; x=1324566374; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=VSU9+5ydCa9WXPHmXu13lS5ePoiSu2CmoaP25gsk78c=; b=ZZPrZ+wC16wmDwdWdVnkufzGovWFUGzk2mOsBs68B5aMssuqP3fwgCUp c+MtTO6RpwUoQlX3ObKAs1ZU43qdAdxAqpoHnoGfgSBuh7lKKTh73gYWm fJfFg3fbnhU4lkNySTg83GjwrMlsaEeYi4J8s1EX4LLIPh6mjJCBC2dnd 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJXR4E6rRDoI/2dsb2JhbABDqmeBBYFyAQEBAxMBJ0SBORwZh2UIl3uBJgGeBopYYwSILow9hUuMew
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208";a="18456648"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 08 Dec 2011 15:06:12 +0000
Received: from Freds-Computer.local (sjc-vpn5-553.cisco.com [10.21.90.41]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB8F6C2R017085 for ; Thu, 8 Dec 2011 15:06:12 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Dec 2011 08:06:14 -0700
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Dec 2011 08:06:14 -0700
From: Fred Baker 
Date: Thu, 8 Dec 2011 08:06:03 -0700
Message-Id: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
To: "v6ops@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 15:06:15 -0000

I'm looking at a presentation that Mark Townsley is giving, and he =
specifies a default route as ::/0. Yes, that's the prefix that RFC 5156 =
says should be used:

> 2.11.  Default Route
>=20
>    ::/0 is the default unicast route address.

I have a problem. If I am describing generic route maps for BGP (what to =
announce, what to accept), I don't want to announce/accept as global =
unicast routes link-local, multicast, ULAs (except for specific ones I =
choose to), IPv4 addresses (::/80), or various not-yet-specified =
addresses - and all of those are included in ::/0 by definition, because =
it includes all addresses. I do want to include addresses that are in =
fact global (eg not ULA, which is a form of local) unicast addresses. =
There are a set of other addresses that are for the moment in limbo - we =
haven't really decided, but we expect that they will be allocated to =
IANA as unicast addresses eventually.

It seems that an operator wants to accept/announce the prefixes in=20
  =
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic=
ast-address-assignments.xml

which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that =
no implementation (no code embedded in a product) should make that =
assumption, but operationally it seems absolutely wise to assume that =
unicast addresses are in fact those that have been delegated as unicast =
addresses.

One prefix I would hope is *never* actually advertised as a default =
route is ::/0, because it includes routes that are in fact not global =
unicast routes.


First: operators, do you agree?

Second: is this something that should be stated somewhere, perhaps as an =
erratum to RFC 5156?


If I were to specify an erratum, I think it might say something like:

old:
> 2.11.  Default Route
>=20
>    ::/0 is the default unicast route address.

new:
2.11.  Default Route

   ::/0 is the set of all IPv6 addresses. Operational default routes, as =
specified in [RFC4147], should include the addresses registered in the =
IANA registry iana-ipv6-unicast-address-assignments, but not include =
ULA, multicast, imported IPv4, or other special purpose routes.



From gert@space.net  Thu Dec  8 07:29:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E1921F8A91 for ; Thu,  8 Dec 2011 07:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level: 
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230,  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 hdb2tFa7pt7C for ; Thu,  8 Dec 2011 07:29:17 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5E21F867F for ; Thu,  8 Dec 2011 07:29:16 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D34CDF8955 for ; Thu,  8 Dec 2011 16:29:14 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F12D0F8953 for ; Thu,  8 Dec 2011 16:29:12 +0100 (CET)
Received: (qmail 56067 invoked by uid 1007); 8 Dec 2011 16:29:12 +0100
Date: Thu, 8 Dec 2011 16:29:12 +0100
From: Gert Doering 
To: Fred Baker 
Message-ID: <20111208152912.GM72014@Space.Net>
References: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 15:29:17 -0000

Hi,

On Thu, Dec 08, 2011 at 08:06:03AM -0700, Fred Baker wrote:
> First: operators, do you agree?

I don't feel that strongly about it - but something to keep in mind: the
"KISS" principle asks for *simple* approaches, and the most simple way
to specify a default aka "catch all" route is ::0/0.

In IPv4, we do 0.0.0.0/0, even if we know that it contains loopback,
multicast, and class E space.

Now, feel free to slap me for stating "we do it that way in IPv4" - but
it's the straightforward way...

Gert Doering
        -- Oper
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From prvs=9323ca65e7=edwin.mallette@bhnis.com  Thu Dec  8 07:44:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0321F8591 for ; Thu,  8 Dec 2011 07:44:45 -0800 (PST)
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 76MmY1c69Y4n for ; Thu,  8 Dec 2011 07:44:43 -0800 (PST)
Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfa.amsl.com (Postfix) with ESMTP id EB88121F8558 for ; Thu,  8 Dec 2011 07:44:42 -0800 (PST)
Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id pB8FiQna011509; Thu, 8 Dec 2011 10:44:40 -0500
Received: from cnedcex2.corp.local ([10.225.5.12]) by mx2.mybrighthouse.com with ESMTP id 11k01181k7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Dec 2011 10:44:40 -0500
Received: from CNEDCEX3.corp.local ([fe80::ac6f:a581:866a:5f86]) by CNEDCEX2.corp.local ([::1]) with mapi id 14.01.0289.001; Thu, 8 Dec 2011 10:44:39 -0500
From: "Mallette, Edwin" 
To: Fred Baker , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] A thought on default routes
Thread-Index: AQHMtcBKQp1vmY5YWUafLktoO9tY6A==
Date: Thu, 8 Dec 2011 15:44:39 +0000
Message-ID: 
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.225.1.248]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <255A318F8256C542B8F6B2ED3745C667@mybrighthouse.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1112080124
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 15:44:45 -0000

Fred,

My responses are in-line...

On 12/8/11 10:06 AM, "Fred Baker"  wrote:

>I'm looking at a presentation that Mark Townsley is giving, and he
>specifies a default route as ::/0. Yes, that's the prefix that RFC 5156
>says should be used:
>
>> 2.11.  Default Route
>>
>>    ::/0 is the default unicast route address.
>
>I have a problem. If I am describing generic route maps for BGP (what to
>announce, what to accept), I don't want to announce/accept as global
>unicast routes link-local, multicast, ULAs (except for specific ones I
>choose to), IPv4 addresses (::/80), or various not-yet-specified
>addresses - and all of those are included in ::/0 by definition, because
>it includes all addresses. I do want to include addresses that are in
>fact global (eg not ULA, which is a form of local) unicast addresses.
>There are a set of other addresses that are for the moment in limbo - we
>haven't really decided, but we expect that they will be allocated to IANA
>as unicast addresses eventually.
>
>It seems that an operator wants to accept/announce the prefixes in
>
>http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic
>ast-address-assignments.xml
>
>which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that no
>implementation (no code embedded in a product) should make that
>assumption, but operationally it seems absolutely wise to assume that
>unicast addresses are in fact those that have been delegated as unicast
>addresses.
>
>One prefix I would hope is *never* actually advertised as a default route
>is ::/0, because it includes routes that are in fact not global unicast
>routes.
>
>
>First: operators, do you agree?

[EJM]  No.  The ::/0 default parallels much of what many of us do in the
IPv4 world.  Certainly within an AS I can think of a number of cases where
I would want to advertise ::/0 rather than having to manage and advertise
a number of individual prefixes to account for my Unicast default, my ULA
prefix "default", etc.  Across AS boundaries, I think I might agree with
you.  However it's certainly possible that in the future I might want to
advertise a default route between AS under my control just like I do for
IPv4 today.
>
>Second: is this something that should be stated somewhere, perhaps as an
>erratum to RFC 5156?
>
>
>If I were to specify an erratum, I think it might say something like:
>
>old:
>> 2.11.  Default Route
>>
>>    ::/0 is the default unicast route address.
>
>new:
>2.11.  Default Route
>
>   ::/0 is the set of all IPv6 addresses. Operational default routes, as
>specified in [RFC4147], should include the addresses registered in the
>IANA registry iana-ipv6-unicast-address-assignments, but not include ULA,
>multicast, imported IPv4, or other special purpose routes.

[EJM] I'm not sure that I see the issue with the original text.  If you
want to provide completely informational text to remind operators that the
::/0 default includes ULA, multicast, imported IPv4, and other special
purpose routes, that's fine.  I don't see the need to add normative text
as I do plan to use ::/0 for operational simplicity just like I use
0.0.0.0/0 for IPv4.
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


________________________________

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile=
ged, confidential or otherwise protected from disclosure. If you are not th=
e intended recipient of this e-mail, please notify the sender immediately b=
y return e-mail, purge it and do not disseminate or copy it.

From marc.blanchet@viagenie.ca  Thu Dec  8 07:57:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BF621F8AD9 for ; Thu,  8 Dec 2011 07:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.38
X-Spam-Level: 
X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619, 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 M1TQjPHC2qWD for ; Thu,  8 Dec 2011 07:57:54 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45421F8AB9 for ; Thu,  8 Dec 2011 07:57:54 -0800 (PST)
Received: from [172.20.10.2] (unknown [74.198.165.40]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5CC7F20E37; Thu,  8 Dec 2011 10:57:23 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Marc Blanchet 
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
Date: Thu, 8 Dec 2011 10:57:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <566AE413-F12A-43FE-8378-EA846EDBCE20@viagenie.ca>
References: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
To: Fred Baker 
X-Mailer: Apple Mail (2.1251.1)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 15:57:55 -0000

that work started as a draft on providing =
more details/advice/... on how to filter IPv6 routes. but the "advice" =
got pushed back by some people. So the concensus was to make it light on =
the "advice" or on more details on bgp routing/filtering.

that explains I think a bit what you were looking for in the RFC but was =
not really there.

we might think of making a -bis or new with more data on filtering and =
include some discussions that you just wrote. Not sure an errata, since =
it starts to be more on changing the content than just fixing a little =
thing in the RFC (as I understand an errata should be)

Marc.

Le 2011-12-08 =E0 10:06, Fred Baker a =E9crit :

> I'm looking at a presentation that Mark Townsley is giving, and he =
specifies a default route as ::/0. Yes, that's the prefix that RFC 5156 =
says should be used:
>=20
>> 2.11.  Default Route
>>=20
>>   ::/0 is the default unicast route address.
>=20
> I have a problem. If I am describing generic route maps for BGP (what =
to announce, what to accept), I don't want to announce/accept as global =
unicast routes link-local, multicast, ULAs (except for specific ones I =
choose to), IPv4 addresses (::/80), or various not-yet-specified =
addresses - and all of those are included in ::/0 by definition, because =
it includes all addresses. I do want to include addresses that are in =
fact global (eg not ULA, which is a form of local) unicast addresses. =
There are a set of other addresses that are for the moment in limbo - we =
haven't really decided, but we expect that they will be allocated to =
IANA as unicast addresses eventually.
>=20
> It seems that an operator wants to accept/announce the prefixes in=20
>  =
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic=
ast-address-assignments.xml
>=20
> which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that =
no implementation (no code embedded in a product) should make that =
assumption, but operationally it seems absolutely wise to assume that =
unicast addresses are in fact those that have been delegated as unicast =
addresses.
>=20
> One prefix I would hope is *never* actually advertised as a default =
route is ::/0, because it includes routes that are in fact not global =
unicast routes.
>=20
>=20
> First: operators, do you agree?
>=20
> Second: is this something that should be stated somewhere, perhaps as =
an erratum to RFC 5156?
>=20
>=20
> If I were to specify an erratum, I think it might say something like:
>=20
> old:
>> 2.11.  Default Route
>>=20
>>   ::/0 is the default unicast route address.
>=20
> new:
> 2.11.  Default Route
>=20
>   ::/0 is the set of all IPv6 addresses. Operational default routes, =
as specified in [RFC4147], should include the addresses registered in =
the IANA registry iana-ipv6-unicast-address-assignments, but not include =
ULA, multicast, imported IPv4, or other special purpose routes.
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From fred@cisco.com  Thu Dec  8 08:04:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AC421F8B1B for ; Thu,  8 Dec 2011 08:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Level: 
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 KHxN6gdA8Poo for ; Thu,  8 Dec 2011 08:04:44 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF021F8B1E for ; Thu,  8 Dec 2011 08:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=848; q=dns/txt; s=iport; t=1323360283; x=1324569883; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=981KeCimIkc28B3EPDrzO7YzCeuUZ3jDXWpPdUhYQrE=; b=NMs+prvpALrbVncYCu91qNn2ZYBhTwC24NuOIpllSXVTLzzAma1gVoIW Yak46R8dUsyimUIGTlzwQ1LyjEURDeBfbJ7CehZSsWYgyt/Q4MDg7QHEd SW6ALLEEFDOcN0Io86S2zpIwVroWluHdXtflnzSLLUoexurppnvDz6qtp k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKDe4E6rRDoJ/2dsb2JhbABDqmeBBYFyAQEBBBIBJz8QC0ZXBjWhDwGeB4pYYwSILow9hUuMew
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208";a="16751369"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 Dec 2011 16:04:43 +0000
Received: from Freds-Computer.local (sjc-vpn5-553.cisco.com [10.21.90.41]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB8G3jB5026008; Thu, 8 Dec 2011 16:04:43 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Dec 2011 09:04:44 -0700
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Dec 2011 09:04:44 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: 
Date: Thu, 8 Dec 2011 09:04:44 -0700
Message-Id: <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com>
References: 
To: "Mallette, Edwin" 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 16:04:44 -0000

On Dec 8, 2011, at 8:44 AM, Mallette, Edwin wrote:

>>  ::/0 is the set of all IPv6 addresses. Operational default routes, as
>> specified in [RFC4147], should include the addresses registered in the
>> IANA registry iana-ipv6-unicast-address-assignments, but not include ULA,
>> multicast, imported IPv4, or other special purpose routes.
> 
> [EJM] I'm not sure that I see the issue with the original text.  If you
> want to provide completely informational text to remind operators that the
> ::/0 default includes ULA, multicast, imported IPv4, and other special
> purpose routes, that's fine.  I don't see the need to add normative text
> as I do plan to use ::/0 for operational simplicity just like I use
> 0.0.0.0/0 for IPv4.

...and as a result accept and announce ULAs by default.

OK, your call. Thanks for responding.

From sarikaya2012@gmail.com  Thu Dec  8 08:37:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D021F84FA for ; Thu,  8 Dec 2011 08:37:21 -0800 (PST)
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.128, BAYES_00=-2.599, J_CHICKENPOX_13=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 b-SfKmX+rVlR for ; Thu,  8 Dec 2011 08:37:20 -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 5888E21F8B04 for ; Thu,  8 Dec 2011 08:37:13 -0800 (PST)
Received: by yenm7 with SMTP id m7so1844392yen.31 for ; Thu, 08 Dec 2011 08:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=JAUsWEjhVcnPTkfuCSwLQm0ZsGlu2nDVUe+MT3d5DoM=; b=bkQ4kl+6T9iPsfqf8mGhrgBHZL98hNv2TpS43Q67M1nJmOStFI827HIBh/LgJybMvq Ge5mPFKl3Ig/UQgwcVht54bfCiDf5P3JurEh/37NaGcVo1L42yAaNpI1nCeYfS40fPzn BIxCVjC49TXPmw+Jjoz8heXxWHk2a1J8LMHOM=
MIME-Version: 1.0
Received: by 10.236.73.166 with SMTP id v26mr5701537yhd.100.1323362231897; Thu, 08 Dec 2011 08:37:11 -0800 (PST)
Received: by 10.236.125.201 with HTTP; Thu, 8 Dec 2011 08:37:11 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 8 Dec 2011 10:37:11 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Victor Kuarsingh 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 16:37:21 -0000

Hi Victor,

I would go with whatever Cameron says.

Regards,

Behcet

On Wed, Dec 7, 2011 at 8:08 PM, Victor Kuarsingh
 wrote:
> Behcet,
>
> On 11-12-07 4:54 PM, "Behcet Sarikaya"  wrote:
>
>>Hi Victor,
>>
>>For NAT64, the host need not be single stack IPv6, it could have IPv4
>>stack but simply not used.
>>This is what happens when you connect to IPv6-only ssid in IETF
>>meetings with Windows 7 PC or with smart phones with iOS or Android.
>
> I agree that a given device in the home can be IPv6 single stack, but the
> overall home would need IPv4 of some form to service the TVs (with IP),
> NAS, Printers, Older OSs, Older Security equipment etc.
>
> This particular draft has a focus on wireline. =A0Some use cases would
> include a directly attached PC which would at times be Win7/Vista, MACOSX
> sporting IPv6 capabilities (I cannot guarantee that all the apps will
> comply with IPv6 - the general computing world is hard to control and
> there are so many applications that customers will use... Not sure how
> confident I will be that all of them would support IPv6 for a while - som=
e
> may disagree). =A0Lorenzo brought this up in Taipei as a point of discuss=
ion.
>
> So on the NAT46 side, what is the likely hood we will see this in actual
> retail and OEM products soon? =A0I know that 6RD and DS-Lite is now out
> there.. I have not seen NAT46 personally (although it has been highlighte=
d
> to me that there are some products out..). =A0Availability of these in th=
e
> mass market is a key consideration for technologies to include (given the
> operator focus I was trying to achieve here). =A0I think a practical,
> attainable result is a benefit to operators here.
>
> If we have consensus in the WG that NAT46 with single stack IPv6 on WAN i=
s
> a valid option for the currently labelled phase 3, we can add it in as an
> option. =A0But, as noted to Wes, we would need to expand the consideratio=
ns
> section (which we would likely do anyway if we put more focus on the IPv6
> single stack [on WAN] result).
>
> Sorry, talked to a few points here...
>
> Victor K
>
>
>>
>>Regards,
>>
>>Behcet
>>
>>On Wed, Dec 7, 2011 at 1:11 PM, Victor Kuarsingh
>> wrote:
>>> Cameron,
>>>
>>> On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne 
>>>wrote:
>>>>
>>>> On Wed, Dec 7, 2011 at 8:44 AM, Victor Kuarsingh
>>>>  wrote:
>>>> > Wes/Cameron,
>>>> >
>>>> > To be clear, we can we define what we mean by "single stack" IPv6.
>>>>In
>>>> > my
>>>> > mind this means things like DS-Lite and not NAT64 (as the latter
>>>>would
>>>> > define a IPv6 only home network which I don't think is feasible in
>>>>the
>>>> > mid-term future).
>>>> >
>>>> > I am assuming that NAT46 (home gateway) is not in the cards since I
>>>>see
>>>> > not
>>>> > drafts or RFCs on that. =A0Hence NAT64 assumes all IPv6
>>>>endpoint/network
>>>> > (to
>>>> > round out my previous statement).
>>>> >
>>>>
>>>> NAT46 in the home =A0gateway draft
>>>> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02
>>>>
>>>
>>> Thanks for the reference. =A0Will review. =A0We have previously stated =
that
>>>we
>>> wanted to keep the technologies in consideration to running code with
>>> commercial availability. =A0Where is this with respect to that type of
>>> position?
>>>
>>> Victor K
>>>
>>>>
>>>> > Further to this, then we would need to beef up the considerations fo=
r
>>>> > IPv6
>>>> > single stack since it's vast.
>>>> >
>>>> > regards,
>>>> >
>>>> > Victor K
>>>> >
>>>> >
>>>> > On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne 
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >> On Dec 7, 2011 8:02 AM, "George, Wes" 
>>>> >> wrote:
>>>> >> >
>>>> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
>>>> >> > Behalf
>>>> >> > Of Victor Kuarsingh
>>>> >> >
>>>> >> > > Questions to the Group:
>>>> >> >
>>>> >> > > Position on IPv4 and IPv6. Should there be a shift in the
>>>> >> > > document's
>>>> >> > > tone
>>>> >> > > to be more progressive on movement to IPv6?
>>>> >> >
>>>> >> > WEG] I'm reproducing and refining some feedback I've given the
>>>> >> > authors
>>>> >> > offline already so that those on-list can agree/disagree.
>>>> >> >
>>>> >> > By the time this document is published as RFCXXXX, I expect that
>>>>one
>>>> >> > or
>>>> >> > more of the planned sequels to World IPv6 Day will have generated
>>>>a
>>>> >> > non-trivial deployment in last-mile access, as well as many
>>>>content
>>>> >> > providers making the decision to enable IPv6 permanently.
>>>>Therefore,
>>>> >> > I
>>>> >> > disagree with your foundational assertion that "most
>>>> >> > services/operators are
>>>> >> > IPv4."
>>>> >> > Plenty of IPv6 documents have already been written with that
>>>> >> > assumption
>>>> >> > in mind, and IMO it's time to start moving away from that. We
>>>>should
>>>> >> > be
>>>> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1
>>>>for
>>>> >> > those
>>>> >> > only deploying now, and treat our recommendations and
>>>>considerations
>>>> >> > accordingly. We should make it clear that they *are* behind on
>>>>IPv6
>>>> >> > deployment if they haven't started yet, not to browbeat them, but
>>>>to
>>>> >> > discuss
>>>> >> > the ramifications of that delay.
>>>> >> > There is a legitimate complaint that SPs and vendors have not
>>>>taken
>>>> >> > IPv6
>>>> >> > seriously and even when they deploy/implement it, it ends up
>>>>being a
>>>> >> > second-class service, either because it's being done using
>>>>different
>>>> >> > topology, reduced peering capacity and diversity, on elements tha=
t
>>>> >> > can't
>>>> >> > scale to "real" levels, it's encapsulated, or the support
>>>>structure
>>>> >> > and
>>>> >> > processes aren't in place yet (supported by a team of 3 people). =
I
>>>> >> > think
>>>> >> > that in a lot of cases, this is being perpetuated by the notion
>>>>that
>>>> >> > you can
>>>> >> > start with "training wheels" on your IPv6 deployment because it
>>>>isn't
>>>> >> > carrying enough traffic to matter, and at this point that notion
>>>>is
>>>> >> > probably
>>>> >> > doing more harm than good.
>>>> >> >
>>>> >> > One note of specific feedback on this regard, rather than treatin=
g
>>>> >> > the
>>>> >> > discussion evenly and saying "avoid using a transition/encaps
>>>> >> > technology on
>>>> >> > your primary traffic path..." say something clearer about making
>>>>sure
>>>> >> > that
>>>> >> > your IPv6 traffic path is first-class. That doesn't mean do
>>>>something
>>>> >> > to
>>>> >> > make IPv4 worse, but I think that making IPv6 equivalent or bette=
r
>>>> >> > should be
>>>> >> > a stated goal.
>>>> >> >
>>>> >>
>>>> >> +1 to non-trivial potential day one loads and treating the traffic
>>>> >> first
>>>> >> class.
>>>> >>
>>>> >> > Second, I think we should tighten the scope of this document to
>>>> >> > explicitly exclude any consideration of IPv4.
>>>> >> > Something equivalent to - "This document makes no recommendation
>>>>on
>>>> >> > when
>>>> >> > (or if) a given network can move away from IPv4. It assumes that
>>>>the
>>>> >> > network
>>>> >> > in question already has a functional IPv4 solution that will
>>>>coexist
>>>> >> > with
>>>> >> > the chosen IPv6 deployment. Further, it does not discuss any
>>>>methods
>>>> >> > of IPv4
>>>> >> > extension/service continuity, because it is purely focusing on th=
e
>>>> >> > practical
>>>> >> > considerations of deploying IPv6 support within an existing
>>>>network.
>>>> >> > Other
>>>> >> > documents exist which discuss and compare options for IPv4
>>>>extension
>>>> >> > technologies in great detail [reference, reference, reference] an=
d
>>>> >> > this can
>>>> >> > be evaluated independently of the IPv6 deployment strategy." - it
>>>>may
>>>> >> > be
>>>> >> > that the separation isn't quite that clean, since you may have to
>>>> >> > note areas
>>>> >> > where coexistence isn't complete or other interaction
>>>>considerations,
>>>> >> > but I
>>>> >> > think that should be the primary philosophy when determining the
>>>> >> > scope of
>>>> >> > any IPv4 discussion in this document.
>>>> >> >
>>>> >> > Put another way, single-stack IPv6 is the end goal, and I don't
>>>>think
>>>> >> > that's as outlandish or unreachable as it sounds as a premise for
>>>> >> > this
>>>> >> > document. Single-stack IPv6 and dual-stack are not that much
>>>> >> > different,
>>>> >> > except for that fact that a single-stack IPv6 network has to
>>>>ensure
>>>> >> > that all
>>>> >> > of its ancillary control-path things (not just data forwarding)
>>>>are
>>>> >> > capable
>>>> >> > of functioning properly without IPv4 configured. Therefore I don'=
t
>>>> >> > think
>>>> >> > it's too aggressive to treat this document as a comprehensive
>>>> >> > recommendation
>>>> >> > on how to deploy a single-stack IPv6 network, with the
>>>> >> > acknowledgement that
>>>> >> > IPv4 may coexist and make it a dual-stack network and nothing (or
>>>>not
>>>> >> > much)
>>>> >> > has to change. This gives the benefit of ensuring that the networ=
k
>>>> >> > itself is
>>>> >> > ready to move to single-stack whenever there is not an appreciabl=
e
>>>> >> > amount of
>>>> >> > IPv4 traffic being carried anymore. You could then prioritize the
>>>> >> > items to
>>>> >> > IPv6-enable given the assumption that everything except IPv6
>>>> >> > forwarding
>>>> >> > works via the existin
>>>> >> > =A0g IPv4 network, meaning that the network doesn't have to go
>>>> >> > single-stack all at once.
>>>> >> >
>>>> >>
>>>> >> +1 for clearly articulating single stack v6 as the attainable end
>>>>state
>>>> >> goal.
>>>> >>
>>>> >> Cb
>>>> >>
>>>> >> > Wes George
>>>> >> >
>>>> >> > This E-mail and any of its attachments may contain Time Warner
>>>>Cable
>>>> >> > proprietary information, which is privileged, confidential, or
>>>> >> > subject to
>>>> >> > copyright belonging to Time Warner Cable. This E-mail is intended
>>>> >> > solely for
>>>> >> > the use of the individual or entity to which it is addressed. If
>>>>you
>>>> >> > are not
>>>> >> > the intended recipient of this E-mail, you are hereby notified
>>>>that
>>>> >> > any
>>>> >> > dissemination, distribution, copying, or action taken in relation
>>>>to
>>>> >> > the
>>>> >> > contents of and attachments to this E-mail is strictly prohibited
>>>>and
>>>> >> > may be
>>>> >> > unlawful. If you have received this E-mail in error, please notif=
y
>>>> >> > the
>>>> >> > sender immediately and permanently delete the original and any
>>>>copy
>>>> >> > of this
>>>> >> > E-mail and any printout.
>>>> >> > _______________________________________________
>>>> >> > v6ops mailing list
>>>> >> > v6ops@ietf.org
>>>> >> > https://www.ietf.org/mailman/listinfo/v6ops
>>>> >
>>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>
>

From gert@space.net  Thu Dec  8 08:40:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B770721F8AFB for ; Thu,  8 Dec 2011 08:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level: 
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192,  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 YRpePHzlokok for ; Thu,  8 Dec 2011 08:40:09 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E10A21F84C3 for ; Thu,  8 Dec 2011 08:40:09 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7572FF8966 for ; Thu,  8 Dec 2011 17:40:08 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 62E6CF8955 for ; Thu,  8 Dec 2011 17:40:08 +0100 (CET)
Received: (qmail 76571 invoked by uid 1007); 8 Dec 2011 17:40:08 +0100
Date: Thu, 8 Dec 2011 17:40:08 +0100
From: Gert Doering 
To: Fred Baker 
Message-ID: <20111208164008.GN72014@Space.Net>
References:  <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 16:40:09 -0000

Hi,

On Thu, Dec 08, 2011 at 09:04:44AM -0700, Fred Baker wrote:
> > ::/0 default includes ULA, multicast, imported IPv4, and other special
> > purpose routes, that's fine.  I don't see the need to add normative text
> > as I do plan to use ::/0 for operational simplicity just like I use
> > 0.0.0.0/0 for IPv4.
> 
> ...and as a result accept and announce ULAs by default.

I'm not sure how that is related.  Having a route for ::0/0 will 
*forward* packets destined to ULA space, that's true - but it doesn't
imply I would "accept and announce ULAs by default".

Now, my *prefix filters* are much more strict, and do not permit 
either ::/0 or 2000::/3.

So what specifically are you talking about...?  Routes, or filters?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From fred@cisco.com  Thu Dec  8 09:13:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE35921F84D7 for ; Thu,  8 Dec 2011 09:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.562
X-Spam-Level: 
X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 YZ98A9ZRLoz8 for ; Thu,  8 Dec 2011 09:13:17 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 38A6821F8A7A for ; Thu,  8 Dec 2011 09:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1544; q=dns/txt; s=iport; t=1323364397; x=1324573997; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=DsjtPpCXK3fzRrZ7kwu/Tq3Vmx2g0uSuOwbqbMyPyQo=; b=Ho1XCV9c4DsBlDSBXjVfTOZXIrMtU8tXrZhI5t/Pm7jhtvZLAURRpsZp e5tNVa+UXR9FbdD4qovjeKpkQFTEOM6T9qdnN4I3yZY1PMcz+e+2ntYL0 EvdiHNeywRbKTde4JHLILmEfCSJ7QGJvIJ3Pa3ddtyiHeewmJeAJa1kpF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAAvv4E6rRDoH/2dsb2JhbABDqmeBBYFyAQEBAwESASc/BQsLRlcGNYdlmS8BnguKWGMEiC6MPYVLjHs
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208";a="18457020"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 08 Dec 2011 17:13:16 +0000
Received: from Freds-Computer.local (sjc-vpn5-494.cisco.com [10.21.89.238]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB8HDFSs014796; Thu, 8 Dec 2011 17:13:15 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Dec 2011 10:13:15 -0700
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Dec 2011 10:13:15 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <20111208164008.GN72014@Space.Net>
Date: Thu, 8 Dec 2011 10:13:02 -0700
Message-Id: <126A9C5E-50F5-4BAA-A05D-41D54C0F232A@cisco.com>
References:  <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com> <20111208164008.GN72014@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 17:13:17 -0000

On Dec 8, 2011, at 9:40 AM, Gert Doering wrote:

> So what specifically are you talking about...?  Routes, or filters?

actually, both.

For filters, I think you and I agree that one should accept/announce =
only routes that make sense. How complex/restrictive that might get is =
cook's choice, but it should not include routes that don't make sense.

For routes, let's take a relatively simple example: I have a =
home/SOHO/whatever that has two routers in it, one of which (R1) is =
advertising a default route to the other (R2):

       -------------------------LAN 1
                  +--+
                  |R1|
                  +--+
       -------------------------LAN 2
                  +--+
                  |R2|
                  +--+
       -------------------------LAN 3

Some host on LAN 3 emits a packet to a random multicast address, one =
that is not advertised in multicast routing (if that is even turned on). =
Is the right result for R2 to obey ::/0 and unicast it to R1, or to drop =
it? If the advertised route were 2000::/3, the answer would be trivially =
obvious: there is no route to forward the packet using, so it is =
dropped. If the default route is ::/0, we now *also* need something else =
to exclude multicasts, which might be an inline test ("if it matches ... =
use the multicast route table"), a null route, or whatever.

Ditto ULAs, link-local, etc.

Not trying to make a federal case out of this, but I got to thinking =
about it, so here I am thinking out loud.=

From shemant@cisco.com  Thu Dec  8 10:16:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD12521F8B57 for ; Thu,  8 Dec 2011 10:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wa82cKDhhckG for ; Thu,  8 Dec 2011 10:16:55 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE421F8B56 for ; Thu,  8 Dec 2011 10:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8201; q=dns/txt; s=iport; t=1323368215; x=1324577815; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=zehhZ4Q6MVYvASBorKCZYiLCeJORxaZ78gehwesIDgA=; b=UK07FCyW9vGApT1enmD8vFG1rEz7V2YTCe2+dg8X/9y+/OLOkKfE0Xtv QzgYx84Zp5021nW76y+r+b//Ij9/vDujFnKtPjPzyJ2cfgMEj9Nu4zeY0 Lomebd3tRx2Y5BFcCpAIeMzprftTApiT0G7EhspegFp/tlPtzV045xfsD 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnUAAL7+4E6tJXHB/2dsb2JhbABDgk2XX5A9gQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIGqE6AZ4LilhjBIgunwI
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208,217";a="42299162"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 08 Dec 2011 18:16:54 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pB8IGs3q000377;  Thu, 8 Dec 2011 18:16:54 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 12:16:53 -0600
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_01CCB5D5.90266755"
Date: Thu, 8 Dec 2011 12:16:51 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303828EB6@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy1MJGjTt+PllXHSJCysWT9oM78QgABgNDw
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Lorenzo Colitti" 
X-OriginalArrivalTime: 08 Dec 2011 18:16:53.0899 (UTC) FILETIME=[903585B0:01CCB5D5]
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 18:16:56 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB5D5.90266755
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Lorenzo Colitti [mailto:lorenzo@google.com]=20
Sent: Wednesday, December 07, 2011 5:35 PM
To: Hemant Singh (shemant)
Cc: jouni korhonen; Thomas Narten; Ray Hunter; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20

>Wait, what?

=20

>You have a set of PD clients on the same link and want to exclude the
same /64 from each of the PDs you hand out? That doesn't make sense.
Since each of the PD clients will >get its own prefix (say, a /60) and
they won't overlap (since they're different customers), only at most one
of the PDs will include the /64. So there's no need to exclude >anything
for the others.

=20

The DR has one network interface serving, say, 20K clients who are RR's.
DR is a CMTS (access concentrator) and the RR's are IPv6 CE routers
behind bridged cable modems.  Like the use case mentioned in the
pd-exclude document, the DR is the next-hop to the RR.  The DR is using
a /64 on the network interface and the DR issues multicast RA from this
network interface.  The /64 matches as the exclude prefix for one RR but
the DR happens to use the /64 on its interface multicasting the RA to
all of the 20K clients.  Thus the /64 is off-link to all clients and
"excluded".  Also, none of the other 19,999 RR's need to support the
pd-exclude option.   Thus soon as the SP domain gets one RR's pd-exclude
to say, a /64, then the SP provisioning does not support pd-exclude RR's
on the same network interface on the SP DR. =20

=20

Alternatively, does the DR uses unicast RA to each of the 20K clients. =20

=20

Do folks think such details needs to be added to the pd-exclude document
as an Appendix so that folks have some SP provisioning background.

=20

Hemant


------_=_NextPart_001_01CCB5D5.90266755
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
>Wait, =
what?
 
>You have a =
set of PD clients on the same link and want to exclude the same /64 from =
each of the PDs you hand out? That doesn't make sense. Since each of the =
PD clients will >get its own =
prefix (say, a /60) and they won't overlap (since they're different =
customers), only at most one of the PDs will include the /64. So there's =
no need to exclude >anything for =
the others.
 
The DR has one network interface serving, say, 20K clients who are =
RR’s.  DR is a CMTS (access concentrator) and the RR’s =
are IPv6 CE routers behind bridged cable modems.  Like the use case =
mentioned in the pd-exclude document, the DR is the next-hop to the =
RR.  The DR is using a /64 on the network interface and the DR =
issues multicast RA from this network interface.  The /64 matches =
as the exclude prefix for one RR but the DR happens to use the /64 on =
its interface multicasting the RA to all of the 20K clients.  Thus =
the /64 is off-link to all clients and “excluded”.  =
Also, none of the other 19,999 RR’s need to support the pd-exclude =
option.   Thus soon as the SP domain gets one RR’s =
pd-exclude to say, a /64, then the SP provisioning does not support =
pd-exclude RR’s on the same network interface on the SP DR.  =

 
Alternatively, does the DR uses unicast RA to each of the 20K =
clients.  
 
Do folks think such details needs to be added to the pd-exclude =
document as an Appendix so that folks have some SP provisioning =
background.
 
Hemant

------_=_NextPart_001_01CCB5D5.90266755--

From cb.list6@gmail.com  Thu Dec  8 10:20:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB0F21F8B79 for ; Thu,  8 Dec 2011 10:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level: 
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, J_CHICKENPOX_13=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 XxUvnEwsgiCx for ; Thu,  8 Dec 2011 10:20:30 -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 18CA921F8B7A for ; Thu,  8 Dec 2011 10:20:30 -0800 (PST)
Received: by dajz8 with SMTP id z8so2620898daj.31 for ; Thu, 08 Dec 2011 10:20:29 -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=yBB5t/6lxZxQS/z0NyAJWcari3IfuBEAPYeX2luUMaM=; b=reIsabbCVydqqJFG/2YzrPIQrS2mBHYWRct0lEoIsFtjHVVwG20YYFpCUhjdAlqbdt /8njFmMRlCSSwSdq42VGgC3M/8AY3LW46afjbRc06TNUhmIckJ4QjsU/13DDxtqIUePx Dv2MUVJHF3GvCKNi/g94KQ9l9UfWkpNyt3T5w=
MIME-Version: 1.0
Received: by 10.68.10.138 with SMTP id i10mr17436106pbb.92.1323368429474; Thu, 08 Dec 2011 10:20:29 -0800 (PST)
Received: by 10.142.43.11 with HTTP; Thu, 8 Dec 2011 10:20:29 -0800 (PST)
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
References: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
Date: Thu, 8 Dec 2011 10:20:29 -0800
Message-ID: 
From: Cameron Byrne 
To: Fred Baker 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 18:20:31 -0000

On Thu, Dec 8, 2011 at 7:06 AM, Fred Baker  wrote:
> I'm looking at a presentation that Mark Townsley is giving, and he specif=
ies a default route as ::/0. Yes, that's the prefix that RFC 5156 says shou=
ld be used:
>
>> 2.11. =A0Default Route
>>
>> =A0 =A0::/0 is the default unicast route address.
>
> I have a problem. If I am describing generic route maps for BGP (what to =
announce, what to accept), I don't want to announce/accept as global unicas=
t routes link-local, multicast, ULAs (except for specific ones I choose to)=
, IPv4 addresses (::/80), or various not-yet-specified addresses - and all =
of those are included in ::/0 by definition, because it includes all addres=
ses. I do want to include addresses that are in fact global (eg not ULA, wh=
ich is a form of local) unicast addresses. There are a set of other address=
es that are for the moment in limbo - we haven't really decided, but we exp=
ect that they will be allocated to IANA as unicast addresses eventually.
>
> It seems that an operator wants to accept/announce the prefixes in
> =A0http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-=
unicast-address-assignments.xml
>
> which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that no=
 implementation (no code embedded in a product) should make that assumption=
, but operationally it seems absolutely wise to assume that unicast address=
es are in fact those that have been delegated as unicast addresses.
>
> One prefix I would hope is *never* actually advertised as a default route=
 is ::/0, because it includes routes that are in fact not global unicast ro=
utes.
>
>
> First: operators, do you agree?
>
> Second: is this something that should be stated somewhere, perhaps as an =
erratum to RFC 5156?
>
>
> If I were to specify an erratum, I think it might say something like:
>
> old:
>> 2.11. =A0Default Route
>>
>> =A0 =A0::/0 is the default unicast route address.
>
> new:
> 2.11. =A0Default Route
>
> =A0 ::/0 is the set of all IPv6 addresses. Operational default routes, as=
 specified in [RFC4147], should include the addresses registered in the IAN=
A registry iana-ipv6-unicast-address-assignments, but not include ULA, mult=
icast, imported IPv4, or other special purpose routes.
>
>


I am with Gert, KISS.

And, importantly, running code thinks a default route is ::/0

So, when i use this command to automagically have a router generate a
default route, it generates a ::/0

http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.0/routing/comma=
nd/reference/rr40crs1book_chapter1.html#wp1835201429

"To cause a Border Gateway Protocol (BGP) speaker (the local router)
to send the default route 0.0.0.0/0 to a neighbor for use as a default
route, use the default-originate command in an appropriate
configuration mode. To disable this function, use the no form of this
command.
................The default-originate command does not require the
presence of the default route (0.0.0.0/0 for IPv4 or ::/0 for IPv6) in
the local router."


While i understand the intention of making the default route more
strict, i would rather avoid confusion on what a default route is.  A
default route, IMHO, says forward all unicast packets over to here.

CB


> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

From shemant@cisco.com  Thu Dec  8 10:29:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D4021F8B3A for ; Thu,  8 Dec 2011 10:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.075
X-Spam-Level: 
X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 w2Aq3uasGtR8 for ; Thu,  8 Dec 2011 10:29:20 -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 097A021F8B24 for ; Thu,  8 Dec 2011 10:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=12466; q=dns/txt; s=iport; t=1323368960; x=1324578560; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=SIxWVK3ZS8gzyxbJaRNJ7OBhMGCP3BjggfsR9ox12f0=; b=G+T358k5Px7guDDI7hh1Qedxd9gj7CeHD8pyomOylh5+wn4qHZfwvAKD 0spKg4VA5xakg1u2QvSwejUC6fR5sV7u61Fun6LHBFSNna3crg7N11szn rUR5WEXFQn4RQnuOzFGEuAgPtGd+ahpEATMN7vMsEJZ3w8gNR7F9H+w2A s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnYAABcB4U6tJXHA/2dsb2JhbABDgk2COZUmjyqBE4EFgXIBAQEDAQEBAQ8BCQcKAz4LBQcEAgEIDgMEAQEBCgYXAQICAgEBHwYfCQgBAQQBEggah2UImU8BjFuRLQSKJTNjBIgulyaHXA
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208,217";a="42304358"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 08 Dec 2011 18:29:19 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pB8ITIVj032739;  Thu, 8 Dec 2011 18:29:18 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 12:29:18 -0600
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_01CCB5D7.4BF6EAEB"
Date: Thu, 8 Dec 2011 12:29:17 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303828ECE@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy1lRDEub/4d3JvSBmTA07haq2PCAAQfXRg
References: <748E8EFF-BA36-42EF-A58A-C34FD8566E69@employees.org><591FE292-8D53-4C86-BFB1-71F0EF78A182@employees.org><399AFFDF-5400-497A-9F47-C3C4519325B8@employees.org><5B6B2B64C9FE2A489045EEEADDAFF2C303778431@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C303778599@XMB-RCD-109.cisco.com><88DA53CA-338E-4574-84AA-DAB8A2599187@steffann.nl><4EDA80AC.6030907@globis.net><435BDEA7-5582-418A-842A-607A37FDE96C@nominum.com><4EDA8DF0.7000803@globis.net><6F36EB9D-258A-4B08-903D-759746393F6D@nominum.com><4EDAA849.40208@globis.net><1808340F7EC362469DDFFB112B37E2FCC5E99F82D1@SRVHKE02.rdm.cz> 
From: "Hemant Singh (shemant)" 
To: "Teemu Savolainen" , =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= 
X-OriginalArrivalTime: 08 Dec 2011 18:29:18.0558 (UTC) FILETIME=[4C0F77E0:01CCB5D7]
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 18:29:21 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB5D7.4BF6EAEB
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

QWZ0ZXIgbXkgZW1haWwgZnJvbSB0b2RheSBleHBsYWluaW5nIGEgZmV3IFNQIHByb3Zpc2lvbmlu
ZyBpc3N1ZXMgdG8gd29yayB3aXRoIGZvciB0aGUgcGQtZXhjbHVkZSwgSSBwZXJzb25hbGx5IGRv
IG5vdCBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0aGUgcGQtZXhjbHVkZSBkcmFmdC4gIEkgc3VwcG9y
dCB0aGUgcGQtZXhjbHVkZSBkb2N1bWVudCB0byBtb3ZlIGZvcndhcmQuICBJIGRvbuKAmXQgbWFr
ZSB0aGUgZGVjaXNpb24gdG8gaW5jbHVkZSB0aGUgcGQtZXhjbHVkZSB3b3JrIGluIHJmYzYyMDRi
aXMuICBJdOKAmXMgdGhlIHY2b3BzIFdHIHRoYXQgZGVjaWRlcy4NCg0KIA0KDQpSZWdhcmRzIGJh
Y2ssDQoNCiANCg0KSGVtYW50DQoNCiANCg0KRnJvbTogVGVlbXUgU2F2b2xhaW5lbiBbbWFpbHRv
OnRzYXZvLnN0ZHNAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwOCwgMjAx
MSA1OjM1IEFNDQpUbzogVsOtemRhbCBBbGXFoQ0KQ2M6IGpvdW5pIGtvcmhvbmVuOyBIZW1hbnQg
U2luZ2ggKHNoZW1hbnQpOyBUaG9tYXMgTmFydGVuOyBSYXkgSHVudGVyOyB2Nm9wc0BpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi1kaGMtcGQtZXhjbHVkZQ0KDQogDQoN
CisxIA0KDQpJIGFsc28gd2FudCB0byBzdGF0ZSBteSBzdXBwb3J0IGhlcmUgaW4gdjZvcHMgbGlz
dCBmb3IgaW5jbHVkaW5nIHRoZSBQRCBleGNsdWRlIG9wdGlvbiBpbnRvIDYyMDRiaXMuDQoNCklu
IHRoZSBwYXN0IHdlIGRpc2N1c3NlZCBhYm91dCBwb3RlbnRpYWwgbmVlZCB0byBpbmNsdWRlIHBy
b3h5IE5EIGZ1bmN0aW9uYWxpdHkgaW4gdGhpcyBkb2N1bWVudCwgbW9zdGx5IGZvciBjZWxsdWxh
ciB1c2UtY2FzZXMgd2hlbiBuZXR3b3JrIGRvZXMgbm90IHN1cHBvcnQgUEQsIGJ1dCB3ZSBhZ3Jl
ZWQgdGhhdCBpcyBub3QgbmVlZGVkLiBXZSBkb24ndCBuZWVkIHRvIGRpc2N1c3MgdGhhdCwgYnV0
IGp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSBmb3IgeW91IHRoYXQgaXQgd2FzIGRpZmZlcmVudCBk
aXNjdXNzaW9uIHRoYW4gdGhpcyBvbmUuDQoNCkZyb20gYnJvd3NpbmcgdGhyb3VnaCB0aGUgMTAw
KyBlbWFpbHMgb24gdGhpcyB0b3BpYyBJIGNvdWxkIG5vdCBzZWUgY2xlYXIgcmVhc29uIHdoeSB0
byBub3QgaW5jbHVkZSBQRCBleGNsdWRlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClRlZW11DQoNCjIw
MTEvMTIvOCBWw616ZGFsIEFsZcWhIDxhbGVzLnZpemRhbEB0LW1vYmlsZS5jej4NCg0KPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFtt
YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGpvdW5pDQo+IGtvcmhv
bmVuDQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgNzo1OSBBTQ0KPiBUbzog
SGVtYW50IFNpbmdoDQo+IENjOiBUaG9tYXMgTmFydGVuOyBSYXkgSHVudGVyOyB2Nm9wc0BpZXRm
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLWRoYy1wZC1leGNsdWRlDQo+
DQoNCj4gSGVtYW50LA0KPg0KPiBPbiBEZWMgNCwgMjAxMSwgYXQgMTo1OSBBTSwgSGVtYW50IFNp
bmdoIChzaGVtYW50KSB3cm90ZToNCj4NCj4gPiBJdCdzIGhpZ2ggdGltZSB0aGUgc3ViamVjdCBv
ZiB0aGUgZW1haWwgY2hhbmdlZCB0byB0aGUgcGQtZXhjbHVkZSBkb2N1bWVudCByYXRoZXINCj4g
dGhhbiB0aGUgcmZjNjIwNGJpcyBkb2N1bWVudCBmb3Igd2hpY2ggdGhlIHNoaXAgaGFzIHNhaWxl
ZCB0byBpbmNsdWRlIHRoZSBwZC1leGNsdWRlDQo+IGluLiAgIFRoYXQgc2FpZCwgb25lIHF1ZXN0
aW9uIEkgaGFkIHdhcyB0aGlzLiAgIEhvdyBhcmUgbmV0d29yayBpbnRlcmZhY2VzDQo+DQo+IElN
SE8gaXQgaXMgdG9vIGVhcmx5IHRvIHN0YXRlIHRoYXQgdGhlIHNoaXAgaGFzIHNhaWxlZCBmb3Ig
UkZDNjIwNGJpcyBhbHJlYWR5Lg0KDQpbc25pcF0NCg0KKzENCg0KV2hhdCBpcyBwcmV2ZW50aW5n
IHBkLWV4Y2x1ZGUgdG8gYmUgcmVmZXJlbmNlZCBpbiB0aGUgNjI0MGJpcyBkcmFmdD8NCg0KVGhl
IGNvbnNlcXVlbmNlIG9mIHBkLWV4Y2x1ZGUgbm90IGJlaW5nIGNvbnNpZGVyZWQgd2lsbCByZXN1
bHQgaW4gYSBzYWZlIG1vZGUNCm9wZXJhdGlvbiBtb2RlIGluIHRoZSBzY2VuYXJpb3MgcmVseWlu
ZyBvbiBwZC1leGNsdWRlIChlLmcuIFByZWZpeCBEZWxlZ2F0aW9uIGluIDNHUFApDQp3aGVyZSB0
aGUgY3VzdG9tZXIgd2lsbCBiZSBhbGxvY2F0ZWQgYSBwcmVmaXgsIGJ1dCBqdXN0IGEgaGFsZiAo
dGhlIG9uZSBleGNsdWRpbmcgLzY0IHVzZWQgZm9yDQp0aGUgd2FuIGxpbmspIG9mIGl0IHdpbGwg
YmUgZGVsZWdhdGVkIHRvIGJlIGNvbXBsaWFudCB3aXRoIFJGQzM2MzMuDQoNCklzIGl0IHdpc2Ug
aWdub3JpbmcgdGhpcyBjb25zZXF1ZW5jZT8NCldoYXQgbmVlZHMgdG8gYmUgZG9uZSBmb3IgdGhl
IHN1cHBvcnQgb2YgcGQtZXhjbHVkZSBpbiB0aGUgZHJhZnQ/DQoNCkFsZXMNCg0KDQo+IC0gSk91
bmkNCj4NCj4NCj4gPg0KPiA+IEhlbWFudA0KPiA+DQo+DQo+IFtzbmlwXQ0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0K
djZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv
cHMNCg0KIA0KDQo=

------_=_NextPart_001_01CCB5D7.4BF6EAEB
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp
bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWZ0ZXIgbXkgZW1haWwgZnJvbSB0b2RheSBl
eHBsYWluaW5nIGEgZmV3IFNQIHByb3Zpc2lvbmluZyBpc3N1ZXMgdG8gd29yayB3aXRoIGZvciB0
aGUgcGQtZXhjbHVkZSwgSSBwZXJzb25hbGx5IGRvIG5vdCBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0
aGUgcGQtZXhjbHVkZSBkcmFmdC7CoCBJIHN1cHBvcnQgdGhlIHBkLWV4Y2x1ZGUgZG9jdW1lbnQg
dG8gbW92ZSBmb3J3YXJkLsKgIEkgZG9u4oCZdCBtYWtlIHRoZSBkZWNpc2lvbiB0byBpbmNsdWRl
IHRoZSBwZC1leGNsdWRlIHdvcmsgaW4gcmZjNjIwNGJpcy7CoCBJdOKAmXMgdGhlIHY2b3BzIFdH
IHRoYXQgZGVjaWRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMgYmFjayw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPkhlbWFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBz
dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h
Iiwic2Fucy1zZXJpZiInPiBUZWVtdSBTYXZvbGFpbmVuIFttYWlsdG86dHNhdm8uc3Rkc0BnbWFp
bC5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDA4LCAyMDExIDU6MzUg
QU08YnI+PGI+VG86PC9iPiBWw616ZGFsIEFsZcWhPGJyPjxiPkNjOjwvYj4gam91bmkga29yaG9u
ZW47IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IFRob21hcyBOYXJ0ZW47IFJheSBIdW50ZXI7IHY2
b3BzQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLWRo
Yy1wZC1leGNsdWRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h
bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i
b3R0b206MTIuMHB0Jz4rMSA8YnI+PGJyPkkgYWxzbyB3YW50IHRvIHN0YXRlIG15IHN1cHBvcnQg
aGVyZSBpbiB2Nm9wcyBsaXN0IGZvciBpbmNsdWRpbmcgdGhlIFBEIGV4Y2x1ZGUgb3B0aW9uIGlu
dG8gNjIwNGJpcy48YnI+PGJyPkluIHRoZSBwYXN0IHdlIGRpc2N1c3NlZCBhYm91dCBwb3RlbnRp
YWwgbmVlZCB0byBpbmNsdWRlIHByb3h5IE5EIGZ1bmN0aW9uYWxpdHkgaW4gdGhpcyBkb2N1bWVu
dCwgbW9zdGx5IGZvciBjZWxsdWxhciB1c2UtY2FzZXMgd2hlbiBuZXR3b3JrIGRvZXMgbm90IHN1
cHBvcnQgUEQsIGJ1dCB3ZSBhZ3JlZWQgdGhhdCBpcyBub3QgbmVlZGVkLiBXZSBkb24ndCBuZWVk
IHRvIGRpc2N1c3MgdGhhdCwgYnV0IGp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSBmb3IgeW91IHRo
YXQgaXQgd2FzIGRpZmZlcmVudCBkaXNjdXNzaW9uIHRoYW4gdGhpcyBvbmUuPGJyPjxicj5Gcm9t
IGJyb3dzaW5nIHRocm91Z2ggdGhlIDEwMCsgZW1haWxzIG9uIHRoaXMgdG9waWMgSSBjb3VsZCBu
b3Qgc2VlIGNsZWFyIHJlYXNvbiB3aHkgdG8gbm90IGluY2x1ZGUgUEQgZXhjbHVkZS48YnI+PGJy
PkJlc3QgcmVnYXJkcyw8YnI+PGJyPlRlZW11PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1N
c29Ob3JtYWw+MjAxMS8xMi84IFbDrXpkYWwgQWxlxaEgJmx0OzxhIGhyZWY9Im1haWx0bzphbGVz
LnZpemRhbEB0LW1vYmlsZS5jeiI+YWxlcy52aXpkYWxAdC1tb2JpbGUuY3o8L2E+Jmd0OzxvOnA+
PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08YnI+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRm
Lm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86
djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl
aGFsZiBPZiBqb3VuaTxicj4mZ3Q7IGtvcmhvbmVuPGJyPiZndDsgU2VudDogV2VkbmVzZGF5LCBE
ZWNlbWJlciAwNywgMjAxMSA3OjU5IEFNPGJyPiZndDsgVG86IEhlbWFudCBTaW5naDxicj4mZ3Q7
IENjOiBUaG9tYXMgTmFydGVuOyBSYXkgSHVudGVyOyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0
Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRy
YWZ0LWlldGYtZGhjLXBkLWV4Y2x1ZGU8YnI+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jmd0OyBIZW1h
bnQsPGJyPiZndDs8YnI+Jmd0OyBPbiBEZWMgNCwgMjAxMSwgYXQgMTo1OSBBTSwgSGVtYW50IFNp
bmdoIChzaGVtYW50KSB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsgSXQncyBoaWdoIHRpbWUg
dGhlIHN1YmplY3Qgb2YgdGhlIGVtYWlsIGNoYW5nZWQgdG8gdGhlIHBkLWV4Y2x1ZGUgZG9jdW1l
bnQgcmF0aGVyPGJyPiZndDsgdGhhbiB0aGUgcmZjNjIwNGJpcyBkb2N1bWVudCBmb3Igd2hpY2gg
dGhlIHNoaXAgaGFzIHNhaWxlZCB0byBpbmNsdWRlIHRoZSBwZC1leGNsdWRlPGJyPiZndDsgaW4u
ICZuYnNwOyBUaGF0IHNhaWQsIG9uZSBxdWVzdGlvbiBJIGhhZCB3YXMgdGhpcy4gJm5ic3A7IEhv
dyBhcmUgbmV0d29yayBpbnRlcmZhY2VzPGJyPiZndDs8YnI+Jmd0OyBJTUhPIGl0IGlzIHRvbyBl
YXJseSB0byBzdGF0ZSB0aGF0IHRoZSBzaGlwIGhhcyBzYWlsZWQgZm9yIFJGQzYyMDRiaXMgYWxy
ZWFkeS48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+W3NuaXBdPGJyPjxi
cj4rMTxicj48YnI+V2hhdCBpcyBwcmV2ZW50aW5nIHBkLWV4Y2x1ZGUgdG8gYmUgcmVmZXJlbmNl
ZCBpbiB0aGUgNjI0MGJpcyBkcmFmdD88YnI+PGJyPlRoZSBjb25zZXF1ZW5jZSBvZiBwZC1leGNs
dWRlIG5vdCBiZWluZyBjb25zaWRlcmVkIHdpbGwgcmVzdWx0IGluIGEgc2FmZSBtb2RlPGJyPm9w
ZXJhdGlvbiBtb2RlIGluIHRoZSBzY2VuYXJpb3MgcmVseWluZyBvbiBwZC1leGNsdWRlIChlLmcu
IFByZWZpeCBEZWxlZ2F0aW9uIGluIDNHUFApPGJyPndoZXJlIHRoZSBjdXN0b21lciB3aWxsIGJl
IGFsbG9jYXRlZCBhIHByZWZpeCwgYnV0IGp1c3QgYSBoYWxmICh0aGUgb25lIGV4Y2x1ZGluZyAv
NjQgdXNlZCBmb3I8YnI+dGhlIHdhbiBsaW5rKSBvZiBpdCB3aWxsIGJlIGRlbGVnYXRlZCB0byBi
ZSBjb21wbGlhbnQgd2l0aCBSRkMzNjMzLjxicj48YnI+SXMgaXQgd2lzZSBpZ25vcmluZyB0aGlz
IGNvbnNlcXVlbmNlPzxicj5XaGF0IG5lZWRzIHRvIGJlIGRvbmUgZm9yIHRoZSBzdXBwb3J0IG9m
IHBkLWV4Y2x1ZGUgaW4gdGhlIGRyYWZ0Pzxicj48YnI+QWxlczxvOnA+PC9vOnA+PC9wPjxkaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPiZndDsgLSBKT3VuaTxicj4mZ3Q7PGJyPiZndDs8
YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBIZW1hbnQ8YnI+Jmd0OyAmZ3Q7PGJyPiZndDs8YnI+
Jmd0OyBbc25pcF08YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+djZvcHMgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRm
Lm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2
PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Jv
ZHk+PC9odG1sPg==

------_=_NextPart_001_01CCB5D7.4BF6EAEB--

From jouni.nospam@gmail.com  Thu Dec  8 11:32:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC68621F8ACE for ; Thu,  8 Dec 2011 11:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level: 
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043,  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 ax+eIg-tbkOn for ; Thu,  8 Dec 2011 11:32:17 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9921F8AB0 for ; Thu,  8 Dec 2011 11:32:16 -0800 (PST)
Received: by laah2 with SMTP id h2so92190laa.31 for ; Thu, 08 Dec 2011 11:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eV2Bt181MdN95CwKfVkfLiDGek4eLHSVsCb8e4XxIOE=; b=rkJgS81ZvfBy7ZUeGZEeiHZQM/YfquLSGZwUh1L8ImUc3B/nvvPoNI7849s7y65pRF /1MxdRB9l5qwdY7E4/fYWjeKLGfDo2I8Q3H3OzICRWCLKnxy/FnbKJwUPbrmozDmCcY9 JGznJUQVApXP2PCn0D8zChsNvKVXKEWEnyC7w=
Received: by 10.152.135.225 with SMTP id pv1mr2844820lab.19.1323372735961; Thu, 08 Dec 2011 11:32:15 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPS id ng10sm5392904lab.13.2011.12.08.11.32.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 11:32:14 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: jouni korhonen 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com>
Date: Thu, 8 Dec 2011 21:32:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AC8BBFA-E7C7-480D-8658-2D92DFD6AFC2@gmail.com>
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3037785BB@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C303778FAA@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Thomas Narten , Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 19:32:18 -0000

Hemant,

On Dec 7, 2011, at 3:40 PM, Hemant Singh (shemant) wrote:

> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Wednesday, December 07, 2011 1:59 AM
> Cc: Ray Hunter; Ted Lemon; Thomas Narten; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
> =20
> =20
> > setup on the DR that is sending an RA with one exclude prefix if the =
DR has 20K different IPV6 CE routers  as RR=92s?  The RA >is multicast =
and, say, reaches 40K CE routers.   How is the exclude prefix working =
with the multicast RA?

This would work assuming you then include the pd-exclude only to that =
single IA_PD that is aggregate of the prefix on the link. The rest of =
the 19999 RRs' IA_PDs do not need pd-exclude for the prefix.

I setup my home network to mimic a deployment like this just to verify =
it worked.. i.e. my 'DR' had a Pref::/56 route to 'CE' A. The link where =
the rest of the routers B etc were, all configure their 'WAN' using =
SLAAC from Pref::/64 (the excluded prefix).

I think it could be useful to explain this case in pd-exclude draft how =
and why it actually works according to the conceptual sending algorithm =
in RFC4861.

- JOuni

> =20
> >Is this a real deployment scenario you are designing or already =
having where you intend to use pd-exclude? My question >regarding this =
specific example is why you would use RAs & SLAAC to configure 40K CE =
routers' WAN links attached to a single >link (with one prefix) and then =
try to apply pd-exclude in the first place?
> =20
> I do have a cable deployment where I can have the access concentrator =
serving 100K PD clients.  The network would like to use the pd-exclude.  =
The reason I asked my question because one person already said, the DR =
can use the RA so that the DR can address it=92s interface with SLAAC.  =
There are two choices for such a deployment and that is why I asked the =
question.  Either the same exclude /64 is given to each of the 100K =
clients or the network uses unicast RA.  Some IETF document has already =
defined a unicast.
> =20
> Hemant
> =20


From tsavo.stds@gmail.com  Thu Dec  8 12:14:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53AA21F8B08 for ; Thu,  8 Dec 2011 12:14:03 -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_13=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 nEb5QAbqofX7 for ; Thu,  8 Dec 2011 12:14:03 -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 2218A21F8770 for ; Thu,  8 Dec 2011 12:14:03 -0800 (PST)
Received: by yenm7 with SMTP id m7so2037324yen.31 for ; Thu, 08 Dec 2011 12:14:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:mime-version:date:subject:from:reply-to:to:cc :content-type:content-transfer-encoding; bh=5LkXZLsHuYByr+FGO2MeveKWLb7QCcVkVDcUnKf1cqQ=; b=IhPrqVl25vxl9AhQT1kLX20NqqPaopm/x14XQxCPmz3Aru9IxGjB04SQuA1fBduxxW L3ORU2X1u44s6VhMBnrSFHP+vnRvgk5lOuLPxnSux2s9DUbaRIZh+hbGyRnpGID1Ppc/ NslaRt2ufKAP37uRTzo2LVQ+ubRgV9m976554=
Received: by 10.236.189.6 with SMTP id b6mr7442584yhn.72.1323375241664; Thu, 08 Dec 2011 12:14:01 -0800 (PST)
Received: from nokia.com ([64.57.242.92]) by mx.google.com with ESMTPS id l31sm10747817yhj.22.2011.12.08.12.13.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 12:13:59 -0800 (PST)
Message-ID: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
MIME-Version: 1.0
Date: Thu, 08 Dec 2011 20:13:59 +0000
From: "tsavo.stds@gmail.com" 
To: "shemant@cisco.com" , "jouni.nospam@gmail.com" 
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "narten@us.ibm.com" , "v6ops@globis.net" , "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "tsavo.stds@gmail.com" 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 20:14:03 -0000

Isn't this pretty extreme corner case? I mean if a DR has 20k RRs in a mult=
icast link, couldn't DR afford to "waste" one /56 and use one /64 out of th=
at /56 for multicast RA, and then not to use exclude option with any RR (i.=
e. not to delegate anyone the /56 prefix out of which one /64 was taken)? I=
.e. while this might be interesting to explain, for me this does not sound =
like a very good reason to delay exclude draft's progress.

Best regards,

Teemu

Sent from my Nokia phone
-----Original Message-----
From: jouni korhonen
Sent:  08/12/2011, 21:32=20
To: Hemant Singh
Cc: Thomas Narten; Ray Hunter; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude


Hemant,

On Dec 7, 2011, at 3:40 PM, Hemant Singh (shemant) wrote:

> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Wednesday, December 07, 2011 1:59 AM
> Cc: Ray Hunter; Ted Lemon; Thomas Narten; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
> =20
> =20
> > setup on the DR that is sending an RA with one exclude prefix if the DR=
 has 20K different IPV6 CE routers  as RR=E2=80=99s?  The RA >is multicast =
and, say, reaches 40K CE routers.   How is the exclude prefix working with =
the multicast RA?

This would work assuming you then include the pd-exclude only to that singl=
e IA_PD that is aggregate of the prefix on the link. The rest of the 19999 =
RRs' IA_PDs do not need pd-exclude for the prefix.

I setup my home network to mimic a deployment like this just to verify it w=
orked.. i.e. my 'DR' had a Pref::/56 route to 'CE' A. The link where the re=
st of the routers B etc were, all configure their 'WAN' using SLAAC from Pr=
ef::/64 (the excluded prefix).

I think it could be useful to explain this case in pd-exclude draft how and=
 why it actually works according to the conceptual sending algorithm in RFC=
4861.

- JOuni

> =20
> >Is this a real deployment scenario you are designing or already having w=
here you intend to use pd-exclude? My question >regarding this specific exa=
mple is why you would use RAs & SLAAC to configure 40K CE routers' WAN link=
s attached to a single >link (with one prefix) and then try to apply pd-exc=
lude in the first place?
> =20
> I do have a cable deployment where I can have the access concentrator ser=
ving 100K PD clients.  The network would like to use the pd-exclude.  The r=
eason I asked my question because one person already said, the DR can use t=
he RA so that the DR can address it=E2=80=99s interface with SLAAC.  There =
are two choices for such a deployment and that is why I asked the question.=
  Either the same exclude /64 is given to each of the 100K clients or the n=
etwork uses unicast RA.  Some IETF document has already defined a unicast.
> =20
> Hemant
> =20

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

From internet-drafts@ietf.org  Thu Dec  8 12:38:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1624D21F8B43; Thu,  8 Dec 2011 12:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 17QfR0OTdtTp; Thu,  8 Dec 2011 12:38:07 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1021F84C5; Thu,  8 Dec 2011 12:38:07 -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: 3.64
Message-ID: <20111208203807.3764.3436.idtracker@ietfa.amsl.com>
Date: Thu, 08 Dec 2011 12:38:07 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-happy-eyeballs-06.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 20:38:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Happy Eyeballs: Success with Dual-Stack Hosts
	Author(s)       : Dan Wing
                          Andrew Yourtchenko
	Filename        : draft-ietf-v6ops-happy-eyeballs-06.txt
	Pages           : 16
	Date            : 2011-12-08

   When a server's IPv4 path and protocol is working but the server's
   IPv6 path and protocol are not working, a dual-stack client
   application experiences significant connection delay compared to an
   IPv4-only client.  This is undesirable because it causes the dual-
   stack client to have a worse user experience.  This document
   specifies requirements for algorithms that reduce this user-visible
   delay, and provides an example algorithm.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-06.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-v6ops-happy-eyeballs-06.txt


From he@uninett.no  Thu Dec  8 13:01:02 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0C1F0C48 for ; Thu,  8 Dec 2011 13:01:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.799
X-Spam-Level: *
X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAfXxoVGCwax for ; Thu,  8 Dec 2011 13:01:01 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id B7E381F0C38 for ; Thu,  8 Dec 2011 13:01:01 -0800 (PST)
Received: from localhost (login2.uninett.no [158.38.62.242]) by smistad.uninett.no (Postfix) with ESMTP id 726B03D0B4; Thu,  8 Dec 2011 22:00:58 +0100 (CET)
Date: Thu, 08 Dec 2011 22:05:37 +0100 (CET)
Message-Id: <20111208.220537.355340714.he@uninett.no>
To: fred@cisco.com
From: Havard Eidnes 
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
References: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 21:01:02 -0000

> One prefix I would hope is *never* actually advertised as a default
> route is ::/0, because it includes routes that are in fact not
> global unicast routes.
>
>
> First: operators, do you agree?

No, I do not agree.

Why is announcing ::/0 problematical?

Is announcing 0.0.0.0/0 in IPv4 any more or less problematical?

Or more generally, why would running with the default route in your
network be problematical?  (Yes, there is and should only be one
default route, and you should not have to periodically look up in the
IANA registry to find "the default route this year".  Instigating such
a procedure is just asking, no, *begging* for widespread trouble.)

Regards,

- H=E5vard, who runs a "mostly edge" network

From lorenzo@google.com  Thu Dec  8 13:18:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB8921F8BA0 for ; Thu,  8 Dec 2011 13:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.909
X-Spam-Level: 
X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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 fba9Jv9oDnH5 for ; Thu,  8 Dec 2011 13:18:05 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14F2A21F8B9B for ; Thu,  8 Dec 2011 13:18:05 -0800 (PST)
Received: by ggnk5 with SMTP id k5so2829948ggn.31 for ; Thu, 08 Dec 2011 13:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/7Qg32ok2EbWt2cTT2/xJefEvRQ3mEzhI1tgzIH4P9A=; b=lMSwh6+6eEuTOTIs8Ddy76gARTjpMajnOEqW8lCjXtRZeOYYU7KKy+9n+PQDcfIMxl nLun85n+G8or74ImeknQ==
Received: by 10.182.156.11 with SMTP id wa11mr1057735obb.18.1323379084397; Thu, 08 Dec 2011 13:18:04 -0800 (PST)
Received: by 10.182.156.11 with SMTP id wa11mr1057730obb.18.1323379084302; Thu, 08 Dec 2011 13:18:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.121.36 with HTTP; Thu, 8 Dec 2011 13:17:43 -0800 (PST)
In-Reply-To: <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com>
References:  <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com>
From: Lorenzo Colitti 
Date: Thu, 8 Dec 2011 13:17:43 -0800
Message-ID: 
To: Fred Baker 
Content-Type: multipart/alternative; boundary=f46d0444ed3539180e04b39b3439
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 21:18:06 -0000

--f46d0444ed3539180e04b39b3439
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 8, 2011 at 08:04, Fred Baker  wrote:

> > ::/0 default includes ULA, multicast, imported IPv4, and other special
> > purpose routes, that's fine.  I don't see the need to add normative text
> > as I do plan to use ::/0 for operational simplicity just like I use
> > 0.0.0.0/0 for IPv4.
>
> ...and as a result accept and announce ULAs by default.


Just as in IPv4 today we accept and announce RFC1918, multicast, and so on,
by default.

--f46d0444ed3539180e04b39b3439
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Dec 8, 2011 at 08:04, Fred Baker <fred@cisco.com> wrote:



> ::/0 default includes ULA, multicast, imported IPv4,=
 and other special

> purpose routes, that's fine. =A0I don't see the need to add no=
rmative text

> as I do plan to use ::/0 for operational simplicity just like I use
> 0.0.0.0/0 for IPv4.=





...and as a result accept and announce ULAs by default.
<=
div>
Just as in IPv4 today we accept and announce RFC1918, mu=
lticast, and so on, by default.


--f46d0444ed3539180e04b39b3439--

From shemant@cisco.com  Thu Dec  8 13:45:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8121F84CD for ; Thu,  8 Dec 2011 13:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level: 
X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079,  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 ibZfCGVpl+YA for ; Thu,  8 Dec 2011 13:45:16 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1121F84C5 for ; Thu,  8 Dec 2011 13:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1262; q=dns/txt; s=iport; t=1323380716; x=1324590316; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=v8FU7UE0KBXshIH6c6aMcKKJ4kF/5MsZ/Vseddsa83g=; b=PucBN6fnsxnxKXPyzJZHDW1IFiFHDaMWOTEvM4SRWsaxMtyIF+2vV/9B a4VWlfMGJ22+kK7T+SxfnUh83uzCNAIlU/1R+FmcKKOXaGPTAG6EWOPAr uEau2gkhmjmQXJxZRdry7XltXprGS/gDs5aLx1n41VCLdIgbeaROa1IJi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMAAJYu4U6tJV2b/2dsb2JhbABDhQaVJ48qgROBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBHyUJCAEBBAESCBMHoT8BjFuRJ4E0iHEzYwSILpcmh1w
X-IronPort-AV: E=Sophos;i="4.71,321,1320624000"; d="scan'208";a="42362052"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 08 Dec 2011 21:45:15 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB8LjFfR022481;  Thu, 8 Dec 2011 21:45:15 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 15:45:15 -0600
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: Thu, 8 Dec 2011 15:45:14 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303828FF3@XMB-RCD-109.cisco.com>
In-Reply-To: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy15e2UL+YZhCVMQK6l1EVNUgj2ZgADEsHw
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
From: "Hemant Singh (shemant)" 
To: , 
X-OriginalArrivalTime: 08 Dec 2011 21:45:15.0619 (UTC) FILETIME=[ABD09B30:01CCB5F2]
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 21:45:17 -0000

DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHNhdm8uc3Rkc0BnbWFpbC5jb20g
W21haWx0bzp0c2F2by5zdGRzQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg
MDgsIDIwMTEgMzoxNCBQTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IGpvdW5pLm5vc3Bh
bUBnbWFpbC5jb20NCkNjOiBuYXJ0ZW5AdXMuaWJtLmNvbTsgdjZvcHNAZ2xvYmlzLm5ldDsgdjZv
cHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbdjZvcHNdIGRyYWZ0LWlldGYtZGhjLXBkLWV4Y2x1
ZGUNCg0KPklzbid0IHRoaXMgcHJldHR5IGV4dHJlbWUgY29ybmVyIGNhc2U/IA0KDQpBYnNvbHV0
ZWx5IG5vdC4gIFRoZSBjYWJsZSBhY2Nlc3MgY29uY2VudHJhdG9yIGlzIGEgQ01UUyB0aGF0IHN1
cHBvcnRzIGZyb20gMjBLIHRvIDEwMEsgY2xpZW50cyBvbiBvbmUgbmV0d29yayBpbnRlcmZhY2Ug
b2YgdGhlIENNVFMuICBUaGUgUlIgY2xpZW50cyBhcmUgSVB2NiBDRSByb3V0ZXJzIGJlaGluZCBi
cmlkZ2VkIGNhYmxlIG1vZGVtcy4gIFRoZSBuZXR3b3JrIGludGVyZmFjZSBvbiB0aGUgQ01UUyBp
c3N1ZXMgbXVsdGljYXN0IFJBIHRvIGFsbCBub2RlcyBpbiB0aGUgaW50ZXJmYWNlIGRvd25zdHJl
YW0uICBJIGFscmVhZHkgZ2F2ZSBzdWNoIGluZm9ybWF0aW9uIGluIGEgcHJpb3IgZW1haWwgb24g
dGhpcyBzdWJqZWN0LiAgSSBhbHNvIHN1Z2dlc3RlZCB0byBhZGQgYW4gQXBwZW5kaXggdG8gdGhl
IHBkLWV4Y2x1ZGUgZG9jdW1lbnQgYW5kIGFkZCB0aGUgY2FzZSBhbmQgaXRzIHNvbHV0aW9uIHRv
IHRoZSBkb2N1bWVudC4gIENhYmxlIGJyb2FkYmFuZCBkZXBsb3ltZW50IGlzIGFsc28gcHJldHR5
IGNvbW1vbiBpbiB0aGUgVS5TLiBhbmQgb3RoZXIgcGxhY2VzIGluIHRoZSB3b3JsZC4gDQoNCkhl
bWFudA0KDQo=

From shemant@cisco.com  Thu Dec  8 14:01:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9621F8ABB for ; Thu,  8 Dec 2011 14:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level: 
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076,  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 7mrDyrephl+0 for ; Thu,  8 Dec 2011 14:01:48 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A7EED21F8AAA for ; Thu,  8 Dec 2011 14:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1266; q=dns/txt; s=iport; t=1323381708; x=1324591308; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dNx77c+XSejMx6w3xpj/ZO8wl2CqI9wpaC1nQa7xv5M=; b=T+F5IyAIxinztse85OrNBa2ZwZe4Gg6jAiD8TnGrJJbVUuliaShDFJfz dS8m/wdZNkzddvdqK8+XdMbkitaDcElHVkzCeSX38at9CyexQn1sgIuVX JOOxSNqcz3EdX6NS4H7PiNFRjmROSqmWIZ3UWoxqvfu+LTgU4L71MJi+L s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMAAAMz4U6tJV2Z/2dsb2JhbABDhQaVJ48qgROBBYFyAQEBBBIBEA0ERQwCAgIBCBEEAQEDAgYGFwECAgIBAR8lCQgBAQQBEggaoTwBjFuRJwSBMIhxM2MEiC6XJodc
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; d="scan'208";a="42377951"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 08 Dec 2011 22:01:48 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB8M1mK2013746;  Thu, 8 Dec 2011 22:01:48 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 16:01:47 -0600
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: Thu, 8 Dec 2011 16:01:46 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303829005@XMB-RCD-109.cisco.com>
In-Reply-To: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy15e2UL+YZhCVMQK6l1EVNUgj2ZgADuGsw
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
From: "Hemant Singh (shemant)" 
To: , 
X-OriginalArrivalTime: 08 Dec 2011 22:01:47.0991 (UTC) FILETIME=[FB508E70:01CCB5F4]
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 22:01:49 -0000

VGVlbXUsDQoNCkp1c3QgY3VyaW91cy4gIEluIHRoZSBjZWxsdWxhciBjYXNlLCBpcyBhIG11bHRp
Y2FzdCBSQSBvciB1bmljYXN0IFJBIHVzZWQ/ICBIb3cgbWFueSBjZWxsdWxhciBJUHY2IFBEIGNs
aWVudHMgZG9lcyB0aGUgRFIgdXNlZCBpbiBjZWxsdWxhciBzdXBwb3J0Pw0KDQpIZW1hbnQNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRzYXZvLnN0ZHNAZ21haWwuY29tIFtt
YWlsdG86dHNhdm8uc3Rkc0BnbWFpbC5jb21dIA0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA4
LCAyMDExIDM6MTQgUE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpOyBqb3VuaS5ub3NwYW1A
Z21haWwuY29tDQpDYzogbmFydGVuQHVzLmlibS5jb207IHY2b3BzQGdsb2Jpcy5uZXQ7IHY2b3Bz
QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3Y2b3BzXSBkcmFmdC1pZXRmLWRoYy1wZC1leGNsdWRl
DQoNCklzbid0IHRoaXMgcHJldHR5IGV4dHJlbWUgY29ybmVyIGNhc2U/IEkgbWVhbiBpZiBhIERS
IGhhcyAyMGsgUlJzIGluIGEgbXVsdGljYXN0IGxpbmssIGNvdWxkbid0IERSIGFmZm9yZCB0byAi
d2FzdGUiIG9uZSAvNTYgYW5kIHVzZSBvbmUgLzY0IG91dCBvZiB0aGF0IC81NiBmb3IgbXVsdGlj
YXN0IFJBLCBhbmQgdGhlbiBub3QgdG8gdXNlIGV4Y2x1ZGUgb3B0aW9uIHdpdGggYW55IFJSIChp
LmUuIG5vdCB0byBkZWxlZ2F0ZSBhbnlvbmUgdGhlIC81NiBwcmVmaXggb3V0IG9mIHdoaWNoIG9u
ZSAvNjQgd2FzIHRha2VuKT8gSS5lLiB3aGlsZSB0aGlzIG1pZ2h0IGJlIGludGVyZXN0aW5nIHRv
IGV4cGxhaW4sIGZvciBtZSB0aGlzIGRvZXMgbm90IHNvdW5kIGxpa2UgYSB2ZXJ5IGdvb2QgcmVh
c29uIHRvIGRlbGF5IGV4Y2x1ZGUgZHJhZnQncyBwcm9ncmVzcy4NCg0KQmVzdCByZWdhcmRzLA0K
DQpUZWVtdQ0KDQo=

From daryl.tanner@blueyonder.co.uk  Thu Dec  8 14:04:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5421F8AB9 for ; Thu,  8 Dec 2011 14:04:18 -0800 (PST)
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.686,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sI6GAfTFd100 for ; Thu,  8 Dec 2011 14:04:18 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC6921F8A7E for ; Thu,  8 Dec 2011 14:04:17 -0800 (PST)
Received: by laah2 with SMTP id h2so142498laa.31 for ; Thu, 08 Dec 2011 14:04:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.124.101 with SMTP id mh5mr1991383lab.16.1323381856632; Thu, 08 Dec 2011 14:04:16 -0800 (PST)
Received: by 10.152.36.98 with HTTP; Thu, 8 Dec 2011 14:04:16 -0800 (PST)
X-Originating-IP: [92.239.43.71]
In-Reply-To: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
References: <29F20823-ECBD-4FE3-987F-9B1974C04345@cisco.com>
Date: Thu, 8 Dec 2011 22:04:16 +0000
Message-ID: 
From: Daryl Tanner 
To: Fred Baker 
Content-Type: multipart/alternative; boundary=f46d042f93f47780f004b39bd9a4
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 22:04:18 -0000

--f46d042f93f47780f004b39bd9a4
Content-Type: text/plain; charset=ISO-8859-1

Hi Fred


> Second: is this something that should be stated somewhere, perhaps as an
> erratum to RFC 5156?
>
>
> If I were to specify an erratum, I think it might say something like:
>
> old:
> > 2.11.  Default Route
> >
> >    ::/0 is the default unicast route address.
>
> new:
> 2.11.  Default Route
>
>   ::/0 is the set of all IPv6 addresses. Operational default routes, as
> specified in [RFC4147], should include the addresses registered in the IANA
> registry iana-ipv6-unicast-address-assignments, but not include ULA,
> multicast, imported IPv4, or other special purpose routes.
>

I think this adds unnecessary complication.

The usage of the default route depends on the application - as an example:
- A host would want to direct anything non-local to its default gateway
- A LAN router would want to forward 'unknown' ULA via its default
- A border router would probably want to filter ULAs / multicast etc.

However. the catch-all is still ::0/0 for the default route. The router
should filter link-local, multicast etc as appropriate.


Daryl

--f46d042f93f47780f004b39bd9a4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Fred




Second: is this something that should be stated somewhere, perhaps as an er=
ratum to RFC 5156?





If I were to specify an erratum, I think it might say something like:



old:

> 2.11. =A0Default Route

>

> =A0 =A0::/0 is the default unicast route address.



new:

2.11. =A0Default Route



 =A0 ::/0 is the set of all IPv6 addresses. Operational default routes, as =
specified in [RFC4147], should include the addresses registered in the IANA=
 registry iana-ipv6-unicast-address-assignments, but not include ULA, multi=
cast, imported IPv4, or other special purpose routes.



I think this adds unnecessary complication.

Th=
e usage of the default route depends on the application - as an example:- A host would want to direct anything non-local to its default gateway
- A LAN router would want to forward 'unknown' ULA via its default =

- A border router would probably want to filter ULAs / multicast etc.
However. the catch-all is still ::0/0 for the default route. The rout=
er should filter link-local, multicast etc as appropriate. 



Daryl




--f46d042f93f47780f004b39bd9a4--

From ales.vizdal@t-mobile.cz  Thu Dec  8 14:15:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005B521F8B33 for ; Thu,  8 Dec 2011 14:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.464
X-Spam-Level: 
X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 yAT6DrQhDcaV for ; Thu,  8 Dec 2011 14:15:27 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id D509F21F8B03 for ; Thu,  8 Dec 2011 14:15:26 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C111D285807; Thu,  8 Dec 2011 23:15:25 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Thu, 8 Dec 2011 23:15:25 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: "Hemant Singh (shemant)" , "tsavo.stds@gmail.com" , "jouni.nospam@gmail.com" 
Date: Thu, 8 Dec 2011 23:15:29 +0100
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy15e2UL+YZhCVMQK6l1EVNUgj2ZgADuGswAAB0h6A=
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E99F8593@SRVHKE02.rdm.cz>
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303829005@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303829005@XMB-RCD-109.cisco.com>
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-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "narten@us.ibm.com" , "v6ops@globis.net" , "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 22:15:28 -0000

Hemant,

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=
 Hemant
> Singh (shemant)
> Sent: Thursday, December 08, 2011 11:02 PM
> To: tsavo.stds@gmail.com; jouni.nospam@gmail.com
> Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
>=20
> Teemu,
>=20
> Just curious.  In the cellular case, is a multicast RA or unicast RA used=
? =20

unicast is used as each subscriber has its own delegated prefix (e.g. /56) =
and the
/64 belongs to the delegated prefix.

Ales

> How many cellular IPv6 PD clients does the DR used in cellular support?
>=20
> Hemant
>=20
> -----Original Message-----
> From: tsavo.stds@gmail.com [mailto:tsavo.stds@gmail.com]
> Sent: Thursday, December 08, 2011 3:14 PM
> To: Hemant Singh (shemant); jouni.nospam@gmail.com
> Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
> Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude
>=20
> Isn't this pretty extreme corner case? I mean if a DR has 20k RRs in a mu=
lticast link,
> couldn't DR afford to "waste" one /56 and use one /64 out of that /56 for=
 multicast RA,
> and then not to use exclude option with any RR (i.e. not to delegate anyo=
ne the /56
> prefix out of which one /64 was taken)? I.e. while this might be interest=
ing to explain,
> for me this does not sound like a very good reason to delay exclude draft=
's progress.
>=20
> Best regards,
>=20
> Teemu
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

From shemant@cisco.com  Thu Dec  8 16:02:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857561F0C38 for ; Thu,  8 Dec 2011 16:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.075
X-Spam-Level: 
X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 PvShAe7mIRzq for ; Thu,  8 Dec 2011 16:02:10 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 07B701F0C36 for ; Thu,  8 Dec 2011 16:02:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2571; q=dns/txt; s=iport; t=1323388930; x=1324598530; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EcJmlDitJhanEiXc/lYyfUoomTsnBOlvSzncpWQQtXo=; b=g7qr6xzs2d6PTfPfJ9pOjf2Lw0EtjqpWGhYiBBjaSFc30z7/CywnBNQe YuhCC+T9Y0QCfjGid3p9PJs8CLiH0GFun7fu2xrDwqgLcH+1qpXpj4oJW QEztVJ1pUary25LdXjQn2Is/VtCl7BWFljtWvyEiXABG+ORWBZ7/zkI28 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMAAGBP4U6tJXG+/2dsb2JhbABDmi2QPYEFgXIBAQEDAQEBAQ8BHT4LBQcCAgIBCBEEAQELBhcBBgEgBh8JCAEBBAESCBqHZQiZWQGdfAQEilRjBIgulyaHXA
X-IronPort-AV: E=Sophos;i="4.71,322,1320624000"; d="scan'208";a="42378564"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 09 Dec 2011 00:02:09 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB90297q028725;  Fri, 9 Dec 2011 00:02:09 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 18:02:09 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Dec 2011 18:02:08 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303829085@XMB-RCD-109.cisco.com>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E99F8593@SRVHKE02.rdm.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy15e2UL+YZhCVMQK6l1EVNUgj2ZgADuGswAAB0h6AAA6kgAA==
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303829005@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E99F8593@SRVHKE02.rdm.cz>
From: "Hemant Singh (shemant)" 
To: =?iso-8859-2?B?Vu16ZGFsIEFsZbk=?= , , 
X-OriginalArrivalTime: 09 Dec 2011 00:02:09.0420 (UTC) FILETIME=[CB9F2CC0:01CCB605]
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 00:02:11 -0000

Ok, thanks.  Since the pd-exclude has a direct impact on rfc3633 where =
rfc3633 applies to all IPv6 nodes and thus pd-exlcude too, it would be =
very helpful to add an Appendix to the pd-exclude document.  The =
appendix would list the multicast RA use case and also if the current =
pd-exclude document does not mention the fact about the unicast RA used =
in cellular, the appendix should also mention the unicast RA fact.  As =
you guys can see the text for the Appendix is mostly there and the text =
gives great context to the reason of the document for subtle deployment =
issues.=20

Hemant

-----Original Message-----
From: V=EDzdal Ale=B9 [mailto:ales.vizdal@t-mobile.cz]=20
Sent: Thursday, December 08, 2011 5:15 PM
To: Hemant Singh (shemant); tsavo.stds@gmail.com; jouni.nospam@gmail.com
Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude

Hemant,

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Hemant
> Singh (shemant)
> Sent: Thursday, December 08, 2011 11:02 PM
> To: tsavo.stds@gmail.com; jouni.nospam@gmail.com
> Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
>=20
> Teemu,
>=20
> Just curious.  In the cellular case, is a multicast RA or unicast RA =
used? =20

unicast is used as each subscriber has its own delegated prefix (e.g. =
/56) and the
/64 belongs to the delegated prefix.

Ales

> How many cellular IPv6 PD clients does the DR used in cellular =
support?
>=20
> Hemant
>=20
> -----Original Message-----
> From: tsavo.stds@gmail.com [mailto:tsavo.stds@gmail.com]
> Sent: Thursday, December 08, 2011 3:14 PM
> To: Hemant Singh (shemant); jouni.nospam@gmail.com
> Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
> Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude
>=20
> Isn't this pretty extreme corner case? I mean if a DR has 20k RRs in a =
multicast link,
> couldn't DR afford to "waste" one /56 and use one /64 out of that /56 =
for multicast RA,
> and then not to use exclude option with any RR (i.e. not to delegate =
anyone the /56
> prefix out of which one /64 was taken)? I.e. while this might be =
interesting to explain,
> for me this does not sound like a very good reason to delay exclude =
draft's progress.
>=20
> Best regards,
>=20
> Teemu
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

From tsavo.stds@gmail.com  Thu Dec  8 21:52:36 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40921F8479 for ; Thu,  8 Dec 2011 21:52:36 -0800 (PST)
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.450,  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 3M3hNr-2Y-SL for ; Thu,  8 Dec 2011 21:52:35 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5221F8477 for ; Thu,  8 Dec 2011 21:52:35 -0800 (PST)
Received: by ggnk5 with SMTP id k5so3278747ggn.31 for ; Thu, 08 Dec 2011 21:52:35 -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=A6fRTMhJldhbnJeSmO2oivNIcHhfZkqZaXQbKPcf6+o=; b=JLeoSPZnHULz9fefeLfB0dp3OipshRUpC570KNh2PMAMwzmzbVi3VupaWONbixFR7u y2cmZbSH2SDAoZYZjAM5huTYgNgOXXhLA9kqMigGRMu85fQ89TN3pAVz7cvX+2Xf9KFn IkrgLubgO/aeGjaw6vpQVGRmeUu0U9oijO73I=
MIME-Version: 1.0
Received: by 10.182.222.106 with SMTP id ql10mr170113obc.53.1323409955189; Thu, 08 Dec 2011 21:52:35 -0800 (PST)
Received: by 10.182.43.8 with HTTP; Thu, 8 Dec 2011 21:52:35 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303828FF3@XMB-RCD-109.cisco.com>
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303828FF3@XMB-RCD-109.cisco.com>
Date: Fri, 9 Dec 2011 07:52:35 +0200
Message-ID: 
From: Teemu Savolainen 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=f46d04462bca45740204b3a26464
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 05:52:36 -0000

--f46d04462bca45740204b3a26464
Content-Type: text/plain; charset=ISO-8859-1

I meant isn't it corner case that in such deployment the CMTS would have to
take /64 out of a /56 that will be delegated to some single poor RR.
Couldn't the CMTS easily afford using /64 from some block that is not going
to be delegated to any RR? I.e. why would anyone use PD exclude at all in
that can of deployment scenario?

Because for me it sounds so weird to use PD exclude in such deployment, I'm
not sure we need to add this case to PD exclude draft (even as at
appendix). And even less so as it should work out anyway just fine.

Teemu

2011/12/8 Hemant Singh (shemant) 

>
> -----Original Message-----
> From: tsavo.stds@gmail.com [mailto:tsavo.stds@gmail.com]
> Sent: Thursday, December 08, 2011 3:14 PM
> To: Hemant Singh (shemant); jouni.nospam@gmail.com
> Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org
> Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude
>
> >Isn't this pretty extreme corner case?
>
> Absolutely not.  The cable access concentrator is a CMTS that supports
> from 20K to 100K clients on one network interface of the CMTS.  The RR
> clients are IPv6 CE routers behind bridged cable modems.  The network
> interface on the CMTS issues multicast RA to all nodes in the interface
> downstream.  I already gave such information in a prior email on this
> subject.  I also suggested to add an Appendix to the pd-exclude document
> and add the case and its solution to the document.  Cable broadband
> deployment is also pretty common in the U.S. and other places in the world.
>
> Hemant
>
>

--f46d04462bca45740204b3a26464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I meant isn't it corner case that in such deployment the CMTS would hav=
e to take /64 out of a /56 that will be delegated to some single poor RR. C=
ouldn't the CMTS easily afford using /64 from some block that is not go=
ing to be delegated to any RR? I.e. why would anyone use PD exclude at all =
in that can of deployment scenario?


Because for me it sounds so weird to use PD exclude in such deployment,=
 I'm not sure we need to add this case to PD exclude draft (even as at =
appendix). And even less so as it should work out anyway just fine.


Teemu

2011/12/8 Hemant Singh (shemant=
) <shemant@cisco.=
com>




-----Original Message-----

From: tsavo.stds@gmail.com [mai=
lto:tsavo.stds@gmail.com]

Sent: Thursday, December 08, 2011 3:14 PM

To: Hemant Singh (shemant); jouni=
.nospam@gmail.com

Cc: narten@us.ibm.com; v6ops@globis.net; v6ops@ietf.org

Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude



>Isn't this pretty extreme corner case?




Absolutely not. =A0The cable access concentrator is a CMTS that suppo=
rts from 20K to 100K clients on one network interface of the CMTS. =A0The R=
R clients are IPv6 CE routers behind bridged cable modems. =A0The network i=
nterface on the CMTS issues multicast RA to all nodes in the interface down=
stream. =A0I already gave such information in a prior email on this subject=
. =A0I also suggested to add an Appendix to the pd-exclude document and add=
 the case and its solution to the document. =A0Cable broadband deployment i=
s also pretty common in the U.S. and other places in the world.




Hemant







--f46d04462bca45740204b3a26464--

From ichiroumakino@gmail.com  Thu Dec  8 23:05:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23101F0C55 for ; Thu,  8 Dec 2011 23:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level: 
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120,  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 XcLxsFD698tQ for ; Thu,  8 Dec 2011 23:05:33 -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 59A7A1F0C50 for ; Thu,  8 Dec 2011 23:05:30 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3944104wgb.13 for ; Thu, 08 Dec 2011 23:05:29 -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=65ANB0O5hUGV+3V8ATxScqd7hjKtck2vv46Ijylz4Gs=; b=h2lAHCt8+YuW1hvNS+ufpGO6G7bsII+HNZs8e5QiDhCzQ2hnDBCxBQttOQO5vMlbvr y/rVxC7sJRl+IqRx7/7UPMAk5WPZNSo0si/yQju/HKeHf/IRkVuVhwsu7cvkj8RbpN9Y oGGmj999/3aiirYbPo/Zcu/sdoDTlfD4Kjv8E=
Received: by 10.216.132.164 with SMTP id o36mr379642wei.76.1323414329452; Thu, 08 Dec 2011 23:05:29 -0800 (PST)
Received: from dhcp-10-55-92-56.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fk3sm11627274wbb.10.2011.12.08.23.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 23:05:27 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Fri, 9 Dec 2011 08:05:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <29CDF0D7-911A-4BB9-92B7-87DF0EA157E9@employees.org>
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303828FF3@XMB-RCD-109.cisco.com> 
To: Teemu Savolainen 
X-Mailer: Apple Mail (2.1084)
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 07:05:33 -0000

> I meant isn't it corner case that in such deployment the CMTS would =
have to take /64 out of a /56 that will be delegated to some single poor =
RR. Couldn't the CMTS easily afford using /64 from some block that is =
not going to be delegated to any RR? I.e. why would anyone use PD =
exclude at all in that can of deployment scenario?
>=20
> Because for me it sounds so weird to use PD exclude in such =
deployment, I'm not sure we need to add this case to PD exclude draft =
(even as at appendix). And even less so as it should work out anyway =
just fine.

agree. you can't use a per client mechanism like PD exclude and expect =
that a broadcast mechanism like RA can be used to give per-client prefix =
information.

in a 3GPP deployment there is a separate link to each CE. I would =
suggest we say nothing in this draft about N:1 style links, or other =
broadcast access network types, where all kinds of "layer violating =
hacks" are required to create isolation between customers.

cheers,
Ole=

From ichiroumakino@gmail.com  Thu Dec  8 23:12:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F691F0C52 for ; Thu,  8 Dec 2011 23:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.484
X-Spam-Level: 
X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115,  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 T3R2HUPYSh1m for ; Thu,  8 Dec 2011 23:12:04 -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 0162A1F0C50 for ; Thu,  8 Dec 2011 23:12:03 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3952538wgb.13 for ; Thu, 08 Dec 2011 23:12:03 -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=ETx5h+VjN1up3B1l6RTX8m6OleLDPSXHYZmqqTbxAQc=; b=DE7Isv9cN9v8+Ycy67NICYaiM+QczxNrU7eXiURVxyPl6Qr7pIdYBQctfSgIe4IlKy OUcEayxFztq2Xo4G9BSfL07A73LLFSGbr438DvBzmrXDgPgFDhdEJyR87ECVPf5RV3h0 FqhCAx7B5L90JfpLey7Q9rguigzaRY3Iaav8U=
Received: by 10.216.187.2 with SMTP id x2mr359692wem.100.1323414723223; Thu, 08 Dec 2011 23:12:03 -0800 (PST)
Received: from dhcp-10-55-92-56.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff1sm11657351wbb.5.2011.12.08.23.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 23:12:01 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <126A9C5E-50F5-4BAA-A05D-41D54C0F232A@cisco.com>
Date: Fri, 9 Dec 2011 08:11:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <47C51AB8-DD7F-4738-98E7-DC8A447C9C96@employees.org>
References:  <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com> <20111208164008.GN72014@Space.Net> <126A9C5E-50F5-4BAA-A05D-41D54C0F232A@cisco.com>
To: Fred Baker 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 07:12:04 -0000

Fred,

>> So what specifically are you talking about...?  Routes, or filters?
>=20
> actually, both.
>=20
> For filters, I think you and I agree that one should accept/announce =
only routes that make sense. How complex/restrictive that might get is =
cook's choice, but it should not include routes that don't make sense.
>=20
> For routes, let's take a relatively simple example: I have a =
home/SOHO/whatever that has two routers in it, one of which (R1) is =
advertising a default route to the other (R2):
>=20
>       -------------------------LAN 1
>                  +--+
>                  |R1|
>                  +--+
>       -------------------------LAN 2
>                  +--+
>                  |R2|
>                  +--+
>       -------------------------LAN 3
>=20
> Some host on LAN 3 emits a packet to a random multicast address, one =
that is not advertised in multicast routing (if that is even turned on). =
Is the right result for R2 to obey ::/0 and unicast it to R1, or to drop =
it? If the advertised route were 2000::/3, the answer would be trivially =
obvious: there is no route to forward the packet using, so it is =
dropped. If the default route is ::/0, we now *also* need something else =
to exclude multicasts, which might be an inline test ("if it matches ... =
use the multicast route table"), a null route, or whatever.
>=20
> Ditto ULAs, link-local, etc.

your argument would have made sense if this is how forwarding worked. =
but it isn't.
conceptually there are separate routing tables for each link-local =
scope. (without a default route.)
multicast is never forwarded using the unicast RIB.

ULA's would break in your case above without a default route (::/0).

cheers,
Ole


From jouni.nospam@gmail.com  Fri Dec  9 01:17:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F2C21F8564 for ; Fri,  9 Dec 2011 01:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.63
X-Spam-Level: 
X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.250,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyH3Zi0xQgBI for ; Fri,  9 Dec 2011 01:17:32 -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 E22C821F850B for ; Fri,  9 Dec 2011 01:17:31 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so4107232wgb.13 for ; Fri, 09 Dec 2011 01:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dq9KqIjfCJCNXET/6P0mue48zj94Uv+n1kZBbckxdUc=; b=uw2WYok0CSj8gjr2kECnUzJeh+dynpdkr9vek/t7Efy2+7bFkRabyZAn4403uSQPz/ 7S+oBDIa7l2xTyCnmnrck4JJR+BPjh5ozPhf5Wp9hNZJmliTTVyJcVAJ+WDLhz7AS+eS 4N5YuVSdyovtBztu0+ruBDzAHv1FO5I3WHPiY=
Received: by 10.227.207.206 with SMTP id fz14mr6343821wbb.7.1323422251019; Fri, 09 Dec 2011 01:17:31 -0800 (PST)
Received: from [10.255.134.144] ([192.100.123.77]) by mx.google.com with ESMTPS id di5sm12495592wib.3.2011.12.09.01.17.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Dec 2011 01:17:29 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <29CDF0D7-911A-4BB9-92B7-87DF0EA157E9@employees.org>
Date: Fri, 9 Dec 2011 11:17:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4221D3BE-86BD-4955-B8DC-2F40A890F63A@gmail.com>
References: <4ee11a87.ab8fec0a.2359.1401@mx.google.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303828FF3@XMB-RCD-109.cisco.com>  <29CDF0D7-911A-4BB9-92B7-87DF0EA157E9@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1084)
Cc: narten@us.ibm.com, v6ops@globis.net, v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 09:17:32 -0000

This is fine with me. And I also agree that this is a corner case of =
already a corner case. The reason why I was slightly in favor of adding =
some text around this is to avoid repeated discussion that pd-exclude in =
N:1/broadcast style links would automatically break something..

- Jouni

On Dec 9, 2011, at 9:05 AM, Ole Troan wrote:

>> I meant isn't it corner case that in such deployment the CMTS would =
have to take /64 out of a /56 that will be delegated to some single poor =
RR. Couldn't the CMTS easily afford using /64 from some block that is =
not going to be delegated to any RR? I.e. why would anyone use PD =
exclude at all in that can of deployment scenario?
>>=20
>> Because for me it sounds so weird to use PD exclude in such =
deployment, I'm not sure we need to add this case to PD exclude draft =
(even as at appendix). And even less so as it should work out anyway =
just fine.
>=20
> agree. you can't use a per client mechanism like PD exclude and expect =
that a broadcast mechanism like RA can be used to give per-client prefix =
information.
>=20
> in a 3GPP deployment there is a separate link to each CE. I would =
suggest we say nothing in this draft about N:1 style links, or other =
broadcast access network types, where all kinds of "layer violating =
hacks" are required to create isolation between customers.
>=20
> cheers,
> Ole
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From gert@space.net  Fri Dec  9 02:24:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8C321F84DD for ; Fri,  9 Dec 2011 02:24:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164,  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 axewlJW+8n3g for ; Fri,  9 Dec 2011 02:24:00 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7906C21F84DA for ; Fri,  9 Dec 2011 02:23:59 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 47F01F888E for ; Fri,  9 Dec 2011 11:23:58 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0200BF8946 for ; Fri,  9 Dec 2011 11:23:57 +0100 (CET)
Received: (qmail 77648 invoked by uid 1007); 9 Dec 2011 11:23:57 +0100
Date: Fri, 9 Dec 2011 11:23:57 +0100
From: Gert Doering 
To: Fred Baker 
Message-ID: <20111209102357.GX72014@Space.Net>
References:  <5555447B-D4A5-4CC2-ADA3-7FFC1A2DEC30@cisco.com> <20111208164008.GN72014@Space.Net> <126A9C5E-50F5-4BAA-A05D-41D54C0F232A@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="19SMvJcDm4DXYM48"
Content-Disposition: inline
In-Reply-To: <126A9C5E-50F5-4BAA-A05D-41D54C0F232A@cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] A thought on default routes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 10:24:01 -0000

--19SMvJcDm4DXYM48
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Dec 08, 2011 at 10:13:02AM -0700, Fred Baker wrote:
> Some host on LAN 3 emits a packet to a random multicast address,
> one that is not advertised in multicast routing (if that is even
> turned on). Is the right result for R2 to obey ::/0 and unicast it
> to R1, or to drop it? If the advertised route were 2000::/3, the
> answer would be trivially obvious: there is no route to forward the
> packet using, so it is dropped. If the default route is ::/0, we
> now *also* need something else to exclude multicasts, which might
> be an inline test ("if it matches ... use the multicast route
> table"), a null route, or whatever.
>=20
> Ditto ULAs, link-local, etc.

I think the router needs special-case checks for link-local and multicast
space, no matter what.  Even if multicast routing isn't active, multicast
handling on lan links is still special, and cannot follow "normal unicast
routing".

So I can understand your thoughts, but I don't think implementations would
get any simpler if we mandated "do not use ::/0 for default, always use
2000::/3".

Historic trivia: some versions of the Linux kernel actually did this,=20
requiring the default route to be specified as 2000::/3 if it was to be=20
used for packet forwarding (as opposed to "host default" where ::/0=20
worked just fine) - and that caused lots of extra confusion to admins...

Gert Doering
        -- operator
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--19SMvJcDm4DXYM48
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTuHhvakuBuNlUUl1AQJthwP+NFVPd6aBrz1SMaUD1uEczmIvPdFHAZFA
MjQofwXNJa6UoEbIeQi+MqaO6qjorXxYAqiIzM9Us4jbeSh0kHowdjcSttDJv81y
OJUSGtmsfd/rPKPKohT90i5955C41sJkz4U0XZzpiG51uoyPkLSfCO9OlF+jblR1
BeHiB4XVpdA=
=NrpO
-----END PGP SIGNATURE-----

--19SMvJcDm4DXYM48--

From gilbert_kim@vanguard.com  Fri Dec  9 04:16:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BDB21F88A0 for ; Fri,  9 Dec 2011 04:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 0bY6uOy7v6Dj for ; Fri,  9 Dec 2011 04:16:39 -0800 (PST)
Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id 37B6E21F87FC for ; Fri,  9 Dec 2011 04:16:39 -0800 (PST)
Received: from pslva831.vanguard.com (pslva831.vanguard.com [10.17.37.6]) by pslva865.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id pB9CGV2E030651 for ; Fri, 9 Dec 2011 07:16:33 -0500
X-DKIM: OpenDKIM Filter v2.1.3 pslva865.vanguard.com pB9CGV2E030651
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1323432993; bh=qIzHw0mtdw9T4mn3d3cvNrlleaA=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=Eqzn6mm+WCNwTJ+j5wGU9E1ilda6fP7PvUW1SbRdERtozjZZi9dKUQeP0r6vIeXlu IbLLW8WuBOly7WcDsfGdw==
Received: from pslva867.vanguard.com (pslva867.vanguard.com [10.17.9.44]) by pslva831.vanguard.com (8.14.4/8.14.4) with ESMTP id pB9CGUdY009949 for ; Fri, 9 Dec 2011 07:16:30 -0500
Received: from vgi4mail.vanguard.com (pvnva784.vanguard.com [10.17.128.144]) by pslva867.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id pB9CGUSD001238 for ; Fri, 9 Dec 2011 07:16:30 -0500
Auto-Submitted: auto-generated
From: gilbert_kim@vanguard.com
To: v6ops@ietf.org
Message-ID: 
Date: Fri, 9 Dec 2011 07:16:29 -0500
X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 12/09/2011 07:16:30 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [v6ops] Gilbert Kim is out of office.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 12:16:39 -0000

I will be out of the office starting  12/09/2011 and will not return until
12/12/2011.

I am currently out of the country with limited access to email. If you need
immediate assistance please contact Scott Yarosh.

----------------------------------------------------------------------
CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system.

From Jean-Francois.TremblayING@videotron.com  Fri Dec  9 08:09:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739B21F85A1; Fri,  9 Dec 2011 08:09:39 -0800 (PST)
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 OIn7uzxBZI-Y; Fri,  9 Dec 2011 08:09:38 -0800 (PST)
Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id C556921F8558; Fri,  9 Dec 2011 08:09:38 -0800 (PST)
In-Reply-To: 
To: v6ops@ietf.org, v6ops@globis.net, v6ops-bounces@ietf.org
MIME-Version: 1.0
X-KeepSent: 51F6250C:40961A0F-85257961:005889C2; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: 
From: Jean-Francois.TremblayING@videotron.com
Date: Fri, 9 Dec 2011 11:09:27 -0500
X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 12/09/2011 11:09:27, Serialize complete at 12/09/2011 11:09:27
Content-Type: multipart/alternative; boundary="=_alternative 0058C1A785257961_="
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 16:09:39 -0000

Message en plusieurs parties au format MIME
--=_alternative 0058C1A785257961_=
Content-Type: text/plain; charset="US-ASCII"

> I meant isn't it corner case that in such deployment the CMTS 
> would have to take /64 out of a /56 that will be delegated to 
> some single poor RR. Couldn't the CMTS easily afford using /64 
> from some block that is not going to be delegated to any RR? 
> I.e. why would anyone use PD exclude at all in that can of deployment 
scenario?

AFAIK, PD-exclude is not used for cable deployments. The common link 
between the DRs (customer routers in this case) and RR (CMTS) uses a 
dedicated 
/64 independant of the PD space. I don't see a need to document this case. 


/JFT

--=_alternative 0058C1A785257961_=
Content-Type: text/html; charset="US-ASCII"



> I meant isn't it corner case that in such deployment
the CMTS 

> would have to take /64 out of a /56 that will
be delegated to 

> some single poor RR. Couldn't the CMTS easily
afford using /64 

> from some block that is not going to be delegated
to any RR? 

> I.e. why would anyone use PD exclude at all in
that can of deployment scenario?



AFAIK, PD-exclude is not used for cable deployments.
The common link 

between the DRs (customer routers in this case) and
RR (CMTS) uses a dedicated 

/64 independant of the PD space. I don't see a need
to document this case. 



/JFT


--=_alternative 0058C1A785257961_=--

From shemant@cisco.com  Fri Dec  9 08:25:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765121F8562; Fri,  9 Dec 2011 08:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.519
X-Spam-Level: 
X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ShjynSZqsRZA; Fri,  9 Dec 2011 08:25:06 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40B21F84E5; Fri,  9 Dec 2011 08:25:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5819; q=dns/txt; s=iport; t=1323447906; x=1324657506; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=kgoNn9rvCXQflUqIsFIjkSiMgEmB4wDa6/tful4MCGM=; b=JEZ7N99tBbx9LZopFleWl+AzEknIQ7clTz/TuMpUtkBmSQtQwNbaNnSs rovqJTrjs32Eth3ZJ9BE2CXZVC+bU4l4QdPD8QSEWbOq5Wxwr3rMZyPPf mW4IHwJmlY93+G9DwoAi/p1SgxIcLyPGvbRRMi3KWCjvgVUa6QrDWhj+n E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIAABc24k6tJXG//2dsb2JhbABDgk2XbpA+gQWBcgEBAQEDEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqfSAGeEIsPYwSIMJ8G
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208,217";a="42612939"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 09 Dec 2011 16:25:05 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB9GP5B0019251;  Fri, 9 Dec 2011 16:25:05 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Dec 2011 10:25:04 -0600
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_01CCB68F.1B9D8143"
Date: Fri, 9 Dec 2011 10:25:03 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy2jQff8XePkWMlR5S5VVCsTnsGaQAAZqjg
References:  
From: "Hemant Singh (shemant)" 
To: , , , 
X-OriginalArrivalTime: 09 Dec 2011 16:25:04.0965 (UTC) FILETIME=[1BC92F50:01CCB68F]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 16:25:08 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB68F.1B9D8143
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Jean-Francois.TremblayING@videotron.com
Sent: Friday, December 09, 2011 11:09 AM
To: v6ops@ietf.org; v6ops@globis.net; v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20



>AFAIK, PD-exclude is not used for cable deployments. The common link=20
>between the DRs (customer routers in this case) and RR (CMTS) uses a
dedicated=20
>/64 independant of the PD space. I don't see a need to document this
case.=20

How can pd-exclude been even use in cable until the document becomes an
RFC?  I am considering future use.  Anyway forget cable for a moment.
The pd-exclude document has focused on the unicast RA case for the
pd-exclude.  The document also needs to consider the multicast RA case
where only the first RR getting online with a DR has the DR use the RR's
excluded prefix on the link between the DR and the RR.  Thereafter, in
the multicast RA domain, other RR's do not need to be allocated excluded
prefixes.  Such details make sense to add to the document. =20

=20

Hemant


------_=_NextPart_001_01CCB68F.1B9D8143
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Jean-Francois.TremblayING@videotron.com
Sent: Friday, =
December 09, 2011 11:09 AM
To: v6ops@ietf.org; =
v6ops@globis.net; v6ops-bounces@ietf.org
Subject: Re: [v6ops] =
draft-ietf-dhc-pd-exclude
 


>AFAIK, PD-exclude is not used for cable =
deployments. The common link 
>between the DRs (customer routers in this =
case) and RR (CMTS) uses a dedicated 
>/64 independant of the PD space. I don't see =
a need to document this case. 

How can pd-exclude been even =
use in cable until the document becomes an RFC?  I am considering =
future use.  Anyway forget cable for a moment.  The pd-exclude =
document has focused on the unicast RA case for the pd-exclude.  =
The document also needs to consider the multicast RA case where =
only the first RR getting online with a DR has the DR use the RR’s =
excluded prefix on the link between the DR and the RR.  Thereafter, =
in the multicast RA domain, other RR’s do not need to be allocated =
excluded prefixes.  Such details make sense to add to the =
document.  
 
Hemant

------_=_NextPart_001_01CCB68F.1B9D8143--

From gert@space.net  Fri Dec  9 08:27:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8597821F8672 for ; Fri,  9 Dec 2011 08:27:53 -0800 (PST)
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.128,  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 nOtAW6i2J4wk for ; Fri,  9 Dec 2011 08:27:53 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0478B21F85F2 for ; Fri,  9 Dec 2011 08:27:53 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 57555F894B for ; Fri,  9 Dec 2011 17:27:52 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 18E42F8948 for ; Fri,  9 Dec 2011 17:27:52 +0100 (CET)
Received: (qmail 99163 invoked by uid 1007); 9 Dec 2011 17:27:51 +0100
Date: Fri, 9 Dec 2011 17:27:51 +0100
From: Gert Doering 
To: "Hemant Singh \(shemant\)" 
Message-ID: <20111209162751.GL72014@Space.Net>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 16:27:53 -0000

Hi,

On Fri, Dec 09, 2011 at 10:25:03AM -0600, Hemant Singh (shemant) wrote:
> How can pd-exclude been even use in cable until the document becomes an
> RFC?  I am considering future use.  Anyway forget cable for a moment.
> The pd-exclude document has focused on the unicast RA case for the
> pd-exclude.  The document also needs to consider the multicast RA case
> where only the first RR getting online with a DR has the DR use the RR's
> excluded prefix on the link between the DR and the RR.  Thereafter, in
> the multicast RA domain, other RR's do not need to be allocated excluded
> prefixes.  Such details make sense to add to the document.  

The deployment scenario where multiple CPEs share a link to the DR 
(aka "multicast RA") and this link has a pd-excluded prefix on it 
doesn't make sense.  Just allocate a non-conflicting /64 and be done.

Adding a non-useful scenario to documents just adds bloat and
needless complexity.

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From shemant@cisco.com  Fri Dec  9 08:35:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4033021F85A4; Fri,  9 Dec 2011 08:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level: 
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078,  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 OTJbrQ7Ergoy; Fri,  9 Dec 2011 08:35:32 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88AAB21F8548; Fri,  9 Dec 2011 08:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1080; q=dns/txt; s=iport; t=1323448532; x=1324658132; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nLBO0b5hy387B/OUcHvKJ+IoaBMTkHPGs0R8L4XFU3U=; b=RV9+DZ3wgMyi7/vy2vcAauH7+zcy7zpP2wbGRWsiV4s3zfa5E3bUXHtR 2HaN46wyVOq22/NZXasnZfzsQn183mr0UobLyJqgPponi7/uNfWhU/XNE 3ZZlwHRZsmY0f8/JuDr0LsCbe6Z6BtVl0kLGyHKwyA/4zzCA4fNBsOzTF Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIAAGE44k6tJXG8/2dsb2JhbABDmjuQPoEFgXIBAQEBAxIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgan0YBnhGLD2MEiDCfBg
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208";a="42609754"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 09 Dec 2011 16:35:32 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB9GZTWV029819;  Fri, 9 Dec 2011 16:35:29 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Dec 2011 10:35:29 -0600
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: Fri, 9 Dec 2011 10:35:28 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com>
In-Reply-To: <20111209162751.GL72014@Space.Net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy2j4Ekt+xLbpziTDCG02Uctz3zrAAAGZZw
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net>
From: "Hemant Singh (shemant)" 
To: "Gert Doering" 
X-OriginalArrivalTime: 09 Dec 2011 16:35:29.0598 (UTC) FILETIME=[90189DE0:01CCB690]
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 16:35:33 -0000

-----Original Message-----
From: Gert Doering [mailto:gert@space.net]=20
Sent: Friday, December 09, 2011 11:28 AM
To: Hemant Singh (shemant)
Cc: Jean-Francois.TremblayING@videotron.com; v6ops@ietf.org;
v6ops@globis.net; v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude


>The deployment scenario where multiple CPEs share a link to the DR=20
>(aka "multicast RA") and this link has a pd-excluded prefix on it=20
>doesn't make sense.  Just allocate a non-conflicting /64 and be done.

Not so fast.  Then add specific text to the pd-exclude document that the
document is addressing the unicast RA deployment. The document does not
even mention the unicast RA.  Since RA is both multicast and unicast, it
does make sense to add at least a few sentences for the SP provisioning
system and the DR RA.  If one allocates a non-conflicting /64 to the DR,
then one has moved the network for RFC 3633 use.  So where is text in
the pd-exclude document that says, gee, the pd-exclude should not be
used in the multicast RA deployment?=20

Hemant

From gert@space.net  Fri Dec  9 08:39:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46F21F86F6 for ; Fri,  9 Dec 2011 08:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  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 xH4bQxf3b78s for ; Fri,  9 Dec 2011 08:39:40 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 281DD21F8531 for ; Fri,  9 Dec 2011 08:39:36 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 213FFF893D for ; Fri,  9 Dec 2011 17:39:36 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 003A8F8948 for ; Fri,  9 Dec 2011 17:39:35 +0100 (CET)
Received: (qmail 2053 invoked by uid 1007); 9 Dec 2011 17:39:35 +0100
Date: Fri, 9 Dec 2011 17:39:35 +0100
From: Gert Doering 
To: "Hemant Singh \(shemant\)" 
Message-ID: <20111209163935.GM72014@Space.Net>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dJD2mDkf33M5vx0J"
Content-Disposition: inline
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 16:39:41 -0000

--dJD2mDkf33M5vx0J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Dec 09, 2011 at 10:35:28AM -0600, Hemant Singh (shemant) wrote:
> then one has moved the network for RFC 3633 use.  So where is text in
> the pd-exclude document that says, gee, the pd-exclude should not be
> used in the multicast RA deployment?=20

"common sense"?

Gert Doering
        -- Operator
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--dJD2mDkf33M5vx0J
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTuI5x6kuBuNlUUl1AQLrzgQAjW/NMVQGYvbezs44L/WrnkaE43mpkgAJ
Nz/o7KmxnGrz8J0BQJtZM8UAENpGif3VjURgxy+vuSgEUdwin/usbrp6uA+Ki2k3
qQiRG7J2Xo3vDI6pbHPRjsq/NmOe8G2yl+XJlIjJqcfVPvDJRnRkCoAAtsP8plJ9
BS84VY4+ShU=
=6Mp+
-----END PGP SIGNATURE-----

--dJD2mDkf33M5vx0J--

From shemant@cisco.com  Fri Dec  9 09:36:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A849A21F853E; Fri,  9 Dec 2011 09:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.222
X-Spam-Level: 
X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 cCVnuQI20-bk; Fri,  9 Dec 2011 09:36:09 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21D21F8512; Fri,  9 Dec 2011 09:36:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1247; q=dns/txt; s=iport; t=1323452169; x=1324661769; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=z4ujWeL324UIpk1eBm7N4DUQIvTE/Qzscl87GHmOXsQ=; b=CKTgcoasAMDFGyX6LVSDtOUS0lVo5n3JGiVT7DYfuda4A3wPdO19j/4C pBYXdt9imTBFTsrDFSO3bl8TxXD4X5wnX6z/TcJwKnrg4RigcTfefUgE6 SNSmC5ZAGR8vW/H5wKijoL/YU8uxKJ0qzIb0iHqaU/fM7wdywOa9X8RG7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhABABEppk6tJV2c/2dsb2JhbACQRY4WeJRVkjSGGQSGUI15ilw
X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208";a="40130714"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 09 Dec 2011 17:36:08 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pB9Ha8XE011199;  Fri, 9 Dec 2011 17:36:08 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Dec 2011 11:36:08 -0600
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: Fri, 9 Dec 2011 11:36:07 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com>
In-Reply-To: <20111209163935.GM72014@Space.Net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy2kST2FyXvyg1KQLm0/lQGs3HbkQABv3cQ
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net>
From: "Hemant Singh (shemant)" 
To: "Gert Doering" 
X-OriginalArrivalTime: 09 Dec 2011 17:36:08.0694 (UTC) FILETIME=[092A9960:01CCB699]
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Dec 2011 17:36:09 -0000

-----Original Message-----
From: Gert Doering [mailto:gert@space.net]=20
Sent: Friday, December 09, 2011 11:40 AM
To: Hemant Singh (shemant)
Cc: Gert Doering; Jean-Francois.TremblayING@videotron.com;
v6ops@ietf.org; v6ops@globis.net; v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude


>"common sense"?

The pd-exclude document is updating rfc3633 and all IPv6 networks are
affected as Ole said in the email below to v6ops.  But when we discuss
more, we see the multicast RA is being recommended to go back to rfc3633
behavior.  See the inconsistency we have when we say all networks are
affected and the pd-exclude is solving the problem but the solution is
not recommended for use in the multicast RA.=20

http://www.ietf.org/mail-archive/web/v6ops/current/msg11527.html

So let's tone down the pd-exclude text a bit.  The text has got to
mention the document is dealing with unicast RA.  Common sense is
debatable because either the multicast RA network goes back to rfc3633
behavior or the multicast RA network uses pd-exclude with only one RR
and the rest of the RR's are not supported for the pd-exclude option.
Which of the two choices should the multicast RA network go with?=20

Hemant

From shemant@cisco.com  Sat Dec 10 09:32:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527821F8BF9; Sat, 10 Dec 2011 09:32:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.218
X-Spam-Level: 
X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 bsg4WhEF2Q3N; Sat, 10 Dec 2011 09:32:25 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DC53521F8BF7; Sat, 10 Dec 2011 09:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9372; q=dns/txt; s=iport; t=1323538345; x=1324747945; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=qqiWRcR/tNJzkWotH1UzX35C3jt9AwzQfixsNF/UjX8=; b=Wgf30+qsX/oqLaG2eqJW8AmkUpdycfpo7nQOX/jsWzuxAIGhjAopHm3I c8dhXnQ9a/LyllUmIXoPdK2HTuTPj0T531TZPFd9p29TTJbV5bnBCps8k KXHNrUbVp4eqx9mhdFsihXth1/qpTCyACbBSXLg1SmmLGHTfn1+W/ThhV k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkAAIGX406tJXG9/2dsb2JhbABDgk2Xc5A+gQWBcgEBAQQBAQEPAQkRAz4LDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCAESB4dulmkBnW+LCmMEiDGfBg
X-IronPort-AV: E=Sophos;i="4.71,332,1320624000"; d="scan'208,217";a="42832639"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 10 Dec 2011 17:32:16 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBAHWGqb016714;  Sat, 10 Dec 2011 17:32:16 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 10 Dec 2011 11:32:16 -0600
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_01CCB761.A8C569B9"
Date: Sat, 10 Dec 2011 11:32:14 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy2kST2FyXvyg1KQLm0/lQGs3HbkQABv3cQADIZeaA=
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com><20111209162751.GL72014@Space.Net><5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com><20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com>
From: "Hemant Singh (shemant)" 
To: "Hemant Singh (shemant)" , "Gert Doering" 
X-OriginalArrivalTime: 10 Dec 2011 17:32:16.0533 (UTC) FILETIME=[A9336450:01CCB761]
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Dec 2011 17:32:26 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB761.A8C569B9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If the pd-exclude document adds something like the Applicability
statement below, then we can close this discussion.

=20

Applicability

=20

   This document is primarily intended for use in IPv6 cellular networks
that use DHCPv6 and unicast IPv6 ND RA. =20

=20

Please find the RFC of the unicast IPv6 ND RA and cite the RFC above and
also find any cellular document to reference, if you want to, and add
the reference.

=20

Thanks,

=20

Hemant

=20

=20

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Hemant Singh (shemant)
Sent: Friday, December 09, 2011 12:36 PM
To: Gert Doering
Cc: v6ops@globis.net; v6ops@ietf.org; v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20

=20

=20

-----Original Message-----

From: Gert Doering [mailto:gert@space.net]=20

Sent: Friday, December 09, 2011 11:40 AM

To: Hemant Singh (shemant)

Cc: Gert Doering; Jean-Francois.TremblayING@videotron.com;

v6ops@ietf.org; v6ops@globis.net; v6ops-bounces@ietf.org

Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20

=20

>"common sense"?

=20

The pd-exclude document is updating rfc3633 and all IPv6 networks are

affected as Ole said in the email below to v6ops.  But when we discuss

more, we see the multicast RA is being recommended to go back to rfc3633

behavior.  See the inconsistency we have when we say all networks are

affected and the pd-exclude is solving the problem but the solution is

not recommended for use in the multicast RA.=20

=20

http://www.ietf.org/mail-archive/web/v6ops/current/msg11527.html

=20

So let's tone down the pd-exclude text a bit.  The text has got to

mention the document is dealing with unicast RA.  Common sense is

debatable because either the multicast RA network goes back to rfc3633

behavior or the multicast RA network uses pd-exclude with only one RR

and the rest of the RR's are not supported for the pd-exclude option.

Which of the two choices should the multicast RA network go with?=20

=20

Hemant

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops


------_=_NextPart_001_01CCB761.A8C569B9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


If the pd-exclude document adds =
something like the Applicability statement below, then we can close this =
discussion.
 
Applicability
 
   This document is primarily intended for use in IPv6 =
cellular networks that use DHCPv6 and unicast IPv6 ND RA. =
 
 
Please =
find the RFC of the unicast IPv6 ND RA and cite the RFC above and also =
find any cellular document to reference, if you want to, and add the =
reference.
 
Thanks,
 
Hemant
 
 
-----Original Message-----
From: =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Hemant Singh (shemant)
Sent: Friday, December 09, 2011 12:36 =
PM
To: Gert Doering
Cc: v6ops@globis.net; v6ops@ietf.org; =
v6ops-bounces@ietf.org
Subject: Re: [v6ops] =
draft-ietf-dhc-pd-exclude
 
 
 
-----Original Message-----
From: Gert Doering [mailto:gert@space.net] =

Sent: Friday, December 09, 2011 =
11:40 AM
To: Hemant Singh =
(shemant)
Cc: Gert Doering; =
Jean-Francois.TremblayING@videotron.com;
v6ops@ietf.org; v6ops@globis.net; =
v6ops-bounces@ietf.org
Subject: =
Re: [v6ops] draft-ietf-dhc-pd-exclude
 
 
>"common sense"?
 
The =
pd-exclude document is updating rfc3633 and all IPv6 networks =
are
affected as Ole said in the =
email below to v6ops.  But when we discuss
more, we see the multicast RA is being recommended =
to go back to rfc3633
behavior.  See the inconsistency we have when =
we say all networks are
affected =
and the pd-exclude is solving the problem but the solution =
is
not recommended for use in the =
multicast RA. 
 
http://www.ietf.org/mail-archive/web/v6ops/current/m=
sg11527.html
 
So =
let's tone down the pd-exclude text a bit.  The text has got =
to
mention the document is dealing =
with unicast RA.  Common sense is
debatable because either the multicast RA network =
goes back to rfc3633
behavior or =
the multicast RA network uses pd-exclude with only one =
RR
and the rest of the RR's are =
not supported for the pd-exclude option.
Which of the two choices should the multicast RA =
network go with? 
 
Hemant
_______________________________________________=

v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

------_=_NextPart_001_01CCB761.A8C569B9--

From wesley.george@twcable.com  Mon Dec 12 07:07:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983EA21F8B70 for ; Mon, 12 Dec 2011 07:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.254
X-Spam-Level: 
X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 nJuMyZfzBI05 for ; Mon, 12 Dec 2011 07:07:13 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9397421F8B6C for ; Mon, 12 Dec 2011 07:07:12 -0800 (PST)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,339,1320642000"; d="scan'208";a="293779020"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Dec 2011 10:00:45 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 12 Dec 2011 10:07:12 -0500
From: "George, Wes" 
To: Brian E Carpenter , IPv6 Operations 
Date: Mon, 12 Dec 2011 10:07:11 -0500
Thread-Topic: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-guidance-01.txt
Thread-Index: AcyzntXBbMdBv4OCTJKTcosY+x/ydwEziH1Q
Message-ID: 
References: <4EDD4786.30500@gmail.com>
In-Reply-To: <4EDD4786.30500@gmail.com>
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
Subject: Re: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-guidance-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 15:07:14 -0000

A couple of comments -

Section 3 - there's a timing aspect to training. If staff are trained too f=
ar in advance of deployment, they forget everything before they have a chan=
ce to apply it. Training has a definite need to be done "just in time" in o=
rder to properly "stick."

In section 11, regarding IPv4 and IPv6 interdependence of Ops/Mgmt, a coupl=
e of points worth making here. You refer to them somewhat generally, but I =
bring these up because I think they're important to make more explicitly:
1) Monitoring systems must have a way to validate the IPv4 and IPv6 SLA and=
 performance independently, so that if the network is set up as you suggest=
, where IPv4 could have a failure that does not affect IPv6 or vice versa, =
the operator is aware that one of the two address-families is having an iss=
ue. Often the tendency is to assume that since things are taking the same p=
ath, that if one is working, so is the other. A good example of where this =
assumption fails is covered in draft-hsingh-6man-enhanced-dad-03, where DAD=
 may leave you with a functional IPv4 stack but dead IPv6.
2) It's worth explicitly stating that the end goal is to have a network tha=
t does not have to have major changes made to it when at some point in the =
future it becomes possible to transition to IPv6-only, even if only for som=
e parts of the network. That is, if the IPv6 deployment is architected in s=
uch a way as to more or less assume that IPv4 is not present, then the netw=
ork will function seamlessly when it is indeed no longer there. - Dual stac=
k, while necessary, does have scaling and management overhead consideration=
s, so if it's reasonably trivial to move to single-stack IPv6 (as the netwo=
rk and its customers can support such), that might be worth recommending in=
 this section. You do note that it should be possible to access devices hav=
ing problems on one address-family using the other (assumedly functional) A=
F, but I think this goes a step further along that line of logic.

Thanks,

Wes George

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Monday, December 05, 2011 5:37 PM
> To: IPv6 Operations
> Subject: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-
> guidance-01.txt
>
> Hi,
>
> This has been updated following the comments received so far. As
> discussed in Taipei, we are requesting reviews from the WG. Additional
> authors with personal expertise would be welcome too.
>
>    Brian and Sheng.
>
> -------- Original Message --------
> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-01.txt
> Date: Mon, 05 Dec 2011 14:33:13 -0800
> From: internet-drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>       Title           : IPv6 Guidance for Internet Content and
> Application Service Providers
>       Author(s)       : Brian Carpenter
>                           Sheng Jiang
>       Filename        : draft-carpenter-v6ops-icp-guidance-01.txt
>       Pages           : 16
>       Date            : 2011-12-05
>
>    This document provides guidance and suggestions for Internet Content
>    Providers and Application Service Providers who wish to offer their
>    service to both IPv6 and IPv4 customers.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-
> 01.txt
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From lorenzo@google.com  Mon Dec 12 15:21:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8C21F8AAA for ; Mon, 12 Dec 2011 15:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.912
X-Spam-Level: 
X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bZIR-yEzlqrd for ; Mon, 12 Dec 2011 15:21:49 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3821F85FF for ; Mon, 12 Dec 2011 15:21:48 -0800 (PST)
Received: by qadb15 with SMTP id b15so3475929qad.10 for ; Mon, 12 Dec 2011 15:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=6XbdNQO8psXOiEJmxzzjZMlYy4uKML+UOPlBFDzgfeQ=; b=XgO6+8PvScoxGGlD3nSeExIfdQJpTyAapsu7/BfeIDoCxgv6hHFglHt5eNu5+A8MXu eSNTrbD8YuNK9UUdCqqg==
Received: by 10.182.159.99 with SMTP id xb3mr3492195obb.8.1323732108457; Mon, 12 Dec 2011 15:21:48 -0800 (PST)
Received: by 10.182.159.99 with SMTP id xb3mr3492185obb.8.1323732108245; Mon, 12 Dec 2011 15:21:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.0.11 with HTTP; Mon, 12 Dec 2011 15:21:26 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>
From: Lorenzo Colitti 
Date: Mon, 12 Dec 2011 15:21:26 -0800
Message-ID: 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=14dae9399db116f9eb04b3ed6693
X-System-Of-Record: true
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 23:21:49 -0000

--14dae9399db116f9eb04b3ed6693
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Dec 10, 2011 at 09:32, Hemant Singh (shemant) wrote:

> Applicability
>
>    This document is primarily intended for use in IPv6 cellular networks
> that use DHCPv6 and unicast IPv6 ND RA.
>

And what does that statement buy you? If people disagree with it, they can
use pd-exclude anyway. If people agree with it, it's useless. So why but it
in there at all?

--14dae9399db116f9eb04b3ed6693
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sat, Dec 10, 2011 at 09:32, Hemant Singh (she=
mant) <shemant@ci=
sco.com> wrote:



Applicability=A0
=A0=A0 This document is primarily intended for use i=
n IPv6 cellular networks that use DHCPv6 and unicast IPv6 ND RA. =A0=





And what does that statement b=
uy you? If people disagree with it, they can use pd-exclude anyway. If peop=
le agree with it, it's useless. So why but it in there at all?





--14dae9399db116f9eb04b3ed6693--

From shemant@cisco.com  Mon Dec 12 15:47:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF22E11E808A; Mon, 12 Dec 2011 15:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.518
X-Spam-Level: 
X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1eKT+WG-RIfO; Mon, 12 Dec 2011 15:47:09 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CCF5411E8073; Mon, 12 Dec 2011 15:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5550; q=dns/txt; s=iport; t=1323733629; x=1324943229; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=x5M3vZHhe0T5gEqlb7F5M6o0NGZCBRhDoc2X4OR7dFw=; b=E308TapZTZipV5NG96kONDPqxltWD+Xl22MbDF/XR/k6g0FuaS2F9pAw bWoxGmvs2usst5a4v7zjxMFNTVpqnRLacKLqayi47nrcDs0ijDzt+kuMc 8WTe+Y0RrqbdVVLGQZXX1ixubTjzzQavaALBCdnMjQyyPg3z/ZM/TfI1H 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8AAN+R5k6tJV2a/2dsb2JhbABDgk2XdZBGgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIEweedQGeMIsKYwSIMZ8G
X-IronPort-AV: E=Sophos;i="4.71,342,1320624000"; d="scan'208,217";a="43355852"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Dec 2011 23:47:08 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBCNl88I028981;  Mon, 12 Dec 2011 23:47:08 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Dec 2011 17:47:07 -0600
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_01CCB928.5BF6A4D5"
Date: Mon, 12 Dec 2011 17:47:07 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy5JNLyRm4O9697RDyiXkcRKm7ICgAAxQLg
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Lorenzo Colitti" 
X-OriginalArrivalTime: 12 Dec 2011 23:47:07.0992 (UTC) FILETIME=[5BFB2D80:01CCB928]
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 23:47:09 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB928.5BF6A4D5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: Lorenzo Colitti [mailto:lorenzo@google.com]=20
Sent: Monday, December 12, 2011 6:21 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; v6ops@globis.net; v6ops@ietf.org;
v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

=20

=20

>And what does that statement buy you?

=20

So that the pd-exclude is NOT used in the multicast RA network because
the pd-exclude document is useless in the multicast network that has to
go back to RFC 3633 behavior.  One author said in an email related to
the pd-exclude that the pd-exclude problem applies to all networks.
But then the solution to the problem does not work in a multicast RA
network for PD acquisition.   The statement should be made so folks know
this document is unable to solve the problem in a multicast RA network.
I have gone hoarse trying to explain this issue.

=20

Hemant

=20


------_=_NextPart_001_01CCB928.5BF6A4D5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Monday, =
December 12, 2011 6:21 PM
To: Hemant Singh =
(shemant)
Cc: Gert Doering; v6ops@globis.net; v6ops@ietf.org; =
v6ops-bounces@ietf.org
Subject: Re: [v6ops] =
draft-ietf-dhc-pd-exclude
 
 
>And what does =
that statement buy you?
 
So that the pd-exclude is NOT used in the multicast RA network =
because the pd-exclude document is useless in the multicast network that =
has to go back to RFC 3633 behavior.  One author said in an email =
related to the pd-exclude that the pd-exclude problem applies to all =
networks.   But then the solution to the problem does not work =
in a multicast RA network for PD acquisition.   The statement =
should be made so folks know this document is unable to solve the =
problem in a multicast RA network.  I have gone hoarse trying to =
explain this issue.
 
Hemant
 

------_=_NextPart_001_01CCB928.5BF6A4D5--

From sander@steffann.nl  Tue Dec 13 01:34:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985721F850D; Tue, 13 Dec 2011 01:34:30 -0800 (PST)
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=[BAYES_00=-2.599, 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 p7E8y3D4HrHj; Tue, 13 Dec 2011 01:34:29 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0421F850E; Tue, 13 Dec 2011 01:34:27 -0800 (PST)
Received: from [10.253.253.9] (unknown [193.176.191.19]) by mail.sintact.nl (Postfix) with ESMTP id D7FF42018; Tue, 13 Dec 2011 10:34:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Sander Steffann 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com>
Date: Tue, 13 Dec 2011 10:34:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1251.1)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 09:34:30 -0000

Hi,

> So that the pd-exclude is NOT used in the multicast RA network because =
the pd-exclude document is useless in the multicast network that has to =
go back to RFC 3633 behavior.  One author said in an email related to =
the pd-exclude that the pd-exclude problem applies to all networks.   =
But then the solution to the problem does not work in a multicast RA =
network for PD acquisition.   The statement should be made so folks know =
this document is unable to solve the problem in a multicast RA network.  =
I have gone hoarse trying to explain this issue.

In that case the wording should be stronger. Instead of saying 'This =
document is primarily intended for use in IPv6 cellular networks' it =
should say 'The solution provided in this document is incompatible with =
multicast RA networks and therefore primarily intended for use in =
non-multicast networks like IPv6 cellular networks'.

Or something like that=85
Sander


From sander@steffann.nl  Tue Dec 13 01:44:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CE821F86AA; Tue, 13 Dec 2011 01:44:30 -0800 (PST)
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.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, 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 P1r7ETGumuYp; Tue, 13 Dec 2011 01:44:30 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 05EA721F85A7; Tue, 13 Dec 2011 01:44:30 -0800 (PST)
Received: from [10.253.253.9] (unknown [193.176.191.19]) by mail.sintact.nl (Postfix) with ESMTP id DCD8C2004; Tue, 13 Dec 2011 10:44:27 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5875AFEF-7D0B-40C7-818F-22800026B619"
From: Sander Steffann 
In-Reply-To: <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
Date: Tue, 13 Dec 2011 10:44:34 +0100
Message-Id: <4E6E680F-8E8E-406F-9E8F-3507C5349DCC@steffann.nl>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1251.1)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 09:44:30 -0000

--Apple-Mail=_5875AFEF-7D0B-40C7-818F-22800026B619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

> In that case the wording should be stronger. Instead of saying 'This =
document is primarily intended for use in IPv6 cellular networks' it =
should say 'The solution provided in this document is incompatible with =
multicast RA networks and therefore primarily intended for use in =
non-multicast networks like IPv6 cellular networks'.


Oops. Without the 'primarily' in the last sentence of course.

Met vriendelijke groet,
Sander Steffann




--Apple-Mail=_5875AFEF-7D0B-40C7-818F-22800026B619
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=windows-1252


In that case the wording should be stronger. Instead of saying 'This document is primarily intended for use in IPv6 cellular networks' it should say 'The solution provided in this document is incompatible with multicast RA networks and therefore primarily intended for use in non-multicast networks like IPv6 cellular networks'.

Oops. Without the 'primarily' in the last sentence of course.


Met vriendelijke groet,
Sander Steffann







--Apple-Mail=_5875AFEF-7D0B-40C7-818F-22800026B619--

From jouni.nospam@gmail.com  Tue Dec 13 02:37:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B757221F86EE; Tue, 13 Dec 2011 02:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level: 
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=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 UrOXdoUoRtCd; Tue, 13 Dec 2011 02:37:00 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B67ED21F86A4; Tue, 13 Dec 2011 02:36:59 -0800 (PST)
Received: by laah2 with SMTP id h2so1752146laa.31 for ; Tue, 13 Dec 2011 02:36:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dRZVbSBf3mZCZ3FFtm7tw/fUay6DV1ELfotTfwLu5Qk=; b=W962wRO+zI2m0UZG8IqvSVSECpyN47GFMTxgAq0k6RU8mgxyOLZ3sXKok8X3GRAwNc MJpXISYuNigijpN9kXYYYbFBBnPmeVuVjqqvrgzs9CttMoXjzoJYULbwVInkM+3jA6sj +yFwidJQtq+dh7dzQ2xrRXNmt5QdD/gppWt68=
Received: by 10.152.105.113 with SMTP id gl17mr6811199lab.25.1323772618680; Tue, 13 Dec 2011 02:36:58 -0800 (PST)
Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id mq11sm9597527lab.11.2011.12.13.02.36.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Dec 2011 02:36:57 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Jouni 
In-Reply-To: <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
Date: Tue, 13 Dec 2011 12:36:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
To: Sander Steffann 
X-Mailer: Apple Mail (2.1251.1)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 10:37:00 -0000

Hi,

I would not say "incompatible", since whether using something makes =
sense in certain deployment is different that incompatible. You don't =
turn on pd-exclude by accident like in broadcast access networks you do =
not turn on RFC6085 by accident (excluding misconfiguration). Also, I do =
not like pointing cellular networks here as the example case; pd-exclude =
applies to deployments where you have 1:1 pipes between RR and DR (e.g. =
VLANs, point to point links or other tweaks to mimic such behavior).  =
So, I would prefer wording like "The solution provided in this document =
is intended for use in networks with point to point semantics between =
the RR and the DR."

- Jouni






On Dec 13, 2011, at 11:34 AM, Sander Steffann wrote:

> Hi,
>=20
>> So that the pd-exclude is NOT used in the multicast RA network =
because the pd-exclude document is useless in the multicast network that =
has to go back to RFC 3633 behavior.  One author said in an email =
related to the pd-exclude that the pd-exclude problem applies to all =
networks.   But then the solution to the problem does not work in a =
multicast RA network for PD acquisition.   The statement should be made =
so folks know this document is unable to solve the problem in a =
multicast RA network.  I have gone hoarse trying to explain this issue.
>=20
> In that case the wording should be stronger. Instead of saying 'This =
document is primarily intended for use in IPv6 cellular networks' it =
should say 'The solution provided in this document is incompatible with =
multicast RA networks and therefore primarily intended for use in =
non-multicast networks like IPv6 cellular networks'.
>=20
> Or something like that=85
> Sander
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From ichiroumakino@gmail.com  Tue Dec 13 05:43:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C499C21F856F; Tue, 13 Dec 2011 05:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.494
X-Spam-Level: 
X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105,  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 vp0iavrISYVL; Tue, 13 Dec 2011 05:43:41 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC5CF21F850E; Tue, 13 Dec 2011 05:43:40 -0800 (PST)
Received: by laah2 with SMTP id h2so1843047laa.31 for ; Tue, 13 Dec 2011 05:43:39 -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=EihaxB69AXfNWUOG4deOdbmxaBba+Ts7dpvYH0gaDG0=; b=M4+Pdc4ouIRaVG6u7hn0DMAuLOnybqRQhWKPlE8haOVV1fyUYSUcfFDVY99vJrxBVa ZBD5KX4xqFOYUklzOrPV9pZ75Os+JQA37zWJHCUtnqxVPFFwY6LxqNjmpAY+4tas0DOu yXCninHuet4BGw9fWbOELqJmvpI71Hhr/RJKs=
Received: by 10.152.108.239 with SMTP id hn15mr15124153lab.44.1323783819802; Tue, 13 Dec 2011 05:43:39 -0800 (PST)
Received: from [10.147.13.198] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id nw10sm20056266lab.4.2011.12.13.05.43.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Dec 2011 05:43:37 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
Date: Tue, 13 Dec 2011 14:43:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl>
To: Sander Steffann 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 13:43:47 -0000

Sander,

>> So that the pd-exclude is NOT used in the multicast RA network =
because the pd-exclude document is useless in the multicast network that =
has to go back to RFC 3633 behavior.  One author said in an email =
related to the pd-exclude that the pd-exclude problem applies to all =
networks.   But then the solution to the problem does not work in a =
multicast RA network for PD acquisition.   The statement should be made =
so folks know this document is unable to solve the problem in a =
multicast RA network.  I have gone hoarse trying to explain this issue.
>=20
> In that case the wording should be stronger. Instead of saying 'This =
document is primarily intended for use in IPv6 cellular networks' it =
should say 'The solution provided in this document is incompatible with =
multicast RA networks and therefore primarily intended for use in =
non-multicast networks like IPv6 cellular networks'.

I have an issue with terminology used here, (even though I might guess =
at what you are trying to say.)
the RA sent on a cellular network or any other access technology may of =
course be a multicast packet, regardless of PD exclude or not.

the issue is _if_ one wants to use the excluded prefix on the link-net =
between the CE and the PE, then it would only make sense to do that in =
cases where you have L2 isolation between CEs. in cases where all the =
CEs sit in the same broadcast domain, that combination doesn't work =
well.=20

cheers,
Ole=

From sander@steffann.nl  Tue Dec 13 05:59:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC821F88B7; Tue, 13 Dec 2011 05:59:11 -0800 (PST)
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.000,  BAYES_00=-2.599, 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 mSY5scXiNJj9; Tue, 13 Dec 2011 05:59:10 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49521F850B; Tue, 13 Dec 2011 05:59:03 -0800 (PST)
Received: from [10.253.253.9] (unknown [193.176.191.19]) by mail.sintact.nl (Postfix) with ESMTP id B377C204E; Tue, 13 Dec 2011 14:59:01 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Sander Steffann 
In-Reply-To: 
Date: Tue, 13 Dec 2011 14:59:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A8EE69F-F340-4DF8-ABFF-B74C0B4129C9@steffann.nl>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1251.1)
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 13:59:11 -0000

Hi Ole,

> I have an issue with terminology used here, (even though I might guess =
at what you are trying to say.)

I must admit that I exaggerated a bit :-)  I think that Jouni took my =
meaning and used better words for it..

Thanks,
Sander


From shemant@cisco.com  Tue Dec 13 08:51:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1205E21F85B9; Tue, 13 Dec 2011 08:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level: 
X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079,  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 6PVrC6QTcQLu; Tue, 13 Dec 2011 08:51:26 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2193021F84D5; Tue, 13 Dec 2011 08:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1534; q=dns/txt; s=iport; t=1323795085; x=1325004685; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TOx2siZtdKTFKmDr3WSLI/fLLeC9/Z5kuKSxBADqBGc=; b=ZTrKfDKKgU4YmO0trL75cYIWIHiPJs1npS+iPOuF+9nPz0rR5Kd+55Cj Crfi1k+W4cxsUw231WqpA93vRLqdVSICNIDc4NXuFifcPAYI7u374reWg u42RFGjj9t7cTY67VofOyifoVsplDKFd3t9mgWlujkuYV2Yd/0RXTJCuS 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcAAFOB506tJXG9/2dsb2JhbABDmlWQUIEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIEwefNgGeL4sFYwSIMJcth1w
X-IronPort-AV: E=Sophos;i="4.71,346,1320624000"; d="scan'208";a="43580826"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 13 Dec 2011 16:51:21 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBDGpLqH008162;  Tue, 13 Dec 2011 16:51:21 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 13 Dec 2011 10:51:21 -0600
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 Dec 2011 10:51:20 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com>
In-Reply-To: <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] draft-ietf-dhc-pd-exclude
Thread-Index: Acy5gya9lcJddsGzQkez0hyUH1GKxQAMzbxg
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com>
From: "Hemant Singh (shemant)" 
To: "Jouni" , "Sander Steffann" 
X-OriginalArrivalTime: 13 Dec 2011 16:51:21.0155 (UTC) FILETIME=[70EBB130:01CCB9B7]
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 16:51:27 -0000

Jouni,

Removing "cellular" from the text is fine by me.  The text I prefer is
"The solution provided in this document is intended for use in networks
with point to point semantics between the RR and the DR including use of
the unicast RA."=20

The semantics definitely include DHCPv6 and the pd-exclude option but it
may be mistaken that the new option is good for use both in the unicast
RA and the multicast RA network.  Thus it's best to preserve the keyword
of "unicast RA".  One document I can find on the unicast RA is rfc6085.

Thanks,

Hemant

-----Original Message-----
From: Jouni [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 13, 2011 5:37 AM
To: Sander Steffann
Cc: Hemant Singh (shemant); v6ops@globis.net; v6ops@ietf.org;
v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude


Hi,

I would not say "incompatible", since whether using something makes
sense in certain deployment is different that incompatible. You don't
turn on pd-exclude by accident like in broadcast access networks you do
not turn on RFC6085 by accident (excluding misconfiguration). Also, I do
not like pointing cellular networks here as the example case; pd-exclude
applies to deployments where you have 1:1 pipes between RR and DR (e.g.
VLANs, point to point links or other tweaks to mimic such behavior).
So, I would prefer wording like "The solution provided in this document
is intended for use in networks with point to point semantics between
the RR and the DR."

- Jouni







From brian.e.carpenter@gmail.com  Tue Dec 13 14:24:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A7321F85A7 for ; Tue, 13 Dec 2011 14:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.289
X-Spam-Level: 
X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 NMwZAp4iwOCg for ; Tue, 13 Dec 2011 14:24:12 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C048321F8541 for ; Tue, 13 Dec 2011 14:24:11 -0800 (PST)
Received: by eaad1 with SMTP id d1so170290eaa.31 for ; Tue, 13 Dec 2011 14:24:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tfH5lW1jNKfOwKzDcmfKljJIU0TEyT1xeOXLKT0ml0M=; b=CgcCIXrnFbAyjNznZZaTaxcBlocDTV8DZbS/+rqpeeGasFGM7ykJHuAZoFxOUQorR6 SyM/nrwJjLSOo0DjRJLTc7pbY+Z/EqsayJ0D8nIYAuo92Oa7f+LysisiXSOKWVgTQCNC 4+SLHz/c7dKNG40fzOG6Rj+rgn3NQQyAQgopA=
Received: by 10.205.138.5 with SMTP id iq5mr14697655bkc.76.1323815050875; Tue, 13 Dec 2011 14:24:10 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id w3sm1121574bkq.3.2011.12.13.14.24.08 (version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 14:24:10 -0800 (PST)
Message-ID: <4EE7D085.3000407@gmail.com>
Date: Wed, 14 Dec 2011 11:24:05 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "George, Wes" 
References: <4EDD4786.30500@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations 
Subject: Re: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-guidance-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Dec 2011 22:24:12 -0000

Hi Wes,

Thanks for the comments. A few responses in line; otherwise we
will cover your points in the next version.

On 2011-12-13 04:07, George, Wes wrote:
> A couple of comments -
> 
> Section 3 - there's a timing aspect to training. If staff are
> trained too far in advance of deployment, they forget
> everything before they have a chance to apply it. Training
> has a definite need to be done "just in time" in order to
> properly "stick."

Agreed


> In section 11, regarding IPv4 and IPv6 interdependence of
> Ops/Mgmt, a couple of points worth making here. You refer to
> them somewhat generally, but I bring these up because I think
> they're important to make more explicitly: 1) Monitoring
> systems must have a way to validate the IPv4 and IPv6 SLA and
> performance independently, so that if the network is set up
> as you suggest, where IPv4 could have a failure that does not
> affect IPv6 or vice versa, the operator is aware that one of
> the two address-families is having an issue. Often the
> tendency is to assume that since things are taking the same
> path, that if one is working, so is the other. A good example
> of where this assumption fails is covered in
> draft-hsingh-6man-enhanced-dad-03, where DAD may leave you
> with a functional IPv4 stack but dead IPv6. 

Agreed

> 2) It's worth
> explicitly stating that the end goal is to have a network
> that does not have to have major changes made to it when at
> some point in the future it becomes possible to transition to
> IPv6-only, even if only for some parts of the network. That
> is, if the IPv6 deployment is architected in such a way as to
> more or less assume that IPv4 is not present, then the
> network will function seamlessly when it is indeed no longer
> there. 

Yes, that's always been my understanding of why "ships in the
night" is the best approach, but of course there's going to be
some back office system that breaks this principle.

> - Dual stack, while necessary, does have scaling and
> management overhead considerations, so if it's reasonably
> trivial to move to single-stack IPv6 (as the network and its
> customers can support such), that might be worth recommending
> in this section. You do note that it should be possible to
> access devices having problems on one address-family using
> the other (assumedly functional) AF, but I think this goes a
> step further along that line of logic.

That would sort of imply that the recommendations would run
backwards at a later stage (e.g. use an HTTP proxy to connect
IPv4 clients to IPv6-only servers). We could certainly suggest
that, although I doubt if ICPs will be thinking about this very
soon.

Thanks

    Brian
> 
> Thanks,
> 
> Wes George
> 
>> -----Original Message----- From: v6ops-bounces@ietf.org
>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E
>> Carpenter Sent: Monday, December 05, 2011 5:37 PM To: IPv6
>> Operations Subject: [v6ops] Requesting reviews of
>> draft-carpenter-v6ops-icp- guidance-01.txt
>> 
>> Hi,
>> 
>> This has been updated following the comments received so
>> far. As discussed in Taipei, we are requesting reviews from
>> the WG. Additional authors with personal expertise would be
>> welcome too.
>> 
>> Brian and Sheng.
>> 
>> -------- Original Message -------- Subject: I-D Action:
>> draft-carpenter-v6ops-icp-guidance-01.txt Date: Mon, 05 Dec
>> 2011 14:33:13 -0800 From: internet-drafts@ietf.org 
>> Reply-To: internet-drafts@ietf.org To:
>> i-d-announce@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> 
>> Title           : IPv6 Guidance for Internet Content and 
>> Application Service Providers Author(s)       : Brian
>> Carpenter Sheng Jiang Filename        :
>> draft-carpenter-v6ops-icp-guidance-01.txt Pages           :
>> 16 Date            : 2011-12-05
>> 
>> This document provides guidance and suggestions for
>> Internet Content Providers and Application Service
>> Providers who wish to offer their service to both IPv6 and
>> IPv4 customers.
>> 
>> 
>> A URL for this Internet-Draft is: 
>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-
>>  01.txt
>> 
>> 
>> _______________________________________________ v6ops
>> mailing list v6ops@ietf.org 
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> This E-mail and any of its attachments may contain Time
> Warner Cable proprietary information, which is privileged,
> confidential, or subject to copyright belonging to Time
> Warner Cable. This E-mail is intended solely for the use of
> the individual or entity to which it is addressed. If you are
> not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments
> to this E-mail is strictly prohibited and may be unlawful. If
> you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and
> any copy of this E-mail and any printout.
> 

From brian.e.carpenter@gmail.com  Tue Dec 13 17:21:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17C221F8AB9 for ; Tue, 13 Dec 2011 17:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.28
X-Spam-Level: 
X-Spam-Status: No, score=-103.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 5fP7H2uFpIdl for ; Tue, 13 Dec 2011 17:21:36 -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 10C5721F8485 for ; Tue, 13 Dec 2011 17:21:35 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so444437wgb.13 for ; Tue, 13 Dec 2011 17:21:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JmQNt6Di916unH0ABnUnmbiGQX8jXzkZ46+ANcEwH9o=; b=jUtAOJmMOoCIuNh27jIDBJdLfXxJbY5nxu3JSXwG3bKnxrS6NUURpuzqBwddNo7PDS K9AqOOOYRf1XWdECcmzKwejz0mu0HH/gqxrzF8numbEPR0K4BicDuUql9DJBqPGzmGpM F+ZP3iccVfxfdqaSVS58ccFTAV/vZrcwcK9r8=
Received: by 10.227.59.204 with SMTP id m12mr628791wbh.10.1323825691031; Tue, 13 Dec 2011 17:21:31 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id u5sm1311692wbm.2.2011.12.13.17.21.28 (version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 17:21:30 -0800 (PST)
Message-ID: <4EE7FA27.2030409@gmail.com>
Date: Wed, 14 Dec 2011 14:21:43 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com>
In-Reply-To: <20111207140615.6706.64255.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 01:21:37 -0000

Hi Ole and Mark,

I'm not sure where this should be discussed, so I picked v6ops for now.

>    MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
>           associated delegated prefixes.  Each entry points to one or
>           more DRIBs.  An entry points to multiple DRIBs only in the
>           case where an identical delegated prefix is associated with
>           multiple WAN interfaces.

I am quite bothered by the second sentence. It seems to assume that
ingress filtering is inevitable, but this is very restrictive as far
as seamless multihoming goes. If we can one day get to a situation
where ingress filtering is automatically tailored for multihomed customers,
we will need each SRIB entry to point to multiple DRIBs accordingly.
At least, qualify it by saying something like

   A prefix is considered to be associated with a WAN interface either
   if it is delegated via that interface, or if it is known that it is
   accepted by complete ingress filtering applied to that interface
   (section 4.2 of [RFC3704]).

Regards
   Brian Carpenter

On 2011-12-08 03:06, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Basic Requirements for IPv6 Customer Edge Routers - multihoming and transition
> 	Author(s)       : Mark Townsley
>                           Ole Troan
> 	Filename        : draft-townsley-troan-ipv6-ce-transitioning-00.txt
> 	Pages           : 5
> 	Date            : 2011-12-07
> 
>    This document specifies general IPv6 multihoming and specific 6rd
>    transitioning requirements for an IPv6 Customer Edge (CE) router.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-townsley-troan-ipv6-ce-transitioning-00.txt

From lorenzo@google.com  Tue Dec 13 19:44:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFFC11E8089 for ; Tue, 13 Dec 2011 19:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.915
X-Spam-Level: 
X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tLIMt5wUlP6Q for ; Tue, 13 Dec 2011 19:44:04 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7381C11E8096 for ; Tue, 13 Dec 2011 19:44:04 -0800 (PST)
Received: by ggnk5 with SMTP id k5so354776ggn.31 for ; Tue, 13 Dec 2011 19:43:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=5gKkM/LCt6pu2/mR1HKl9t//NiNiRy7nXnj+1ggFWXA=; b=CvSdrcvjjPAM9PuVcSfsl/WIbyMKmTA5O3t4+o4OYhKKuOlmC2FhudijnYkMi+SqCj fk4DtyXFnuoXxSXU/Qlg==
Received: by 10.182.49.66 with SMTP id s2mr562603obn.58.1323834239421; Tue, 13 Dec 2011 19:43:59 -0800 (PST)
Received: by 10.182.49.66 with SMTP id s2mr562591obn.58.1323834239269; Tue, 13 Dec 2011 19:43:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.0.11 with HTTP; Tue, 13 Dec 2011 19:43:38 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com>
From: Lorenzo Colitti 
Date: Tue, 13 Dec 2011 19:43:38 -0800
Message-ID: 
To: "Hemant Singh (shemant)" 
Content-Type: multipart/alternative; boundary=f46d044630da92bb7904b4052d05
X-System-Of-Record: true
Cc: v6ops@globis.net, v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 03:44:05 -0000

--f46d044630da92bb7904b4052d05
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 13, 2011 at 08:51, Hemant Singh (shemant) wrote:

> The semantics definitely include DHCPv6 and the pd-exclude option but it
> may be mistaken that the new option is good for use both in the unicast
> RA and the multicast RA network.  Thus it's best to preserve the keyword
> of "unicast RA".  One document I can find on the unicast RA is rfc6085.
>

Hemant, I think you're using the wrong terminology. As Ole says, where you
say "multicast RA" you should say "a deployment where multiple CEs are on a
shared layer 2 domain" (e.g., the N:1 model) and where you say "unicast RA"
you should instead say "with a deployment where each CEs is on its own
layer 2 domain".

--f46d044630da92bb7904b4052d05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Dec 13, 2011 at 08:51, Hemant Singh (she=
mant) <shemant@ci=
sco.com> wrote:


The semantics definitely include DHCPv6 and the pd-exclude option but it
may be mistaken that the new option is good for use both in the unicast

RA and the multicast RA network. =A0Thus it's best to preserve the keyw=
ord

of "unicast RA". =A0One document I can find on the unicast RA is =
rfc6085.

Hemant, I think you're usi=
ng the wrong terminology. As Ole says, where you say "multicast RA&quo=
t; you should say "a deployment where multiple CEs are on a shared lay=
er 2 domain" (e.g., the N:1 model) and where you say "unicast RA&=
quot; you should instead say "with a deployment where each CEs is on i=
ts own layer 2 domain".





--f46d044630da92bb7904b4052d05--

From ichiroumakino@gmail.com  Wed Dec 14 00:50:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F2821F8B14 for ; Wed, 14 Dec 2011 00:50:14 -0800 (PST)
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.199, BAYES_00=-2.599, J_CHICKENPOX_13=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 ARVta-tQQtAa for ; Wed, 14 Dec 2011 00:50:14 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9521F8A7B for ; Wed, 14 Dec 2011 00:50:13 -0800 (PST)
Received: by faas1 with SMTP id s1so1038892faa.31 for ; Wed, 14 Dec 2011 00:50:13 -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=wPMyN738Qx0FcjXW7hCeLcaODi1Nki83Cw9UOYsvluU=; b=U5v6iAfaMC2NqgklCvfEh+AoKe1PFOsTJ8Crchw/fl0KLGe5OV9EQ1u7Up6rcdQd05 UM9qLQ2ld1myg/g6PMXUjn+rk93LscAkK6k48LEn0duPuGL8FbC3tWNnXegckT1w3SsS hbJuEKdghj2ve4rDCGHdgA3tIQmiL7dOsjp8g=
Received: by 10.180.106.3 with SMTP id gq3mr2862890wib.34.1323852612955; Wed, 14 Dec 2011 00:50:12 -0800 (PST)
Received: from [10.147.13.198] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ca18sm2412298wib.13.2011.12.14.00.50.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Dec 2011 00:50:11 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <4EE7FA27.2030409@gmail.com>
Date: Wed, 14 Dec 2011 09:50:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 08:50:15 -0000

Brian,

> I'm not sure where this should be discussed, so I picked v6ops for =
now.

probably as good as anything. one of homenet, intarea, 6man, v6ops... =
;-)

>>   MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
>>          associated delegated prefixes.  Each entry points to one or
>>          more DRIBs.  An entry points to multiple DRIBs only in the
>>          case where an identical delegated prefix is associated with
>>          multiple WAN interfaces.
>=20
> I am quite bothered by the second sentence. It seems to assume that
> ingress filtering is inevitable, but this is very restrictive as far
> as seamless multihoming goes. If we can one day get to a situation
> where ingress filtering is automatically tailored for multihomed =
customers,
> we will need each SRIB entry to point to multiple DRIBs accordingly.
> At least, qualify it by saying something like
>=20
>   A prefix is considered to be associated with a WAN interface either
>   if it is delegated via that interface, or if it is known that it is
>   accepted by complete ingress filtering applied to that interface
>   (section 4.2 of [RFC3704]).

perhaps we should qualify that this applies to PA addressing, and =
multi-homing without the ISP's involvement?

if the ISPs exchanged routing information/RFC2260 (required for the =
return-path) and opened up for ingress filtering for each others =
prefixes... is there a use case for that, or are we in PI territory?

in the case of a link to ISP A was down, the CPE could of course forward =
traffic with SA =3D ISP A out ISP B's link. if it was stopped by ingress =
filtering the host would get an ICMP back from the PE instead of the =
CPE.

cheers,
Ole=

From jouni.nospam@gmail.com  Wed Dec 14 01:22:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1401E21F8B24 for ; Wed, 14 Dec 2011 01:22:30 -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 YeZpHALVv9g8 for ; Wed, 14 Dec 2011 01:22:29 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 607C221F8B1D for ; Wed, 14 Dec 2011 01:22:29 -0800 (PST)
Received: by eeke49 with SMTP id e49so525830eek.31 for ; Wed, 14 Dec 2011 01:22:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=2P189mO+y178ZSGWnj534hEkjopVPtBN+JsAhvSGeDM=; b=tSQhZRBcpxLwukRb7YiMFWdXhsDLiQdb4ghuX/cS5Zw4ZDLDxpYogYIEEjg2NoH5F4 PYUSajX8OedqzuRi0mG5Sp4lIlSflVhMlAe+UJu+FKrlus5wi1N/MRhc8iV5bnEE4S8S ihlRs1bhUiMwTdJJVyhWv6gSCFABasMCChamQ=
Received: by 10.213.17.198 with SMTP id t6mr378784eba.13.1323854548489; Wed, 14 Dec 2011 01:22:28 -0800 (PST)
Received: from [10.45.197.110] ([188.238.197.110]) by mx.google.com with ESMTPS id j20sm8013252eej.8.2011.12.14.01.22.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Dec 2011 01:22:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: jouni korhonen 
In-Reply-To: 
Date: Wed, 14 Dec 2011 11:22:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73C15E41-A377-4094-86BD-62B4BD9E8AB6@gmail.com>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com> 
To: "v6ops@ietf.org Operations" 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 09:22:30 -0000

Using Lorenzo's proposed wording:

"The solution provided in this document is intended for use in networks =
where each RR is on its own layer 2 domain."

Any better?

- Jouni


On Dec 14, 2011, at 5:43 AM, Lorenzo Colitti wrote:

> On Tue, Dec 13, 2011 at 08:51, Hemant Singh (shemant) =
 wrote:
> The semantics definitely include DHCPv6 and the pd-exclude option but =
it
> may be mistaken that the new option is good for use both in the =
unicast
> RA and the multicast RA network.  Thus it's best to preserve the =
keyword
> of "unicast RA".  One document I can find on the unicast RA is =
rfc6085.
>=20
> Hemant, I think you're using the wrong terminology. As Ole says, where =
you say "multicast RA" you should say "a deployment where multiple CEs =
are on a shared layer 2 domain" (e.g., the N:1 model) and where you say =
"unicast RA" you should instead say "with a deployment where each CEs is =
on its own layer 2 domain".


From gert@space.net  Wed Dec 14 02:06:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425021F8B12 for ; Wed, 14 Dec 2011 02:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level: 
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096,  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 Dt9A1fR3rs-x for ; Wed, 14 Dec 2011 02:06:28 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 104EC21F8A69 for ; Wed, 14 Dec 2011 02:06:27 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 8C977F896E for ; Wed, 14 Dec 2011 11:06:24 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7A091F8965 for ; Wed, 14 Dec 2011 11:06:24 +0100 (CET)
Received: (qmail 3089 invoked by uid 1007); 14 Dec 2011 11:06:24 +0100
Date: Wed, 14 Dec 2011 11:06:24 +0100
From: Gert Doering 
To: Ole Troan 
Message-ID: <20111214100624.GF72014@Space.Net>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 10:06:28 -0000

Hi,

On Wed, Dec 14, 2011 at 09:50:11AM +0100, Ole Troan wrote:
> in the case of a link to ISP A was down, the CPE could of course forward traffic with SA = ISP A out ISP B's link. if it was stopped by ingress filtering the host would get an ICMP back from the PE instead of the CPE.

Would it?

ISP B's PE has no route to send ISP A's prefix to that CPE, so how would
the ICMP reach the host?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From sander@steffann.nl  Wed Dec 14 03:27:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84B921F8B0C for ; Wed, 14 Dec 2011 03:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.252
X-Spam-Level: **
X-Spam-Status: No, score=2.252 tagged_above=-999 required=5 tests=[AWL=-0.638,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_EQ_IP_ADDR=1.119, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kBTQS7ZfHNb for ; Wed, 14 Dec 2011 03:27:39 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66421F8B03 for ; Wed, 14 Dec 2011 03:27:38 -0800 (PST)
Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id E6B10207B; Wed, 14 Dec 2011 12:27:36 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_18E19A7C-94A8-4B9F-B301-24DBFE4FDEC6"; protocol="application/pkcs7-signature"; micalg=sha1
From: Sander Steffann 
In-Reply-To: <73C15E41-A377-4094-86BD-62B4BD9E8AB6@gmail.com>
Date: Wed, 14 Dec 2011 12:27:35 +0100
Message-Id: <265AF202-ECDD-46D9-959F-193D73129FBA@steffann.nl>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com>  <73C15E41-A377-4094-86BD-62B4BD9E8AB6@gmail.com>
To: jouni korhonen 
X-Mailer: Apple Mail (2.1251.1)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 11:27:39 -0000

--Apple-Mail=_18E19A7C-94A8-4B9F-B301-24DBFE4FDEC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

> "The solution provided in this document is intended for use in =
networks where each RR is on its own layer 2 domain."
>=20
> Any better?

Much better :-)
Sander


--Apple-Mail=_18E19A7C-94A8-4B9F-B301-24DBFE4FDEC6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw
ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk
b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD
QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4
MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g
U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy
QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh
X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez
7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID
AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W
HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw
Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO
TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK
TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny
oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu
bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn
mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1
/SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL
RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O
VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE
74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr
A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX
Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr
kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk
DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV
BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB
AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMTEyMTQxMTI3MzdaMCMGCSqGSIb3DQEJBDEWBBToNQy9hdTattSzAbMnrtNUzZLANjCBigYJ
KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK
EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN
AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M
MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN
IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG
SIb3DQEBAQUABIGAtyGLmvr1YQoIw4ay2Mtm1a5JH+OR/t7yeAADS0HSsUWk0zZG7L11iglUcbBp
FBR6hSkWhh4WBnIc4KzzTVXQEYPrZTpKr57djSkAbCInC32EUNvIZKIw/UmprgxyT0kSQ6jNY8U6
M3geVVrSJVAQ+IiUEzZEa4CdQybQY4fDVqsAAAAAAAA=

--Apple-Mail=_18E19A7C-94A8-4B9F-B301-24DBFE4FDEC6--

From ichiroumakino@gmail.com  Wed Dec 14 05:40:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74A321F8B2B for ; Wed, 14 Dec 2011 05:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.49
X-Spam-Level: 
X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109,  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 xCpyLXPCKoKP for ; Wed, 14 Dec 2011 05:40:56 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6CA21F8A6C for ; Wed, 14 Dec 2011 05:40:56 -0800 (PST)
Received: by faas1 with SMTP id s1so1360745faa.31 for ; Wed, 14 Dec 2011 05:40:54 -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=+IiexODQNq4O0uJOZweYkAkVkZDX4rXT7tSakVQulYk=; b=uBnGtCdY5rLHAKm6+FXGlVvWdQRlDwj3DONJ6ucNafbgPZz9xQHb7yW1lrEJ+VyF4z 12EXt+vYxGGOwPiZaq2vEb67z0ZaR93qPCmAqYIDUc9QBdCVEgqqYl5l9Q2gAygBac4w 1OlpuNhVUlXj7QFMFYtSMXx09SRuLdcMgJ52s=
Received: by 10.180.6.71 with SMTP id y7mr4709096wiy.67.1323870053992; Wed, 14 Dec 2011 05:40:53 -0800 (PST)
Received: from [10.147.13.198] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z5sm3511175wix.5.2011.12.14.05.40.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Dec 2011 05:40:51 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <20111214100624.GF72014@Space.Net>
Date: Wed, 14 Dec 2011 14:40:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 13:40:57 -0000

Gert,

>> in the case of a link to ISP A was down, the CPE could of course =
forward traffic with SA =3D ISP A out ISP B's link. if it was stopped by =
ingress filtering the host would get an ICMP back from the PE instead of =
the CPE.
>=20
> Would it?
>=20
> ISP B's PE has no route to send ISP A's prefix to that CPE, so how =
would
> the ICMP reach the host?

good point.

OK, for auto-detection of ingress filtering. we could use "BFD echo =
mode". like what we do for 6rd BR reachability check.
the CPE generates a packet with SA =3D DA =3D one of its own addresses =
from ISP A. this packet it forwards to the ISP B.

cheers,
Ole=

From gert@space.net  Wed Dec 14 05:50:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EC621F8B40 for ; Wed, 14 Dec 2011 05:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088,  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 C7ta+f1611+c for ; Wed, 14 Dec 2011 05:50:25 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B73321F8A7E for ; Wed, 14 Dec 2011 05:50:24 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 94940F8972 for ; Wed, 14 Dec 2011 14:50:23 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 80C84F895E for ; Wed, 14 Dec 2011 14:50:23 +0100 (CET)
Received: (qmail 66924 invoked by uid 1007); 14 Dec 2011 14:50:23 +0100
Date: Wed, 14 Dec 2011 14:50:23 +0100
From: Gert Doering 
To: Ole Troan 
Message-ID: <20111214135023.GN72014@Space.Net>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net> <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xckK/iGhmv//OAJ0"
Content-Disposition: inline
In-Reply-To: <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 13:50:26 -0000

--xckK/iGhmv//OAJ0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Dec 14, 2011 at 02:40:50PM +0100, Ole Troan wrote:
> OK, for auto-detection of ingress filtering. we could use "BFD echo mode"=
=2E like what we do for 6rd BR reachability check.
> the CPE generates a packet with SA =3D DA =3D one of its own addresses fr=
om ISP A. this packet it forwards to the ISP B.

Yep, that would work (just don't call it "BFD anything" as people - like=20
me, before re-reading - would assume that it needs BFD to be enabled on=20
the ISP side).

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--xckK/iGhmv//OAJ0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTuipn6kuBuNlUUl1AQL9KwQArWJFruahvVC5I+JM+ff5E2HxAFBgELAJ
Z29Y87z5vUilenTfiumYmO0+MbMZzNgNjAA6Wxyt6rQeIpBh6uAi1/uvfMn04kOf
MrkK4kvY+HtSdmTG3GbAkNrpYYXscTCowWiQ5dlAKaAKDJXEPLsaiE15KnHXF/ss
BpSD2YZhho4=
=ASvx
-----END PGP SIGNATURE-----

--xckK/iGhmv//OAJ0--

From mark@townsley.net  Wed Dec 14 09:27:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D5B21F8B26 for ; Wed, 14 Dec 2011 09:27:25 -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.188,  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 UGKHDt16EneE for ; Wed, 14 Dec 2011 09:27:25 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3AC21F850B for ; Wed, 14 Dec 2011 09:27:24 -0800 (PST)
Received: by faas1 with SMTP id s1so1663505faa.31 for ; Wed, 14 Dec 2011 09:27:23 -0800 (PST)
Received: by 10.180.73.193 with SMTP id n1mr6758635wiv.1.1323883643732; Wed, 14 Dec 2011 09:27:23 -0800 (PST)
Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id bl10sm4467522wib.15.2011.12.14.09.27.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Dec 2011 09:27:22 -0800 (PST)
From: Mark Townsley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Dec 2011 18:27:20 +0100
Message-Id: 
To: "v6ops@ietf.org Operations" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 17:27:25 -0000

Folks,

We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20

The requirements in RFC 6204 are based on a fundamental assumption that =
a CE router has a single active WAN interface for forwarding IPv4 and =
IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)=20
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20=


Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no =
problem when enabling one vs. the other.=20

For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an =
existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20

I'd like to identify two strategies to deal with these situations.=20

The first I will call "configuration-oriented". For this to work, one of =
the following assumptions must hold. None are pretty, but you MUST pick =
one to avoid solving how to forward traffic when multiple interfaces are =
enabled at the same time for a given IP version.=20

 (a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or=20

 (b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or

 (c) The CE router goes through an ordered set of configuration attempts =
in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20

 (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.

The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally accepts packets on WAN =
ingress. This is "classic multihoming" and should work for any order of =
planned incremental transition steps, as well as failover and/or =
transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began =
adopting some of the "forwarding-based" requirements for IPv6, though =
DS-Lite remained in the "configuration-based" role for IPv4.=20

Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know =
if people understand and agree with the basic premise here, and if so =
whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20

Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,

- Mark

From lorenzo@google.com  Wed Dec 14 10:26:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AAB21F8AFD for ; Wed, 14 Dec 2011 10:26:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.916
X-Spam-Level: 
X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hfFZE-ONhat7 for ; Wed, 14 Dec 2011 10:26:43 -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 6BF0521F8AFB for ; Wed, 14 Dec 2011 10:26:43 -0800 (PST)
Received: by iaek3 with SMTP id k3so1918550iae.31 for ; Wed, 14 Dec 2011 10:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sLZ4TdWtWc/IPpjBfR436mld8LHVjMAjMqdQf+01vzc=; b=K1oVrN3DRj6Txwho1L5E4UVs5rvDSmZSKCi14BGxLYlepk281BoHGx1IYdKHF/MpbK dbVJZ+FD/OCic1Zlkurg==
Received: by 10.50.157.135 with SMTP id wm7mr1460170igb.39.1323887203098; Wed, 14 Dec 2011 10:26:43 -0800 (PST)
Received: by 10.50.157.135 with SMTP id wm7mr1460163igb.39.1323887202999; Wed, 14 Dec 2011 10:26:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.122.218 with HTTP; Wed, 14 Dec 2011 10:26:21 -0800 (PST)
In-Reply-To: 
References: 
From: Lorenzo Colitti 
Date: Wed, 14 Dec 2011 10:26:21 -0800
Message-ID: 
To: Mark Townsley 
Content-Type: multipart/alternative; boundary=e89a8f235949751f4e04b41182ef
X-System-Of-Record: true
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 18:26:44 -0000

--e89a8f235949751f4e04b41182ef
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Dec 14, 2011 at 09:27, Mark Townsley  wrote:

> Mostly I would like to know if people understand and agree with the basic
> premise here, and if so whether "configuration-oriented" or
> "forwarding-oriented" is the best way forward.


Since you forgot to put your homenet chair hat on, I'll note that homenet
has at least expressed a desire (if not a requirement) to be able to
support multihoming, and for multihoming to function properly, routers need
to be able to do source-based forwarding. So going with the forwarding
strategy will help homenet achieve its goals too.

--e89a8f235949751f4e04b41182ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Dec 14, 2011 at 09:27, Mark Townsley <mark@townsley.net> wrote:


Mostly I would like to know if people understand and agree with the basic p=
remise here, and if so whether "configuration-oriented" or "=
forwarding-oriented" is the best way forward.




Since you forgot to put your homenet chair hat on, I'll note=
 that homenet has at least expressed a desire (if not a requirement) to be =
able to support multihoming, and for multihoming to function properly,=A0ro=
uters need to be able to do source-based forwarding. So going with the forw=
arding strategy will help homenet achieve its goals too.





--e89a8f235949751f4e04b41182ef--

From brian.e.carpenter@gmail.com  Wed Dec 14 11:57:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC5111E80A0 for ; Wed, 14 Dec 2011 11:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.628
X-Spam-Level: 
X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 rsv1o8KA0o8L for ; Wed, 14 Dec 2011 11:57:17 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6185211E8083 for ; Wed, 14 Dec 2011 11:57:17 -0800 (PST)
Received: by eaad1 with SMTP id d1so1290161eaa.31 for ; Wed, 14 Dec 2011 11:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NAyUhNA26KxEN64sYu6ij44wjTplW2egspIo3PAniGU=; b=MWsxXZpKYsWDPLo9bubJWvaRuxBIC/KWT8l89ed9qNVuBr0P/yvnN6TtNybSbDoazR UyKjwL+Ad+97zh/PBSTEFPjSCkTYi4xfRDrYp+pr2+EJrj/zkVkFepmtmqPJ+H3zjDvv MrktA/J/YZ0J9dyHZlV/gIrhgqZC85mJ944dI=
Received: by 10.204.147.194 with SMTP id m2mr54803bkv.22.1323892636562; Wed, 14 Dec 2011 11:57:16 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q6sm8621734bka.6.2011.12.14.11.57.12 (version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 11:57:15 -0800 (PST)
Message-ID: <4EE8FF91.3010800@gmail.com>
Date: Thu, 15 Dec 2011 08:57:05 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Gert Doering 
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net> <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org> <20111214135023.GN72014@Space.Net>
In-Reply-To: <20111214135023.GN72014@Space.Net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 19:57:18 -0000

On 2011-12-15 02:50, Gert Doering wrote:
> Hi,
> 
> On Wed, Dec 14, 2011 at 02:40:50PM +0100, Ole Troan wrote:
>> OK, for auto-detection of ingress filtering. we could use "BFD echo mode". like what we do for 6rd BR reachability check.
>> the CPE generates a packet with SA = DA = one of its own addresses from ISP A. this packet it forwards to the ISP B.
> 
> Yep, that would work (just don't call it "BFD anything" as people - like 
> me, before re-reading - would assume that it needs BFD to be enabled on 
> the ISP side).

I found it quite interesting to read RFC3704 again. There are quite a few
things needed to make PA multihoming work properly, but my point was to
ensure that the ce-transitioning draft doesn't unintentionally break
this completely.

Incidentally, draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat
doesn't have a reference to RFC3704, and maybe it should.

    Brian

From brian.e.carpenter@gmail.com  Wed Dec 14 12:06:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB931F0C5D for ; Wed, 14 Dec 2011 12:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.626
X-Spam-Level: 
X-Spam-Status: No, score=-103.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 1HTo57NFZ++s for ; Wed, 14 Dec 2011 12:06:07 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E80761F0C4F for ; Wed, 14 Dec 2011 12:06:06 -0800 (PST)
Received: by eaad1 with SMTP id d1so1300262eaa.31 for ; Wed, 14 Dec 2011 12:06:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7ARnfQv0DPhNZb3QFaelu9VIYm8dSQiTZXL6C4ElMIA=; b=HObw1NGABHL15L++Xeb615V1f4oyF43uYfJAmC3Hsdytl2vTXVuHTT2wqVwby6TIxl NnV9JA9Y6ubpErOdZHq1hSzaWG6+fmfQofBftBdSHOfe5OKJM28iM1dID87ADIikBScV C2khQDRHt0USgjzFYU4qBUHZfTTUap2o2tNO8=
Received: by 10.204.130.90 with SMTP id r26mr37707bks.46.1323893166070; Wed, 14 Dec 2011 12:06:06 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id jf4sm8684950bkc.5.2011.12.14.12.06.02 (version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 12:06:05 -0800 (PST)
Message-ID: <4EE901A3.40205@gmail.com>
Date: Thu, 15 Dec 2011 09:05:55 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 20:06:07 -0000

On 2011-12-15 07:26, Lorenzo Colitti wrote:
> On Wed, Dec 14, 2011 at 09:27, Mark Townsley  wrote:
> 
>> Mostly I would like to know if people understand and agree with the basic
>> premise here, and if so whether "configuration-oriented" or
>> "forwarding-oriented" is the best way forward.
> 
> 
> Since you forgot to put your homenet chair hat on, I'll note that homenet
> has at least expressed a desire (if not a requirement) to be able to
> support multihoming, and for multihoming to function properly, routers need
> to be able to do source-based forwarding. So going with the forwarding
> strategy will help homenet achieve its goals too.

Agreed, and also

> The requirements in RFC 6204 are based on a fundamental assumption that a 
> CE router has a single active WAN interface for forwarding IPv4 and IPv6 
> traffic towards an ISP.

This overlooks the fact that multiple PA prefixes are by design a normal
way of doing business for a small IPv6 site that wants multihoming.
(Where 'small' means too small to justify a PI prefix.) That's not a bad
assumption for 6204 or even 6204bis, but 6204ter may need to deal with
this, and with the MIF/HOMENET/6RENUM/ipv6-multihoming-without-ipv6nat
scenarios.

    Brian

From jouni.nospam@gmail.com  Thu Dec 15 04:49:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02221F86A5 for ; Thu, 15 Dec 2011 04:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.508
X-Spam-Level: 
X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091,  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 YZH3eZV87YLj for ; Thu, 15 Dec 2011 04:49:32 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2318B21F86A1 for ; Thu, 15 Dec 2011 04:49:31 -0800 (PST)
Received: by laah2 with SMTP id h2so997254laa.31 for ; Thu, 15 Dec 2011 04:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PboR7NFnLmHiujFlUXxczHrKP6gfaKwU5lT2+sav2dg=; b=IPpnk+fa6u0l7e+e46C3Be2ZU2PNlImEhK/ZEPylQrx22GYBJd5ao1HUBZ3orXYkA/ 87pYyRQMMDJcPW98unDrunxQYsFAn6ruNTo25OWqeiaiWJX7Uj1XUPnVbsvnSNfS4OTO XGTAZdwHpSO/JDH6sS6LpOPLgfKcB/3CYaYpw=
Received: by 10.152.102.196 with SMTP id fq4mr2502705lab.26.1323953371106; Thu, 15 Dec 2011 04:49:31 -0800 (PST)
Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id pc8sm5257965lab.8.2011.12.15.04.49.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Dec 2011 04:49:29 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <265AF202-ECDD-46D9-959F-193D73129FBA@steffann.nl>
Date: Thu, 15 Dec 2011 14:49:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3038291E2@XMB-RCD-109.cisco.com> <20111209162751.GL72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C3038291F1@XMB-RCD-109.cisco.com> <20111209163935.GM72014@Space.Net> <5B6B2B64C9FE2A489045EEEADDAFF2C303829251@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30382943B@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3038298F6@XMB-RCD-109.cisco.com> <92DE244D-4F26-4CF9-98F0-2DB90CED4A43@steffann.nl> <00F796E0-82BE-4B26-8450-2BB42115B19A@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3038E528F@XMB-RCD-109.cisco.com>  <73C15E41-A377-4094-86BD-62B4BD9E8AB6@gmail.com> <265AF202-ECDD-46D9-959F-193D73129FBA@steffann.nl>
To: "v6ops@ietf.org Operations" 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 12:49:33 -0000

Right, I'll massage a new introduction text to pd-exclude based on the =
below sentence.

- Jouni


On Dec 14, 2011, at 1:27 PM, Sander Steffann wrote:

> Hi,
>=20
>> "The solution provided in this document is intended for use in =
networks where each RR is on its own layer 2 domain."
>>=20
>> Any better?
>=20
> Much better :-)
> Sander
>=20


From Tina.Tsou.Zouting@huawei.com  Thu Dec 15 14:30:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9987A11E80AA for ; Thu, 15 Dec 2011 14:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.233
X-Spam-Level: 
X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 pCzt8-DjkdhQ for ; Thu, 15 Dec 2011 14:30:15 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 78DF111E8080 for ; Thu, 15 Dec 2011 14:30:15 -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 <0LW9001IGNU8S8@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 16 Dec 2011 06:30:09 +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 <0LW900B7NNU8UJ@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 16 Dec 2011 06:30:08 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFV82001; Fri, 16 Dec 2011 06:30:08 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 06:30:01 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 16 Dec 2011 06:29:58 +0800
Date: Thu, 15 Dec 2011 22:29:58 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: Mark Townsley , "v6ops@ietf.org Operations" 
Message-id: 
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: [v6ops] Up-leveling Transition Coexistence
Thread-index: AQHMuoWtLIv9EMTPEUqfzMLkWVTTkJXde9CA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 22:30:16 -0000

Mark,
Thanks. It is very useful. 
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?

- Tina


-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs. 

The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc) 
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other. 

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.  

I'd like to identify two strategies to deal with these situations. 

The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version. 

 (a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or 

 (b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or

 (c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch. 

 (d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4. 

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-) 

Thanks, and Happy Holidays in advance to those who will be celebrating soon,

- Mark
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From mark@townsley.net  Fri Dec 16 00:26:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6F921F8A97 for ; Fri, 16 Dec 2011 00:26:54 -0800 (PST)
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 jw2mUXdenunr for ; Fri, 16 Dec 2011 00:26:53 -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 8E68421F8AA8 for ; Fri, 16 Dec 2011 00:26:53 -0800 (PST)
Received: by werb14 with SMTP id b14so353123wer.31 for ; Fri, 16 Dec 2011 00:26:52 -0800 (PST)
Received: by 10.216.138.201 with SMTP id a51mr3371445wej.24.1324024012463; Fri, 16 Dec 2011 00:26:52 -0800 (PST)
Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id m13sm13488402wbh.0.2011.12.16.00.26.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 00:26:51 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <4EE901A3.40205@gmail.com>
Date: Fri, 16 Dec 2011 09:26:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <4EE901A3.40205@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 08:26:54 -0000

On Dec 14, 2011, at 9:05 PM, Brian E Carpenter wrote:

> On 2011-12-15 07:26, Lorenzo Colitti wrote:
>> On Wed, Dec 14, 2011 at 09:27, Mark Townsley  =
wrote:
>>=20
>>> Mostly I would like to know if people understand and agree with the =
basic
>>> premise here, and if so whether "configuration-oriented" or
>>> "forwarding-oriented" is the best way forward.
>>=20
>>=20
>> Since you forgot to put your homenet chair hat on, I'll note that =
homenet
>> has at least expressed a desire (if not a requirement) to be able to
>> support multihoming, and for multihoming to function properly, =
routers need
>> to be able to do source-based forwarding. So going with the =
forwarding
>> strategy will help homenet achieve its goals too.
>=20
> Agreed, and also
>=20
>> The requirements in RFC 6204 are based on a fundamental assumption =
that a=20
>> CE router has a single active WAN interface for forwarding IPv4 and =
IPv6=20
>> traffic towards an ISP.
>=20
> This overlooks the fact that multiple PA prefixes are by design a =
normal
> way of doing business for a small IPv6 site that wants multihoming.
> (Where 'small' means too small to justify a PI prefix.) That's not a =
bad
> assumption for 6204 or even 6204bis, but 6204ter may need to deal with
> this, and with the MIF/HOMENET/6RENUM/ipv6-multihoming-without-ipv6nat
> scenarios.

It is not a bad assumption for 6204, as 6204 didn't step into the use of =
transition mechanisms. 6204 could have even gone as far as defining =
basic IPv6 via 6rd on a Native IPv4-only network, or IPv4 via DS-Lite on =
a Native IPv6-only network, without breaking the basic forwarding model. =
As long as there is only one way for the CE to do IPv4, and only one way =
to do IPv6, it all works.=20

The moment you have the potential for more than one way to deliver IPv6 =
or more than one way to deliver IPv4 from a given CE, all bets are off. =
That's precisely what you get when enabling DS-Lite on a Dual-Stack =
network, or Native IPv6 on a 6rd network. To address these (arguably =
important) cases,  you either have to force yourself back into =
single-homed forwarding by one of the four "configuration-oriented" =
methods I outlined, or go ahead and tackle multihoming via the (I'd =
argue more robust) forwarding-oriented design.=20

- Mark



>=20
>    Brian


From mark@townsley.net  Fri Dec 16 00:41:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3521F8AF0 for ; Fri, 16 Dec 2011 00:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.126
X-Spam-Level: 
X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_13=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 zWwhYtnKrTFA for ; Fri, 16 Dec 2011 00:41:50 -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 E5AF521F8AEA for ; Fri, 16 Dec 2011 00:41:49 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so4462258wgb.13 for ; Fri, 16 Dec 2011 00:41:49 -0800 (PST)
Received: by 10.227.206.78 with SMTP id ft14mr4977504wbb.24.1324024907432; Fri, 16 Dec 2011 00:41:47 -0800 (PST)
Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k5sm12130844wiz.9.2011.12.16.00.41.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 00:41:45 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Fri, 16 Dec 2011 09:41:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 08:41:51 -0000

On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:

> Mark,
> Thanks. It is very useful.=20
>> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc)
> How to do "forwarding-oriented" in CPE to distinguish among the =
techniques such as classical DS-Lite and Light Weight 4over6?

DS-Lite, 4over6, 4rd-U/T/E, dIVI, and Native IPv4, are all methods for =
delivering IPv4 over some type of transport. Each look like separate =
interfaces in the NAPT table. When you have more than one active at a =
time, this is similar in implementation at the CE to a "Dual-WAN" CE =
router you can buy today.

DS-Lite is a bit special in that as long as the "4over6" feature of it =
is not enabled, we don't want packets sent over the tunnel to create  =
NAPT translation entries in the CE. That's a very good thing given that =
DS-Lite is effectively an unnumbered point to point interface with no =
ISP-assigned address - i.e., the NAPT entries would be missing a very =
important bit of information by not having an IPv4 address to translate =
to :-)

Ole and I have taken a stab at an illustrative model of how this could =
be implemented, and will be posting it soon. This is all IPv4 technology =
though, it doesn't really have much to do at all with IPv6 other than =
most of the tunnels happen to use IPv6 as a transport.

- Mark

>=20
> - Tina
>=20
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Mark Townsley
> Sent: Wednesday, December 14, 2011 9:27 AM
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>=20
>=20
> Folks,
>=20
> We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20
>=20
> The requirements in RFC 6204 are based on a fundamental assumption =
that a CE router has a single active WAN interface for forwarding IPv4 =
and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:
>=20
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20=

>=20
> Digging deeper into transition between these states:
>=20
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is =
no problem when enabling one vs. the other.=20
>=20
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.
>=20
> For (3) there similarly is no problem when enabling tunneled IPv4 on =
an existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20
>=20
> I'd like to identify two strategies to deal with these situations.=20
>=20
> The first I will call "configuration-oriented". For this to work, one =
of the following assumptions must hold. None are pretty, but you MUST =
pick one to avoid solving how to forward traffic when multiple =
interfaces are enabled at the same time for a given IP version.=20
>=20
> (a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or=20
>=20
> (b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or
>=20
> (c) The CE router goes through an ordered set of configuration =
attempts in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20
>=20
> (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.
>=20
> The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally accepts packets on WAN =
ingress. This is "classic multihoming" and should work for any order of =
planned incremental transition steps, as well as failover and/or =
transient situations.
>=20
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis =
began adopting some of the "forwarding-based" requirements for IPv6, =
though DS-Lite remained in the "configuration-based" role for IPv4.=20
>=20
> Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.
>=20
> Again, technical comments are very welcome. Mostly I would like to =
know if people understand and agree with the basic premise here, and if =
so whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20
>=20
> Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,
>=20
> - Mark
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From wesley.george@twcable.com  Fri Dec 16 05:18:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7921F8AD9 for ; Fri, 16 Dec 2011 05:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.032
X-Spam-Level: 
X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=0.431,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Jalve2qB2x2h for ; Fri, 16 Dec 2011 05:18:24 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D517721F8801 for ; Fri, 16 Dec 2011 05:18:23 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,362,1320642000"; d="scan'208";a="311547938"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Dec 2011 08:12:54 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 16 Dec 2011 08:18:22 -0500
From: "George, Wes" 
To: Mark Townsley , "v6ops@ietf.org Operations" 
Date: Fri, 16 Dec 2011 08:18:22 -0500
Thread-Topic: [v6ops] Up-leveling Transition Coexistence
Thread-Index: Acy6haqIxE8sgP1ZSg2Q2N93znD+OwAsGOJw
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
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 13:18:24 -0000

> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Mark Townsley
> Sent: Wednesday, December 14, 2011 12:27 PM
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S
> via L2TP, TSP, etc)
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)

[WEG] I think you missed one...
(4) no IPv4 and one Native IPv6 interface

Yes, this is a longer way off, but that's the complete end of the transitio=
n, so we shouldn't pretend that the story ends with dual stack, even if it'=
s dual-stack with IPv6 the more native and emphasized protocol. We don't ha=
ve to come to consensus on *when* it might happen, because it's likely that=
 it'll be different for different networks and applications. I think we can=
 agree that it will, and given that, we should plan for it for completeness=
 when discussing things in these rough categories. The last thing that we w=
ant is to have to expend resources maintaining vestigial support for IPv4 n=
ot because we actually need it for services anymore, but because we forgot =
to mention that (and figure out how) we might want to turn it off in the CP=
E router someday.

For example a transition/technical consideration here is that the CPE route=
r would need to have a hook to know when it's supposed to operate in IPv6-o=
nly mode (perhaps simply that it does not receive an IPv4 address when it a=
sks for one, or gets some sort of NACK from the DHCP server) and stop provi=
ding IPv4 addresses to its local hosts, stop making queries for A records, =
etc - or possibly running in some sort of hybrid mode where IPv4 can be use=
d for local services (printers, uPnP, etc) but external IPv4 connection att=
empts result in the box sending a RST to the sending host, or providing a n=
ew flag in DHCP that these addresses are for local connectivity only.

I'd rather consider this now so that we can provide the right guidance up-f=
ront for when we need it, rather than having to write YAB (Yet another BIS)=
 to correct the oversight.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From cb.list6@gmail.com  Fri Dec 16 05:45:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC3721F8B6C for ; Fri, 16 Dec 2011 05:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=-0.302,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 Cdb3T0TJelrW for ; Fri, 16 Dec 2011 05:45:58 -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 6880221F84ED for ; Fri, 16 Dec 2011 05:45:58 -0800 (PST)
Received: by dajz8 with SMTP id z8so3048519daj.31 for ; Fri, 16 Dec 2011 05:45:58 -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=COFHygRCZRWUoTxBkjkZ0ZCjhwClCC3k40LlpS2Izqo=; b=s8NUXvZI0WLPc08SxSnsE93Ym4FHy7c/IQm6wGpG4UbdnvqfjVRyVA3bB0ulBghrVF xujBqAdnbaq3rzPsaXWzVXm6bAywnM/3YUDy+FSooaVRANDjT3Hm6eOGvjksUjxLnHvR n5C+OojkDMHZ7FhnoRF3hJvUNFgt6TQWC5s6c=
MIME-Version: 1.0
Received: by 10.68.74.69 with SMTP id r5mr16338459pbv.118.1324043158166; Fri, 16 Dec 2011 05:45:58 -0800 (PST)
Received: by 10.143.67.21 with HTTP; Fri, 16 Dec 2011 05:45:58 -0800 (PST)
Received: by 10.143.67.21 with HTTP; Fri, 16 Dec 2011 05:45:58 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 16 Dec 2011 05:45:58 -0800
Message-ID: 
From: Cameron Byrne 
To: "George, Wes" 
Content-Type: multipart/alternative; boundary=bcaec54693e51c1c0d04b435d232
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 13:45:59 -0000

--bcaec54693e51c1c0d04b435d232
Content-Type: text/plain; charset=ISO-8859-1

On Dec 16, 2011 8:18 AM, "George, Wes"  wrote:
>
> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> > Of Mark Townsley
> > Sent: Wednesday, December 14, 2011 12:27 PM
> > To: v6ops@ietf.org Operations
> > Subject: [v6ops] Up-leveling Transition Coexistence
> >
> > (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
> > (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S
> > via L2TP, TSP, etc)
> > (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
>
> [WEG] I think you missed one...
> (4) no IPv4 and one Native IPv6 interface
>
> Yes, this is a longer way off, but that's the complete end of the
transition, so we shouldn't pretend that the story ends with dual stack,
even if it's dual-stack with IPv6 the more native and emphasized protocol.
We don't have to come to consensus on *when* it might happen, because it's
likely that it'll be different for different networks and applications. I
think we can agree that it will, and given that, we should plan for it for
completeness when discussing things in these rough categories. The last
thing that we want is to have to expend resources maintaining vestigial
support for IPv4 not because we actually need it for services anymore, but
because we forgot to mention that (and figure out how) we might want to
turn it off in the CPE router someday.
>
> For example a transition/technical consideration here is that the CPE
router would need to have a hook to know when it's supposed to operate in
IPv6-only mode (perhaps simply that it does not receive an IPv4 address
when it asks for one, or gets some sort of NACK from the DHCP server) and
stop providing IPv4 addresses to its local hosts, stop making queries for A
records, etc - or possibly running in some sort of hybrid mode where IPv4
can be used for local services (printers, uPnP, etc) but external IPv4
connection attempts result in the box sending a RST to the sending host, or
providing a new flag in DHCP that these addresses are for local
connectivity only.
>
> I'd rather consider this now so that we can provide the right guidance
up-front for when we need it, rather than having to write YAB (Yet another
BIS) to correct the oversight.
>

+1 to all of the above. We must focus on the end-state (single stack v6)
and work backwards from there.

The tactic of taking one step forward from our current broken state has yet
to yield much beyond "yet another band aid "

Cb

> Thanks
> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--bcaec54693e51c1c0d04b435d232
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Dec 16, 2011 8:18 AM, "George, Wes" <wesley.george@twcable.com> wrote:

>

> > From: v6ops-bounces@iet=
f.org [mailto:v6ops-bounces@i=
etf.org] On Behalf

> > Of Mark Townsley

> > Sent: Wednesday, December 14, 2011 12:27 PM

> > To: v6ops@ietf.org Operatio=
ns

> > Subject: [v6ops] Up-leveling Transition Coexistence

> >

> > (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)

> > (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwire=
s H&S

> > via L2TP, TSP, etc)

> > (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd,=
 etc)

>

> [WEG] I think you missed one...

> (4) no IPv4 and one Native IPv6 interface

>

> Yes, this is a longer way off, but that's the complete end of the =
transition, so we shouldn't pretend that the story ends with dual stack=
, even if it's dual-stack with IPv6 the more native and emphasized prot=
ocol. We don't have to come to consensus on *when* it might happen, bec=
ause it's likely that it'll be different for different networks and=
 applications. I think we can agree that it will, and given that, we should=
 plan for it for completeness when discussing things in these rough categor=
ies. The last thing that we want is to have to expend resources maintaining=
 vestigial support for IPv4 not because we actually need it for services an=
ymore, but because we forgot to mention that (and figure out how) we might =
want to turn it off in the CPE router someday.


>

> For example a transition/technical consideration here is that the CPE =
router would need to have a hook to know when it's supposed to operate =
in IPv6-only mode (perhaps simply that it does not receive an IPv4 address =
when it asks for one, or gets some sort of NACK from the DHCP server) and s=
top providing IPv4 addresses to its local hosts, stop making queries for A =
records, etc - or possibly running in some sort of hybrid mode where IPv4 c=
an be used for local services (printers, uPnP, etc) but external IPv4 conne=
ction attempts result in the box sending a RST to the sending host, or prov=
iding a new flag in DHCP that these addresses are for local connectivity on=
ly.


>

> I'd rather consider this now so that we can provide the right guid=
ance up-front for when we need it, rather than having to write YAB (Yet ano=
ther BIS) to correct the oversight.

>


+1 to all of the above. We must focus on the end-state (single stack v6)=
 and work backwards from there.


The tactic of taking one step forward from our current broken state has =
yet to yield much beyond "yet another band aid "


Cb


> Thanks

> Wes George

>

> This E-mail and any of its attachments may contain Time Warner Cable p=
roprietary information, which is privileged, confidential, or subject to co=
pyright belonging to Time Warner Cable. This E-mail is intended solely for =
the use of the individual or entity to which it is addressed. If you are no=
t the intended recipient of this E-mail, you are hereby notified that any d=
issemination, distribution, copying, or action taken in relation to the con=
tents of and attachments to this E-mail is strictly prohibited and may be u=
nlawful. If you have received this E-mail in error, please notify the sende=
r immediately and permanently delete the original and any copy of this E-ma=
il and any printout.


> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--bcaec54693e51c1c0d04b435d232--

From tore.anderson@redpill-linpro.com  Fri Dec 16 06:43:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A5021F84D6 for ; Fri, 16 Dec 2011 06:43:39 -0800 (PST)
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 OcEeUraEdcCq for ; Fri, 16 Dec 2011 06:43:39 -0800 (PST)
Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6921F84A4 for ; Fri, 16 Dec 2011 06:43:33 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 2BDBC1030044; Fri, 16 Dec 2011 15:43:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNa6zIpQxNqe; Fri, 16 Dec 2011 15:43:22 +0100 (CET)
Received: from envy.fud.no (unknown [IPv6:2001:840:3035:0:21c:bfff:fe02:f2a5]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 7EC09103000E;  Fri, 16 Dec 2011 15:43:22 +0100 (CET)
Message-ID: <4EEB590A.6040506@redpill-linpro.com>
Date: Fri, 16 Dec 2011 15:43:22 +0100
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "George, Wes" 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 14:43:39 -0000

* George, Wes

> [WEG] I think you missed one...
> (4) no IPv4 and one Native IPv6 interface

Fully agreed. That's where the transition needs to end (and the sooner
the better). If that is not the end state, the so-called «transition»,
well, isn't one.

> [...] or possibly running in some sort of hybrid mode where IPv4 can be
> used for local services (printers, uPnP, etc) but external IPv4
> connection attempts result in the box sending a RST to the sending
> host, or providing a new flag in DHCP that these addresses are for
> local connectivity only.

Wouldn't it in this case be much easier to simply omit the router option
from the CE's DHCPv4 response? Also, use of 169.254/16 could provide an
additional hint that the addresses are for local connectivity only.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

From mark@townsley.net  Fri Dec 16 07:36:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2141921F8B08 for ; Fri, 16 Dec 2011 07:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level: 
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178,  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 zaf7kapBMELF for ; Fri, 16 Dec 2011 07:36:25 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9821F8B04 for ; Fri, 16 Dec 2011 07:36:25 -0800 (PST)
Received: by faas1 with SMTP id s1so3499066faa.31 for ; Fri, 16 Dec 2011 07:36:24 -0800 (PST)
Received: by 10.180.74.211 with SMTP id w19mr13464109wiv.7.1324049784199; Fri, 16 Dec 2011 07:36:24 -0800 (PST)
Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k5sm13544066wiz.9.2011.12.16.07.36.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 07:36:23 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Fri, 16 Dec 2011 16:36:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <212E1A9D-C827-4A46-ACEB-C2D24153223E@townsley.net>
References:  
To: "George, Wes" 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 15:36:26 -0000

On Dec 16, 2011, at 2:18 PM, George, Wes wrote:

>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf
>> Of Mark Townsley
>> Sent: Wednesday, December 14, 2011 12:27 PM
>> To: v6ops@ietf.org Operations
>> Subject: [v6ops] Up-leveling Transition Coexistence
>>=20
>> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
>> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires =
H&S
>> via L2TP, TSP, etc)
>> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc)
>=20
> [WEG] I think you missed one...
> (4) no IPv4 and one Native IPv6 interface

Agree, but... 6204-bis currently does not enter the realm of v6-only. I =
was working within the scope of that document in this email. That's why =
I prefaced these 3 with:

"...steady-state combinations of "native" and "virtual" (tunneled) =
dual-stack connectivity methods"

> Yes, this is a longer way off, but that's the complete end of the =
transition, so we shouldn't pretend that the story ends with dual stack, =
even if it's dual-stack with IPv6 the more native and emphasized =
protocol. We don't have to come to consensus on *when* it might happen, =
because it's likely that it'll be different for different networks and =
applications. I think we can agree that it will, and given that, we =
should plan for it for completeness when discussing things in these =
rough categories. The last thing that we want is to have to expend =
resources maintaining vestigial support for IPv4 not because we actually =
need it for services anymore, but because we forgot to mention that (and =
figure out how) we might want to turn it off in the CPE router someday.
>=20
> For example a transition/technical consideration here is that the CPE =
router would need to have a hook to know when it's supposed to operate =
in IPv6-only mode (perhaps simply that it does not receive an IPv4 =
address when it asks for one, or gets some sort of NACK from the DHCP =
server) and stop providing IPv4 addresses to its local hosts, stop =
making queries for A records, etc - or possibly running in some sort of =
hybrid mode where IPv4 can be used for local services (printers, uPnP, =
etc) but external IPv4 connection attempts result in the box sending a =
RST to the sending host, or providing a new flag in DHCP that these =
addresses are for local connectivity only.

I do think "sunsetting IPv4" needs work. It's not going to go away =
without a fight.=20

- Mark

>=20
> I'd rather consider this now so that we can provide the right guidance =
up-front for when we need it, rather than having to write YAB (Yet =
another BIS) to correct the oversight.
>=20
> Thanks
> Wes George
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.


From wesley.george@twcable.com  Fri Dec 16 13:52:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B9211E8097 for ; Fri, 16 Dec 2011 13:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.547
X-Spam-Level: 
X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fsPBv7IZF3q for ; Fri, 16 Dec 2011 13:52:51 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC411E8089 for ; Fri, 16 Dec 2011 13:52:51 -0800 (PST)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,365,1320642000"; d="scan'208";a="296332586"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Dec 2011 16:46:09 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 16 Dec 2011 16:52:49 -0500
From: "George, Wes" 
To: Mark Townsley 
Date: Fri, 16 Dec 2011 16:52:48 -0500
Thread-Topic: [v6ops] Up-leveling Transition Coexistence
Thread-Index: Acy8CHlmYOI/1mFAQB+5EJwUSq/ZeQAJ6/XQ
Message-ID: 
References:   <212E1A9D-C827-4A46-ACEB-C2D24153223E@townsley.net>
In-Reply-To: <212E1A9D-C827-4A46-ACEB-C2D24153223E@townsley.net>
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: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 21:52:52 -0000

> From: Mark Townsley [mailto:mark@townsley.net]
> Sent: Friday, December 16, 2011 10:36 AM
> To: George, Wes
> Cc: v6ops@ietf.org Operations
> Subject: Re: [v6ops] Up-leveling Transition Coexistence
>
> > [WEG] I think you missed one...
> > (4) no IPv4 and one Native IPv6 interface
>
> Agree, but... 6204-bis currently does not enter the realm of v6-only. I
> was working within the scope of that document in this email. That's why
> I prefaced these 3 with:
>
> "...steady-state combinations of "native" and "virtual" (tunneled)
> dual-stack connectivity methods"
>
[WEG] The scope of this whole discussion is a bit unclear to me, for 2 reas=
ons - I haven't been closely following the 6204-bis mega thread, and I saw =
you make reference to several new drafts in your original message. It sound=
ed to me like you were talking about abstracting transition coexistence a b=
it from the discussion of 6204-bis that it's currently mired in, which is w=
hy I pointed to this as being missing. I'm not saying that it has to be tot=
ally covered in 6204-bis, merely that any serious discussion about IPv4/IPv=
6 transition and coexistence needs to consider this its end state. I'm open=
 for discussion on what the next step is in that regard, but I'm going to c=
ontinue pointing at places where IPv6-only is not being considered so that =
it doesn't get missed in the discussion.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From wwwrun@rfc-editor.org  Fri Dec 16 10:47:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34921F8B1D for ; Fri, 16 Dec 2011 10:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.416
X-Spam-Level: 
X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 BoyipSff6Lvq for ; Fri, 16 Dec 2011 10:47:00 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1C21F8B04 for ; Fri, 16 Dec 2011 10:46:57 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 719D272E004; Fri, 16 Dec 2011 10:45:50 -0800 (PST)
To: shemant@cisco.com, wbeebee@cisco.com, c.donley@cablelabs.com, barbara.stark@att.com, ot@cisco.com, dromasca@avaya.com, rbonica@juniper.net, fred.baker@cisco.com, joelja@bogus.com
From: RFC Errata System 
Message-Id: <20111216184550.719D272E004@rfc-editor.org>
Date: Fri, 16 Dec 2011 10:45:50 -0800 (PST)
X-Mailman-Approved-At: Fri, 16 Dec 2011 15:59:33 -0800
Cc: v6ops@ietf.org, tore@fud.no, rfc-editor@rfc-editor.org
Subject: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 18:47:01 -0000

The following errata report has been submitted for RFC6204,
"Basic Requirements for IPv6 Customer Edge Routers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6204&eid=3054

--------------------------------------
Type: Technical
Reported by: Tore Anderson 

Section: 4.3

Original Text
-------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of the lower of the current Valid Lifetime and 2
          hours (which must be decremented in real time) in a Router
          Advertisement message as described in Section 5.5.3, (e) of
          [RFC4862].

Corrected Text
--------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero, or b) the lower of the current
          Valid Lifetime and 2 hours (which must be decremented in real
          time), in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

Notes
-----
The original text in L-13 prohibits implementers from transmitting Valid Lifetime = 0 whenever a prefix needs to be invalidated. It should not, because transmitting VL=0 is easier to implement than sending "the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time)".

Transmitting Valid Lifetime = 0 has the exact same effect on a host as the procedure described in the original text, i.e., it will the host to lower (but never raise) the remaining valid lifetime to 7200 seconds.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09)
--------------------------------------
Title               : Basic Requirements for IPv6 Customer Edge Routers
Publication Date    : April 2011
Author(s)           : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.
Category            : INFORMATIONAL
Source              : IPv6 Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

From mark@townsley.net  Sat Dec 17 01:52:42 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B221F8C04 for ; Sat, 17 Dec 2011 01:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.428
X-Spam-Level: 
X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170,  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 ExhBH2ttpDpD for ; Sat, 17 Dec 2011 01:52:42 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43821F8BF0 for ; Sat, 17 Dec 2011 01:52:41 -0800 (PST)
Received: by wgbds13 with SMTP id ds13so4372872wgb.1 for ; Sat, 17 Dec 2011 01:52:40 -0800 (PST)
Received: by 10.180.95.136 with SMTP id dk8mr12616269wib.11.1324115560400; Sat, 17 Dec 2011 01:52:40 -0800 (PST)
Received: from ams-townsley-8717.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id et20sm17726831wbb.15.2011.12.17.01.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Dec 2011 01:52:39 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-15-63490491
From: Mark Townsley 
In-Reply-To: 
Date: Sat, 17 Dec 2011 10:52:37 +0100
Message-Id: 
References:   <212E1A9D-C827-4A46-ACEB-C2D24153223E@townsley.net> 
To: "George, Wes" 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 09:52:42 -0000

--Apple-Mail-15-63490491
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 16, 2011, at 10:52 PM, George, Wes wrote:

>> From: Mark Townsley [mailto:mark@townsley.net]
>> Sent: Friday, December 16, 2011 10:36 AM
>> To: George, Wes
>> Cc: v6ops@ietf.org Operations
>> Subject: Re: [v6ops] Up-leveling Transition Coexistence
>>=20
>>> [WEG] I think you missed one...
>>> (4) no IPv4 and one Native IPv6 interface
>>=20
>> Agree, but... 6204-bis currently does not enter the realm of v6-only. =
I
>> was working within the scope of that document in this email. That's =
why
>> I prefaced these 3 with:
>>=20
>> "...steady-state combinations of "native" and "virtual" (tunneled)
>> dual-stack connectivity methods"
>>=20
> [WEG] The scope of this whole discussion is a bit unclear to me, for 2 =
reasons - I haven't been closely following the 6204-bis mega thread, and =
I saw you make reference to several new drafts in your original message. =
It sounded to me like you were talking about abstracting transition =
coexistence a bit from the discussion of 6204-bis that it's currently =
mired in, which is why I pointed to this as being missing. I'm not =
saying that it has to be totally covered in 6204-bis, merely that any =
serious discussion about IPv4/IPv6 transition and coexistence needs to =
consider this its end state. I'm open for discussion on what the next =
step is in that regard, but I'm going to continue pointing at places =
where IPv6-only is not being considered so that it doesn't get missed in =
the discussion.

Perfectly reasonable, and you'll get no objection from me that IPv6-only =
needs to be addressed. The practical corollary of course is that we =
really know what is going to work and break when we try to turn off =
IPv4. It's not something many people have done :-)

I'm not sure what the fate of 6204-bis is in terms of the transition =
coexistence section. A the moment, it seems it will still include 6rd =
and DS-Lite requirements, but there is really no advice on how to make =
these work with their Native equivalents as you either have to include =
multihoming or figure out how to enforce only allowing one egress at a =
time. For 6rd, that means you can turn on IPv6 service over your IPv4 =
network, but if you turn on Native IPv6 at the same time 6204-bis is =
insufficient. For DS-Lite, it's a bit worse because it means that you =
can turn on IPv4 on an IPv6-only network, but turning on DS-Lite on a =
Dual-Stack 6204-bis will be insufficient.

Ole and I have tried to capture this problem as well as a proposed =
solution in our latest revision of:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02

Here, the IPv6 multihoming 6rd requirements seems fairly solid. IMHO, it =
would be an improvement to include them in 6204-bis, then at least it is =
a complete solution that allows you to turn on IPv6 with 6rd, then =
Native IPv6, then turn off 6rd.=20

The paint is still dry on the the IPv4 DS-Lite+ model we are proposing. =
The main point though is that once you bring in a new IPv4 delivery =
model, you can't just wave your hands and expect it to work alongside =
the IPv4 that's already there, or wave your hands and expect you can =
turn off Native IPv4 without thinking it through.=20

Please have a read and let us know what you think.

Thanks,

- Mark



>=20
> Thanks
> Wes George
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.


--Apple-Mail-15-63490491
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


From: Mark Townsley =
[mailto:mark@townsley.net]
Sent:=
 Friday, December 16, 2011 10:36 AM
To: George, Wes
Cc: v6ops@ietf.org =
Operations
Subject: Re: =
[v6ops] Up-leveling Transition Coexistence

[WEG] I think you missed =
one...
(4) no IPv4 and one Native IPv6 =
interface

Agree, but... =
6204-bis currently does not enter the realm of v6-only. =
I
was working within the scope =
of that document in this email. That's why
I prefaced these 3 with:

"...steady-state =
combinations of "native" and "virtual" =
(tunneled)
dual-stack =
connectivity methods"

[WEG] The scope of this whole discussion =
is a bit unclear to me, for 2 reasons - I haven't been closely following =
the 6204-bis mega thread, and I saw you make reference to several new =
drafts in your original message. It sounded to me like you were talking =
about abstracting transition coexistence a bit from the discussion of =
6204-bis that it's currently mired in, which is why I pointed to this as =
being missing. I'm not saying that it has to be totally covered in =
6204-bis, merely that any serious discussion about IPv4/IPv6 transition =
and coexistence needs to consider this its end state. I'm open for =
discussion on what the next step is in that regard, but I'm going to =
continue pointing at places where IPv6-only is not being considered so =
that it doesn't get missed in the =
discussion.

Perfectly =
reasonable, and you'll get no objection from me that IPv6-only needs to =
be addressed. The practical corollary of course is that we really know =
what is going to work and break when we try to turn off IPv4. It's not =
something many people have done :-)

I'm not =
sure what the fate of 6204-bis is in terms of the transition coexistence =
section. A the moment, it seems it will still include 6rd and DS-Lite =
requirements, but there is really no advice on how to make these work =
with their Native equivalents as you either have to include multihoming =
or figure out how to enforce only allowing one egress at a time. For =
6rd, that means you can turn on IPv6 service over your IPv4 network, but =
if you turn on Native IPv6 at the same time 6204-bis is insufficient. =
For DS-Lite, it's a bit worse because it means that you can turn on IPv4 =
on an IPv6-only network, but turning on DS-Lite on a Dual-Stack 6204-bis =
will be insufficient.

Ole and I have tried to =
capture this problem as well as a proposed solution in our latest =
revision of:


Here, the IPv6 multihoming 6rd =
requirements seems fairly solid. IMHO, it would be an improvement to =
include them in 6204-bis, then at least it is a complete solution that =
allows you to turn on IPv6 with 6rd, then Native IPv6, then turn off =
6rd. 

The paint is still dry on the the =
IPv4 DS-Lite+ model we are proposing. The main point though is that once =
you bring in a new IPv4 delivery model, you can't just wave your hands =
and expect it to work alongside the IPv4 that's already there, or wave =
your hands and expect you can turn off Native IPv4 without thinking it =
through. 

Please have a read and let us =
know what you =
think.

Thanks,

- =
Mark




Thanks
Wes George

This E-mail and any =
of its attachments may contain Time Warner Cable proprietary =
information, which is privileged, confidential, or subject to copyright =
belonging to Time Warner Cable. This E-mail is intended solely for the =
use of the individual or entity to which it is addressed. If you are not =
the intended recipient of this E-mail, you are hereby notified that any =
dissemination, distribution, copying, or action taken in relation to the =
contents of and attachments to this E-mail is strictly prohibited and =
may be unlawful. If you have received this E-mail in error, please =
notify the sender immediately and permanently delete the original and =
any copy of this E-mail and any =
printout.

=

--Apple-Mail-15-63490491--

From mark@townsley.net  Sat Dec 17 01:53:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1521F8AE9 for ; Sat, 17 Dec 2011 01:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.134
X-Spam-Level: 
X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 ck-WhcrpLtus for ; Sat, 17 Dec 2011 01:53:53 -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 2284421F84A8 for ; Sat, 17 Dec 2011 01:53:46 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so5905646wgb.13 for ; Sat, 17 Dec 2011 01:53:44 -0800 (PST)
Received: by 10.216.133.29 with SMTP id p29mr4372206wei.49.1324115624758; Sat, 17 Dec 2011 01:53:44 -0800 (PST)
Received: from ams-townsley-8717.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fy13sm17717936wbb.18.2011.12.17.01.53.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Dec 2011 01:53:43 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-16-63554546
From: Mark Townsley 
In-Reply-To: 
Date: Sat, 17 Dec 2011 10:53:41 +0100
Message-Id: 
References:  
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 09:53:54 -0000

--Apple-Mail-16-63554546
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:

> Mark,
> Thanks. It is very useful.=20
>> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc)
> How to do "forwarding-oriented" in CPE to distinguish among the =
techniques such as classical DS-Lite and Light Weight 4over6?

Our latest version attempts to tackle this:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02

- Mark

>=20
> - Tina
>=20
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Mark Townsley
> Sent: Wednesday, December 14, 2011 9:27 AM
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>=20
>=20
> Folks,
>=20
> We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20
>=20
> The requirements in RFC 6204 are based on a fundamental assumption =
that a CE router has a single active WAN interface for forwarding IPv4 =
and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:
>=20
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20=

>=20
> Digging deeper into transition between these states:
>=20
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is =
no problem when enabling one vs. the other.=20
>=20
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.
>=20
> For (3) there similarly is no problem when enabling tunneled IPv4 on =
an existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20
>=20
> I'd like to identify two strategies to deal with these situations.=20
>=20
> The first I will call "configuration-oriented". For this to work, one =
of the following assumptions must hold. None are pretty, but you MUST =
pick one to avoid solving how to forward traffic when multiple =
interfaces are enabled at the same time for a given IP version.=20
>=20
> (a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or=20
>=20
> (b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or
>=20
> (c) The CE router goes through an ordered set of configuration =
attempts in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20
>=20
> (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.
>=20
> The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally accepts packets on WAN =
ingress. This is "classic multihoming" and should work for any order of =
planned incremental transition steps, as well as failover and/or =
transient situations.
>=20
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis =
began adopting some of the "forwarding-based" requirements for IPv6, =
though DS-Lite remained in the "configuration-based" role for IPv4.=20
>=20
> Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.
>=20
> Again, technical comments are very welcome. Mostly I would like to =
know if people understand and agree with the basic premise here, and if =
so whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20
>=20
> Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,
>=20
> - Mark
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-16-63554546
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Mark,
Thanks. It is very useful. 
(3) One Virtual IPv4 and one Native IPv6 interface =
(DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in =
CPE to distinguish among the techniques such as classical DS-Lite and =
Light Weight 4over6?

Our =
latest version attempts to tackle this:


- Mark


- Tina


-----Original =
Message-----
From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: =
Wednesday, December 14, 2011 9:27 AM
To: v6ops@ietf.org Operations
Subject: =
[v6ops] Up-leveling Transition Coexistence


Folks,

We =
have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to =
work together on a residential CE router. I'd like to summarize what I =
think the main architectural issue is alongside a possible solution =
framework. Technical comments are very welcome, but let's also try and =
keep them thoughtful and at a pace that everyone can keep up amidst =
their day-jobs. 

The requirements in RFC 6204 are based on a =
fundamental assumption that a CE router has a single active WAN =
interface for forwarding IPv4 and IPv6 traffic towards an ISP. The =
inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 =
via Native together forces us to at least reconsider this basic =
assumption.  Breaking this down at bit, there are three possible =
steady-state combinations of "native" and "virtual" (tunneled) =
dual-stack connectivity methods that do not break the basic forwarding =
model of a single WAN egress per IP version:

(1) One Native IPv4 =
and IPv6 interface (Classic Dual-Stack) 
(2) One Native IPv4 and one =
Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc) =

(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc) 

Digging deeper into transition between these =
states:

For (1), IPv4 and IPv6 each share a single WAN interface, =
so there is no problem when enabling one vs. the other. 

For (2), =
when enabling tunneled IPv6 on an existing IPv4-only network there is no =
significant change in the basic model as each IP version still has its =
own distinct single WAN interface. Multihoming issues arise when =
enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.

For (3) there similarly is no problem when enabling =
tunneled IPv4 on an existing IPv6-only network, and I have been told =
that there are greenfield deployments just like this happening. The =
multihoming issues arise when enabling tunneled IPv4 on a network that =
has native IPv4 available at the same time.  

I'd like to =
identify two strategies to deal with these situations. 

The first =
I will call "configuration-oriented". For this to work, one of the =
following assumptions must hold. None are pretty, but you MUST pick one =
to avoid solving how to forward traffic when multiple interfaces are =
enabled at the same time for a given IP version. 

 (a) =46rom the =
perspective of the CE router, the network supports only one type of =
interface for a given IP version, or 

 (b) The CE router is =
configured in advance of any IP configuration to support only one type =
of interface for a given IP version, or

 (c) The CE router goes =
through an ordered set of configuration attempts in series, each =
requiring a timeout before moving to the next. Transition-oriented =
changes after steady-state is reached will require "reboot" to go =
through the ordered process from scratch. 

 (d) The CE router =
chooses one type of interface and shuts down all others based on a =
predetermined priority when more than one interface with the same IP =
version is configured. This allows parallel configuration attempts and =
changes after reaching steady-state, but requires the CE router and =
network to manage a "flash cut" from one configured interface to the =
other and may be prone to tricky race-conditions.

The second =
strategy I will call "forwarding-oriented." In this model, configuration =
of any WAN interface method at any time is accepted. The CE follows =
forwarding rules in order to ensure packets make it out the right =
interface on WAN egress, and liberally accepts packets on WAN ingress. =
This is "classic multihoming" and should work for any order of planned =
incremental transition steps, as well as failover and/or transient =
situations.

After publishing =
draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of =
the "forwarding-based" requirements for IPv6, though DS-Lite remained in =
the "configuration-based" role for IPv4. 

Ole and I also just =
published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a =
general set of IPv6 requirements for multihoming with 6rd-specifics =
(i.e., it is a "forwarding-based" solution for IPv6). We'll be =
publishing the same for IPv4 in order to support DS-Lite. Neither are =
rocket science, but teaching the CE to properly forward when faced with =
more than one alternative egress interface has been labeled "hard" =
(though as an interesting data point I have found IPv4 routers that =
support multiple WAN interfaces at the same time for less than $50). In =
my mind, the "configuration-oriented" alternative seems at least as hard =
as the "forwarding-oriented" alternative, is less robust, and certainly =
less flexible in terms of letting the operator decide its fate in terms =
of how to perform each transition step.

Again, technical comments =
are very welcome. Mostly I would like to know if people understand and =
agree with the basic premise here, and if so whether =
"configuration-oriented" or "forwarding-oriented" is the best way =
forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-) 

Thanks, and Happy Holidays in advance to those who will be =
celebrating soon,

- =
Mark
_______________________________________________
v6ops mailing =
list
v6ops@ietf.org
https://www.ietf.org/=
mailman/listinfo/v6ops

=

--Apple-Mail-16-63554546--

From Tina.Tsou.Zouting@huawei.com  Sat Dec 17 16:34:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A611E807F for ; Sat, 17 Dec 2011 16:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.227
X-Spam-Level: 
X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 F+93GHEnF3mK for ; Sat, 17 Dec 2011 16:34:43 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB611E8073 for ; Sat, 17 Dec 2011 16:34:42 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWD00EQDIXSC7@szxga03-in.huawei.com> for v6ops@ietf.org; Sun, 18 Dec 2011 08:34:40 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWD00533IXRV2@szxga03-in.huawei.com> for v6ops@ietf.org; Sun, 18 Dec 2011 08:34:40 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFT63853; Sun, 18 Dec 2011 08:34:22 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 18 Dec 2011 08:33:30 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Sun, 18 Dec 2011 08:34:16 +0800
Date: Sun, 18 Dec 2011 00:34:15 +0000
From: Tina TSOU 
In-reply-to: 
To: Mark Townsley 
Message-id: <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_9UGkCPAAtl2ptW7tYVtKuQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Up-leveling Transition Coexistence
Thread-index: AQHMuoWtLIv9EMTPEUqfzMLkWVTTkJXde9CAgAHMi4CAAXwkAw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Dec 2011 00:34:44 -0000

--Boundary_(ID_9UGkCPAAtl2ptW7tYVtKuQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Mark,

Sent from my iPad

On Dec 17, 2011, at 1:53 AM, "Mark Townsley" > wrote:


On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:

Mark,
Thanks. It is very useful.
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?

Our latest version attempts to tackle this:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
I read this draft, it is well written. In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented? Then, do we have to to change this value by re-coding if each mechanism is added? Or make a CLI to change this value?

- Mark


- Tina


-----Original Message-----
From:  v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To:  v6ops@ietf.org Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs.

The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc)
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other.

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.

I'd like to identify two strategies to deal with these situations.

The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version.

(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or

(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or

(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch.

(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4.

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-)

Thanks, and Happy Holidays in advance to those who will be celebrating soon,

- Mark
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--Boundary_(ID_9UGkCPAAtl2ptW7tYVtKuQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT







Mark,



Sent from my iPad




On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <mark@townsley.net> wrote:















On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:






Mark,

Thanks. It is very useful. 


(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)



How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?











Our latest version attempts to tackle this:













I read this draft, it is well written. In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented? Then, do we have to to change this value
 by re-coding if each mechanism is added? Or make a CLI to change this value?













- Mark








- Tina





-----Original Message-----

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley

Sent: Wednesday, December 14, 2011 9:27 AM

To: v6ops@ietf.org Operations

Subject: [v6ops] Up-leveling Transition Coexistence





Folks,



We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible
 solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs.




The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together
 forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single
 WAN egress per IP version:



(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 

(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc)


(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 



Digging deeper into transition between these states:



For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other.




For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled
 IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.



For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that
 has native IPv4 available at the same time.  



I'd like to identify two strategies to deal with these situations. 



The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP
 version. 



(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or




(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or



(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch.




(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state,
 but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.



The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally
 accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.



After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4.




Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order
 to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple
 WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its
 fate in terms of how to perform each transition step.



Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented
 approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-)




Thanks, and Happy Holidays in advance to those who will be celebrating soon,



- Mark

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops
















--Boundary_(ID_9UGkCPAAtl2ptW7tYVtKuQ)--

From fred@cisco.com  Sat Dec 17 20:00:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D540011E8097 for ; Sat, 17 Dec 2011 20:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104
X-Spam-Level: 
X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[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 I-5oO1ltRhbt for ; Sat, 17 Dec 2011 20:00:01 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5E11E8094 for ; Sat, 17 Dec 2011 20:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=823; q=dns/txt; s=iport; t=1324180801; x=1325390401; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ErY76uaNdjGsYqk2ZmxuPyMW2yrz6UpbnBgX54cadUA=; b=AxTovz9lmmtGCu4fICaDvOChbfDHVyuYiIIWanjdotOlyI8Apbauu7hJ uBXoTZ9fCTBh6XQb6NNM41rliUuqHCJNZWjTPTCr23xDosanhZV7KceWR fC9T3yRrKMEURnVtJMcSFLqL/Qr7Klyc5Ag2FfEZk7xyVCMu3EWLF+s0o A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEBk7U6rRDoG/2dsb2JhbABDq1mBBYFyAQEBAwESASc/BQsLRlcGNYdYmHkBnVuLIWMEiDaMSIVOjQE
X-IronPort-AV: E=Sophos;i="4.71,370,1320624000"; d="scan'208";a="19609318"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 18 Dec 2011 04:00:00 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBI3xx3U017900; Sun, 18 Dec 2011 03:59:59 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Sat, 17 Dec 2011 20:00:00 -0800
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Sat, 17 Dec 2011 20:00:00 -0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <4EE7FA27.2030409@gmail.com>
Date: Sat, 17 Dec 2011 19:59:49 -0800
Message-Id: <90491DAE-BF52-4ED3-990F-FD5E91779AF1@cisco.com>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Dec 2011 04:00:02 -0000

On Dec 13, 2011, at 5:21 PM, Brian E Carpenter wrote:

> It seems to assume that
> ingress filtering is inevitable, but this is very restrictive as far
> as seamless multihoming goes. If we can one day get to a situation
> where ingress filtering is automatically tailored for multihomed =
customers,
> we will need each SRIB entry to point to multiple DRIBs accordingly.

To be really honest, I think you need to demonstrate that there is =
interest in achieving the nirvana you desire. Generally speaking, a =
service provider will do what you pay him to do, and anything that he =
can't describe in generic "service" terms will be generally offered, if =
at all, at a high price. Couple that with the general behavior of =
markets - seeking the lowest price for a reasonable set of services, =
and...=

From brian.e.carpenter@gmail.com  Sun Dec 18 12:58:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA7221F8A97 for ; Sun, 18 Dec 2011 12:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 gz8QGuco+d6P for ; Sun, 18 Dec 2011 12:58:25 -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 DC43821F8A7A for ; Sun, 18 Dec 2011 12:58:21 -0800 (PST)
Received: by iaek3 with SMTP id k3so8676893iae.31 for ; Sun, 18 Dec 2011 12:58:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JJLYIDduou8t8HCxo3zK5Voo+8BYcvDurTFGMkLXaOU=; b=Gm5VimPjtgQkT38bx/QgjEWeN3jGzHJzWL623KjP85w4vX1CXZ1XtIBgN0c//zagG+ 1OFA43w56L/YJPYIkAfyHEISTCfxYSzIOPCSPJvu5gp/BLlVpmBQeoL8/4iq8GZllA6V vsoJHIVwt54Y+Hy8R4Sag5znqAY4eql+2X+FQ=
Received: by 10.50.236.5 with SMTP id uq5mr23960640igc.47.1324241900365; Sun, 18 Dec 2011 12:58:20 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id py4sm16166389igc.2.2011.12.18.12.58.17 (version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 12:58:19 -0800 (PST)
Message-ID: <4EEE53E7.5050901@gmail.com>
Date: Mon, 19 Dec 2011 09:58:15 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fred Baker 
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <90491DAE-BF52-4ED3-990F-FD5E91779AF1@cisco.com>
In-Reply-To: <90491DAE-BF52-4ED3-990F-FD5E91779AF1@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Dec 2011 20:58:25 -0000

On 2011-12-18 16:59, Fred Baker wrote:
> On Dec 13, 2011, at 5:21 PM, Brian E Carpenter wrote:
> 
>> It seems to assume that
>> ingress filtering is inevitable, but this is very restrictive as far
>> as seamless multihoming goes. If we can one day get to a situation
>> where ingress filtering is automatically tailored for multihomed customers,
>> we will need each SRIB entry to point to multiple DRIBs accordingly.
> 
> To be really honest, I think you need to demonstrate that there is interest in achieving the nirvana you desire. Generally speaking, a service provider will do what you pay him to do, and anything that he can't describe in generic "service" terms will be generally offered, if at all, at a high price. Couple that with the general behavior of markets - seeking the lowest price for a reasonable set of services, and...

Well yes, the market does what it does. If small users come to care
deeply about multihoming, the incentive for ISPs to support flexible
ingress filtering will arise and a solution will emerge. If the users
don't care, there will be no incentive.

My point is that we shouldn't write specs that unnecessarily constrain
things that might be desirable. I think a tiny change will do that:

   MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
          associated delegated prefixes.  Each entry points to one or
          more DRIBs.  An entry points to multiple DRIBs only in the
          case where an identical delegated prefix is known to be
          routeable via multiple WAN interfaces.

 Brian


   Brian

From Carl.Wuyts@technicolor.com  Sun Dec 18 23:40:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4921F8B25 for ; Sun, 18 Dec 2011 23:40:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 51VSYnPtkuW0 for ; Sun, 18 Dec 2011 23:40:15 -0800 (PST)
Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5144A21F84F5 for ; Sun, 18 Dec 2011 23:40:13 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKTu7qUF2gaNu+fHubfhEiPHPz1dp/O751@postini.com; Sun, 18 Dec 2011 23:40:14 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 08:35:49 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 08:35:50 +0100
From: Wuyts Carl 
To: Mark Townsley , "v6ops@ietf.org Operations" 
Date: Mon, 19 Dec 2011 08:35:48 +0100
Thread-Topic: [v6ops] Up-leveling Transition Coexistence
Thread-Index: Acy6ha6ry89se0RvS42z3V0XW1O0sADmMYxg
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B264D@MOPESMBX01.eu.thmulti.com>
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
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 07:40:16 -0000

Some feedback on the below, being a CPE vendor for residential market.
First note that, although our main deployment is in the residential CPE mar=
ket, we're not present in retail, so maybe my view is "spoiled" due to this=
.

I don't believe in this configuration-oriented approach at all as it is mai=
nly to complicated or not really a possible approach.  There are 4 possibil=
ities listed in this scenario, where we would have to pick one from, but no=
ne of them are really suitable I think, for sure not the one where you'd ha=
ve to run a "couple" of configuration attempts with timeouts etc" or "have =
to shut down intfs based upon ...".
Although some of these can possibly covered through some scripting, this is=
 nothing really one should force upon a CPE, in fact, to no other IP device=
 either.  Let's stick to standard behavior, threating an IP intf as it shou=
ld be, not try to enforce some "extra's" on top of them.  An IP intf gets e=
nabled, and can start forwarding traffic if the forwarding is allowed upon =
it (so routes availabe etc).  If you want to accomplish the below, I think =
you've to force lots of policy on top of the present CPE's capabilities in =
this area, so a no-go I'd say.  Please don't mix a residential CPE with a f=
ull-blown business router.  Again this seems to be an attempt of enforcing =
some stuff upon the CPE, to be avoided I'd say (again).

I also see some replies on "what if multiple transition scenario's are bein=
g used at the same time, combining DSLite with 4over6 or whatever".  This i=
s of course possible in multi-homed scenario's but again here the same appl=
ies.  Let's try to keep normal IP behavior in place, read forwarding-orient=
ed approach, not try to enforce all kind of tricky things.  As our customer=
s are operators, not end-users, dual-homed scenario's are not our main targ=
et, but I can't see any added value looking into this "configuration-orient=
ed" approach.

My 2 cents
Regs
Carl






-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M=
ark Townsley
Sent: woensdag 14 december 2011 18:27
To: v6ops@ietf.org Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-=
bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on=
 a residential CE router. I'd like to summarize what I think the main archi=
tectural issue is alongside a possible solution framework. Technical commen=
ts are very welcome, but let's also try and keep them thoughtful and at a p=
ace that everyone can keep up amidst their day-jobs.=20

The requirements in RFC 6204 are based on a fundamental assumption that a C=
E router has a single active WAN interface for forwarding IPv4 and IPv6 tra=
ffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 v=
ia DS-lite and IPv4 via Native together forces us to at least reconsider th=
is basic assumption.  Breaking this down at bit, there are three possible s=
teady-state combinations of "native" and "virtual" (tunneled) dual-stack co=
nnectivity methods that do not break the basic forwarding model of a single=
 WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via =
L2TP, TSP, etc)=20
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no pr=
oblem when enabling one vs. the other.=20

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there=
 is no significant change in the basic model as each IP version still has i=
ts own distinct single WAN interface. Multihoming issues arise when enablin=
g native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6=
 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an exi=
sting IPv6-only network, and I have been told that there are greenfield dep=
loyments just like this happening. The multihoming issues arise when enabli=
ng tunneled IPv4 on a network that has native IPv4 available at the same ti=
me. =20

I'd like to identify two strategies to deal with these situations.=20

The first I will call "configuration-oriented". For this to work, one of th=
e following assumptions must hold. None are pretty, but you MUST pick one t=
o avoid solving how to forward traffic when multiple interfaces are enabled=
 at the same time for a given IP version.=20

 (a) From the perspective of the CE router, the network supports only one t=
ype of interface for a given IP version, or=20

 (b) The CE router is configured in advance of any IP configuration to supp=
ort only one type of interface for a given IP version, or

 (c) The CE router goes through an ordered set of configuration attempts in=
 series, each requiring a timeout before moving to the next. Transition-ori=
ented changes after steady-state is reached will require "reboot" to go thr=
ough the ordered process from scratch.=20

 (d) The CE router chooses one type of interface and shuts down all others =
based on a predetermined priority when more than one interface with the sam=
e IP version is configured. This allows parallel configuration attempts and=
 changes after reaching steady-state, but requires the CE router and networ=
k to manage a "flash cut" from one configured interface to the other and ma=
y be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, confi=
guration of any WAN interface method at any time is accepted. The CE follow=
s forwarding rules in order to ensure packets make it out the right interfa=
ce on WAN egress, and liberally accepts packets on WAN ingress. This is "cl=
assic multihoming" and should work for any order of planned incremental tra=
nsition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began ado=
pting some of the "forwarding-based" requirements for IPv6, though DS-Lite =
remained in the "configuration-based" role for IPv4.=20

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01=
.txt, which is a general set of IPv6 requirements for multihoming with 6rd-=
specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be pu=
blishing the same for IPv4 in order to support DS-Lite. Neither are rocket =
science, but teaching the CE to properly forward when faced with more than =
one alternative egress interface has been labeled "hard" (though as an inte=
resting data point I have found IPv4 routers that support multiple WAN inte=
rfaces at the same time for less than $50). In my mind, the "configuration-=
oriented" alternative seems at least as hard as the "forwarding-oriented" a=
lternative, is less robust, and certainly less flexible in terms of letting=
 the operator decide its fate in terms of how to perform each transition st=
ep.

Again, technical comments are very welcome. Mostly I would like to know if =
people understand and agree with the basic premise here, and if so whether =
"configuration-oriented" or "forwarding-oriented" is the best way forward. =
So far, I think the forwarding-oriented approach wins hands down, but then =
again I'm used to building routers that have lots of interfaces and operato=
rs that ask them to do all sorts of crazy things :-)=20

Thanks, and Happy Holidays in advance to those who will be celebrating soon=
,

- Mark
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From Carl.Wuyts@technicolor.com  Sun Dec 18 23:40:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA221F8B38 for ; Sun, 18 Dec 2011 23:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 nyD1bkGtDhHG for ; Sun, 18 Dec 2011 23:40:33 -0800 (PST)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24421F84E5 for ; Sun, 18 Dec 2011 23:40:11 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTu7qWh+G/oV/SqqdTuRnhe9Yc+mOdknJ@postini.com; Sun, 18 Dec 2011 23:40:32 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 08:39:03 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 08:39:25 +0100
From: Wuyts Carl 
To: Ole Troan , Gert Doering 
Date: Mon, 19 Dec 2011 08:39:23 +0100
Thread-Topic: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
Thread-Index: Acy6ZgmqLGQcJG4XT1SfRNVTRwnrvADuyQLw
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B2651@MOPESMBX01.eu.thmulti.com>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net> <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org>
In-Reply-To: <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org>
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: IPv6 Operations , "draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org" 
Subject: Re: [v6ops] I-D Action:	draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 07:40:33 -0000

Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

regs
Carl




-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of O=
le Troan
Sent: woensdag 14 december 2011 14:41
To: Gert Doering
Cc: IPv6 Operations; draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.=
org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning=
-00.txt

Gert,

>> in the case of a link to ISP A was down, the CPE could of course forward=
 traffic with SA =3D ISP A out ISP B's link. if it was stopped by ingress f=
iltering the host would get an ICMP back from the PE instead of the CPE.
>=20
> Would it?
>=20
> ISP B's PE has no route to send ISP A's prefix to that CPE, so how=20
> would the ICMP reach the host?

good point.

OK, for auto-detection of ingress filtering. we could use "BFD echo mode". =
like what we do for 6rd BR reachability check.
the CPE generates a packet with SA =3D DA =3D one of its own addresses from=
 ISP A. this packet it forwards to the ISP B.

cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From mark@townsley.net  Mon Dec 19 00:31:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C43221F89BA for ; Mon, 19 Dec 2011 00:31:35 -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_13=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 lXcF91V8BbVl for ; Mon, 19 Dec 2011 00:31:34 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2246F21F891D for ; Mon, 19 Dec 2011 00:31:33 -0800 (PST)
Received: by eekc14 with SMTP id c14so3819999eek.31 for ; Mon, 19 Dec 2011 00:31:33 -0800 (PST)
Received: by 10.213.105.212 with SMTP id u20mr4729757ebo.24.1324283492870; Mon, 19 Dec 2011 00:31:32 -0800 (PST)
Received: from ?IPv6:2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0? ([2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0]) by mx.google.com with ESMTPS id a60sm41811537eeb.4.2011.12.19.00.31.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 00:31:30 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB44B264D@MOPESMBX01.eu.thmulti.com>
Date: Mon, 19 Dec 2011 09:31:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <93E30FA4-E814-4AA3-B3FD-52CD4C1AB23F@townsley.net>
References:  <867F4B6A1672E541A94676D556793ACD0CB44B264D@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 08:31:35 -0000

On Dec 19, 2011, at 8:35 AM, Wuyts Carl wrote:

> Some feedback on the below, being a CPE vendor for residential market.
> First note that, although our main deployment is in the residential =
CPE market, we're not present in retail, so maybe my view is "spoiled" =
due to this.
>=20
> I don't believe in this configuration-oriented approach at all as it =
is mainly to complicated or not really a possible approach.  There are 4 =
possibilities listed in this scenario, where we would have to pick one =
from, but none of them are really suitable I think, for sure not the one =
where you'd have to run a "couple" of configuration attempts with =
timeouts etc" or "have to shut down intfs based upon ...".
> Although some of these can possibly covered through some scripting, =
this is nothing really one should force upon a CPE, in fact, to no other =
IP device either.  Let's stick to standard behavior, threating an IP =
intf as it should be, not try to enforce some "extra's" on top of them.  =
An IP intf gets enabled, and can start forwarding traffic if the =
forwarding is allowed upon it (so routes availabe etc).  If you want to =
accomplish the below, I think you've to force lots of policy on top of =
the present CPE's capabilities in this area, so a no-go I'd say.  Please =
don't mix a residential CPE with a full-blown business router.  Again =
this seems to be an attempt of enforcing some stuff upon the CPE, to be =
avoided I'd say (again).

Fully agree that the "configuration-oriented" approach is very =
problematic. Unfortunately, this was the path that 6204-bis seemed to =
have been headed down. I hope we're changing that course.

>=20
> I also see some replies on "what if multiple transition scenario's are =
being used at the same time, combining DSLite with 4over6 or whatever".  =
This is of course possible in multi-homed scenario's but again here the =
same applies.  Let's try to keep normal IP behavior in place, read =
forwarding-oriented approach, not try to enforce all kind of tricky =
things.  As our customers are operators, not end-users, dual-homed =
scenario's are not our main target, but I can't see any added value =
looking into this "configuration-oriented" approach.

I think you are saying the "forwarding-oriented" approach is preferred, =
given the alternative being the "configuration-oriented" approach. =
However, perhaps you are saying you really want to do "none of the =
above".=20

Problem is, you have to choose one or the other if you are going to =
support DS-Lite or 6rd. Take your pick. Neither is not an option.=20

- Mark

>=20
> My 2 cents
> Regs
> Carl
>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Mark Townsley
> Sent: woensdag 14 december 2011 18:27
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>=20
>=20
> Folks,
>=20
> We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20
>=20
> The requirements in RFC 6204 are based on a fundamental assumption =
that a CE router has a single active WAN interface for forwarding IPv4 =
and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:
>=20
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20=

>=20
> Digging deeper into transition between these states:
>=20
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is =
no problem when enabling one vs. the other.=20
>=20
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.
>=20
> For (3) there similarly is no problem when enabling tunneled IPv4 on =
an existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20
>=20
> I'd like to identify two strategies to deal with these situations.=20
>=20
> The first I will call "configuration-oriented". For this to work, one =
of the following assumptions must hold. None are pretty, but you MUST =
pick one to avoid solving how to forward traffic when multiple =
interfaces are enabled at the same time for a given IP version.=20
>=20
> (a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or=20
>=20
> (b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or
>=20
> (c) The CE router goes through an ordered set of configuration =
attempts in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20
>=20
> (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.
>=20
> The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally accepts packets on WAN =
ingress. This is "classic multihoming" and should work for any order of =
planned incremental transition steps, as well as failover and/or =
transient situations.
>=20
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis =
began adopting some of the "forwarding-based" requirements for IPv6, =
though DS-Lite remained in the "configuration-based" role for IPv4.=20
>=20
> Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.
>=20
> Again, technical comments are very welcome. Mostly I would like to =
know if people understand and agree with the basic premise here, and if =
so whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20
>=20
> Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,
>=20
> - Mark
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From mark@townsley.net  Mon Dec 19 00:49:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4E321F893C for ; Mon, 19 Dec 2011 00:49:56 -0800 (PST)
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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 0oX4MsCDqu9I for ; Mon, 19 Dec 2011 00:49:55 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0A21F8531 for ; Mon, 19 Dec 2011 00:49:55 -0800 (PST)
Received: by eekc14 with SMTP id c14so3832748eek.31 for ; Mon, 19 Dec 2011 00:49:54 -0800 (PST)
Received: by 10.14.9.164 with SMTP id 36mr3732444eet.127.1324284593221; Mon, 19 Dec 2011 00:49:53 -0800 (PST)
Received: from ?IPv6:2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0? ([2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0]) by mx.google.com with ESMTPS id z43sm41939600eef.7.2011.12.19.00.49.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 00:49:50 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2-232521633
From: Mark Townsley 
In-Reply-To: <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com>
Date: Mon, 19 Dec 2011 09:49:48 +0100
Message-Id: <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com>
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 08:49:57 -0000

--Apple-Mail-2-232521633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:

> Mark,
>=20
> Sent from my iPad
>=20
> On Dec 17, 2011, at 1:53 AM, "Mark Townsley"  =
wrote:
>=20
>>=20
>> On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:
>>=20
>>> Mark,
>>> Thanks. It is very useful.=20
>>>> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc)
>>> How to do "forwarding-oriented" in CPE to distinguish among the =
techniques such as classical DS-Lite and Light Weight 4over6?
>>=20
>> Our latest version attempts to tackle this:
>>=20
>> =
http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
> I read this draft, it is well written.

Thank you.

> In table one, we have used all 3 bits. Light Weight 4over6 is not on =
the list. How does the CE know it is going to be operated in which =
mechanism, if it is only forwarding-oriented?

It is assumed the CE naturally knows which interface types it supports =
because it had to implement them. The "forwarding-oriented" model =
followed in the document assumes that any can be configured at any time. =
If the CE supports 4over6, it will fit that into the policy table based =
on the main principles we outline in the draft. The example table is =
just that, an example of some technologies available today based on a =
set of base principles. If we agree on the principles, I think we can =
classify just about any new technology that we have now or comes along. =
In the case of 4over6, since the default policy we proposed ranks use of =
IPv6 transport very high, 4over6 would also be weighted very high.=20

In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native =
IPv4. Based on the principles in the draft, the use of IPv6 as a =
transport would place DS-lite on a preferred path vs. Native IPv4. So, =
when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear =
in the AFTR, while existing local NAPT entries time out or shut down =
naturally. It should be fairly seamless to the user, and allows for =
active failover as well in case the DS-Lite tunnel goes down for =
whatever reason.=20

> Then, do we have to to change this value by re-coding if each =
mechanism is added? Or make a CLI to change this value?

The policy is essentially a global preference in terms of v6 transport =
and NAPT state boiled down to a single point of default configuration. =
Follow the defaults, and there will be no need for CLI or otherwise. If =
you want to override the defaults, there is a single place to do so.=20

- Mark


>>=20
>> - Mark
>>=20
>>>=20
>>> - Tina
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf Of Mark Townsley
>>> Sent: Wednesday, December 14, 2011 9:27 AM
>>> To: v6ops@ietf.org Operations
>>> Subject: [v6ops] Up-leveling Transition Coexistence
>>>=20
>>>=20
>>> Folks,
>>>=20
>>> We have had a lot of lively discussion of late on the new sections =
in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20
>>>=20
>>> The requirements in RFC 6204 are based on a fundamental assumption =
that a CE router has a single active WAN interface for forwarding IPv4 =
and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:
>>>=20
>>> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
>>> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires =
H&S via L2TP, TSP, etc)=20
>>> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, =
etc)=20
>>>=20
>>> Digging deeper into transition between these states:
>>>=20
>>> For (1), IPv4 and IPv6 each share a single WAN interface, so there =
is no problem when enabling one vs. the other.=20
>>>=20
>>> For (2), when enabling tunneled IPv6 on an existing IPv4-only =
network there is no significant change in the basic model as each IP =
version still has its own distinct single WAN interface. Multihoming =
issues arise when enabling native IPv6 alongside tunneled IPv6 (needed =
for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces =
at the same time.
>>>=20
>>> For (3) there similarly is no problem when enabling tunneled IPv4 on =
an existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20
>>>=20
>>> I'd like to identify two strategies to deal with these situations.=20=

>>>=20
>>> The first I will call "configuration-oriented". For this to work, =
one of the following assumptions must hold. None are pretty, but you =
MUST pick one to avoid solving how to forward traffic when multiple =
interfaces are enabled at the same time for a given IP version.=20
>>>=20
>>> (a) =46rom the perspective of the CE router, the network supports =
only one type of interface for a given IP version, or=20
>>>=20
>>> (b) The CE router is configured in advance of any IP configuration =
to support only one type of interface for a given IP version, or
>>>=20
>>> (c) The CE router goes through an ordered set of configuration =
attempts in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20
>>>=20
>>> (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.
>>>=20
>>> The second strategy I will call "forwarding-oriented." In this =
model, configuration of any WAN interface method at any time is =
accepted. The CE follows forwarding rules in order to ensure packets =
make it out the right interface on WAN egress, and liberally accepts =
packets on WAN ingress. This is "classic multihoming" and should work =
for any order of planned incremental transition steps, as well as =
failover and/or transient situations.
>>>=20
>>> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis =
began adopting some of the "forwarding-based" requirements for IPv6, =
though DS-Lite remained in the "configuration-based" role for IPv4.=20
>>>=20
>>> Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.
>>>=20
>>> Again, technical comments are very welcome. Mostly I would like to =
know if people understand and agree with the basic premise here, and if =
so whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20
>>>=20
>>> Thanks, and Happy Holidays in advance to those who will be =
celebrating soon,
>>>=20
>>> - Mark
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20


--Apple-Mail-2-232521633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii









Mark,



Sent from my iPad




On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <mark@townsley.net> wrote:















On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:






Mark,

Thanks. It is very useful. 


(3) One Virtual IPv4 and one Native IPv6 =
interface (DS-Lite, 4rd, etc)



How to do "forwarding-oriented" in CPE to distinguish among the =
techniques such as classical DS-Lite and Light Weight 4over6?











Our latest version attempts to tackle this:













I read this draft, it is well =
written.

Thank =
you.

 In =
table one, we have used all 3 bits. Light Weight 4over6 is not on the =
list. How does the CE know it is going to be operated in which =
mechanism, if it is only forwarding-oriented? =


It is assumed the CE naturally =
knows which interface types it supports because it had to implement =
them. The "forwarding-oriented" model followed in the document assumes =
that any can be configured at any time. If the CE supports 4over6, it =
will fit that into the policy table based on the main principles we =
outline in the draft. The example table is just that, an example of some =
technologies available today based on a set of base principles. If we =
agree on the principles, I think we can classify just about any new =
technology that we have now or comes along. In the case of 4over6, since =
the default policy we proposed ranks use of IPv6 transport very high, =
4over6 would also be weighted very =
high. 

In terms of 6204-bis, we would only =
need to "rank" DS-Lite vs. Native IPv4. Based on the principles in the =
draft, the use of IPv6 as a transport would place DS-lite on a preferred =
path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, =
new NAPT entries appear in the AFTR, while existing local NAPT entries =
time out or shut down naturally. It should be fairly seamless to the =
user, and allows for active failover as well in case the DS-Lite tunnel =
goes down for whatever reason. 

Then, do we have to to change =
this value
 by re-coding if each mechanism is added? Or make a CLI to change this =
value?

The policy is =
essentially a global preference in terms of v6 transport and NAPT state =
boiled down to a single point of default configuration. Follow the =
defaults, and there will be no need for CLI or otherwise. If you want to =
override the defaults, there is a single place to do =
so. 

- =
Mark















- Mark








- Tina





-----Original Message-----

From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley

Sent: Wednesday, December 14, 2011 9:27 AM

To: v6ops@ietf.org Operations

Subject: [v6ops] Up-leveling Transition Coexistence





Folks,



We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to =
work together on a residential CE router. I'd like to summarize what I =
think the main architectural issue is alongside a possible
 solution framework. Technical comments are very welcome, but let's also =
try and keep them thoughtful and at a pace that everyone can keep up =
amidst their day-jobs.




The requirements in RFC 6204 are based on a fundamental assumption that =
a CE router has a single active WAN interface for forwarding IPv4 and =
IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together
 forces us to at least reconsider this basic assumption.  Breaking =
this down at bit, there are three possible steady-state combinations of =
"native" and "virtual" (tunneled) dual-stack connectivity methods that =
do not break the basic forwarding model of a single
 WAN egress per IP version:



(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 

(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires =
H&S via L2TP, TSP, etc)


(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) =




Digging deeper into transition between these states:



For (1), IPv4 and IPv6 each share a single WAN interface, so there is no =
problem when enabling one vs. the other.




For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled
 IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two =
distinct interfaces at the same time.



For (3) there similarly is no problem when enabling tunneled IPv4 on an =
existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that
 has native IPv4 available at the same time.  



I'd like to identify two strategies to deal with these situations. 



The first I will call "configuration-oriented". For this to work, one of =
the following assumptions must hold. None are pretty, but you MUST pick =
one to avoid solving how to forward traffic when multiple interfaces are =
enabled at the same time for a given IP
 version. 



(a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or




(b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or



(c) The CE router goes through an ordered set of configuration attempts =
in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.




(d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state,
 but requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.



The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally
 accepts packets on WAN ingress. This is "classic multihoming" and =
should work for any order of planned incremental transition steps, as =
well as failover and/or transient situations.



After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began =
adopting some of the "forwarding-based" requirements for IPv6, though =
DS-Lite remained in the "configuration-based" role for IPv4.




Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order
 to support DS-Lite. Neither are rocket science, but teaching the CE to =
properly forward when faced with more than one alternative egress =
interface has been labeled "hard" (though as an interesting data point I =
have found IPv4 routers that support multiple
 WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its
 fate in terms of how to perform each transition step.



Again, technical comments are very welcome. Mostly I would like to know =
if people understand and agree with the basic premise here, and if so =
whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented
 approach wins hands down, but then again I'm used to building routers =
that have lots of interfaces and operators that ask them to do all sorts =
of crazy things :-)




Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,



- Mark

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/=
mailman/listinfo/v6ops


















=

--Apple-Mail-2-232521633--

From Carl.Wuyts@technicolor.com  Mon Dec 19 01:07:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7F21F84D8 for ; Mon, 19 Dec 2011 01:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 TprYtTnMMhfH for ; Mon, 19 Dec 2011 01:07:25 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id B0E6721F84A9 for ; Mon, 19 Dec 2011 01:07:23 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTu7+ylxU/pcDz7lmAaGcr7IpyChVNYjF@postini.com; Mon, 19 Dec 2011 01:07:24 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 10:05:16 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 10:05:37 +0100
From: Wuyts Carl 
To: Mark Townsley 
Date: Mon, 19 Dec 2011 10:05:35 +0100
Thread-Topic: [v6ops] Up-leveling Transition Coexistence
Thread-Index: Acy+KKCZ49J2rMQMT3GwoJn4mMEIpQABK9mg
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B26E2@MOPESMBX01.eu.thmulti.com>
References:  <867F4B6A1672E541A94676D556793ACD0CB44B264D@MOPESMBX01.eu.thmulti.com> <93E30FA4-E814-4AA3-B3FD-52CD4C1AB23F@townsley.net>
In-Reply-To: <93E30FA4-E814-4AA3-B3FD-52CD4C1AB23F@townsley.net>
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: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 09:07:26 -0000

Sorry, indeed, forwarding preferred over configuration-oriented, if any mus=
t be chosen :-)


Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90


Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n

Help preserve the color of our world - Think before you print.




-----Original Message-----
From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: maandag 19 december 2011 9:31
To: Wuyts Carl
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence


On Dec 19, 2011, at 8:35 AM, Wuyts Carl wrote:

> Some feedback on the below, being a CPE vendor for residential market.
> First note that, although our main deployment is in the residential CPE m=
arket, we're not present in retail, so maybe my view is "spoiled" due to th=
is.
>=20
> I don't believe in this configuration-oriented approach at all as it is m=
ainly to complicated or not really a possible approach.  There are 4 possib=
ilities listed in this scenario, where we would have to pick one from, but =
none of them are really suitable I think, for sure not the one where you'd =
have to run a "couple" of configuration attempts with timeouts etc" or "hav=
e to shut down intfs based upon ...".
> Although some of these can possibly covered through some scripting, this =
is nothing really one should force upon a CPE, in fact, to no other IP devi=
ce either.  Let's stick to standard behavior, threating an IP intf as it sh=
ould be, not try to enforce some "extra's" on top of them.  An IP intf gets=
 enabled, and can start forwarding traffic if the forwarding is allowed upo=
n it (so routes availabe etc).  If you want to accomplish the below, I thin=
k you've to force lots of policy on top of the present CPE's capabilities i=
n this area, so a no-go I'd say.  Please don't mix a residential CPE with a=
 full-blown business router.  Again this seems to be an attempt of enforcin=
g some stuff upon the CPE, to be avoided I'd say (again).

Fully agree that the "configuration-oriented" approach is very problematic.=
 Unfortunately, this was the path that 6204-bis seemed to have been headed =
down. I hope we're changing that course.

>=20
> I also see some replies on "what if multiple transition scenario's are be=
ing used at the same time, combining DSLite with 4over6 or whatever".  This=
 is of course possible in multi-homed scenario's but again here the same ap=
plies.  Let's try to keep normal IP behavior in place, read forwarding-orie=
nted approach, not try to enforce all kind of tricky things.  As our custom=
ers are operators, not end-users, dual-homed scenario's are not our main ta=
rget, but I can't see any added value looking into this "configuration-orie=
nted" approach.

I think you are saying the "forwarding-oriented" approach is preferred, giv=
en the alternative being the "configuration-oriented" approach. However, pe=
rhaps you are saying you really want to do "none of the above".=20

Problem is, you have to choose one or the other if you are going to support=
 DS-Lite or 6rd. Take your pick. Neither is not an option.=20

- Mark

>=20
> My 2 cents
> Regs
> Carl
>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=
 Mark Townsley
> Sent: woensdag 14 december 2011 18:27
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>=20
>=20
> Folks,
>=20
> We have had a lot of lively discussion of late on the new sections in 620=
4-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together =
on a residential CE router. I'd like to summarize what I think the main arc=
hitectural issue is alongside a possible solution framework. Technical comm=
ents are very welcome, but let's also try and keep them thoughtful and at a=
 pace that everyone can keep up amidst their day-jobs.=20
>=20
> The requirements in RFC 6204 are based on a fundamental assumption that a=
 CE router has a single active WAN interface for forwarding IPv4 and IPv6 t=
raffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4=
 via DS-lite and IPv4 via Native together forces us to at least reconsider =
this basic assumption.  Breaking this down at bit, there are three possible=
 steady-state combinations of "native" and "virtual" (tunneled) dual-stack =
connectivity methods that do not break the basic forwarding model of a sing=
le WAN egress per IP version:
>=20
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S vi=
a L2TP, TSP, etc)=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20
>=20
> Digging deeper into transition between these states:
>=20
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is no =
problem when enabling one vs. the other.=20
>=20
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network the=
re is no significant change in the basic model as each IP version still has=
 its own distinct single WAN interface. Multihoming issues arise when enabl=
ing native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IP=
v6 may be enabled on two distinct interfaces at the same time.
>=20
> For (3) there similarly is no problem when enabling tunneled IPv4 on an e=
xisting IPv6-only network, and I have been told that there are greenfield d=
eployments just like this happening. The multihoming issues arise when enab=
ling tunneled IPv4 on a network that has native IPv4 available at the same =
time. =20
>=20
> I'd like to identify two strategies to deal with these situations.=20
>=20
> The first I will call "configuration-oriented". For this to work, one of =
the following assumptions must hold. None are pretty, but you MUST pick one=
 to avoid solving how to forward traffic when multiple interfaces are enabl=
ed at the same time for a given IP version.=20
>=20
> (a) From the perspective of the CE router, the network supports only one =
type of interface for a given IP version, or=20
>=20
> (b) The CE router is configured in advance of any IP configuration to sup=
port only one type of interface for a given IP version, or
>=20
> (c) The CE router goes through an ordered set of configuration attempts i=
n series, each requiring a timeout before moving to the next. Transition-or=
iented changes after steady-state is reached will require "reboot" to go th=
rough the ordered process from scratch.=20
>=20
> (d) The CE router chooses one type of interface and shuts down all others=
 based on a predetermined priority when more than one interface with the sa=
me IP version is configured. This allows parallel configuration attempts an=
d changes after reaching steady-state, but requires the CE router and netwo=
rk to manage a "flash cut" from one configured interface to the other and m=
ay be prone to tricky race-conditions.
>=20
> The second strategy I will call "forwarding-oriented." In this model, con=
figuration of any WAN interface method at any time is accepted. The CE foll=
ows forwarding rules in order to ensure packets make it out the right inter=
face on WAN egress, and liberally accepts packets on WAN ingress. This is "=
classic multihoming" and should work for any order of planned incremental t=
ransition steps, as well as failover and/or transient situations.
>=20
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began a=
dopting some of the "forwarding-based" requirements for IPv6, though DS-Lit=
e remained in the "configuration-based" role for IPv4.=20
>=20
> Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-=
01.txt, which is a general set of IPv6 requirements for multihoming with 6r=
d-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be =
publishing the same for IPv4 in order to support DS-Lite. Neither are rocke=
t science, but teaching the CE to properly forward when faced with more tha=
n one alternative egress interface has been labeled "hard" (though as an in=
teresting data point I have found IPv4 routers that support multiple WAN in=
terfaces at the same time for less than $50). In my mind, the "configuratio=
n-oriented" alternative seems at least as hard as the "forwarding-oriented"=
 alternative, is less robust, and certainly less flexible in terms of letti=
ng the operator decide its fate in terms of how to perform each transition =
step.
>=20
> Again, technical comments are very welcome. Mostly I would like to know i=
f people understand and agree with the basic premise here, and if so whethe=
r "configuration-oriented" or "forwarding-oriented" is the best way forward=
. So far, I think the forwarding-oriented approach wins hands down, but the=
n again I'm used to building routers that have lots of interfaces and opera=
tors that ask them to do all sorts of crazy things :-)=20
>=20
> Thanks, and Happy Holidays in advance to those who will be celebrating so=
on,
>=20
> - Mark
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From mark@townsley.net  Mon Dec 19 01:20:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7521F8B44 for ; Mon, 19 Dec 2011 01:20:30 -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.000,  BAYES_00=-2.599, J_CHICKENPOX_13=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 6PzbFU4Ha54D for ; Mon, 19 Dec 2011 01:20:30 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73321F8A6F for ; Mon, 19 Dec 2011 01:20:29 -0800 (PST)
Received: by eekc14 with SMTP id c14so3855376eek.31 for ; Mon, 19 Dec 2011 01:20:29 -0800 (PST)
Received: by 10.213.35.20 with SMTP id n20mr4825416ebd.50.1324286429119; Mon, 19 Dec 2011 01:20:29 -0800 (PST)
Received: from ?IPv6:2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0? ([2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0]) by mx.google.com with ESMTPS id z43sm42222833eef.7.2011.12.19.01.20.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 01:20:27 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <90491DAE-BF52-4ED3-990F-FD5E91779AF1@cisco.com>
Date: Mon, 19 Dec 2011 10:20:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <90491DAE-BF52-4ED3-990F-FD5E91779AF1@cisco.com>
To: Fred Baker 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations , draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 09:20:31 -0000

On Dec 18, 2011, at 4:59 AM, Fred Baker wrote:

>=20
> On Dec 13, 2011, at 5:21 PM, Brian E Carpenter wrote:
>=20
>> It seems to assume that
>> ingress filtering is inevitable, but this is very restrictive as far
>> as seamless multihoming goes. If we can one day get to a situation
>> where ingress filtering is automatically tailored for multihomed =
customers,
>> we will need each SRIB entry to point to multiple DRIBs accordingly.
>=20
> To be really honest, I think you need to demonstrate that there is =
interest in achieving the nirvana you desire. Generally speaking, a =
service provider will do what you pay him to do, and anything that he =
can't describe in generic "service" terms will be generally offered, if =
at all, at a high price. Couple that with the general behavior of =
markets - seeking the lowest price for a reasonable set of services, =
and...

The demonstration of interest is the overwhelming operator support of =
the scope laid out in 6204-bis which includes coexistence of 6rd, Native =
IPv6 and IPv4, and DS-Lite. That, and on the 6rd side at least, the =
largest 6rd deployment (and largest IPv6 deployment for that matter) in =
the world letting us know that this is how they would like to bring up =
IPv6 alongside 6rd (re: 6rd-sunsetting). =20

Please don't confuse this work as primarily motivated by a "nirvana" of =
multiple ISP support on CE Routers. The solution laid out by Ole and I =
only happens to use multihoming techniques because that is in fact what =
you largely end up needing to tackle when you build a CE that supports =
6rd, Native and DS-Lite together. Whether a CE router decides to include =
multiple physical WAN interfaces and market it as what is today referred =
to as "Dual-WAN" is up to its product management team.=20

The issue at hand is that as of a few months ago we have 6204-bis that =
plainly outlines that a CE router needs to be able to support 6rd, =
native, and DS-Lite together. When it comes to running code, it's an =
observable fact that a 6rd IPv6 interface next to a native IPv6 =
interface looks like two IPv6 interfaces to the routing system. =
Similarly. a Native IPv4 interface next to a DS-Lite IPv4 over IPv6 =
tunnel looks like two CE IPv4 WAN interfaces.=20

So, 6204-bis stepped into this, though perhaps it is more fair to say =
softwires did even before with the definition of 6rd and DS-Lite at all. =
It's incumbent upon us to at least state how these can be made to work =
together in a way that operates.=20

- Mark



> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From ichiroumakino@gmail.com  Mon Dec 19 02:50:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D321921F8B6B for ; Mon, 19 Dec 2011 02:50:10 -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_13=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 unm4cecJoW-0 for ; Mon, 19 Dec 2011 02:50:10 -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 CDAF721F84FA for ; Mon, 19 Dec 2011 02:50:09 -0800 (PST)
Received: by werb14 with SMTP id b14so1372211wer.31 for ; Mon, 19 Dec 2011 02:50:07 -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=mnVltai/5/zMebEYfdfdgCk2XUIE0LxIu2dxg8HhP+U=; b=ZmvNzePaF1E/snjpJjO9czJE35Mdhdnd4UWTrgwrPm6kN+SXzN7jrhjqPXuZAFQO1x tlFawK0XS6wNONxYRl7lVrMZ2KsYk5Qnbmyw8C18wxbg4+Oe8XWqyji/yO3kJZTeKkbc M1BvL+AwkzsfwEVMCku1prEwdA9Ugvgp1WIrQ=
Received: by 10.216.132.67 with SMTP id n45mr6722674wei.21.1324291807716; Mon, 19 Dec 2011 02:50:07 -0800 (PST)
Received: from dhcp-10-61-96-210.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id hq5sm25241948wib.7.2011.12.19.02.50.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 02:50:06 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB44B2651@MOPESMBX01.eu.thmulti.com>
Date: Mon, 19 Dec 2011 17:49:56 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <29FB1C13-AED3-4B4A-8F76-EA3B928DD997@employees.org>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net> <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org> <867F4B6A1672E541A94676D556793ACD0CB44B2651@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations , "draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 10:50:11 -0000

Carl,

> Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

as Gert pointed out this isn't really BFD.
it is whatever packet you'd like to send yourself forwarded through the =
PE.

with regards to your question, too early to say.

cheers,
Ole

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Ole Troan
> Sent: woensdag 14 december 2011 14:41
> To: Gert Doering
> Cc: IPv6 Operations; =
draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org
> Subject: Re: [v6ops] I-D Action: =
draft-townsley-troan-ipv6-ce-transitioning-00.txt
>=20
> Gert,
>=20
>>> in the case of a link to ISP A was down, the CPE could of course =
forward traffic with SA =3D ISP A out ISP B's link. if it was stopped by =
ingress filtering the host would get an ICMP back from the PE instead of =
the CPE.
>>=20
>> Would it?
>>=20
>> ISP B's PE has no route to send ISP A's prefix to that CPE, so how=20
>> would the ICMP reach the host?
>=20
> good point.
>=20
> OK, for auto-detection of ingress filtering. we could use "BFD echo =
mode". like what we do for 6rd BR reachability check.
> the CPE generates a packet with SA =3D DA =3D one of its own addresses =
from ISP A. this packet it forwards to the ISP B.
>=20
> cheers,
> Ole
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From gert@space.net  Mon Dec 19 02:56:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F821F8B51 for ; Mon, 19 Dec 2011 02:56:30 -0800 (PST)
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 t78rONPgBYoQ for ; Mon, 19 Dec 2011 02:56:29 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 750E321F8B4A for ; Mon, 19 Dec 2011 02:56:28 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C90A6F8955 for ; Mon, 19 Dec 2011 11:56:25 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B3AC4F893D for ; Mon, 19 Dec 2011 11:56:25 +0100 (CET)
Received: (qmail 45645 invoked by uid 1007); 19 Dec 2011 11:56:25 +0100
Date: Mon, 19 Dec 2011 11:56:25 +0100
From: Gert Doering 
To: Wuyts Carl 
Message-ID: <20111219105625.GZ72014@Space.Net>
References: <20111207140615.6706.64255.idtracker@ietfa.amsl.com> <4EE7FA27.2030409@gmail.com> <25C02113-D448-4B3F-A9C8-CDCF9B5D612B@employees.org> <20111214100624.GF72014@Space.Net> <68CE9775-BCC1-48D8-A777-374352E0A45C@employees.org> <867F4B6A1672E541A94676D556793ACD0CB44B2651@MOPESMBX01.eu.thmulti.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EI1INYmCmoCyddgn"
Content-Disposition: inline
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB44B2651@MOPESMBX01.eu.thmulti.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "draft-townsley-troan-ipv6-ce-transitioning@tools.ietf.org" , IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 10:56:30 -0000

--EI1INYmCmoCyddgn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Dec 19, 2011 at 08:39:23AM +0100, Wuyts Carl wrote:
> Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

Well, I'd love to see BFD supported, but given that the PE usually doesn't
properly support BFD for large-scale deployments either, I'm not putting
much hopes into it.

Regarding Ole's proposal - that's "operating like BFD in echo mode", but
(I think) it is not BFD-as-a-protocol, just the way it works.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

--EI1INYmCmoCyddgn
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTu8YWakuBuNlUUl1AQKmqQP/dfEc4cSi+OLklv7S3ImEN+0ojBBkP5FW
DaUTQIlmaBfPGS4ORAU3Jt55bFuAB0J1g0sTtxREAte4lJClTi8me3gwDc0lDkOq
6bwE3U899/XEHM3fG0a+6RfAu5t5DVzb7kCVAcPsQXcmkkeQAjvGupNMWgp2sfN6
XQyz98rKLvg=
=Wiug
-----END PGP SIGNATURE-----

--EI1INYmCmoCyddgn--

From shemant@cisco.com  Mon Dec 19 06:56:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4502321F8B4A for ; Mon, 19 Dec 2011 06:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 c0EQ1rDtoFYt for ; Mon, 19 Dec 2011 06:56:43 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B8C8C21F853B for ; Mon, 19 Dec 2011 06:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2091; q=dns/txt; s=iport; t=1324306603; x=1325516203; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to:cc; bh=gX0Zan1+MiltOGoROQ6pPV3t7TfOb8hE2Uj3/CazeBo=; b=Pj8pijQY6NdD9y/DTdviO+7mtDNSnYRCc90qA9pKSko5GgJ2hT7/2vMF /QSljWbk4pBSMZHJYR5DEGmP4HejaATAAMa08lMY5bgnZ7HLUX1SzSKCE yM6WkaNDaPi+ceCMUgrL4vw1rwHewKWU3oFXbDka3Ts4mfRz/VcK78ZH+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AACRQ706tJV2b/2dsb2JhbABDmxOQToEFgXIBAQEDARIBHQo/BQcEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHWJlzAZ4iiyFjBIg2nxU
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; d="scan'208";a="45198001"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 19 Dec 2011 14:56:43 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBJEuhZk008584;  Mon, 19 Dec 2011 14:56:43 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 19 Dec 2011 08:56:43 -0600
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: Mon, 19 Dec 2011 08:56:42 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30398D659@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy+OF5RV1PN/JmhTw2fg/zH6VdlYQAJXwYQAAAg2bA=
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com> <4EEF05A5.3000601@fud.no> <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com> <4EEF10CA.7030301@fud.no> 
From: "Hemant Singh (shemant)" 
To: "Tore Anderson" , "Wuyts Carl" 
X-OriginalArrivalTime: 19 Dec 2011 14:56:43.0243 (UTC) FILETIME=[6BD81BB0:01CCBE5E]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 14:56:44 -0000

-----Original Message-----
From: Hemant Singh (shemant)=20
Sent: Monday, December 19, 2011 9:56 AM
To: 'Tore Anderson'; Wuyts Carl
Cc: RFC Errata System; Wes Beebee (wbeebee); c.donley@cablelabs.com;
barbara.stark@att.com; ot@cisco.com; dromasca@avaya.com;
rbonica@juniper.net; fred.baker@cisco.com; joelja@bogus.com;
v6ops@ietf.org
Subject: RE: [v6ops] [Technical Errata Reported] RFC6204 (3054)

This errata seems to be a lazy implementation which does not want to
deal with complexity of the behavior in L-13.  The errata is suggesting
to augment the text with a zero value for Valid Lifetime and that looks
to be an enhancement rather than an errata.  Since rfc6204bis is
supposed to replace rfc6204, rfc6204bis can change the text for L-13 to
include the enhancement.

Hemant

-----Original Message-----
From: Tore Anderson [mailto:tore@fud.no]=20
Sent: Monday, December 19, 2011 5:24 AM
To: Wuyts Carl
Cc: RFC Errata System; Hemant Singh (shemant); Wes Beebee (wbeebee);
c.donley@cablelabs.com; barbara.stark@att.com; ot@cisco.com;
dromasca@avaya.com; rbonica@juniper.net; fred.baker@cisco.com;
joelja@bogus.com; v6ops@ietf.org
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> It'll be backwards compatible, but the =3D0 was initially not in, so
> has to be added into the RA daemon..

Carl,

If your RA daemon currently implements VL=3D,
you don't have to change anything in order to be in compliance with the
new L-13, and you should feel free ignore the errata completely. I don't
understand why you feel otherwise?

What prompted me to submit the errata was discussions with a CPE
manufacturer that felt the current L-13 requirement was needlessly
complex, compared to simply always sending VL=3D0. The intention is to
make it easier, not harder, for a CPE manufacturer to correctly
implement L-13 by allowing two alternative methods (that both accomplish
the exact same thing).

--=20
Tore Anderson

From Carl.Wuyts@technicolor.com  Sun Dec 18 23:58:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212AA21F85D1 for ; Sun, 18 Dec 2011 23:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 2PThUvFvI9Re for ; Sun, 18 Dec 2011 23:58:22 -0800 (PST)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 12B8D21F858C for ; Sun, 18 Dec 2011 23:58:12 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTu7ujQfBaQVPxJXQXyluh5oSL1YNF1YI@postini.com; Sun, 18 Dec 2011 23:58:22 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 08:52:21 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 08:52:19 +0100
From: Wuyts Carl 
To: RFC Errata System , "shemant@cisco.com" , "wbeebee@cisco.com" , "c.donley@cablelabs.com" , "barbara.stark@att.com" , "ot@cisco.com" , "dromasca@avaya.com" , "rbonica@juniper.net" , "fred.baker@cisco.com" , "joelja@bogus.com" 
Date: Mon, 19 Dec 2011 08:52:17 +0100
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy8TsdIcx93JpK1R1CWDz2o2hF+6AB03b2g
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com>
References: <20111216184550.719D272E004@rfc-editor.org>
In-Reply-To: <20111216184550.719D272E004@rfc-editor.org>
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
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:06 -0800
Cc: "v6ops@ietf.org" , "tore@fud.no" 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 07:58:23 -0000

Well, seems like this one keeps changing.  Behavior first as described in R=
FC4862, then RFC6204, now RFC6204bis.  We've had complaints in the past tha=
t CPE's are not IPv6 ready (or taking too long to become IPv6 ready), but y=
et again, IETF WGs keep changing behavior on this, so once again, the CPE m=
ust be adjusted, so not really helping on this matter.

Regs
Carl





-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R=
FC Errata System
Sent: vrijdag 16 december 2011 19:46
To: shemant@cisco.com; wbeebee@cisco.com; c.donley@cablelabs.com; barbara.s=
tark@att.com; ot@cisco.com; dromasca@avaya.com; rbonica@juniper.net; fred.b=
aker@cisco.com; joelja@bogus.com
Cc: v6ops@ietf.org; tore@fud.no; rfc-editor@rfc-editor.org
Subject: [v6ops] [Technical Errata Reported] RFC6204 (3054)


The following errata report has been submitted for RFC6204, "Basic Requirem=
ents for IPv6 Customer Edge Routers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6204&eid=3D3054

--------------------------------------
Type: Technical
Reported by: Tore Anderson 

Section: 4.3

Original Text
-------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of the lower of the current Valid Lifetime and 2
          hours (which must be decremented in real time) in a Router
          Advertisement message as described in Section 5.5.3, (e) of
          [RFC4862].

Corrected Text
--------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero, or b) the lower of the current
          Valid Lifetime and 2 hours (which must be decremented in real
          time), in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

Notes
-----
The original text in L-13 prohibits implementers from transmitting Valid Li=
fetime =3D 0 whenever a prefix needs to be invalidated. It should not, beca=
use transmitting VL=3D0 is easier to implement than sending "the lower of t=
he current Valid Lifetime and 2 hours (which must be decremented in real ti=
me)".

Transmitting Valid Lifetime =3D 0 has the exact same effect on a host as th=
e procedure described in the original text, i.e., it will the host to lower=
 (but never raise) the remaining valid lifetime to 7200 seconds.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use "Re=
ply All" to discuss whether it should be verified or rejected. When a decis=
ion is reached, the verifying party (IESG) can log in to change the status =
and edit the report, if necessary.=20

--------------------------------------
RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09)
--------------------------------------
Title               : Basic Requirements for IPv6 Customer Edge Routers
Publication Date    : April 2011
Author(s)           : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, E=
d.
Category            : INFORMATIONAL
Source              : IPv6 Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From Carl.Wuyts@technicolor.com  Mon Dec 19 01:55:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB8021F8B3F for ; Mon, 19 Dec 2011 01:55:48 -0800 (PST)
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=[AWL=0.300,  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 owEbmkYDCpIo for ; Mon, 19 Dec 2011 01:55:47 -0800 (PST)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6821F8B33 for ; Mon, 19 Dec 2011 01:55:38 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTu8KFYVFtGzIx8U+d/jAExWk8kvwEtPO@postini.com; Mon, 19 Dec 2011 01:55:47 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 10:52:25 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 10:52:26 +0100
From: Wuyts Carl 
To: Tore Anderson 
Date: Mon, 19 Dec 2011 10:52:25 +0100
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy+Mboevkjb0pf7QUOEyoZQFwen8gAAgK3g
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com>
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com> <4EEF05A5.3000601@fud.no>
In-Reply-To: <4EEF05A5.3000601@fud.no>
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
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:06 -0800
Cc: "ot@cisco.com" , "fred.baker@cisco.com" , "v6ops@ietf.org" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 09:55:48 -0000

It'll be backwards compatible, but the =3D0 was initially not in, so has to=
 be added into the RA daemon..
I'm not saying this is very difficult, but yet another (small) change. It h=
as of course also impact on our internal testing etc.

Carl Wuyts





-----Original Message-----
From: Tore Anderson [mailto:tore@fud.no]=20
Sent: maandag 19 december 2011 10:37
To: Wuyts Carl
Cc: RFC Errata System; shemant@cisco.com; wbeebee@cisco.com; c.donley@cable=
labs.com; barbara.stark@att.com; ot@cisco.com; dromasca@avaya.com; rbonica@=
juniper.net; fred.baker@cisco.com; joelja@bogus.com; v6ops@ietf.org
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> Well, seems like this one keeps changing.  Behavior first as described=20
> in RFC4862, then RFC6204, now RFC6204bis.  We've had complaints in the=20
> past that CPE's are not IPv6 ready (or taking too long to become IPv6=20
> ready), but yet again, IETF WGs keep changing behavior on this, so=20
> once again, the CPE must be adjusted, so not really helping on this=20
> matter.

Carl,

Could you explain how, exactly, you interpret the proposed errata to requir=
e CPE adjustments? It is intended to be backwards compatible with
L-13 in RFC 6204/6204bis.

Thanks,
--
Tore Anderson

From tore@fud.no  Mon Dec 19 01:36:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C221F8B25 for ; Mon, 19 Dec 2011 01:36:53 -0800 (PST)
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 9lOo2vevnYoT for ; Mon, 19 Dec 2011 01:36:53 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [87.238.35.20]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5F21F8A7D for ; Mon, 19 Dec 2011 01:36:53 -0800 (PST)
Received: from [2001:840:3035:0:230:1bff:febc:7f23] (port=36086 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.71) (envelope-from ) id 1RcZe9-0001eT-R0; Mon, 19 Dec 2011 10:36:37 +0100
Message-ID: <4EEF05A5.3000601@fud.no>
Date: Mon, 19 Dec 2011 10:36:37 +0100
From: Tore Anderson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Wuyts Carl 
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:07 -0800
Cc: "ot@cisco.com" , "fred.baker@cisco.com" , "v6ops@ietf.org" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 09:59:18 -0000

* Wuyts Carl

> Well, seems like this one keeps changing.  Behavior first as
> described in RFC4862, then RFC6204, now RFC6204bis.  We've had
> complaints in the past that CPE's are not IPv6 ready (or taking too
> long to become IPv6 ready), but yet again, IETF WGs keep changing
> behavior on this, so once again, the CPE must be adjusted, so not
> really helping on this matter.

Carl,

Could you explain how, exactly, you interpret the proposed errata to
require CPE adjustments? It is intended to be backwards compatible with
L-13 in RFC 6204/6204bis.

Thanks,
-- 
Tore Anderson

From tore@fud.no  Mon Dec 19 02:24:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B3D21F8B65 for ; Mon, 19 Dec 2011 02:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.458
X-Spam-Level: 
X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141,  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 iaOqn2BWnCWS for ; Mon, 19 Dec 2011 02:24:26 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [87.238.35.20]) by ietfa.amsl.com (Postfix) with ESMTP id A0EAA21F8B59 for ; Mon, 19 Dec 2011 02:24:25 -0800 (PST)
Received: from [2001:840:3035:0:230:1bff:febc:7f23] (port=40189 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.71) (envelope-from ) id 1RcaOC-0002mj-DX; Mon, 19 Dec 2011 11:24:12 +0100
Message-ID: <4EEF10CA.7030301@fud.no>
Date: Mon, 19 Dec 2011 11:24:10 +0100
From: Tore Anderson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Wuyts Carl 
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com> <4EEF05A5.3000601@fud.no> <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:07 -0800
Cc: "ot@cisco.com" , "fred.baker@cisco.com" , "v6ops@ietf.org" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 10:24:26 -0000

* Wuyts Carl

> It'll be backwards compatible, but the =0 was initially not in, so
> has to be added into the RA daemon..

Carl,

If your RA daemon currently implements VL=«the lower of the current
Valid Lifetime and 2 hours (which must be decremented in real time)»,
you don't have to change anything in order to be in compliance with the
new L-13, and you should feel free ignore the errata completely. I don't
understand why you feel otherwise?

What prompted me to submit the errata was discussions with a CPE
manufacturer that felt the current L-13 requirement was needlessly
complex, compared to simply always sending VL=0. The intention is to
make it easier, not harder, for a CPE manufacturer to correctly
implement L-13 by allowing two alternative methods (that both accomplish
the exact same thing).

-- 
Tore Anderson

From Carl.Wuyts@technicolor.com  Mon Dec 19 02:31:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1154B21F8B6C for ; Mon, 19 Dec 2011 02:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.359
X-Spam-Level: 
X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240,  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 N9OO9sX0cPZH for ; Mon, 19 Dec 2011 02:31:36 -0800 (PST)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAB21F8B67 for ; Mon, 19 Dec 2011 02:31:26 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTu8Sebqei9a/zZhCCptMst9geNPhHixX@postini.com; Mon, 19 Dec 2011 02:31:36 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 19 Dec 2011 11:29:02 +0100
Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Dec 2011 11:29:22 +0100
From: Wuyts Carl 
To: Tore Anderson 
Date: Mon, 19 Dec 2011 11:29:20 +0100
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy+OF7CQEYD+vQkQ5WSlX/kIhR/WQAACjPg
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB44B279F@MOPESMBX01.eu.thmulti.com>
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com> <4EEF05A5.3000601@fud.no> <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com> <4EEF10CA.7030301@fud.no>
In-Reply-To: <4EEF10CA.7030301@fud.no>
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
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:07 -0800
Cc: "ot@cisco.com" , "fred.baker@cisco.com" , "v6ops@ietf.org" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 10:31:37 -0000

I agree that always sending 0 is easier and less complex.
But we're always trying to stick very close to the standards, so have imple=
mented it the way now without =3D0, and I'm aware that we can ignore the er=
rata.
On the other hand, this will mean that certain CPEs send =3D0, others don't=
, so try to avoid this.

Anyway, my point is that I see too many changes lately for the CPE.  Don't =
forget we're "just" a residential CPE.  Small things like this, but bigger =
things like potential changes in dhcpv6 state machine (e.g. the idea to hav=
e separate messages for discover etc) are not beneficial to get some CPEs p=
erforming well/steady in IPv6.

Carl Wuyts




-----Original Message-----
From: Tore Anderson [mailto:tore@fud.no]=20
Sent: maandag 19 december 2011 11:24
To: Wuyts Carl
Cc: RFC Errata System; shemant@cisco.com; wbeebee@cisco.com; c.donley@cable=
labs.com; barbara.stark@att.com; ot@cisco.com; dromasca@avaya.com; rbonica@=
juniper.net; fred.baker@cisco.com; joelja@bogus.com; v6ops@ietf.org
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> It'll be backwards compatible, but the =3D0 was initially not in, so has=
=20
> to be added into the RA daemon..

Carl,

If your RA daemon currently implements VL=3D, you don't =
have to change anything in order to be in compliance with the new L-13, and=
 you should feel free ignore the errata completely. I don't understand why =
you feel otherwise?

What prompted me to submit the errata was discussions with a CPE manufactur=
er that felt the current L-13 requirement was needlessly complex, compared =
to simply always sending VL=3D0. The intention is to make it easier, not ha=
rder, for a CPE manufacturer to correctly implement L-13 by allowing two al=
ternative methods (that both accomplish the exact same thing).

--
Tore Anderson

From shemant@cisco.com  Mon Dec 19 06:55:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950FF21F853B for ; Mon, 19 Dec 2011 06:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 TWm44c1CdQo4 for ; Mon, 19 Dec 2011 06:55:49 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DD55021F8B4A for ; Mon, 19 Dec 2011 06:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1679; q=dns/txt; s=iport; t=1324306548; x=1325516148; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yzPT1+HPwKnZ61+avNaJQHGd2bDMbMjHyaH+xToMpgs=; b=L5NtXn2ZL1RlvyI+D3uhkr7A3BBBZAOPlM9EXltFn4tB2a4B6kTdsSeh llUDjdUilGVbDp8xFioldxPKeVPy9/1k/2qjVTotC3XJbQNff9S7cDabw I70Cw6Wrkwv2grbthGE78MsIAiIYTxhOAyixkbLVMVENcNc+j6VkGKd5Q E=;
X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; d="scan'208";a="45186224"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 19 Dec 2011 14:55:48 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBJEtm4w019026;  Mon, 19 Dec 2011 14:55:48 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 19 Dec 2011 08:55:48 -0600
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: Mon, 19 Dec 2011 08:55:47 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30398D657@XMB-RCD-109.cisco.com>
In-Reply-To: <4EEF10CA.7030301@fud.no>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy+OF5RV1PN/JmhTw2fg/zH6VdlYQAJXwYQ
References: <20111216184550.719D272E004@rfc-editor.org> <867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com> <4EEF05A5.3000601@fud.no> <867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com> <4EEF10CA.7030301@fud.no>
From: "Hemant Singh (shemant)" 
To: "Tore Anderson" , "Wuyts Carl" 
X-OriginalArrivalTime: 19 Dec 2011 14:55:48.0203 (UTC) FILETIME=[4B09ABB0:01CCBE5E]
X-Mailman-Approved-At: Mon, 19 Dec 2011 07:12:06 -0800
Cc: ot@cisco.com, fred.baker@cisco.com, v6ops@ietf.org, barbara.stark@att.com, dromasca@avaya.com, RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 14:55:49 -0000

This errata seems to be a lazy implementation which does not want to
deal with complexity of the behavior in L-13.  The errata is suggesting
to augment the text with a zero value for Valid Lifetime and that looks
to be an enhancement rather than an errata.  Since rfc6204bis is
supposed to replace rfc6204, rfc6204bis can change the text for L-13 to
include the enhancement.

Hemant

-----Original Message-----
From: Tore Anderson [mailto:tore@fud.no]=20
Sent: Monday, December 19, 2011 5:24 AM
To: Wuyts Carl
Cc: RFC Errata System; Hemant Singh (shemant); Wes Beebee (wbeebee);
c.donley@cablelabs.com; barbara.stark@att.com; ot@cisco.com;
dromasca@avaya.com; rbonica@juniper.net; fred.baker@cisco.com;
joelja@bogus.com; v6ops@ietf.org
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> It'll be backwards compatible, but the =3D0 was initially not in, so
> has to be added into the RA daemon..

Carl,

If your RA daemon currently implements VL=3D,
you don't have to change anything in order to be in compliance with the
new L-13, and you should feel free ignore the errata completely. I don't
understand why you feel otherwise?

What prompted me to submit the errata was discussions with a CPE
manufacturer that felt the current L-13 requirement was needlessly
complex, compared to simply always sending VL=3D0. The intention is to
make it easier, not harder, for a CPE manufacturer to correctly
implement L-13 by allowing two alternative methods (that both accomplish
the exact same thing).

--=20
Tore Anderson

From brian.e.carpenter@gmail.com  Mon Dec 19 13:14:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED31F0C51 for ; Mon, 19 Dec 2011 13:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.197
X-Spam-Level: 
X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 dkMRmcPhyXFc for ; Mon, 19 Dec 2011 13:14:45 -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 BFB1C1F0C40 for ; Mon, 19 Dec 2011 13:14:45 -0800 (PST)
Received: by iaen33 with SMTP id n33so719074iae.31 for ; Mon, 19 Dec 2011 13:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3sw5sEtyv55QAvNdrPqfL76+qLGBwlKhjBkCN/k8RSE=; b=C/IyfEmUK2v8bXaMVSkNNLJ5qDF8D7Ayjic1DH7bF5rwywO4MIQjcfM0zhLcHytVdK qCmIODGHhWaSwzZTc/cuyoSbRW26VheRdAkOCjRIXa6pcc1FebV1R6CxIvXCvhbtbx3/ Zm/GDFIJ5Xv79tzuzQhzVMDMH1HJZBRfE12tg=
Received: by 10.50.190.195 with SMTP id gs3mr29763975igc.82.1324329285186; Mon, 19 Dec 2011 13:14:45 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id i2sm20972369igq.7.2011.12.19.13.14.40 (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 13:14:44 -0800 (PST)
Message-ID: <4EEFA93E.5010306@gmail.com>
Date: Tue, 20 Dec 2011 10:14:38 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tore Anderson 
References: <20111216184550.719D272E004@rfc-editor.org>	<867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com>	<4EEF05A5.3000601@fud.no>	<867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com> <4EEF10CA.7030301@fud.no>
In-Reply-To: <4EEF10CA.7030301@fud.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "ot@cisco.com" , "v6ops@ietf.org" , "fred.baker@cisco.com" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 21:14:46 -0000

On 2011-12-19 23:24, Tore Anderson wrote:
> * Wuyts Carl
>=20
>> It'll be backwards compatible, but the =3D0 was initially not in, so
>> has to be added into the RA daemon..
>=20
> Carl,
>=20
> If your RA daemon currently implements VL=3D=C2=ABthe lower of the curr=
ent
> Valid Lifetime and 2 hours (which must be decremented in real time)=C2=BB=
,
> you don't have to change anything in order to be in compliance with the=

> new L-13, and you should feel free ignore the errata completely. I don'=
t
> understand why you feel otherwise?
>=20
> What prompted me to submit the errata was discussions with a CPE
> manufacturer that felt the current L-13 requirement was needlessly
> complex, compared to simply always sending VL=3D0. The intention is to
> make it easier, not harder, for a CPE manufacturer to correctly
> implement L-13 by allowing two alternative methods (that both accomplis=
h
> the exact same thing).

This seems like a strange use of the errata mechanism when we are so
close to finishing the bis document. It's a technical *change*, not
the correction of an error, so shouldn't it just be in bis?

    Brian


From brian.e.carpenter@gmail.com  Mon Dec 19 13:17:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B01F0C40 for ; Mon, 19 Dec 2011 13:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.297
X-Spam-Level: 
X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 0d6hDN3YTMaq for ; Mon, 19 Dec 2011 13:17:44 -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 4F35C1F0C53 for ; Mon, 19 Dec 2011 13:17:44 -0800 (PST)
Received: by iaen33 with SMTP id n33so723155iae.31 for ; Mon, 19 Dec 2011 13:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=EmC4L8DeufJt/xljCBfL9EM2i+5swg+KaTAeTINuEJU=; b=SGuudllEpbJJPAOz/QnbZOGoBdJ7wn17x62Lyfdtx9BG8zYMR/BVt70wPVDyUrpeja +cJjLdPfgPXW/mAA+SMt/DamepjTieFBA8Ys2fhh/UM3KPjWae2A8TmQtGj7WSQheHYB NZX9fMgHc6AUFsYojXiTio35zsaxhq/Jjn8rg=
Received: by 10.42.159.195 with SMTP id m3mr243526icx.33.1324329463897; Mon, 19 Dec 2011 13:17:43 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id l35sm8262476ibj.0.2011.12.19.13.17.41 (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 13:17:43 -0800 (PST)
Message-ID: <4EEFA9F4.8010402@gmail.com>
Date: Tue, 20 Dec 2011 10:17:40 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "v6ops@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Nit in draft-ietf-v6ops-6204bis-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 21:17:44 -0000

The header says:

> Updates: 6204 (if approved)

It should say:

Obsoletes: 6204 (if approved)

Also, the IESG will want this to be stated in the Abstract.

-- 
Regards
   Brian Carpenter



From shemant@cisco.com  Mon Dec 19 16:47:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008D221F84AC for ; Mon, 19 Dec 2011 16:47:40 -0800 (PST)
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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 A9Nx81DVOiVR for ; Mon, 19 Dec 2011 16:47:39 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1421F84AB for ; Mon, 19 Dec 2011 16:47:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=783; q=dns/txt; s=iport; t=1324342059; x=1325551659; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Ah2PL/dqtIVIqNbSEqWiEmgII+LWACYga/xddQJZ9KE=; b=PSPjSlgUJ3i6emV/vWK40VPkjTP9wXCQ0aNE31u1ae/0n7NAaHSp1O9t LpWE5p6OnAdS7HDxKXOALMq10fBy6uuSXUl0S5iRVO92hEFEBXdtZQAqP evjDK2bzmRvRddBXYR2YpZ4QtMZepcgn9JD9CSNdbhNdcqYfw7hsJGp+K E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AAIHa706tJXG8/2dsb2JhbABDmxqQUIEFgXIBAQEDAQEBAQ8BHQo0EAcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah1gImTQBnk8EiyljBIg2nxU
X-IronPort-AV: E=Sophos;i="4.71,379,1320624000"; d="scan'208";a="45375904"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 20 Dec 2011 00:47:39 +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 pBK0ldck023996;  Tue, 20 Dec 2011 00:47:39 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 19 Dec 2011 18:47:38 -0600
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: Mon, 19 Dec 2011 18:47:37 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30398D921@XMB-RCD-109.cisco.com>
In-Reply-To: <4EEFA9F4.8010402@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Nit in draft-ietf-v6ops-6204bis-04
Thread-Index: Acy+k7xdy6WXNHbkRGSJ5zol5hs/NwAHQvrw
References: <4EEFA9F4.8010402@gmail.com>
From: "Hemant Singh (shemant)" 
To: "Brian E Carpenter" , 
X-OriginalArrivalTime: 20 Dec 2011 00:47:38.0761 (UTC) FILETIME=[F8FACF90:01CCBEB0]
Subject: Re: [v6ops] Nit in draft-ietf-v6ops-6204bis-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 00:47:40 -0000

Brian,

Thanks much.  I made the changes to the document as per your comments.
Will post a new copy of the document soon.

Merry Christmas and Happy holidays to you and folks on the mailer.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Brian E Carpenter
Sent: Monday, December 19, 2011 4:18 PM
To: v6ops@ietf.org
Subject: [v6ops] Nit in draft-ietf-v6ops-6204bis-04

The header says:

> Updates: 6204 (if approved)

It should say:

Obsoletes: 6204 (if approved)

Also, the IESG will want this to be stated in the Abstract.

--=20
Regards
   Brian Carpenter


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

From jouni.nospam@gmail.com  Mon Dec 19 23:49:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C495111E80D8 for ; Mon, 19 Dec 2011 23:49:26 -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 CEjhE6u8sC0L for ; Mon, 19 Dec 2011 23:49:26 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01A7E11E80A2 for ; Mon, 19 Dec 2011 23:49:25 -0800 (PST)
Received: by laah2 with SMTP id h2so2719519laa.31 for ; Mon, 19 Dec 2011 23:49:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=05aGRwKz7QEt+bd9t7bWKWB1tuBJGhlipXerW90P8E0=; b=CLa3KMXOEvd4xUqFGkToH0Jzg9rsvNY6wBhUlE2u56ci3tAAVROp5zgCdXZ97S/e7/ WHwFI2iwtGCn72WO4IPTN29ls4MXmC3oaNJX0INf8IK1BRTImWNGcFB/WnRr/aRg6Lil s0xOknd/vml10DF8Zj8Ek59r0b+gHMkBBrNmg=
Received: by 10.152.102.136 with SMTP id fo8mr694077lab.30.1324367364864; Mon, 19 Dec 2011 23:49:24 -0800 (PST)
Received: from a83-245-212-5.elisa-laajakaista.fi (a83-245-212-5.elisa-laajakaista.fi. [83.245.212.5]) by mx.google.com with ESMTPS id st7sm762946lab.12.2011.12.19.23.49.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 23:49:23 -0800 (PST)
From: jouni korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Dec 2011 09:49:20 +0200
References: <20111220073924.5093.19864.idtracker@ietfa.amsl.com>
To: "v6ops@ietf.org Operations" , "Hemant Singh (shemant)" 
Message-Id: <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 07:49:26 -0000

Hemant, all,

We added the applicability statement into the Introduction, which now =
states the pd-exclude is intended for deployments where CEs are on their =
own layer 2 domain. This should clear your concern on 'multicast RAs".

- Jouni


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: December 20, 2011 9:39:24 AM GMT+02:00
> To: jouni.nospam@gmail.com
> Cc: ot@cisco.com, jouni.nospam@gmail.com, =
suresh.krishnan@ericsson.com, teemu.savolainen@nokia.com
> Subject: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
>=20
> A new version of I-D, draft-ietf-dhc-pd-exclude-04.txt has been =
successfully submitted by Jouni Korhonen and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-dhc-pd-exclude
> Revision:	 04
> Title:		 Prefix Exclude Option for DHCPv6-based Prefix =
Delegation
> Creation date:	 2011-12-20
> WG ID:		 dhc
> Number of pages: 10
>=20
> Abstract:
>   This specification defines an optional mechanism to allow exclusion
>   of one specific prefix from a delegated prefix set when using =
DHCPv6-
>   based prefix delegation.  The new mechanism updates RFC 3633.


From tore@fud.no  Tue Dec 20 03:49:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F8021F8B23 for ; Tue, 20 Dec 2011 03:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level: 
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094,  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 M6fNqOnVazNl for ; Tue, 20 Dec 2011 03:49:06 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [87.238.35.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9190021F8B1C for ; Tue, 20 Dec 2011 03:49:06 -0800 (PST)
Received: from [2001:840:3035:0:230:1bff:febc:7f23] (port=50424 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.71) (envelope-from ) id 1RcyBm-0006vf-SB; Tue, 20 Dec 2011 12:48:58 +0100
Message-ID: <4EF0762A.4040506@fud.no>
Date: Tue, 20 Dec 2011 12:48:58 +0100
From: Tore Anderson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Brian E Carpenter 
References: <20111216184550.719D272E004@rfc-editor.org>	<867F4B6A1672E541A94676D556793ACD0CB44B2661@MOPESMBX01.eu.thmulti.com>	<4EEF05A5.3000601@fud.no>	<867F4B6A1672E541A94676D556793ACD0CB44B274F@MOPESMBX01.eu.thmulti.com> <4EEF10CA.7030301@fud.no> <4EEFA93E.5010306@gmail.com>
In-Reply-To: <4EEFA93E.5010306@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "ot@cisco.com" , "v6ops@ietf.org" , "fred.baker@cisco.com" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 11:49:07 -0000

* Brian E Carpenter

> This seems like a strange use of the errata mechanism when we are so
> close to finishing the bis document. It's a technical *change*, not
> the correction of an error, so shouldn't it just be in bis?

Brian,

I don't know, it was Ole's idea to submit an errata against 6204,
actually. I'm not terribly familiar with the formal IETF procedures
myself. I am quite happy if the change is put into 6204bis (only).

That said, disallowing VL=0 appears to me to be either an oversight, or
based on an incorrect reading of RFC 4862 section 5.5.3 (e). If that is
indeed the case I would classify the change as a correction, rather than
a feature enhancement, so calling it an errata makes sense to me.

-- 
Tore Anderson

From shemant@cisco.com  Tue Dec 20 05:29:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146FD21F8B3E for ; Tue, 20 Dec 2011 05:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 cC9r8IdMSDVS for ; Tue, 20 Dec 2011 05:29:21 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32A1E21F8B0F for ; Tue, 20 Dec 2011 05:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1539; q=dns/txt; s=iport; t=1324387761; x=1325597361; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=D9yQEiiZVbr32vzb/25Mnq99apr1nONUC8Q13vCFQxk=; b=B7/14EB7tNhDYQaEeXLHQ9zwRCDsLOzRc6fU8B48HO996BGvp7wxhRX/ JHDmKFC5BE9xo3CsDZPD8QgWDNVuObk3cp6C9vhu29rusgKZHvZVQ0XIH RVRTqz6rzqVzsBWxV29Nk7lJT/6IosTMIFtwZ8HKd7WvHMr0qLUaHeRPG Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq4AACCN8E6tJXG+/2dsb2JhbABDmymQVIEFgXIBAQEDARIBHQo9BwcEAgEIEQMBAQELBhcBBgEgJQkIAQEEARIIGodYmGIBnkGLKWMEiDeXN4dg
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; d="scan'208";a="45480832"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 20 Dec 2011 13:29:21 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBKDTKvn020257;  Tue, 20 Dec 2011 13:29:20 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 20 Dec 2011 07:29:20 -0600
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, 20 Dec 2011 07:29:18 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30398D99C@XMB-RCD-109.cisco.com>
In-Reply-To: <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
Thread-Index: Acy+6+Xkv3kHhTayTN+PsuVgx026rwAED4sw
References: <20111220073924.5093.19864.idtracker@ietfa.amsl.com> <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" , 
X-OriginalArrivalTime: 20 Dec 2011 13:29:20.0648 (UTC) FILETIME=[616D5880:01CCBF1B]
Subject: Re: [v6ops] New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 13:29:22 -0000

Jouni,

The changes look fine to me and appreciate taking care of my comments,

Thanks,

Happy Holidays.

Hemant

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 20, 2011 2:49 AM
To: v6ops@ietf.org Operations; Hemant Singh (shemant)
Subject: Fwd: New Version Notification for
draft-ietf-dhc-pd-exclude-04.txt

Hemant, all,

We added the applicability statement into the Introduction, which now
states the pd-exclude is intended for deployments where CEs are on their
own layer 2 domain. This should clear your concern on 'multicast RAs".

- Jouni


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: December 20, 2011 9:39:24 AM GMT+02:00
> To: jouni.nospam@gmail.com
> Cc: ot@cisco.com, jouni.nospam@gmail.com,
suresh.krishnan@ericsson.com, teemu.savolainen@nokia.com
> Subject: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
>=20
> A new version of I-D, draft-ietf-dhc-pd-exclude-04.txt has been
successfully submitted by Jouni Korhonen and posted to the IETF
repository.
>=20
> Filename:	 draft-ietf-dhc-pd-exclude
> Revision:	 04
> Title:		 Prefix Exclude Option for DHCPv6-based Prefix
Delegation
> Creation date:	 2011-12-20
> WG ID:		 dhc
> Number of pages: 10
>=20
> Abstract:
>   This specification defines an optional mechanism to allow exclusion
>   of one specific prefix from a delegated prefix set when using
DHCPv6-
>   based prefix delegation.  The new mechanism updates RFC 3633.


From ietfc@btconnect.com  Tue Dec 20 10:50:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC291F0C3F for ; Tue, 20 Dec 2011 10:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.607
X-Spam-Level: 
X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[AWL=1.406,  BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 g4wA22VIOgXP for ; Tue, 20 Dec 2011 10:50:31 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2089A1F0C3B for ; Tue, 20 Dec 2011 10:50:30 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr10.btconnect.com with SMTP id FQV90015; Tue, 20 Dec 2011 18:50:28 +0000 (GMT)
Message-ID: <034301ccbf40$0c672440$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ari Keranen" 
References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com><033501cc5035$13e0f360$4001a8c0@gateway.2wire.net><032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net><6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> <022e01cc5355$5f083240$4001a8c0@gateway.2wire.net>
Date: Tue, 20 Dec 2011 18:50:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0302.4EF0D8F4.0052, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.12.14.220316:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4EF0D8F4.017E,ss=1,re=0.000,fgs=12, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine
X-Junkmail-IWF: false
Cc: IPv6 Operations 
Subject: Re: [v6ops] draft-keranen-ipv6day-measurements
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 18:50:32 -0000

I had hoped to see this progress towards an RFC; like
'draft-arkko-ipv6-only-experience', I see it as a memo 'of the moment', out of
date as soon as it is written but still valuable as long as it does not take too
long to hit the streets ie I would still like it to progress, but could change
my mind in future!

Tom Petch


----- Original Message -----
From: "t.petch" 
To: "Ari Keranen" 
Cc: "IPv6 Operations" 
Sent: Friday, August 05, 2011 10:52 AM
 inline
> --- Original Message -----
> From: "Ari Keranen" 
> To: "t.petch" 
> Cc: "IPv6 Operations" 
> Sent: Thursday, August 04, 2011 11:33 AM
> On Aug 2, 2011, at 2:07 PM, t.petch wrote:
> > In the hope that you will take up Fred's generous offer to push this through
> to
> > an RFC, I hope that you will find these comments helpful
>
> Thanks for the feedback! As Jari already mentioned, we haven't fixed our plans
> regarding how and if these results should be published, but if there is
interest
> in the WG, v6ops RFC is indeed one good option.
>
> > I would like to see more references, for 6to4 and for the various .pdf; I
> think
> > it works better to have them all in one place.
>
> By .pdf do you mean the graph PDFs, other presentations something else?
>
> 
> I mean the graph PDFs, where you have the URI in the text but not in the
> References, I would like it at least in the latter, less concerned about the
> former.
> 
>
> > I find the X-axis of the graphs unclear; time presumably, but what time?
>
> It's the sequence number of the measurement run; so something like "time in 3
> hour steps since the start of the tests". Probably hours (or even time and
date)
> would work better here.
>
> 
> Yes, date and time would be lovely; I thought it was measurement run but did
not
> have a start point and the interval was not obvious.
> 
>
> > I think that the biggest conclusion is omitted; only 2.45% of the top 10,000
> > sites offer IPv6 via DNS ie next to none; I think that this should be in BIG
> > BOLD LETTERS.
>
> True, but that was not news to anyone :)
>
> 
> Disagree; we know that the availability of IPv6 is negligible but we do not
know
> how much it is, and a hard data point at a point in time will provide a
valuable
> record.  I was surprised at how small it was, I would have guessed 10-20% (
but
> then I am probably misled but the amount of traffic on the v6ops list:-)
> 
>
> > And while comprehension is no problem, the idiom is sometimes slightly odd.
> > Doubtless the RFC Editor will fix it but I could point some of these out to
> you
> > if you want.
>
> That'd be helpful; please send me a mail with those off-list.
>
> 
> I hope you do; Fred has indicated a willingness to help.  I cannot think of a
> way to put it without being unfair to Fred, but it is an offer never to spurn.
>
> Tom Petch
> 
> Cheers,
> Ari
>
> P.S. I'll be out of office for a couple of weeks, so it may take a while
before
> I have a chance to follow up on this
>
>
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Fred Baker" 
> > To: "t.petch" 
> > Cc: "IPv6 Operations" 
> > Sent: Monday, August 01, 2011 6:49 PM
> > On Aug 1, 2011, at 3:23 AM, t.petch wrote:
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From fred@cisco.com  Tue Dec 20 11:05:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB9321F85DB for ; Tue, 20 Dec 2011 11:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.349
X-Spam-Level: 
X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 7cEGY3eQwAKA for ; Tue, 20 Dec 2011 11:05:14 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C421F8569 for ; Tue, 20 Dec 2011 11:05:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4353; q=dns/txt; s=iport; t=1324407914; x=1325617514; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=anf4Hor2rrfg7HSsvi9KrhYDgss9E/hXq4ccaSJGl/U=; b=WeyCz5F4XC3ZwJ2lgjEDXtsGkdjxrHqP7qJZUxqUvWGy7oZ61TKvN3dn LDZsvQq00csaunUtYVLUYgR7AAbrPTVtITJ0eNVsWjMK1QUJIzED4qcyG c8jQKTxumjvCQ+gs27vkNvSnuUbMp6BwpJ0I0npmHi93FozzIWYZLyTYG E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AAP7b8E6rRDoJ/2dsb2JhbABDmy2QVYEFgXIBAQEDAQEBAQ8BJzQLBQcEBQYVAQIuJzAGExEJCIdYCJh2AZ42BIspYwSIN4xIhU+NAg
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; d="scan'208";a="21744074"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Dec 2011 19:05:12 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBKJ5B8f022151; Tue, 20 Dec 2011 19:05:11 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 20 Dec 2011 11:05:12 -0800
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 20 Dec 2011 11:05:12 -0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
X-Priority: 3
In-Reply-To: <034301ccbf40$0c672440$4001a8c0@gateway.2wire.net>
Date: Tue, 20 Dec 2011 11:04:59 -0800
Message-Id: 
References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com><033501cc5035$13e0f360$4001a8c0@gateway.2wire.net><032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net><6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> <022e01cc5355$5f083240$4001a8c0@gateway.2wire.net> <034301ccbf40$0c672440$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Operations , Ron Bonica , Nevil Brownlee 
Subject: Re: [v6ops] draft-keranen-ipv6day-measurements
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 19:05:15 -0000

Copying the ISE and the Ops AD. In my opinion, the best path for the =
document, if it is to be published as an RFC, is the independent track. =
If we take it as a working group document, I suspect it needs to be a =
very different one, and that isn't in keeping with the author's intent.

On Dec 20, 2011, at 9:50 AM, t.petch wrote:

> I had hoped to see this progress towards an RFC; like
> 'draft-arkko-ipv6-only-experience', I see it as a memo 'of the =
moment', out of
> date as soon as it is written but still valuable as long as it does =
not take too
> long to hit the streets ie I would still like it to progress, but =
could change
> my mind in future!
>=20
> Tom Petch
>=20
>=20
> ----- Original Message -----
> From: "t.petch" 
> To: "Ari Keranen" 
> Cc: "IPv6 Operations" 
> Sent: Friday, August 05, 2011 10:52 AM
> inline
>> --- Original Message -----
>> From: "Ari Keranen" 
>> To: "t.petch" 
>> Cc: "IPv6 Operations" 
>> Sent: Thursday, August 04, 2011 11:33 AM
>> On Aug 2, 2011, at 2:07 PM, t.petch wrote:
>>> In the hope that you will take up Fred's generous offer to push this =
through
>> to
>>> an RFC, I hope that you will find these comments helpful
>>=20
>> Thanks for the feedback! As Jari already mentioned, we haven't fixed =
our plans
>> regarding how and if these results should be published, but if there =
is
> interest
>> in the WG, v6ops RFC is indeed one good option.
>>=20
>>> I would like to see more references, for 6to4 and for the various =
.pdf; I
>> think
>>> it works better to have them all in one place.
>>=20
>> By .pdf do you mean the graph PDFs, other presentations something =
else?
>>=20
>> 
>> I mean the graph PDFs, where you have the URI in the text but not in =
the
>> References, I would like it at least in the latter, less concerned =
about the
>> former.
>> 
>>=20
>>> I find the X-axis of the graphs unclear; time presumably, but what =
time?
>>=20
>> It's the sequence number of the measurement run; so something like =
"time in 3
>> hour steps since the start of the tests". Probably hours (or even =
time and
> date)
>> would work better here.
>>=20
>> 
>> Yes, date and time would be lovely; I thought it was measurement run =
but did
> not
>> have a start point and the interval was not obvious.
>> 
>>=20
>>> I think that the biggest conclusion is omitted; only 2.45% of the =
top 10,000
>>> sites offer IPv6 via DNS ie next to none; I think that this should =
be in BIG
>>> BOLD LETTERS.
>>=20
>> True, but that was not news to anyone :)
>>=20
>> 
>> Disagree; we know that the availability of IPv6 is negligible but we =
do not
> know
>> how much it is, and a hard data point at a point in time will provide =
a
> valuable
>> record.  I was surprised at how small it was, I would have guessed =
10-20% (
> but
>> then I am probably misled but the amount of traffic on the v6ops =
list:-)
>> 
>>=20
>>> And while comprehension is no problem, the idiom is sometimes =
slightly odd.
>>> Doubtless the RFC Editor will fix it but I could point some of these =
out to
>> you
>>> if you want.
>>=20
>> That'd be helpful; please send me a mail with those off-list.
>>=20
>> 
>> I hope you do; Fred has indicated a willingness to help.  I cannot =
think of a
>> way to put it without being unfair to Fred, but it is an offer never =
to spurn.
>>=20
>> Tom Petch
>> 
>> Cheers,
>> Ari
>>=20
>> P.S. I'll be out of office for a couple of weeks, so it may take a =
while
> before
>> I have a chance to follow up on this
>>=20
>>=20
>>> Tom Petch
>>>=20
>>> ----- Original Message -----
>>> From: "Fred Baker" 
>>> To: "t.petch" 
>>> Cc: "IPv6 Operations" 
>>> Sent: Monday, August 01, 2011 6:49 PM
>>> On Aug 1, 2011, at 3:23 AM, t.petch wrote:
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From wbeebee@cisco.com  Tue Dec 20 11:06:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF1721F86B3 for ; Tue, 20 Dec 2011 11:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5udnP4Fh+gW for ; Tue, 20 Dec 2011 11:06:55 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0121F86A5 for ; Tue, 20 Dec 2011 11:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=835; q=dns/txt; s=iport; t=1324408015; x=1325617615; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=zex1CS5FbZRN5g0FV3UdfioViUyemD/bz3ZJH/iu1tE=; b=SS5eEKWUW+trwaGsKn/4AxhqU3GcEr+x01F3oykGo3Z1MrWNLyDks+ca ZmAJOvD3LhBzACT8NkR/vHLUv3xYCH++dDWk9xVSaayiE+QvnGX/mYVas kZ5+GDSQ2BVgyw6klPtX8wZRwxLbQDGyUb4UXIigSY0PaXlk9cQwLECP0 E=;
X-IronPort-AV: E=Sophos;i="4.71,383,1320624000"; d="scan'208";a="45633416"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 20 Dec 2011 19:06:54 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBKJ6sdh018595;  Tue, 20 Dec 2011 19:06:54 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 20 Dec 2011 13:06:54 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 20 Dec 2011 19:06:53 +0000
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 20 Dec 2011 14:06:44 -0500
From: Wes Beebee 
To: Tore Anderson , Brian E Carpenter 
Message-ID: 
Thread-Topic: [v6ops] [Technical Errata Reported] RFC6204 (3054)
Thread-Index: Acy/SoNnYTtoDljoi02UZa3RGFw/Iw==
In-Reply-To: <4EF0762A.4040506@fud.no>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 20 Dec 2011 19:06:54.0601 (UTC) FILETIME=[89B94F90:01CCBF4A]
Cc: "ot@cisco.com" , "v6ops@ietf.org" , "fred.baker@cisco.com" , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 19:06:55 -0000

> That said, disallowing VL=0 appears to me to be either an oversight, or
> based on an incorrect reading of RFC 4862 section 5.5.3 (e).

Specifically, RFC 4862 section 5.5.3 (e) governs the processing of RA's on
receipt by a host.  It does not govern the sending of RA's by routers.  In
the case where a router sends VL=0 in an RA, the processing of that RA by
the receiving host will result in exactly the same actions on the part of
the host as when the VL follows the more complicated 2-hour rule.
Therefore, setting VL=0 in the RA will result in no harm done to the network
and may result in a simpler router implementation.

The Errata process bypasses WG consensus.  The advantage of putting this in
rfc6204bis is that the change will be ratified by the WG during the normal
document progression process.

- Wes


From lorenzo@google.com  Tue Dec 20 11:29:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3481921F8A69 for ; Tue, 20 Dec 2011 11:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tZKrZsXGHkz2 for ; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A461821F8508 for ; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: by obcuz6 with SMTP id uz6so2962991obc.31 for ; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=PkRqSZQtLAJvr2TT04vRBQTImlaCDgkai2YnzcwU//8=; b=C/wR9ZtUYYAeWNY6SoViwfyh3tpOg6RDXO6VhMUXioain1oNDy54LrCr6jZX3+TVOp abfg2UKPGpZhSJGl1crA==
Received: by 10.182.113.71 with SMTP id iw7mr2912132obb.68.1324409347301; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
Received: by 10.182.113.71 with SMTP id iw7mr2912117obb.68.1324409347179; Tue, 20 Dec 2011 11:29:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.0.11 with HTTP; Tue, 20 Dec 2011 11:28:46 -0800 (PST)
In-Reply-To: <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
References: <20111220073924.5093.19864.idtracker@ietfa.amsl.com> <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com>
From: Lorenzo Colitti 
Date: Tue, 20 Dec 2011 11:28:46 -0800
Message-ID: 
To: jouni korhonen 
X-System-Of-Record: true
Content-Type: multipart/alternative; boundary=f46d0447f3c6ad046204b48b146d
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 19:29:08 -0000

--f46d0447f3c6ad046204b48b146d
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 19, 2011 at 23:49, jouni korhonen wrote:

> We added the applicability statement into the Introduction, which now
> states the pd-exclude is intended for deployments where CEs are on their
> own layer 2 domain. This should clear your concern on 'multicast RAs".
>

As discussed already, I have two objections to this on the grounds that it
needlessly complicates implementations.

First, I object to the text that says "The requesting router must create
sink routes for the delegated prefixes minus the excluded prefixes." This
is complex to implement properly.

I think it should say: "The requesting router must create sink routes for
the entire delegated prefix. If it is desired that the requesting router
route the excluded prefix in any other way, this MUST be configured to do
so via other means (for example, via a Router Advertisement containing a
Prefix Information Option for the excluded prefix and the on-link bit set).

Second, I think the draft should make it clear that only one prefix can be
excluded per delegated prefix, and that if the RR receives (at any time),
another OPTION_IAPREFIX option for the same prefix with different excluded
prefixes, then the RR is free to ignore the previous excluded prefix.

--f46d0447f3c6ad046204b48b146d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Dec 19, 2011 at 23:49, jouni korhonen <jouni.nospam@=
gmail.com> wrote:


We added the applicability statement into the Introduction, which now state=
s the pd-exclude is intended for deployments where CEs are on their own lay=
er 2 domain. This should clear your concern on 'multicast RAs".



As discussed already, I have two objection=
s to this on the grounds that it needlessly complicates implementations.

First, I object to the text that says "The requ=
esting router must create sink routes for the delegated=A0prefixes minus th=
e excluded prefixes." This is complex to implement properly.




I think it should say:=A0"The requesting router mu=
st create sink routes for the entire delegated prefix. If it is desired tha=
t the requesting router route the excluded prefix in any other way, this MU=
ST be configured to do so via other means (for example, via a Router Advert=
isement containing a Prefix Information Option for the excluded prefix and =
the on-link bit set).




Second, I think the draft should make it clear that onl=
y one prefix can be excluded per delegated prefix, and that if the RR recei=
ves (at any time), another=A0OPTION_IAPREFIX =
option for the same prefix with different excluded prefixes, then the RR is=
 free to ignore the previous excluded prefix.





--f46d0447f3c6ad046204b48b146d--

From joelja@bogus.com  Tue Dec 20 15:16:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6421F84BC for ; Tue, 20 Dec 2011 15:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pYADT69m3--P for ; Tue, 20 Dec 2011 15:16:19 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B694E21F848F for ; Tue, 20 Dec 2011 15:16:19 -0800 (PST)
Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pBKNGIJj048823 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 20 Dec 2011 23:16:19 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EF1173D.40407@bogus.com>
Date: Tue, 20 Dec 2011 15:16:13 -0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IPv6 Ops WG 
References: <4EF06D47.2060202@si6networks.com>
In-Reply-To: <4EF06D47.2060202@si6networks.com>
X-Forwarded-Message-Id: <4EF06D47.2060202@si6networks.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 20 Dec 2011 23:16:19 +0000 (UTC)
Subject: [v6ops] FYI: New IETF I-D on IPv6 smurf amplifiers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 23:16:20 -0000

-------- Original Message --------
Subject: New IETF I-D on IPv6 smurf amplifiers
Date: Tue, 20 Dec 2011 08:11:03 -0300
From: Fernando Gont 
Organization: SI6 Networks
To: ipv6@ietf.org 

Folks,

We have published a new IETF I-D on "IPv6 smurf amplifiers". The I-D is
available at:
.

This may be an issue when BC38 is not deployed, or when the BCP38
implementation is buggy (yes, there have been instances of this).

Note: This vector can also be exploited with normal link-local multicast
addresses, but for obvious reasons it becomes a more important issue
with non-local multicast.

Abstract:
---- cut here ----
   When an IPv6 node processing an IPv6 packet does not support an IPv6
   option whose two-highest-order bits of the Option Type are '10', it
   is required to respond with an ICMPv6 Parameter Problem error
   message, even if the Destination Address of the packet was a
   multicast address.  This feature provides an amplification vector,
   opening the door to an IPv6 version of the 'Smurf' Denial-of-Service
   (DoS) attack found in IPv4 networks.  This document discusses the
   security implications of the aforementioned options, and formally
   updates RFC 2460 such that this attack vector is eliminated.
   Additionally, it describes a number of operational mitigations that
   could be deployed against this attack vector.
---- cut here ----

Any feedback will be welcome.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From Tina.Tsou.Zouting@huawei.com  Tue Dec 20 18:17:02 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA6721F8432 for ; Tue, 20 Dec 2011 18:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 tEX4XVwziIVr for ; Tue, 20 Dec 2011 18:16:57 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0DF11E8073 for ; Tue, 20 Dec 2011 18:16:56 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ00MDO7O5EF@szxga05-in.huawei.com> for v6ops@ietf.org; Wed, 21 Dec 2011 10:16:54 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ00MNP7O5VR@szxga05-in.huawei.com> for v6ops@ietf.org; Wed, 21 Dec 2011 10:16:53 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFV30478; Wed, 21 Dec 2011 10:16:17 +0800
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 10:16:13 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 21 Dec 2011 10:16:08 +0800
Date: Wed, 21 Dec 2011 02:16:07 +0000
From: Tina TSOU 
In-reply-to: <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>
X-Originating-IP: [10.212.244.251]
To: Mark Townsley 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1o1insOT/PvD8OnOwFFiSw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Up-leveling Transition Coexistence
Thread-index: AQHMuoWtLIv9EMTPEUqfzMLkWVTTkJXde9CAgAHMi4CAAXwkA4ABlqwAgAM7azA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com> <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 02:17:03 -0000

--Boundary_(ID_1o1insOT/PvD8OnOwFFiSw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Mark,
After discussing with co-authors of Light Weight 4over6, I think my question is "how the CPE to distinguish AFTR from TC?". You talks about that for the CPE to select the right interface for multi-homing setting. It won't solve the problem I asked.
If it is not in the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that's fine. Thank you for your help anyway.

-Tina

From: Mark Townsley [mailto:mark@townsley.net]
Sent: Monday, December 19, 2011 12:50 AM
To: Tina TSOU
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence


On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:


Mark,

Sent from my iPad

On Dec 17, 2011, at 1:53 AM, "Mark Townsley" > wrote:

On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:


Mark,
Thanks. It is very useful.

(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?

Our latest version attempts to tackle this:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
I read this draft, it is well written.

Thank you.


In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented?

It is assumed the CE naturally knows which interface types it supports because it had to implement them. The "forwarding-oriented" model followed in the document assumes that any can be configured at any time. If the CE supports 4over6, it will fit that into the policy table based on the main principles we outline in the draft. The example table is just that, an example of some technologies available today based on a set of base principles. If we agree on the principles, I think we can classify just about any new technology that we have now or comes along. In the case of 4over6, since the default policy we proposed ranks use of IPv6 transport very high, 4over6 would also be weighted very high.

In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native IPv4. Based on the principles in the draft, the use of IPv6 as a transport would place DS-lite on a preferred path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear in the AFTR, while existing local NAPT entries time out or shut down naturally. It should be fairly seamless to the user, and allows for active failover as well in case the DS-Lite tunnel goes down for whatever reason.


Then, do we have to to change this value by re-coding if each mechanism is added? Or make a CLI to change this value?

The policy is essentially a global preference in terms of v6 transport and NAPT state boiled down to a single point of default configuration. Follow the defaults, and there will be no need for CLI or otherwise. If you want to override the defaults, there is a single place to do so.

- Mark




- Mark



- Tina


-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs.

The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc)
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other.

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.

I'd like to identify two strategies to deal with these situations.

The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version.

(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or

(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or

(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch.

(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4.

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-)

Thanks, and Happy Holidays in advance to those who will be celebrating soon,

- Mark
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--Boundary_(ID_1o1insOT/PvD8OnOwFFiSw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable













Mark,


After discussing with co-authors of Light Weight 4o=
ver6, I think my question is “how
 the CPE to distinguish AFTR from TC?&=
#8221;.
 You talks about that for the C=
PE to select the right interface for multi-homing setting. It won't
 solve the problem I asked.


If it is not in=
 the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that’s
 fine. Thank you for your help anyway.




 


-Tina




 






From: Mark
 Townsley [mailto:mark@townsley.net] 

Sent: Monday, December 19, 2011 12:50 AM

To: Tina TSOU

Cc: v6ops@ietf.org Operations

Subject: Re: [v6ops] Up-leveling Transition Coexistence






 


 






On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:















Mark,



Sent from my iPad








On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <mark@townsley.net> wrote:








 






On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:













Mark,

Thanks. It is very useful. 






(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite=
, 4rd, etc)


How to do "forwarding-oriented" in CPE to disting=
uish among the techniques such as classical DS-Lite and Light Weight 4over6=
?






 






Our latest version attempts to tackle this:






 











I read this draft, it is well written.





 






Thank you.













In table one, we have used all 3 bits. Light Weight 4over6 =
is not on the list. How does the CE know it is going to be operated in whic=
h mechanism, if it is only forwarding-oriented?







 






It is assumed the CE naturally knows which interface types =
it supports because it had to implement them. The "forwarding-oriented=
" model followed in the document assumes that any can
 be configured at any time. If the CE supports 4over6, it will fit that int=
o the policy table based on the main principles we outline in the draft. Th=
e example table is just that, an example of some technologies available tod=
ay based on a set of base principles.
 If we agree on the principles, I think we can classify just about any new =
technology that we have now or comes along. In the case of 4over6, since th=
e default policy we proposed ranks use of IPv6 transport very high, 4over6 =
would also be weighted very high. 






 






In terms of 6204-bis, we would only need to "rank"=
; DS-Lite vs. Native IPv4. Based on the principles in the draft, the use of=
 IPv6 as a transport would place DS-lite on a preferred
 path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, n=
ew NAPT entries appear in the AFTR, while existing local NAPT entries time =
out or shut down naturally. It should be fairly seamless to the user, and a=
llows for active failover as well
 in case the DS-Lite tunnel goes down for whatever reason. =














Then, do we have to to change this value by re-coding if ea=
ch mechanism is added? Or make a CLI to change this value?






 






The policy is essentially a global preference in terms of v=
6 transport and NAPT state boiled down to a single point of default configu=
ration. Follow the defaults, and there will be
 no need for CLI or otherwise. If you want to override the defaults, there =
is a single place to do so. 






 






- Mark






 





















 






- Mark















- Tina





-----Original Message-----

From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley

Sent: Wednesday, December 14, 2011 9:27 AM

To: v6ops@ietf.org Operations

Subject: [v6ops] Up-leveling Transition Coexistence





Folks,



We have had a lot of lively discussion of late on the new sections in 6204-=
bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work togeth=
er on a residential CE router. I'd like to summarize what I think the main =
architectural issue is alongside a possible
 solution framework. Technical comments are very welcome, but let's also tr=
y and keep them thoughtful and at a pace that everyone can keep up amidst t=
heir day-jobs.




The requirements in RFC 6204 are based on a fundamental assumption that a C=
E router has a single active WAN interface for forwarding IPv4 and IPv6 tra=
ffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 v=
ia DS-lite and IPv4 via Native together
 forces us to at least reconsider this basic assumption.  Breaking thi=
s down at bit, there are three possible steady-state combinations of "=
native" and "virtual" (tunneled) dual-stack connectivity met=
hods that do not break the basic forwarding model of a single
 WAN egress per IP version:



(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 

(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)


(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 



Digging deeper into transition between these states:



For (1), IPv4 and IPv6 each share a single WAN interface, so there is no pr=
oblem when enabling one vs. the other.




For (2), when enabling tunneled IPv6 on an existing IPv4-only network there=
 is no significant change in the basic model as each IP version still has i=
ts own distinct single WAN interface. Multihoming issues arise when enablin=
g native IPv6 alongside tunneled
 IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two=
 distinct interfaces at the same time.



For (3) there similarly is no problem when enabling tunneled IPv4 on an exi=
sting IPv6-only network, and I have been told that there are greenfield dep=
loyments just like this happening. The multihoming issues arise when enabli=
ng tunneled IPv4 on a network that
 has native IPv4 available at the same time.  



I'd like to identify two strategies to deal with these situations. 



The first I will call "configuration-oriented". For this to work,=
 one of the following assumptions must hold. None are pretty, but you MUST =
pick one to avoid solving how to forward traffic when multiple interfaces a=
re enabled at the same time for a given IP
 version. 



(a) From the perspective of the CE router, the network supports only one ty=
pe of interface for a given IP version, or




(b) The CE router is configured in advance of any IP configuration to suppo=
rt only one type of interface for a given IP version, or



(c) The CE router goes through an ordered set of configuration attempts in =
series, each requiring a timeout before moving to the next. Transition-orie=
nted changes after steady-state is reached will require "reboot" =
to go through the ordered process from scratch.




(d) The CE router chooses one type of interface and shuts down all others b=
ased on a predetermined priority when more than one interface with the same=
 IP version is configured. This allows parallel configuration attempts and =
changes after reaching steady-state,
 but requires the CE router and network to manage a "flash cut" f=
rom one configured interface to the other and may be prone to tricky race-c=
onditions.



The second strategy I will call "forwarding-oriented." In this mo=
del, configuration of any WAN interface method at any time is accepted. The=
 CE follows forwarding rules in order to ensure packets make it out the rig=
ht interface on WAN egress, and liberally
 accepts packets on WAN ingress. This is "classic multihoming" an=
d should work for any order of planned incremental transition steps, as wel=
l as failover and/or transient situations.



After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began ado=
pting some of the "forwarding-based" requirements for IPv6, thoug=
h DS-Lite remained in the "configuration-based" role for IPv4.




Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01=
.txt, which is a general set of IPv6 requirements for multihoming with 6rd-=
specifics (i.e., it is a "forwarding-based" solution for IPv6). W=
e'll be publishing the same for IPv4 in order
 to support DS-Lite. Neither are rocket science, but teaching the CE to pro=
perly forward when faced with more than one alternative egress interface ha=
s been labeled "hard" (though as an interesting data point I have=
 found IPv4 routers that support multiple
 WAN interfaces at the same time for less than $50). In my mind, the "=
configuration-oriented" alternative seems at least as hard as the &quo=
t;forwarding-oriented" alternative, is less robust, and certainly less=
 flexible in terms of letting the operator decide its
 fate in terms of how to perform each transition step.



Again, technical comments are very welcome. Mostly I would like to know if =
people understand and agree with the basic premise here, and if so whether =
"configuration-oriented" or "forwarding-oriented" is th=
e best way forward. So far, I think the forwarding-oriented
 approach wins hands down, but then again I'm used to building routers that=
 have lots of interfaces and operators that ask them to do all sorts of cra=
zy things :-)




Thanks, and Happy Holidays in advance to those who will be celebrating soon=
,



- Mark

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.or=
g/mailman/listinfo/v6ops






 










 






--Boundary_(ID_1o1insOT/PvD8OnOwFFiSw)--

From internet-drafts@ietf.org  Tue Dec 20 19:47:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E024211E8094; Tue, 20 Dec 2011 19:47:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 E9eZ1Cd+lV5h; Tue, 20 Dec 2011 19:47:48 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3ED21F845F; Tue, 20 Dec 2011 19:47:40 -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: 3.64p1
Message-ID: <20111221034740.24733.23893.idtracker@ietfa.amsl.com>
Date: Tue, 20 Dec 2011 19:47:40 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-happy-eyeballs-07.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 03:47:49 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Happy Eyeballs: Success with Dual-Stack Hosts
	Author(s)       : Dan Wing
                          Andrew Yourtchenko
	Filename        : draft-ietf-v6ops-happy-eyeballs-07.txt
	Pages           : 17
	Date            : 2011-12-20

   When a server's IPv4 path and protocol is working but the server's
   IPv6 path and protocol are not working, a dual-stack client
   application experiences significant connection delay compared to an
   IPv4-only client.  This is undesirable because it causes the dual-
   stack client to have a worse user experience.  This document
   specifies requirements for algorithms that reduce this user-visible
   delay, and provides an algorithm.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-07.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-v6ops-happy-eyeballs-07.txt


From jouni.nospam@gmail.com  Wed Dec 21 03:46:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373F21F88B6 for ; Wed, 21 Dec 2011 03:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP2Cfph9Y+U3 for ; Wed, 21 Dec 2011 03:46:44 -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 9EAF221F889A for ; Wed, 21 Dec 2011 03:46:44 -0800 (PST)
Received: by iaen33 with SMTP id n33so3743338iae.31 for ; Wed, 21 Dec 2011 03:46:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7yuzfzcA8hwrmdK8/pfA3VtTHfcGXDm2oRmykyFDl5A=; b=iZkKOEaZ+EPy3ZoVWri3a9uujwMxJqM1XgsmBSrTOTd8X4OhJ7Uz9mtiToRvSfHXQ2 MPCtwzLyaJyLVfF9QH5WxQOUKGKRhzwlT2MWkArZbPfsrcED/mwz3aSlLbu9+4t7yT1Q UIEHkoiNLPdfRpWHzpx1iu3L6Rq7ghVg7EMyE=
Received: by 10.42.154.69 with SMTP id p5mr6490213icw.11.1324468004243; Wed, 21 Dec 2011 03:46:44 -0800 (PST)
Received: from [10.255.133.139] ([192.100.123.77]) by mx.google.com with ESMTPS id ew6sm7559065igc.4.2011.12.21.03.46.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 03:46:43 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Wed, 21 Dec 2011 13:46:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111220073924.5093.19864.idtracker@ietfa.amsl.com> <422FF86C-4C27-4C0A-9A5B-F445766220DD@gmail.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 11:46:45 -0000

Lorenzo,

On Dec 20, 2011, at 9:28 PM, Lorenzo Colitti wrote:

> On Mon, Dec 19, 2011 at 23:49, jouni korhonen  =
wrote:
> We added the applicability statement into the Introduction, which now =
states the pd-exclude is intended for deployments where CEs are on their =
own layer 2 domain. This should clear your concern on 'multicast RAs".
>=20
> As discussed already, I have two objections to this on the grounds =
that it needlessly complicates implementations.
> First, I object to the text that says "The requesting router must =
create sink routes for the delegated prefixes minus the excluded =
prefixes." This is complex to implement properly.

I am not sure I agree. Can you clarify why it is so complex to implement =
properly? Ole already responded to this in =
http://www.ietf.org/mail-archive/web/v6ops/current/msg11526.html

> I think it should say: "The requesting router must create sink routes =
for the entire delegated prefix. If it is desired that the requesting =
router route the excluded prefix in any other way, this MUST be =
configured to do so via other means (for example, via a Router =
Advertisement containing a Prefix Information Option for the excluded =
prefix and the on-link bit set).

Why not proposing the exact text you want to see in the draft?

>=20
> Second, I think the draft should make it clear that only one prefix =
can be excluded per delegated prefix, and that if=20

Section 4.1 says  "There can be at most one OPTION_PD_EXCLUDE option in =
one OPTION_IAPREFIX option". I say it is clearly stated.

> the RR receives (at any time), another OPTION_IAPREFIX option for the =
same prefix with different excluded prefixes, then the RR is free to =
ignore the previous excluded prefix.

Why would a DR do such? I do not see such scenario. No problem to state =
this though.

- Jouni=

From ari.keranen@nomadiclab.com  Wed Dec 21 05:52:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458321F84DB for ; Wed, 21 Dec 2011 05:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 zQtqOWyi9FrC for ; Wed, 21 Dec 2011 05:52:10 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70221F84D6 for ; Wed, 21 Dec 2011 05:52:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id CBC924E6E8; Wed, 21 Dec 2011 15:52:08 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW4wAqaM1kTe; Wed, 21 Dec 2011 15:52:01 +0200 (EET)
Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 5019A4E6E1; Wed, 21 Dec 2011 15:52:01 +0200 (EET)
Message-ID: <4EF1E481.2060705@nomadiclab.com>
Date: Wed, 21 Dec 2011 15:52:01 +0200
From: Ari Keranen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Fred Baker , "t.petch" 
References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com><033501cc5035$13e0f360$4001a8c0@gateway.2wire.net><032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net><6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> <022e01cc5355$5f083240$4001a8c0@gateway.2wire.net> <034301ccbf40$0c672440$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations , Nevil Brownlee , Ron Bonica 
Subject: Re: [v6ops] draft-keranen-ipv6day-measurements
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 13:52:11 -0000

Fred, Tom,

I agree that the best path for this draft is the independent track. 
We'll do an update to the draft taking into account the feedback and 
submit a new version soon.


Cheers,
Ari

On 12/20/11 9:04 PM, Fred Baker wrote:
> Copying the ISE and the Ops AD. In my opinion, the best path for the
> document, if it is to be published as an RFC, is the independent
> track. If we take it as a working group document, I suspect it needs
> to be a very different one, and that isn't in keeping with the
> author's intent.
>
> On Dec 20, 2011, at 9:50 AM, t.petch wrote:
>
>> I had hoped to see this progress towards an RFC; like
>> 'draft-arkko-ipv6-only-experience', I see it as a memo 'of the
>> moment', out of date as soon as it is written but still valuable as
>> long as it does not take too long to hit the streets ie I would
>> still like it to progress, but could change my mind in future!
>>
>> Tom Petch
>>
>>
>> ----- Original Message ----- From: "t.petch"
>> To: "Ari Keranen" Cc: "IPv6
>> Operations" Sent: Friday, August 05, 2011 10:52 AM
>> inline
>>> --- Original Message ----- From: "Ari
>>> Keranen" To:
>>> "t.petch" Cc: "IPv6
>>> Operations" Sent: Thursday, August 04, 2011 11:33
>>> AM On Aug 2, 2011, at 2:07 PM, t.petch wrote:
>>>> In the hope that you will take up Fred's generous offer to push
>>>> this through
>>> to
>>>> an RFC, I hope that you will find these comments helpful
>>>
>>> Thanks for the feedback! As Jari already mentioned, we haven't
>>> fixed our plans regarding how and if these results should be
>>> published, but if there is
>> interest
>>> in the WG, v6ops RFC is indeed one good option.
>>>
>>>> I would like to see more references, for 6to4 and for the
>>>> various .pdf; I
>>> think
>>>> it works better to have them all in one place.
>>>
>>> By .pdf do you mean the graph PDFs, other presentations something
>>> else?
>>>
>>>  I mean the graph PDFs, where you have the URI in the text
>>> but not in the References, I would like it at least in the
>>> latter, less concerned about the former. 
>>>
>>>> I find the X-axis of the graphs unclear; time presumably, but
>>>> what time?
>>>
>>> It's the sequence number of the measurement run; so something
>>> like "time in 3 hour steps since the start of the tests".
>>> Probably hours (or even time and
>> date)
>>> would work better here.
>>>
>>>  Yes, date and time would be lovely; I thought it was
>>> measurement run but did
>> not
>>> have a start point and the interval was not obvious. 
>>>
>>>> I think that the biggest conclusion is omitted; only 2.45% of
>>>> the top 10,000 sites offer IPv6 via DNS ie next to none; I
>>>> think that this should be in BIG BOLD LETTERS.
>>>
>>> True, but that was not news to anyone :)
>>>
>>>  Disagree; we know that the availability of IPv6 is
>>> negligible but we do not
>> know
>>> how much it is, and a hard data point at a point in time will
>>> provide a
>> valuable
>>> record.  I was surprised at how small it was, I would have
>>> guessed 10-20% (
>> but
>>> then I am probably misled but the amount of traffic on the v6ops
>>> list:-) 
>>>
>>>> And while comprehension is no problem, the idiom is sometimes
>>>> slightly odd. Doubtless the RFC Editor will fix it but I could
>>>> point some of these out to
>>> you
>>>> if you want.
>>>
>>> That'd be helpful; please send me a mail with those off-list.
>>>
>>>  I hope you do; Fred has indicated a willingness to help.  I
>>> cannot think of a way to put it without being unfair to Fred, but
>>> it is an offer never to spurn.
>>>
>>> Tom Petch  Cheers, Ari
>>>
>>> P.S. I'll be out of office for a couple of weeks, so it may take
>>> a while
>> before
>>> I have a chance to follow up on this
>>>
>>>
>>>> Tom Petch
>>>>
>>>> ----- Original Message ----- From: "Fred
>>>> Baker" To: "t.petch" Cc:
>>>> "IPv6 Operations" Sent: Monday, August 01, 2011
>>>> 6:49 PM On Aug 1, 2011, at 3:23 AM, t.petch wrote:
>>>
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>


From marc.blanchet@viagenie.ca  Wed Dec 21 07:17:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA59921F848D for ; Wed, 21 Dec 2011 07:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.579
X-Spam-Level: 
X-Spam-Status: No, score=-100.579 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, 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 21zz6yGJI0NC for ; Wed, 21 Dec 2011 07:17:17 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 69BBE21F848A for ; Wed, 21 Dec 2011 07:17:17 -0800 (PST)
Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BCD4620C96; Wed, 21 Dec 2011 10:16:46 -0500 (EST)
From: Marc Blanchet 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Dec 2011 10:16:44 -0500
Message-Id: <44F3E2BD-EC1E-4623-8914-0563407F89AC@viagenie.ca>
To: draft-ietf-v6ops-happy-eyeballs@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Cc: "v6ops@ietf.org WG" 
Subject: [v6ops] draft-ietf-v6ops-happy-eyeballs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 15:17:17 -0000

Hi, from draft-ietf-v6ops-happy-eyeballs:


5.3.  Three or More Interfaces

   A dual-stack host normally has two logical interfaces:  an IPv6
   interface and an IPv4 interface.  However, a dual-stack host might
   have more than two logical interfaces because of a VPN (where a third
   interface is the tunnel address, often assigned by the remote
   corporate network) or because of multiple physical interfaces such as
   wired and wireless Ethernet, because the host belongs to multiple
   VLANs, or other reasons.  The interaction of Happy Eyeballs with more
   than two logical interfaces is for further study.


I think this text above is underspecified and the problem is much more =
complex than what is currently written.=20
I'm not sure what to write to help, but at least it should reference to =
the MIF problem statement [RFC6418].=20
There is also a draft about HE and MIF, maybe it should be referenced =
too?
Maybe some text around this should be added:

In the context of multiple interfaces, or multiple provisioning domains, =
the algorithm described in this document
might lead to wrong results or failed connections, as some of these =
issues are described in [RFC6418].=20
Therefore, in the context of multiple interfaces or multiple =
provisioning domains, additional processing such
as [draft-chen-mif-happy-eyeballs-extension] or else must be implemented =
to properly handle this situation.


Marc.=

From mark@townsley.net  Wed Dec 21 08:22:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91E21F888A for ; Wed, 21 Dec 2011 08:22:55 -0800 (PST)
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_13=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 fg2NI8mBQX1x for ; Wed, 21 Dec 2011 08:22:54 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A11BF21F86FF for ; Wed, 21 Dec 2011 08:22:53 -0800 (PST)
Received: by faas1 with SMTP id s1so4046923faa.31 for ; Wed, 21 Dec 2011 08:22:52 -0800 (PST)
Received: by 10.180.91.201 with SMTP id cg9mr15691071wib.15.1324484572222; Wed, 21 Dec 2011 08:22:52 -0800 (PST)
Received: from ams-townsley-8718.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fy13sm6378440wbb.18.2011.12.21.08.22.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 08:22:50 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-432501267
From: Mark Townsley 
In-Reply-To: 
Date: Wed, 21 Dec 2011 17:22:48 +0100
Message-Id: 
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com> <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net> 
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 16:22:57 -0000

--Apple-Mail-1-432501267
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Dec 21, 2011, at 3:16 AM, Tina TSOU wrote:

> Mark,
> After discussing with co-authors of Light Weight 4over6, I think my =
question is =93how the CPE to distinguish AFTR from TC?=94. You talks =
about that for the CPE to select the right interface for multi-homing =
setting. It won't solve the problem I asked.

Well, the our model should be able to fit 4over6 or anything else out =
there (otherwise its not nearly as robust as we are saying it is!). If I =
understand what 4over6 is, the key point to the CE here is that an IPv4 =
address is assigned by the ISP to the CE over the IPv6 tunnel. In our =
model, this would enable the NAPT function on that 4over6 virtual =
interface, and packets would be routed there accordingly. Which packets =
get there depends on policy-based metrics in the RIB, which could be =
configured by the user, operator, or simply follow default policy.=20

- Mark


> If it is not in the scope of =
draft-townsley-troan-ipv6-ce-transitioning-02, that=92s fine. Thank you =
for your help anyway.
> =20
> -Tina
> =20
> From: Mark Townsley [mailto:mark@townsley.net]=20
> Sent: Monday, December 19, 2011 12:50 AM
> To: Tina TSOU
> Cc: v6ops@ietf.org Operations
> Subject: Re: [v6ops] Up-leveling Transition Coexistence
> =20
> =20
> On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:
>=20
>=20
> Mark,
>=20
> Sent from my iPad
>=20
> On Dec 17, 2011, at 1:53 AM, "Mark Townsley"  =
wrote:
>=20
> =20
> On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:
>=20
>=20
> Mark,
> Thanks. It is very useful.=20
>=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
> How to do "forwarding-oriented" in CPE to distinguish among the =
techniques such as classical DS-Lite and Light Weight 4over6?
> =20
> Our latest version attempts to tackle this:
> =20
> =
http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
> I read this draft, it is well written.
> =20
> Thank you.
>=20
>=20
> In table one, we have used all 3 bits. Light Weight 4over6 is not on =
the list. How does the CE know it is going to be operated in which =
mechanism, if it is only forwarding-oriented?
> =20
> It is assumed the CE naturally knows which interface types it supports =
because it had to implement them. The "forwarding-oriented" model =
followed in the document assumes that any can be configured at any time. =
If the CE supports 4over6, it will fit that into the policy table based =
on the main principles we outline in the draft. The example table is =
just that, an example of some technologies available today based on a =
set of base principles. If we agree on the principles, I think we can =
classify just about any new technology that we have now or comes along. =
In the case of 4over6, since the default policy we proposed ranks use of =
IPv6 transport very high, 4over6 would also be weighted very high.=20
> =20
> In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native =
IPv4. Based on the principles in the draft, the use of IPv6 as a =
transport would place DS-lite on a preferred path vs. Native IPv4. So, =
when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear =
in the AFTR, while existing local NAPT entries time out or shut down =
naturally. It should be fairly seamless to the user, and allows for =
active failover as well in case the DS-Lite tunnel goes down for =
whatever reason.=20
>=20
>=20
> Then, do we have to to change this value by re-coding if each =
mechanism is added? Or make a CLI to change this value?
> =20
> The policy is essentially a global preference in terms of v6 transport =
and NAPT state boiled down to a single point of default configuration. =
Follow the defaults, and there will be no need for CLI or otherwise. If =
you want to override the defaults, there is a single place to do so.=20
> =20
> - Mark
> =20
>=20
>=20
> =20
> - Mark
>=20
>=20
>=20
> - Tina
>=20
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Mark Townsley
> Sent: Wednesday, December 14, 2011 9:27 AM
> To: v6ops@ietf.org Operations
> Subject: [v6ops] Up-leveling Transition Coexistence
>=20
>=20
> Folks,
>=20
> We have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work =
together on a residential CE router. I'd like to summarize what I think =
the main architectural issue is alongside a possible solution framework. =
Technical comments are very welcome, but let's also try and keep them =
thoughtful and at a pace that everyone can keep up amidst their =
day-jobs.=20
>=20
> The requirements in RFC 6204 are based on a fundamental assumption =
that a CE router has a single active WAN interface for forwarding IPv4 =
and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via =
Native, IPv4 via DS-lite and IPv4 via Native together forces us to at =
least reconsider this basic assumption.  Breaking this down at bit, =
there are three possible steady-state combinations of "native" and =
"virtual" (tunneled) dual-stack connectivity methods that do not break =
the basic forwarding model of a single WAN egress per IP version:
>=20
> (1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)=20
> (2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S =
via L2TP, TSP, etc)=20
> (3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)=20=

>=20
> Digging deeper into transition between these states:
>=20
> For (1), IPv4 and IPv6 each share a single WAN interface, so there is =
no problem when enabling one vs. the other.=20
>=20
> For (2), when enabling tunneled IPv6 on an existing IPv4-only network =
there is no significant change in the basic model as each IP version =
still has its own distinct single WAN interface. Multihoming issues =
arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.
>=20
> For (3) there similarly is no problem when enabling tunneled IPv4 on =
an existing IPv6-only network, and I have been told that there are =
greenfield deployments just like this happening. The multihoming issues =
arise when enabling tunneled IPv4 on a network that has native IPv4 =
available at the same time. =20
>=20
> I'd like to identify two strategies to deal with these situations.=20
>=20
> The first I will call "configuration-oriented". For this to work, one =
of the following assumptions must hold. None are pretty, but you MUST =
pick one to avoid solving how to forward traffic when multiple =
interfaces are enabled at the same time for a given IP version.=20
>=20
> (a) =46rom the perspective of the CE router, the network supports only =
one type of interface for a given IP version, or=20
>=20
> (b) The CE router is configured in advance of any IP configuration to =
support only one type of interface for a given IP version, or
>=20
> (c) The CE router goes through an ordered set of configuration =
attempts in series, each requiring a timeout before moving to the next. =
Transition-oriented changes after steady-state is reached will require =
"reboot" to go through the ordered process from scratch.=20
>=20
> (d) The CE router chooses one type of interface and shuts down all =
others based on a predetermined priority when more than one interface =
with the same IP version is configured. This allows parallel =
configuration attempts and changes after reaching steady-state, but =
requires the CE router and network to manage a "flash cut" from one =
configured interface to the other and may be prone to tricky =
race-conditions.
>=20
> The second strategy I will call "forwarding-oriented." In this model, =
configuration of any WAN interface method at any time is accepted. The =
CE follows forwarding rules in order to ensure packets make it out the =
right interface on WAN egress, and liberally accepts packets on WAN =
ingress. This is "classic multihoming" and should work for any order of =
planned incremental transition steps, as well as failover and/or =
transient situations.
>=20
> After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis =
began adopting some of the "forwarding-based" requirements for IPv6, =
though DS-Lite remained in the "configuration-based" role for IPv4.=20
>=20
> Ole and I also just published =
draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general =
set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is =
a "forwarding-based" solution for IPv6). We'll be publishing the same =
for IPv4 in order to support DS-Lite. Neither are rocket science, but =
teaching the CE to properly forward when faced with more than one =
alternative egress interface has been labeled "hard" (though as an =
interesting data point I have found IPv4 routers that support multiple =
WAN interfaces at the same time for less than $50). In my mind, the =
"configuration-oriented" alternative seems at least as hard as the =
"forwarding-oriented" alternative, is less robust, and certainly less =
flexible in terms of letting the operator decide its fate in terms of =
how to perform each transition step.
>=20
> Again, technical comments are very welcome. Mostly I would like to =
know if people understand and agree with the basic premise here, and if =
so whether "configuration-oriented" or "forwarding-oriented" is the best =
way forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-)=20
>=20
> Thanks, and Happy Holidays in advance to those who will be celebrating =
soon,
>=20
> - Mark
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =20
> =20


--Apple-Mail-1-432501267
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Dec 21, 2011, at 3:16 AM, Tina =
TSOU wrote:

After =
discussing with co-authors of Light Weight 4over6, I think my question =
is =93how =
the CPE to distinguish AFTR from TC?=94. You=
 talks about that for=
 the CPE to select the right interface for multi-homing setting. It =
won't solve the problem I =
asked.

<=
div>Well, the our model should be able to fit 4over6 or anything else =
out there (otherwise its not nearly as robust as we are saying it is!). =
If I understand what 4over6 is, the key point to the CE here is that an =
IPv4 address is assigned by the ISP to the CE over the IPv6 tunnel. In =
our model, this would enable the NAPT function on that 4over6 virtual =
interface, and packets would be routed there accordingly. Which packets =
get there depends on policy-based metrics in the RIB, which could be =
configured by the user, operator, or simply follow default =
policy. 

- =
Mark


If it is not in the scope of =
draft-townsley-troan-ipv6-ce-transitioning-02, that=92s fine. Thank you =
for your help =
anyway.
From: Mark Townsley =
[mailto:mark@townsley.net] 
Sent: Monday, December 19, 2011 =
12:50 AM
To: Tina =
TSOU
Cc: v6ops@ietf.org Operations
Subject:=
 Re: [v6ops] =
Up-leveling Transition =
Coexistence
On Dec =
18, 2011, at 1:34 AM, Tina TSOU wrote:


Mark,

Sent from my =
iPad

On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <mark@townsley.net> =
wrote:
On Dec =
15, 2011, at 11:29 PM, Tina TSOU =
wrote:
 

(3) One Virtual IPv4 and one Native IPv6 =
interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to =
distinguish among the techniques such as classical DS-Lite and Light =
Weight 4over6?
Our =
latest version attempts to tackle =
this:



- Tina


-----Original =
Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or=
g] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 =
AM
To: v6ops@ietf.org Operations
Subject: =
[v6ops] Up-leveling Transition Coexistence


Folks,

We =
have had a lot of lively discussion of late on the new sections in =
6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to =
work together on a residential CE router. I'd like to summarize what I =
think the main architectural issue is alongside a possible solution =
framework. Technical comments are very welcome, but let's also try and =
keep them thoughtful and at a pace that everyone can keep up amidst =
their day-jobs. 

The requirements in =
RFC 6204 are based on a fundamental assumption that a CE router has a =
single active WAN interface for forwarding IPv4 and IPv6 traffic towards =
an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite =
and IPv4 via Native together forces us to at least reconsider this basic =
assumption.  Breaking this down at bit, there are three possible =
steady-state combinations of "native" and "virtual" (tunneled) =
dual-stack connectivity methods that do not break the basic forwarding =
model of a single WAN egress per IP version:

(1) One Native IPv4 =
and IPv6 interface (Classic Dual-Stack) 
(2) One Native IPv4 and =
one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, =
etc) 
(3) One =
Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 

Digging deeper into =
transition between these states:

For (1), IPv4 and IPv6 each =
share a single WAN interface, so there is no problem when enabling one =
vs. the other. 

For (2), when =
enabling tunneled IPv6 on an existing IPv4-only network there is no =
significant change in the basic model as each IP version still has its =
own distinct single WAN interface. Multihoming issues arise when =
enabling native IPv6 alongside tunneled IPv6 (needed for "6rd =
sunsetting") as IPv6 may be enabled on two distinct interfaces at the =
same time.

For (3) there similarly is no problem when enabling =
tunneled IPv4 on an existing IPv6-only network, and I have been told =
that there are greenfield deployments just like this happening. The =
multihoming issues arise when enabling tunneled IPv4 on a network that =
has native IPv4 available at the same time.  

I'd like to =
identify two strategies to deal with these situations. 

The first I will =
call "configuration-oriented". For this to work, one of the following =
assumptions must hold. None are pretty, but you MUST pick one to avoid =
solving how to forward traffic when multiple interfaces are enabled at =
the same time for a given IP version. 

(a) =46rom the =
perspective of the CE router, the network supports only one type of =
interface for a given IP version, or 

(b) The CE router =
is configured in advance of any IP configuration to support only one =
type of interface for a given IP version, or

(c) The CE router =
goes through an ordered set of configuration attempts in series, each =
requiring a timeout before moving to the next. Transition-oriented =
changes after steady-state is reached will require "reboot" to go =
through the ordered process from scratch. 

(d) The CE router =
chooses one type of interface and shuts down all others based on a =
predetermined priority when more than one interface with the same IP =
version is configured. This allows parallel configuration attempts and =
changes after reaching steady-state, but requires the CE router and =
network to manage a "flash cut" from one configured interface to the =
other and may be prone to tricky race-conditions.

The second =
strategy I will call "forwarding-oriented." In this model, configuration =
of any WAN interface method at any time is accepted. The CE follows =
forwarding rules in order to ensure packets make it out the right =
interface on WAN egress, and liberally accepts packets on WAN ingress. =
This is "classic multihoming" and should work for any order of planned =
incremental transition steps, as well as failover and/or transient =
situations.

After publishing =
draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of =
the "forwarding-based" requirements for IPv6, though DS-Lite remained in =
the "configuration-based" role for IPv4. 

Ole and I also just =
published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a =
general set of IPv6 requirements for multihoming with 6rd-specifics =
(i.e., it is a "forwarding-based" solution for IPv6). We'll be =
publishing the same for IPv4 in order to support DS-Lite. Neither are =
rocket science, but teaching the CE to properly forward when faced with =
more than one alternative egress interface has been labeled "hard" =
(though as an interesting data point I have found IPv4 routers that =
support multiple WAN interfaces at the same time for less than $50). In =
my mind, the "configuration-oriented" alternative seems at least as hard =
as the "forwarding-oriented" alternative, is less robust, and certainly =
less flexible in terms of letting the operator decide its fate in terms =
of how to perform each transition step.

Again, technical comments =
are very welcome. Mostly I would like to know if people understand and =
agree with the basic premise here, and if so whether =
"configuration-oriented" or "forwarding-oriented" is the best way =
forward. So far, I think the forwarding-oriented approach wins hands =
down, but then again I'm used to building routers that have lots of =
interfaces and operators that ask them to do all sorts of crazy things =
:-) 

Thanks, =
and Happy Holidays in advance to those who will be celebrating =
soon,

- =
Mark
_______________________________________________
v6ops mailing =
list
v6ops@ietf.org
, "v6ops@ietf.org" , "fred.baker@cisco.com" , Tore Anderson , "barbara.stark@att.com" , "dromasca@avaya.com" , RFC Errata System 
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 16:28:59 -0000

On Dec 20, 2011, at 8:06 PM, Wes Beebee wrote:

>> That said, disallowing VL=3D0 appears to me to be either an =
oversight, or
>> based on an incorrect reading of RFC 4862 section 5.5.3 (e).
>=20
> Specifically, RFC 4862 section 5.5.3 (e) governs the processing of =
RA's on
> receipt by a host.  It does not govern the sending of RA's by routers. =
 In
> the case where a router sends VL=3D0 in an RA, the processing of that =
RA by
> the receiving host will result in exactly the same actions on the part =
of
> the host as when the VL follows the more complicated 2-hour rule.
> Therefore, setting VL=3D0 in the RA will result in no harm done to the =
network
> and may result in a simpler router implementation.
>=20
> The Errata process bypasses WG consensus.

The intent of Errata is indeed to catch oversights and errors, not =
bypass WG consensus (or IETF consensus, which is really what happens =
when a WG document is approved for publication). ADs have to sign off on =
all Errata, and part of that job is verifying that the errata is not =
circumventing consensus.

>  The advantage of putting this in
> rfc6204bis is that the change will be ratified by the WG during the =
normal
> document progression process.

We can do both.

- Mark

>=20
> - Wes
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From internet-drafts@ietf.org  Thu Dec 22 13:03:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3C41F0C4A; Thu, 22 Dec 2011 13:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 qRZTbnaudffD; Thu, 22 Dec 2011 13:03:18 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2B11F0C35; Thu, 22 Dec 2011 13:03:18 -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: 3.64p1
Message-ID: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>
Date: Thu, 22 Dec 2011 13:03:18 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 21:03:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Basic Requirements for IPv6 Customer Edge Routers
	Author(s)       : Hemant Singh
                          Wes Beebee
                          Chris Donley
                          Barbara Stark
                          Ole Troan
	Filename        : draft-ietf-v6ops-6204bis-05.txt
	Pages           : 21
	Date            : 2011-12-22

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers IP transition
   technologies.  Two transition technologies in RFC 5969's 6rd and RFC
   6333's DS-Lite. are covered in the document.  The document obsoletes
   RFC 6204, if approved.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.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-v6ops-6204bis-05.txt


From Tina.Tsou.Zouting@huawei.com  Thu Dec 22 14:05:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB2B1F0C4C for ; Thu, 22 Dec 2011 14:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.527
X-Spam-Level: 
X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, 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 nkSK2N8qhOF4 for ; Thu, 22 Dec 2011 14:05:52 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id ED6E721F84D5 for ; Thu, 22 Dec 2011 14:05:51 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWM004S1LDJEW@szxga05-in.huawei.com> for v6ops@ietf.org; Fri, 23 Dec 2011 06:05:43 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWM004NYLDJRR@szxga05-in.huawei.com> for v6ops@ietf.org; Fri, 23 Dec 2011 06:05:43 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFW69490; Fri, 23 Dec 2011 06:05:42 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 06:05:35 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 06:05:37 +0800
Date: Thu, 22 Dec 2011 22:05:36 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: Mark Townsley 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_6uf4iNeoUuRjjMI828Yebg)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Up-leveling Transition Coexistence
Thread-index: AQHMuoWtLIv9EMTPEUqfzMLkWVTTkJXde9CAgAHMi4CAAXwkA4ABlqwAgAM7azCAAGfQAIACd7OA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com> <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>  
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 22:05:58 -0000

--Boundary_(ID_6uf4iNeoUuRjjMI828Yebg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

In line...

- Tina


From: Mark Townsley [mailto:mark@townsley.net]
Sent: Wednesday, December 21, 2011 8:23 AM
To: Tina TSOU
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence


On Dec 21, 2011, at 3:16 AM, Tina TSOU wrote:


Mark,
After discussing with co-authors of Light Weight 4over6, I think my question is "how the CPE to distinguish AFTR from TC?". You talks about that for the CPE to select the right interface for multi-homing setting. It won't solve the problem I asked.

Well, the our model should be able to fit 4over6 or anything else out there (otherwise its not nearly as robust as we are saying it is!). If I understand what 4over6 is, the key point to the CE here is that an IPv4 address is assigned by the ISP to the CE over the IPv6 tunnel. In our model, this would enable the NAPT function on that 4over6 virtual interface, and packets would be routed there accordingly. Which packets get there depends on policy-based metrics in the RIB, which could be configured by the user, operator, or simply follow default policy.

[Tina] it seems like you are trying to explain how to survive the CPE forwarding when there're both DS-Lite and 4over6, or native IPv4 access.
But our problem is the AFTR/TC discovery.

- Mark


If it is not in the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that's fine. Thank you for your help anyway.

-Tina

From: Mark Townsley [mailto:mark@townsley.net]
Sent: Monday, December 19, 2011 12:50 AM
To: Tina TSOU
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence


On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:



Mark,

Sent from my iPad

On Dec 17, 2011, at 1:53 AM, "Mark Townsley" > wrote:

On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:



Mark,
Thanks. It is very useful.


(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?

Our latest version attempts to tackle this:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
I read this draft, it is well written.

Thank you.



In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented?

It is assumed the CE naturally knows which interface types it supports because it had to implement them. The "forwarding-oriented" model followed in the document assumes that any can be configured at any time. If the CE supports 4over6, it will fit that into the policy table based on the main principles we outline in the draft. The example table is just that, an example of some technologies available today based on a set of base principles. If we agree on the principles, I think we can classify just about any new technology that we have now or comes along. In the case of 4over6, since the default policy we proposed ranks use of IPv6 transport very high, 4over6 would also be weighted very high.

In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native IPv4. Based on the principles in the draft, the use of IPv6 as a transport would place DS-lite on a preferred path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear in the AFTR, while existing local NAPT entries time out or shut down naturally. It should be fairly seamless to the user, and allows for active failover as well in case the DS-Lite tunnel goes down for whatever reason.



Then, do we have to to change this value by re-coding if each mechanism is added? Or make a CLI to change this value?

The policy is essentially a global preference in terms of v6 transport and NAPT state boiled down to a single point of default configuration. Follow the defaults, and there will be no need for CLI or otherwise. If you want to override the defaults, there is a single place to do so.

- Mark





- Mark




- Tina


-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To: v6ops@ietf.org Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs.

The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc)
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other.

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.

I'd like to identify two strategies to deal with these situations.

The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version.

(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or

(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or

(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch.

(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4.

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-)

Thanks, and Happy Holidays in advance to those who will be celebrating soon,

- Mark
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops




--Boundary_(ID_6uf4iNeoUuRjjMI828Yebg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT















In line…


 


- Tina


 




 






From: Mark
 Townsley [mailto:mark@townsley.net] 

Sent: Wednesday, December 21, 2011 8:23 AM

To: Tina TSOU

Cc: v6ops@ietf.org Operations

Subject: Re: [v6ops] Up-leveling Transition Coexistence






 


 






On Dec 21, 2011, at 3:16 AM, Tina TSOU wrote:















Mark,






After discussing with co-authors of Light Weight 4over6, I think my question is “how
 the CPE to distinguish AFTR from TC?”. You
 talks about that for
 the CPE to select the right interface for multi-homing setting. It won't solve the problem I asked.








 






Well, the our model should be able to fit 4over6 or anything else out there (otherwise its not nearly as robust as we are saying it is!). If I understand what 4over6 is, the key point
 to the CE here is that an IPv4 address is assigned by the ISP to the CE over the IPv6 tunnel. In our model, this would enable the NAPT function on that 4over6 virtual interface, and packets would be routed there accordingly. Which packets get there depends
 on policy-based metrics in the RIB, which could be configured by the user, operator, or simply follow default policy. 






 


[Tina] it seems like you are trying to explain how to survive the CPE forwarding when
there're both DS-Lite and 4over6, or native IPv4 access.


But our problem is the AFTR/TC discovery.


 






- Mark






 






 










If it is not in the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that’s
 fine. Thank you for your help anyway.
















 






-Tina








 







 






 










On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:

























Mark,



Sent from my iPad













 










On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:























Mark,

Thanks. It is very useful. 












(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)






How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?










 










Our latest version attempts to tackle this:










 















I read this draft, it is well written.










 










Thank you.























In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented?










 










It is assumed the CE naturally knows which interface types it supports because it had to implement them. The "forwarding-oriented" model followed in the document assumes that any can
 be configured at any time. If the CE supports 4over6, it will fit that into the policy table based on the main principles we outline in the draft. The example table is just that, an example of some technologies available today based on a set of base principles.
 If we agree on the principles, I think we can classify just about any new technology that we have now or comes along. In the case of 4over6, since the default policy we proposed ranks use of IPv6 transport very high, 4over6 would also be weighted very high. 










 










In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native IPv4. Based on the principles in the draft, the use of IPv6 as a transport would place DS-lite on a preferred
 path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear in the AFTR, while existing local NAPT entries time out or shut down naturally. It should be fairly seamless to the user, and allows for active failover as well
 in case the DS-Lite tunnel goes down for whatever reason. 























Then, do we have to to change this value by re-coding if each mechanism is added? Or make a CLI to change this value?










 










The policy is essentially a global preference in terms of v6 transport and NAPT state boiled down to a single point of default configuration. Follow the defaults, and there will be
 no need for CLI or otherwise. If you want to override the defaults, there is a single place to do so. 










 










- Mark










 































 










- Mark

























- Tina





-----Original Message-----

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley

Sent: Wednesday, December 14, 2011 9:27 AM

To: v6ops@ietf.org Operations

Subject: [v6ops] Up-leveling Transition Coexistence





Folks,



We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible
 solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs. 



The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together
 forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single
 WAN egress per IP version:



(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack) 

(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc) 

(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc) 



Digging deeper into transition between these states:



For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other. 



For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled
 IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.



For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that
 has native IPv4 available at the same time.  



I'd like to identify two strategies to deal with these situations. 



The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP
 version. 



(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or 



(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or



(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch. 



(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state,
 but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.



The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally
 accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.



After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4. 



Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order
 to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple
 WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its
 fate in terms of how to perform each transition step.



Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented
 approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-) 



Thanks, and Happy Holidays in advance to those who will be celebrating soon,



- Mark

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops










 














 










 






--Boundary_(ID_6uf4iNeoUuRjjMI828Yebg)--

From phdgang@gmail.com  Thu Dec 22 19:58:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BBF11E80DC for ; Thu, 22 Dec 2011 19:58:24 -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 iFh1CQ54rlHq for ; Thu, 22 Dec 2011 19:58:24 -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 D0E2011E80BD for ; Thu, 22 Dec 2011 19:58:23 -0800 (PST)
Received: by wibhj6 with SMTP id hj6so3605781wib.31 for ; Thu, 22 Dec 2011 19:58:22 -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=vBnFCSztm4k8Ld8OyBQ26nEQ32Zdlg/02podTSaYq0I=; b=n7v4rf6gBCgeUHINw7F/ugRkH6xu72A1tLvjuv5f7ZjEFf5VpDp2pY1JwrA5yNswIN Cd27XRrRdwVdmiUUr3ZHP7qizVzUc5GIqjIkc7YlqoExL817ga53m00zZBxzS0z0b8Rn bWIX9U6DbcjjJ4TgP8PXFZJcnydA59rL+vOqo=
MIME-Version: 1.0
Received: by 10.180.81.72 with SMTP id y8mr28746154wix.14.1324612702805; Thu, 22 Dec 2011 19:58:22 -0800 (PST)
Received: by 10.180.95.230 with HTTP; Thu, 22 Dec 2011 19:58:22 -0800 (PST)
In-Reply-To: <44F3E2BD-EC1E-4623-8914-0563407F89AC@viagenie.ca>
References: <44F3E2BD-EC1E-4623-8914-0563407F89AC@viagenie.ca>
Date: Fri, 23 Dec 2011 11:58:22 +0800
Message-ID: 
From: GangChen 
To: Marc Blanchet 
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-ietf-v6ops-happy-eyeballs@tools.ietf.org, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 03:58:24 -0000

> I think this text above is underspecified and the problem is much more
> complex than what is currently written.
> I'm not sure what to write to help, but at least it should reference to the
> MIF problem statement [RFC6418].
> There is also a draft about HE and MIF, maybe it should be referenced too?

+1

> Maybe some text around this should be added:
> 
> In the context of multiple interfaces, or multiple provisioning domains, the
> algorithm described in this document
> might lead to wrong results or failed connections, as some of these issues
> are described in [RFC6418].
> Therefore, in the context of multiple interfaces or multiple provisioning
> domains, additional processing such
> as [draft-chen-mif-happy-eyeballs-extension] or else must be implemented to
> properly handle this situation.
> 
>

We (HE-MIF-extension authors) are targeting to solve the issues in the
context of multiple interfaces. For the suggested text, please allow
me to revise a little.

Since RFC6418 describes some particular issues in the context of
multiple interfaces, or multiple provisioning domains, the algorithm
described in this document is mainly focusing on the context of
single-home. Therefore, in the context of multiple interfaces or
multiple provisioning domains, additional processing such as
[draft-chen-mif-happy-eyeballs-extension] or else must be implemented
to properly handle this situation.


BRs

Gang

From fred@cisco.com  Thu Dec 22 23:48:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE81F0C48 for ; Thu, 22 Dec 2011 23:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.119
X-Spam-Level: 
X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, 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 WqA1+i9hQdOp for ; Thu, 22 Dec 2011 23:48:13 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 356CD1F0C3F for ; Thu, 22 Dec 2011 23:48:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1988; q=dns/txt; s=iport; t=1324626493; x=1325836093; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Eg2Oi6GIV+D23Ggpg3c0if0qdkKUTBcdOSNEM5FaaSc=; b=g96twp11McCVNv2zZu2Vb1wxCEXnLr5UJd70INPdbTh4GFp+O15sOtP6 1bUPKcElwx6xHi7+0ZryvJIJOzNxVkBuQx8K6yLO0cXgp0O5ThJ3YnMRE S5myz8h+AqX8sKvuEQa/3dHokffOBVjYmxHVJEPn62SgA3HeZh7r/BLFO M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGgx9E6rRDoJ/2dsb2JhbABErDOBBYFyAQEBAwEBAQEPASc0CwULC0YnMAYTIodYCJhuAZ4hBIssYwSIN4xKhU+NBA
X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; d="scan'208";a="22268864"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 23 Dec 2011 07:48:12 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBN7mBOb004480; Fri, 23 Dec 2011 07:48:11 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Thu, 22 Dec 2011 23:48:11 -0800
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Thu, 22 Dec 2011 23:48:11 -0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <44F3E2BD-EC1E-4623-8914-0563407F89AC@viagenie.ca>
Date: Thu, 22 Dec 2011 23:47:41 -0800
Message-Id: 
References: <44F3E2BD-EC1E-4623-8914-0563407F89AC@viagenie.ca>
To: Marc Blanchet 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-v6ops-happy-eyeballs@tools.ietf.org, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 07:48:14 -0000

So, what you're saying is that it has multiple addresses, some of which =
might be IPv4 and some of which might be IPv6, and the number of =
addresses is independent of the number of physical interface?


On Dec 21, 2011, at 7:16 AM, Marc Blanchet wrote:

> Hi, from draft-ietf-v6ops-happy-eyeballs:
>=20
> 
> 5.3.  Three or More Interfaces
>=20
>   A dual-stack host normally has two logical interfaces:  an IPv6
>   interface and an IPv4 interface.  However, a dual-stack host might
>   have more than two logical interfaces because of a VPN (where a =
third
>   interface is the tunnel address, often assigned by the remote
>   corporate network) or because of multiple physical interfaces such =
as
>   wired and wireless Ethernet, because the host belongs to multiple
>   VLANs, or other reasons.  The interaction of Happy Eyeballs with =
more
>   than two logical interfaces is for further study.
> 
>=20
> I think this text above is underspecified and the problem is much more =
complex than what is currently written.=20
> I'm not sure what to write to help, but at least it should reference =
to the MIF problem statement [RFC6418].=20
> There is also a draft about HE and MIF, maybe it should be referenced =
too?
> Maybe some text around this should be added:
> 
> In the context of multiple interfaces, or multiple provisioning =
domains, the algorithm described in this document
> might lead to wrong results or failed connections, as some of these =
issues are described in [RFC6418].=20
> Therefore, in the context of multiple interfaces or multiple =
provisioning domains, additional processing such
> as [draft-chen-mif-happy-eyeballs-extension] or else must be =
implemented to properly handle this situation.
> 
>=20
> Marc.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From mark@townsley.net  Fri Dec 23 04:36:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4066621F8B18 for ; Fri, 23 Dec 2011 04:36:03 -0800 (PST)
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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 OBJK61z-IBva for ; Fri, 23 Dec 2011 04:36: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 10B9B21F8AF9 for ; Fri, 23 Dec 2011 04:36:01 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so13212053wgb.13 for ; Fri, 23 Dec 2011 04:36:01 -0800 (PST)
Received: by 10.227.206.6 with SMTP id fs6mr14347852wbb.20.1324643761167; Fri, 23 Dec 2011 04:36:01 -0800 (PST)
Received: from ams-townsley-8718.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dj9sm31271758wib.6.2011.12.23.04.35.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Dec 2011 04:35:57 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-16-591687083
From: Mark Townsley 
In-Reply-To: 
Date: Fri, 23 Dec 2011 13:35:54 +0100
Message-Id: 
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com> <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>   
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 12:36:03 -0000

--Apple-Mail-16-591687083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 22, 2011, at 11:05 PM, Tina TSOU wrote:
>=20
> [Tina] it seems like you are trying to explain how to survive the CPE =
forwarding when there're both DS-Lite and 4over6, or native IPv4 access.

Yes.

> But our problem is the AFTR/TC discovery.

OK. By "discovery" you mean the tunnel endpoint address for sending =
traffic to an AFTR or TC? Isn't that simply part of a DHCPv6 option?

- Mark=

--Apple-Mail-16-591687083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Dec 22, 2011, at 11:05 PM, Tina =
TSOU wrote:

 there're both DS-Lite and 4over6, or native IPv4 =
access.

<=
/div>
Yes.

But our =
problem is the AFTR/TC =
discovery.
OK. By "discovery" you mean the tunnel endpoint address for =
sending traffic to an AFTR or TC? Isn't that simply part of a DHCPv6 =
option?

- Mark
=

--Apple-Mail-16-591687083--

From mark@townsley.net  Fri Dec 23 05:55:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019C321F8B5C for ; Fri, 23 Dec 2011 05:55:17 -0800 (PST)
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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 EGb7R5yYjfuS for ; Fri, 23 Dec 2011 05:55:16 -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 044BC21F8B4E for ; Fri, 23 Dec 2011 05:55:15 -0800 (PST)
Received: by wibhj6 with SMTP id hj6so3942765wib.31 for ; Fri, 23 Dec 2011 05:55:15 -0800 (PST)
Received: by 10.180.90.40 with SMTP id bt8mr32874687wib.4.1324648515266; Fri, 23 Dec 2011 05:55:15 -0800 (PST)
Received: from ams-townsley-8718.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d17sm13727847wbh.19.2011.12.23.05.55.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Dec 2011 05:55:14 -0800 (PST)
From: Mark Townsley 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-17-596444889
Date: Fri, 23 Dec 2011 14:55:12 +0100
In-Reply-To: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>
To: "v6ops@ietf.org Operations" 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>
Message-Id: 
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 13:55:17 -0000

--Apple-Mail-17-596444889
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


   DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
           its WAN interface then the IPv6 CE Router SHOULD disable the
           DS-Lite B4 element.
This requirement is saying that if the ISP has Dual-Stack configured =
alongside Dual-Stack Lite, that the CE SHOULD override this and disable =
Dual-Stack Lite entirely.
Is that what we *really* want for Christmas?
- Mark

On Dec 22, 2011, at 10:03 PM, Internet-Drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the IPv6 Operations Working =
Group of the IETF.
>=20
> 	Title           : Basic Requirements for IPv6 Customer Edge =
Routers
> 	Author(s)       : Hemant Singh
>                          Wes Beebee
>                          Chris Donley
>                          Barbara Stark
>                          Ole Troan
> 	Filename        : draft-ietf-v6ops-6204bis-05.txt
> 	Pages           : 21
> 	Date            : 2011-12-22
>=20
>   This document specifies requirements for an IPv6 Customer Edge (CE)
>   router.  Specifically, the current version of this document focuses
>   on the basic provisioning of an IPv6 CE router and the provisioning
>   of IPv6 hosts attached to it.  The document also covers IP =
transition
>   technologies.  Two transition technologies in RFC 5969's 6rd and RFC
>   6333's DS-Lite. are covered in the document.  The document obsoletes
>   RFC 6204, if approved.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-17-596444889
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

   DLW-3:  If the IPv6 =
CE Router is configured with an IPv4 address on
           its WAN interface then the IPv6 CE Router SHOULD disable the
           DS-Lite B4 element.
This requirement is saying that if the ISP has Dual-Stack =
configured alongside Dual-Stack Lite, that the CE SHOULD override this =
and disable Dual-Stack Lite entirely.
Is that what =
we *really* want for Christmas?
- Mark

On Dec 22, 2011, at 10:03 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 IPv6 Operations Working =
Group of the IETF.

	Title =
          : Basic =
Requirements for IPv6 Customer Edge Routers
	Author(s) =
      : Hemant Singh
 =
            &n=
bsp;           &nbs=
p;Wes Beebee
 =
            &n=
bsp;           &nbs=
p;Chris Donley
 =
            &n=
bsp;           &nbs=
p;Barbara Stark
 =
            &n=
bsp;           &nbs=
p;Ole Troan
	=
Filename        : =
draft-ietf-v6ops-6204bis-05.txt
	Pages =
          : =
21
	=
Date =
           : =
2011-12-22

   This document specifies requirements for =
an IPv6 Customer Edge (CE)
   router.  Specifically, =
the current version of this document focuses
   on the =
basic provisioning of an IPv6 CE router and the provisioning
 =
  of IPv6 hosts attached to it.  The document also covers =
IP transition
   technologies.  Two transition =
technologies in RFC 5969's 6rd and RFC
   6333's DS-Lite. =
are covered in the document.  The document obsoletes
 =
  RFC 6204, if approved.


A URL for this =
Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.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-v6ops-6204bis-05.txt<=
br>
_______________________________________________
v6ops mailing =
list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
<=
/div>

=

--Apple-Mail-17-596444889--

From denghui02@gmail.com  Fri Dec 23 06:33:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D4E21F87D6 for ; Fri, 23 Dec 2011 06:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.765
X-Spam-Level: 
X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tZzLRdvj-BvG for ; Fri, 23 Dec 2011 06:32:57 -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 1B05A21F87FA for ; Fri, 23 Dec 2011 06:32:57 -0800 (PST)
Received: by yenm7 with SMTP id m7so6640221yen.31 for ; Fri, 23 Dec 2011 06:32:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=b/1ouUilh6/+aycmI/gWe4uvykRYo9fqtaIvYpCuF7c=; b=GMK29aCVJpUxKHlb5a7kvYXVDSr4+axmfKqxbmE2RyWLVZOgYFDF9TdXRgPH4NHCAA kuhb+s2v2IW2fqxBg2xEk2chIlN/au/+XzvenIZTxBJY6+APJkjqxBjNXr4vSdjxYZU6 sMm4omQFipfD269Beh3blNzW1XbDFY9KsESc0=
MIME-Version: 1.0
Received: by 10.236.175.39 with SMTP id y27mr10212878yhl.86.1324650775648; Fri, 23 Dec 2011 06:32:55 -0800 (PST)
Received: by 10.146.118.14 with HTTP; Fri, 23 Dec 2011 06:32:55 -0800 (PST)
Date: Fri, 23 Dec 2011 22:32:55 +0800
Message-ID: 
From: Hui Deng 
To: v6ops@ietf.org
Content-Type: multipart/alternative; boundary=20cf305b0e18ef1ab104b4c34acc
Subject: [v6ops] Prime minister of China has arranged the next CNGI (IPv6) work today
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 14:33:00 -0000

--20cf305b0e18ef1ab104b4c34acc
Content-Type: text/plain; charset=ISO-8859-1

This is public information:
http://www.gov.cn/ldhd/2011-12/23/content_2027750.htm

IPv6 for IoT, Cloud, Mobile Internet

 In Chinese, but you may read them by google translation.

Happy Holiday

-Hui

--20cf305b0e18ef1ab104b4c34acc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


This is public information:



=A0


IPv6 for IoT, Cloud, Mobile Internet


=A0




In Chinese, but you may read them=A0by google translation.


=A0


Happy Holiday


=A0


-Hui


--20cf305b0e18ef1ab104b4c34acc--

From Tina.Tsou.Zouting@huawei.com  Fri Dec 23 09:47:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55C821F84C2 for ; Fri, 23 Dec 2011 09:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.88
X-Spam-Level: 
X-Spam-Status: No, score=-6.88 tagged_above=-999 required=5 tests=[AWL=-0.282,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MNdTqsJBtyAZ for ; Fri, 23 Dec 2011 09:47:05 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D154B21F84C1 for ; Fri, 23 Dec 2011 09:47:04 -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 <0LWO00JQ6429J1@szxga04-in.huawei.com> for v6ops@ietf.org; Sat, 24 Dec 2011 01:46:57 +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 <0LWO00LXD428UI@szxga04-in.huawei.com> for v6ops@ietf.org; Sat, 24 Dec 2011 01:46:57 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFX38562; Sat, 24 Dec 2011 01:46:56 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Dec 2011 01:46:48 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Sat, 24 Dec 2011 01:46:47 +0800
Date: Fri, 23 Dec 2011 17:46:45 +0000
From: Tina TSOU 
In-reply-to: 
To: Hui Deng 
Message-id: <0FB3D8DE-F053-4C7C-A60F-0C73C6B466FB@huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_qnJsz80Po+ancsu/7IqkzQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Prime minister of China has arranged the next CNGI (IPv6) work today
Thread-index: AQHMwX/YxeRjHBINZE+dzvStnL4T25Xpsq3e
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Prime minister of China has arranged the next CNGI (IPv6)	work today
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 17:47:06 -0000

--Boundary_(ID_qnJsz80Po+ancsu/7IqkzQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

The goal is to achieve the interflow of IPv6 and IPv4 mainstream services.

Happy Holidays,
Sent from my iPad

On Dec 23, 2011, at 6:33 AM, "Hui Deng" > wrote:

This is public information:
http://www.gov.cn/ldhd/2011-12/23/content_2027750.htm

IPv6 for IoT, Cloud, Mobile Internet

In Chinese, but you may read them by google translation.

Happy Holiday

-Hui

--Boundary_(ID_qnJsz80Po+ancsu/7IqkzQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT







The goal is to achieve the interflow of IPv6 and IPv4 mainstream services.






Happy Holidays,


Sent from my iPad




On Dec 23, 2011, at 6:33 AM, "Hui Deng" <denghui02@gmail.com> wrote:












This is public information:



 


IPv6 for IoT, Cloud, Mobile Internet


 




In Chinese, but you may read them by google translation.


 


Happy Holiday


 




-Hui














--Boundary_(ID_qnJsz80Po+ancsu/7IqkzQ)--

From brian.e.carpenter@gmail.com  Fri Dec 23 11:24:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919E821F8ABC for ; Fri, 23 Dec 2011 11:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.502
X-Spam-Level: 
X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 MXx4lmazcTkT for ; Fri, 23 Dec 2011 11:24:53 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E028021F8ABB for ; Fri, 23 Dec 2011 11:24:52 -0800 (PST)
Received: by eekc14 with SMTP id c14so8286929eek.31 for ; Fri, 23 Dec 2011 11:24:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Lyt9YfQkyNvPLKnyYBwPp9EQn/P5Th2T4KR/sk2mMr4=; b=O+H9y47j9U98VAglTLPQbIdPAwEfL0xPV7YXoFQ5Yvr7MEFzDDc31J+8UNXQrjTS1z V1DGZvgZr/RLJeCqc8cWYYfW1w8CDMwzz3j41o+QVvU7SjnXGmTOAE6CxQAP4DG4xiQZ A1rGuHTJ8hNsqJvYj8+1/U+mjqQPCor64OG00=
Received: by 10.14.35.80 with SMTP id t56mr6342769eea.1.1324668288522; Fri, 23 Dec 2011 11:24:48 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id 13sm52203165eeu.1.2011.12.23.11.24.45 (version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 11:24:47 -0800 (PST)
Message-ID: <4EF4D576.7000602@gmail.com>
Date: Sat, 24 Dec 2011 08:24:38 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Townsley 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 19:24:53 -0000

On 2011-12-24 02:55, Mark Townsley wrote:
>    DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
>            its WAN interface then the IPv6 CE Router SHOULD disable the
>            DS-Lite B4 element.
> This requirement is saying that if the ISP has Dual-Stack configured alongside Dual-Stack Lite, that the CE SHOULD override this and disable Dual-Stack Lite entirely.
> Is that what we *really* want for Christmas?

I would have thought so, yes. Native is surely always better than a tunnel,
for any version of IP. I'd be happy to get a dual stack ISP service for Christmas.

   Brian

From mark@townsley.net  Fri Dec 23 11:52:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4787021F8AD9 for ; Fri, 23 Dec 2011 11:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vPBHVyhx5wcv for ; Fri, 23 Dec 2011 11:52:42 -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 41D3421F8AB8 for ; Fri, 23 Dec 2011 11:52:41 -0800 (PST)
Received: by werb14 with SMTP id b14so4878636wer.31 for ; Fri, 23 Dec 2011 11:52:41 -0800 (PST)
Received: by 10.216.137.28 with SMTP id x28mr8917691wei.0.1324669961158; Fri, 23 Dec 2011 11:52:41 -0800 (PST)
Received: from [10.39.231.18] ([92.90.20.11]) by mx.google.com with ESMTPS id en20sm34276267wid.10.2011.12.23.11.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Dec 2011 11:52:40 -0800 (PST)
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>  <4EF4D576.7000602@gmail.com>
In-Reply-To: <4EF4D576.7000602@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPhone Mail (9A405)
From: Mark Townsley 
Date: Fri, 23 Dec 2011 20:52:36 +0100
To: Brian E Carpenter 
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 19:52:48 -0000

On Dec 23, 2011, at 8:24 PM, Brian E Carpenter =
 wrote:

> On 2011-12-24 02:55, Mark Townsley wrote:
>>   DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
>>           its WAN interface then the IPv6 CE Router SHOULD disable the
>>           DS-Lite B4 element.
>> This requirement is saying that if the ISP has Dual-Stack configured alon=
gside Dual-Stack Lite, that the CE SHOULD override this and disable Dual-Sta=
ck Lite entirely.
>> Is that what we *really* want for Christmas?
>=20
> I would have thought so, yes. Native is surely always better than a tunnel=
,
> for any version of IP. I'd be happy to get a dual stack ISP service for Ch=
ristmas.

There are two points here though. One, whether the default behavior should b=
e to prefer v6 or v4 over v6 transport which you address in this reply.=20

The other equally if not more important is whether the CE should automatical=
ly reject one type of config from the ISP when another is made available, an=
d the race conditions associated with trying to own than decision locally at=
 the CE - something very much not addressed in the document.=20

>=20
>   Brian

From marka@isc.org  Fri Dec 23 14:34:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6221F8B38 for ; Fri, 23 Dec 2011 14:34:23 -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.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 ldpKNefQNLRx for ; Fri, 23 Dec 2011 14:34:23 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5621B21F8B37 for ; Fri, 23 Dec 2011 14:34:23 -0800 (PST)
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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 45D525F9865; Fri, 23 Dec 2011 22:34:09 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:905c:7066:2fba:33ba]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 909D1216C6A; Fri, 23 Dec 2011 22:34:07 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 22D581AA6FBD; Sat, 24 Dec 2011 09:34:07 +1100 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>  <4EF4D576.7000602@gmail.com>
In-reply-to: Your message of "Sat, 24 Dec 2011 08:24:38 +1300." <4EF4D576.7000602@gmail.com>
Date: Sat, 24 Dec 2011 09:34:07 +1100
Message-Id: <20111223223407.22D581AA6FBD@drugs.dv.isc.org>
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Dec 2011 22:34:23 -0000

In message <4EF4D576.7000602@gmail.com>, Brian E Carpenter writes:
> On 2011-12-24 02:55, Mark Townsley wrote:
> >    DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
> >            its WAN interface then the IPv6 CE Router SHOULD disable the
> >            DS-Lite B4 element.
> > This requirement is saying that if the ISP has Dual-Stack configured alongs
> ide Dual-Stack Lite, that the CE SHOULD override this and disable Dual-Stack 
> Lite entirely.
> > Is that what we *really* want for Christmas?
> 
> I would have thought so, yes. Native is surely always better than a tunnel,
> for any version of IP. I'd be happy to get a dual stack ISP service for Chris
> tmas.

It's NAT44 or NAT44 + CGN vs local tunnel + CGN.  Disabling
DS-Lite is not a straight forward call.  If you have RFC 1918
on the outside then you know you are comparing NAT44 + CGN to
local tunnel + CGN.

local tunnel == internal to the ISP

All *other* things have to be equal for native to trump tunnel.

Mark

>    Brian
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From brian.e.carpenter@gmail.com  Fri Dec 23 16:01:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812B921F8B0D for ; Fri, 23 Dec 2011 16:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.514
X-Spam-Level: 
X-Spam-Status: No, score=-103.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 YB6W1ulgHA6g for ; Fri, 23 Dec 2011 16:01: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 04F9921F8B09 for ; Fri, 23 Dec 2011 16:01:27 -0800 (PST)
Received: by iaen33 with SMTP id n33so8236739iae.31 for ; Fri, 23 Dec 2011 16:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7fquqCFvloncOH6AA4IC8ou97mq+pW2+LDauCGo+408=; b=XIc0PNP8/o4VIMcNyffk0+eebxr+HmK4lg2yEPg/X+Z1HAP4taXyMjJ4ednFjkCBNI mEd40ToPdOtPhHZ/ts+y/6dc9LFj2T7d3263plFAx8o2cwb4XXJV9MtmVMxGIngxZXh1 pWeFsUvrb89HF/bQoabp4xI7iIzzKMRun2TIY=
Received: by 10.50.161.135 with SMTP id xs7mr10923037igb.15.1324684887604; Fri, 23 Dec 2011 16:01:27 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a2sm22460100igj.7.2011.12.23.16.01.23 (version=SSLv3 cipher=OTHER); Fri, 23 Dec 2011 16:01:26 -0800 (PST)
Message-ID: <4EF5164D.8060807@gmail.com>
Date: Sat, 24 Dec 2011 13:01:17 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Andrews 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>  <4EF4D576.7000602@gmail.com> <20111223223407.22D581AA6FBD@drugs.dv.isc.org>
In-Reply-To: <20111223223407.22D581AA6FBD@drugs.dv.isc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Dec 2011 00:01:28 -0000

On 2011-12-24 11:34, Mark Andrews wrote:
> In message <4EF4D576.7000602@gmail.com>, Brian E Carpenter writes:
>> On 2011-12-24 02:55, Mark Townsley wrote:
>>>    DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
>>>            its WAN interface then the IPv6 CE Router SHOULD disable the
>>>            DS-Lite B4 element.
>>> This requirement is saying that if the ISP has Dual-Stack configured alongs
>> ide Dual-Stack Lite, that the CE SHOULD override this and disable Dual-Stack 
>> Lite entirely.
>>> Is that what we *really* want for Christmas?
>> I would have thought so, yes. Native is surely always better than a tunnel,
>> for any version of IP. I'd be happy to get a dual stack ISP service for Chris
>> tmas.
> 
> It's NAT44 or NAT44 + CGN vs local tunnel + CGN.  Disabling
> DS-Lite is not a straight forward call.  If you have RFC 1918
> on the outside then you know you are comparing NAT44 + CGN to
> local tunnel + CGN.
> 
> local tunnel == internal to the ISP
> 
> All *other* things have to be equal for native to trump tunnel.

But why would an operator provide CGN (NAT444) and DS-Lite service
simultaneously to the same customer?

In any case it seems like this should be a configurable choice;
the SHOULD in the draft is the default for that choice.

    Brian

From marka@isc.org  Fri Dec 23 18:26:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785DD11E8083 for ; Fri, 23 Dec 2011 18:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 25vhqTcNT54Q for ; Fri, 23 Dec 2011 18:26:10 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46411E8080 for ; Fri, 23 Dec 2011 18:26:10 -0800 (PST)
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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 94FEF5F9887; Sat, 24 Dec 2011 02:25:49 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B2D15216C6A; Sat, 24 Dec 2011 02:25:47 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 27C221AA7C2A; Sat, 24 Dec 2011 13:25:12 +1100 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>  <4EF4D576.7000602@gmail.com> <20111223223407.22D581AA6FBD@drugs.dv.isc.org> <4EF5164D.8060807@gmail.com>
In-reply-to: Your message of "Sat, 24 Dec 2011 13:01:17 +1300." <4EF5164D.8060807@gmail.com>
Date: Sat, 24 Dec 2011 13:25:09 +1100
Message-Id: <20111224022513.27C221AA7C2A@drugs.dv.isc.org>
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Dec 2011 02:26:11 -0000

In message <4EF5164D.8060807@gmail.com>, Brian E Carpenter writes:
> On 2011-12-24 11:34, Mark Andrews wrote:
> > In message <4EF4D576.7000602@gmail.com>, Brian E Carpenter writes:
> >> On 2011-12-24 02:55, Mark Townsley wrote:
> >>>    DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
> >>>            its WAN interface then the IPv6 CE Router SHOULD disable the
> >>>            DS-Lite B4 element.
> >>> This requirement is saying that if the ISP has Dual-Stack configured alon
> gs
> >> ide Dual-Stack Lite, that the CE SHOULD override this and disable Dual-Sta
> ck 
> >> Lite entirely.
> >>> Is that what we *really* want for Christmas?
> >> I would have thought so, yes. Native is surely always better than a tunnel
> ,
> >> for any version of IP. I'd be happy to get a dual stack ISP service for Ch
> ris
> >> tmas.
> > 
> > It's NAT44 or NAT44 + CGN vs local tunnel + CGN.  Disabling
> > DS-Lite is not a straight forward call.  If you have RFC 1918
> > on the outside then you know you are comparing NAT44 + CGN to
> > local tunnel + CGN.
> > 
> > local tunnel == internal to the ISP
> > 
> > All *other* things have to be equal for native to trump tunnel.
> 
> But why would an operator provide CGN (NAT444) and DS-Lite service
> simultaneously to the same customer?

Because they have a mix of IPv4 only and IPv6 customers that they
are trying to migrate to IPv6 only.  If the CPE does everything
over IPv6 the ISP can see when the native IPv4 traffic drops to
zero.

> In any case it seems like this should be a configurable choice;
> the SHOULD in the draft is the default for that choice.
> 
>     Brian
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From Tina.Tsou.Zouting@huawei.com  Fri Dec 23 21:40:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4D821F84B0 for ; Fri, 23 Dec 2011 21:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level: 
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 6Vf8LnPE2QOV for ; Fri, 23 Dec 2011 21:40:27 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A451721F84AE for ; Fri, 23 Dec 2011 21:40:26 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWP00D0X13C4I@szxga03-in.huawei.com> for v6ops@ietf.org; Sat, 24 Dec 2011 13:40:24 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWP008FS13767@szxga03-in.huawei.com> for v6ops@ietf.org; Sat, 24 Dec 2011 13:40:24 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFZ78302; Sat, 24 Dec 2011 13:40:23 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Dec 2011 13:40:08 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Sat, 24 Dec 2011 13:40:14 +0800
Date: Sat, 24 Dec 2011 05:40:13 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.212.246.178]
To: Mark Townsley 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_2N92nwDB7/wfqQ7217UpXQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Up-leveling Transition Coexistence
Thread-index: AQHMuoWtLIv9EMTPEUqfzMLkWVTTkJXde9CAgAHMi4CAAXwkA4ABlqwAgAM7azCAAGfQAIACd7OAgABtkgCAAaOOwA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    <5E60E449-D19C-4D02-8B77-3A45B77AE049@huawei.com> <1F7CDCE2-6DD8-44B0-AA3F-B3594FC3AAFA@townsley.net>    
Cc: "v6ops@ietf.org Operations" 
Subject: Re: [v6ops] Up-leveling Transition Coexistence
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Dec 2011 05:40:28 -0000

--Boundary_(ID_2N92nwDB7/wfqQ7217UpXQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT



From: Mark Townsley [mailto:mark@townsley.net]
Sent: Friday, December 23, 2011 4:36 AM
To: Tina TSOU
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence


On Dec 22, 2011, at 11:05 PM, Tina TSOU wrote:

[Tina] it seems like you are trying to explain how to survive the CPE forwarding when there're both DS-Lite and 4over6, or native IPv4 access.

Yes.


But our problem is the AFTR/TC discovery.

OK. By "discovery" you mean the tunnel endpoint address for sending traffic to an AFTR or TC? Isn't that simply part of a DHCPv6 option?

That's what I thought. If this is not in the scope of draft-townsley, that's fine. If it is in the scope of draft-townsley, I was curious about how forwarding-oriented can solve it.

Tina

- Mark

--Boundary_(ID_2N92nwDB7/wfqQ7217UpXQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable















 




 






From: Mark
 Townsley [mailto:mark@townsley.net] 

Sent: Friday, December 23, 2011 4:36 AM

To: Tina TSOU

Cc: v6ops@ietf.org Operations

Subject: Re: [v6ops] Up-leveling Transition Coexistence






 


 






On Dec 22, 2011, at 11:05 PM, Tina TSOU wrote:












 




[Tina] it seems like you are trying to explain h=
ow to survive the CPE forwarding when=
 there're both
 DS-Lite and 4over6, or native IPv4 access.














 






Yes.



















But our problem is the AFTR/TC discovery.=













 






OK. By "discovery" you mean the tunnel endpoint a=
ddress for sending traffic to an AFTR or TC? Isn't that simply part of a DH=
CPv6 option?






 


That’s what I thought. If this is not in the =
scope of draft-townsley, that’s fine. I=
f it
 is in the scope of draft-townsley, I was cur=
ious about how forwarding-oriented can solve it.


 


Tina


 






- Mark










--Boundary_(ID_2N92nwDB7/wfqQ7217UpXQ)--

From frnkblk@iname.com  Mon Dec 26 07:18:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC16621F8BA8 for ; Mon, 26 Dec 2011 07:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.915
X-Spam-Level: 
X-Spam-Status: No, score=0.915 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=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 2TZmhdVUIv-Q for ; Mon, 26 Dec 2011 07:18:48 -0800 (PST)
Received: from premieronline.net (smtp2-4.premieronline.net [96.31.0.29]) by ietfa.amsl.com (Postfix) with ESMTP id 572FF21F8BAE for ; Mon, 26 Dec 2011 07:18:48 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from BULKFAMLAPTOP (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 8370443-1729245 for multiple; Mon, 26 Dec 2011 09:18:46 -0600
From: "Frank Bulk" 
To: "'Mark Andrews'" , "Brian E Carpenter" 
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com>		<4EF4D576.7000602@gmail.com>	<20111223223407.22D581AA6FBD@drugs.dv.isc.org>	<4EF5164D.8060807@gmail.com> <20111224022513.27C221AA7C2A@drugs.dv.isc.org>
In-Reply-To: <20111224022513.27C221AA7C2A@drugs.dv.isc.org>
Date: Mon, 26 Dec 2011 09:18:43 -0600
Message-ID: <006901ccc3e1$a8205190$f860f4b0$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AczB43GDFkNfdRUASoyIZzflHGrx1AB/iVRA
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 1021, in=2810, out=0, spam=0 ip=199.120.69.4
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Dec 2011 15:18:49 -0000

All transition concerns, ones we've decided to punt to ter or another
document.

Frank

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Mark Andrews
Sent: Friday, December 23, 2011 8:25 PM
To: Brian E Carpenter
Cc: v6ops@ietf.org Operations
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis-05.txt


In message <4EF5164D.8060807@gmail.com>, Brian E Carpenter writes:
> On 2011-12-24 11:34, Mark Andrews wrote:
> > In message <4EF4D576.7000602@gmail.com>, Brian E Carpenter writes:
> >> On 2011-12-24 02:55, Mark Townsley wrote:
> >>>    DLW-3:  If the IPv6 CE Router is configured with an IPv4 address on
> >>>            its WAN interface then the IPv6 CE Router SHOULD disable
the
> >>>            DS-Lite B4 element.
> >>> This requirement is saying that if the ISP has Dual-Stack configured
alon
> gs
> >> ide Dual-Stack Lite, that the CE SHOULD override this and disable
Dual-Sta
> ck 
> >> Lite entirely.
> >>> Is that what we *really* want for Christmas?
> >> I would have thought so, yes. Native is surely always better than a
tunnel
> ,
> >> for any version of IP. I'd be happy to get a dual stack ISP service for
Ch
> ris
> >> tmas.
> > 
> > It's NAT44 or NAT44 + CGN vs local tunnel + CGN.  Disabling
> > DS-Lite is not a straight forward call.  If you have RFC 1918
> > on the outside then you know you are comparing NAT44 + CGN to
> > local tunnel + CGN.
> > 
> > local tunnel == internal to the ISP
> > 
> > All *other* things have to be equal for native to trump tunnel.
> 
> But why would an operator provide CGN (NAT444) and DS-Lite service
> simultaneously to the same customer?

Because they have a mix of IPv4 only and IPv6 customers that they
are trying to migrate to IPv6 only.  If the CPE does everything
over IPv6 the ISP can see when the native IPv4 traffic drops to
zero.

> In any case it seems like this should be a configurable choice;
> the SHOULD in the draft is the default for that choice.
> 
>     Brian
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



From C.Grundemann@cablelabs.com  Tue Dec 27 13:25:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A9B21F8A91 for ; Tue, 27 Dec 2011 13:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.551
X-Spam-Level: **
X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 kybCm9+Edn0t for ; Tue, 27 Dec 2011 13:25:45 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2021F8A57 for ; Tue, 27 Dec 2011 13:25:45 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pBRLPgRa001890; Tue, 27 Dec 2011 14:25:42 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 27 Dec 2011 14:25:42 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 27 Dec 2011 14:25:42 -0700
From: Chris Grundemann 
To: "George, Wes" , Fred Baker , v6ops v6ops WG 
Date: Tue, 27 Dec 2011 14:25:39 -0700
Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn
Thread-Index: AczE3hYrxNASJmabRUaOCTV/UHGuUg==
Message-ID: 
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB11D94DA3@PRVPEXVS04.corp.twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
Cc: Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" 
Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 21:25:46 -0000

Thanks for the feedback Wes,

I'm digging in to prepare a -01 so am reviewing all the comments to date=8A
Comments inline below.

Cheers,
~Chris


On 10/11/11 2:43 PM, "George, Wes"  wrote:

>I'm not sure why this draft is classified as experimental and not
>informational or even standards track formally updating RFC6264 and/or
>shirasaki-nat444.
>
>After reading this:
>http://www.ietf.org/old/2009/u/ietfchair/info-exp.html I'm still not sure
>why. Can someone involved in the discussion apply the clue brick?

I'll allow those more versed in the intricacies of IETF doc types step in
here as to the preferred classification - I do not believe that we are
married to experimental if another class is deemed more appropriate.

>In terms of the meat of the document, I think that the document needs to
>cover the case where ports are not allocated sequentially (such as in
>order to reduce the determinisim and make it harder for a rogue entity to
>guess the next port, or for privacy reasons). It may work basically the
>same way as when a subscriber exceeds their pre-allocated ports, but the
>draft should explicitly cover this.

I may be misunderstanding but I believe this is covered in Section 2, Step
2, which reads in part:

"Port allocation could be made sequentially (e.g. the first block goes to
address 1, the second block to address 2, etc.), staggered (e.g. address 1
receives ports n*(C+D), address 2 receives ports 1+n*(C+D), etc.), or
through some other deterministic algorithm left to CGN implementation.
Subscribers could be restricted to ports from a single IPv4 address, or
could be allocated ports across all addresses in a pool, for example."

>Also, it would be good to discuss failover cases - how much (if any)
>state has to be maintained between CGNs in order to ensure adequate
>logging information is available during common failover cases (failure
>within the CGN instance, failure between two standalone CGN instances,
>etc). I'm not suggesting discussion of how to make a CGN fail over, I'm
>only talking about the considerations unique to this implementation.

I'm not opposed to adding a section covering failover but I believe that
it would be fairly simple.

Since the reservations are deterministic, knowing the outside IP should
lead you to the proper CGN instance (whether in failure mode or not) and
having the IP and port will allow the reverse mapping on that instance
(again, does not matter if the instance is the primary or secondary).

This holds true if the instances are active/passive and a primary failure
causes sessions to break and re-connect over the secondary, or in an
active/active cluster arrangement where the outside IP pool is shared
between multiple active CGN instances.

Perhaps I'm missing something though, and this is more complicated than I
propose.

>Lastly - the draft should recommend (possibly even a MUST) that
>implementers should provide a means to reverse the mapping algorithm. One
>of the challenges for any mapping algorithm is that one must understand
>it well enough to reverse it, and either do manual calculations to
>determine the mapping, or write a tool to do it. The path chosen largely
>depends on the frequency of the requests for that type of information. It
>makes far more sense for the implementer to make their mapping available
>in both directions so that there is no guesswork on the part of the
>operator as to whether they are reverse-engineering the mapping properly
>to arrive at the correct result.

I will talk about this with the other authors, however, I tend to agree
that this should at least be suggested, if not required.

>Thanks,

Thank you!

>Wes George
>
>
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> Of Fred Baker
>> Sent: Tuesday, October 11, 2011 9:52 AM
>> To: v6ops v6ops WG
>> Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org
>> Subject: [v6ops] Please review draft-donley-behave-deterministic-cgn
>>
>> Operators subject to law enforcement subpoenas and using Carrier Grade
>> NAT are having difficulties with the syslog rate for per-connection
>> logging. Chris Donley has proposed a simplification; the provider
>> allocates a deterministic set of source ports to his subscribers, and
>> only needs to log exceptions. Research in the area suggests that usage
>> of source ports is pareto distributed; a typical user has a requirement
>> on the order of 4 port numbers in simultaneous use (median), but port
>> scans and other large volume uses drive the average quite a bit higher.
>>
>> They haven't asked for it, but I suspect the behave chairs would
>> appreciate operational commentary on the draft.
>>
>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn
>>   "Deterministic Address Mapping to Reduce Logging in Carrier Grade
>> NATs",
>>   Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan,
>>   26-Sep-11
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.


From joelja@bogus.com  Sat Dec 31 20:28:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6B21F84BD for ; Sat, 31 Dec 2011 20:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.776
X-Spam-Level: 
X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_05=-1.11, 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 IYLo5+B-+DuC for ; Sat, 31 Dec 2011 20:28:31 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD921F8477 for ; Sat, 31 Dec 2011 20:28:31 -0800 (PST)
Received: from Joels-MacBook-Pro.local (c-76-115-174-157.hsd1.wa.comcast.net [76.115.174.157]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q014STxV033629 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 1 Jan 2012 04:28:29 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EFFE0E8.5060509@bogus.com>
Date: Sat, 31 Dec 2011 20:28:24 -0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IPv6 Ops WG 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 01 Jan 2012 04:28:29 +0000 (UTC)
Subject: [v6ops] Milestones between now and IETF 83 Paris.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 01 Jan 2012 04:28:31 -0000

As we are approaching the New Year and the halfway point between the
previous meeting and the next one, I thought it germain to enumerate the
milestones. The following are the relevant document submission and
scheduling milestones for IETF 83.

2012- 02-13 (Monday): Cutoff date for BOF proposal requests to Area
Directors at 17:00 PT (UTC -8). To request a BOF, please see
instructions on Requesting a BOF.

2012-02-23 (Thursday): Preliminary agenda published for comment.

2012-02-27 (Monday): Working Group Chair approval for initial document
(Version -00) submissions appreciated by 17:00 PT (UTC -8).

2012-03-02 (Friday): Final agenda to be published.

2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00)
submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool.

2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT
(UTC -7), upload using IETF ID Submission Tool.

2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC
-7), upload using IETF Meeting Materials Management Tool.

2012-03-25 - 2012-03-30: 83rd IETF Meeting in Paris, France.

From joelja@bogus.com  Sat Dec 31 20:34:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7390621F84C9 for ; Sat, 31 Dec 2011 20:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.998
X-Spam-Level: 
X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Q30QsKs4sHow for ; Sat, 31 Dec 2011 20:34:03 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1E121F84B2 for ; Sat, 31 Dec 2011 20:34:02 -0800 (PST)
Received: from Joels-MacBook-Pro.local (c-76-115-174-157.hsd1.wa.comcast.net [76.115.174.157]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q014Y1LI033735 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 1 Jan 2012 04:34:02 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EFFE234.8010004@bogus.com>
Date: Sat, 31 Dec 2011 20:33:56 -0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: IPv6 Ops WG 
References: <20120101043215.2246D21F8442@ietfa.amsl.com>
In-Reply-To: <20120101043215.2246D21F8442@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120101043215.2246D21F8442@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 01 Jan 2012 04:34:02 +0000 (UTC)
Subject: [v6ops] FYI: v6ops - New Meeting Session Request for IETF 83
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 01 Jan 2012 04:34:03 -0000

If anyone has additions to or issues with the conflict list let us know.

-------- Original Message --------
Subject: v6ops - New Meeting Session Request for IETF 83
Date: Sat, 31 Dec 2011 20:32:15 -0800 (PST)
From: IETF Meeting Session Request Tool

To: session-request@ietf.org
CC: dromasca@avaya.com, rbonica@juniper.net, joelja@bogus.com,
fred.baker@cisco.com

A new meeting session request has just been submitted
by Joel Jaeggli, a working group chair of v6ops.

---------------------------------------------------------
Working Group Name: v6ops
Area Name: Operations and Management Area
Session Requester: Joel Jaeggli

Number of Sessions: 2
Length of Session(s):  2.5 hours
                       2 hours

Number of Attendees: 300
Conflicts to Avoid:
  First Priority:  6man opsawg behave softwire homenet
  Second Priority:  6lowpan 6renum
  Third Priority:  opsarea

Special Requests:

---------------------------------------------------------



3DEco