From owner-v6ops@ops.ietf.org Tue Jul 1 02:42:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527E93A6A16 for ; Tue, 1 Jul 2008 02:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w1oNMqRcNF8 for ; Tue, 1 Jul 2008 02:42:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44AE73A69FC for ; Tue, 1 Jul 2008 02:42:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDcI3-0003A4-3J for v6ops-data@psg.com; Tue, 01 Jul 2008 09:36:47 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDcHx-00039C-7e for v6ops@ops.ietf.org; Tue, 01 Jul 2008 09:36:44 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 8B152EE5; Tue, 1 Jul 2008 11:36:39 +0200 (CEST) To: Wes Beebee (wbeebee) Subject: Re: new draft on IPv6 CPE router available for review MIME-Version: 1.0 Date: Tue, 1 Jul 2008 11:36:39 +0200 From: Remi Denis-Courmont Cc: v6ops@ops.ietf.org, Hemant Singh (shemant) Organization: Remlab.net In-Reply-To: References: Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 30 Jun 2008 13:14:22 -0400, "Wes Beebee (wbeebee)" wrote: > Please review this draft. > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.txt Section 6.1 seems to be a reinvention of RFC4605. I am also confused as to how multicast should be forwarded (or not) between the multiple LAN interfaces, if there are more than one. Also, IMHO, the document lacks (adequate) guidance on the chaining of CPEs. This is a real life problem, which in IPv4 is typically "solved" through layering of NATs. It might not be wise to ignore the issue in IPv6. I guess one solution is to have the CPE revert to bridging (but loops may occur), while another solution is to _mandate_ support for prefix sub-delegation. -- RĂ©mi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Tue Jul 1 03:31:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1AF3A696A for ; Tue, 1 Jul 2008 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue8uFqCzq2KX for ; Tue, 1 Jul 2008 03:31:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6129C3A682B for ; Tue, 1 Jul 2008 03:31:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDd60-000BNG-0F for v6ops-data@psg.com; Tue, 01 Jul 2008 10:28:24 +0000 Received: from [74.125.44.28] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDd5s-000BM0-My for v6ops@ops.ietf.org; Tue, 01 Jul 2008 10:28:21 +0000 Received: by yx-out-2324.google.com with SMTP id 8so431292yxb.71 for ; Tue, 01 Jul 2008 03:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=htgytMo9vP+6rBXof2ffMq5VAb8KIHF6L5ZLu6Hc7XY=; b=g8H1YwYawJR+6dOggS9qpufKoMOZXWgdTg6mNWWJ2t7iFgX/CaqIHf6lHbr7GiaPjS JES8eW+V4Xahqq0ohXkPlfjAcWyNWpkTzkQKk651kVQYNpReZ+D7nxuNbBfyQUYVfKhX I6zqv6TB3ir6nEwUPMf9/A8ltZwV3bRy706P4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=oWDCRyRhudni56Hv/sVGYYxEq0BwxCzWBwVZDWPYtNJdCWFjGLkg8dHWC6au758DwA FOitErXdChHY7xntFQRExdStTqqBTSAHlCqiK2rl+TLw1DJmJfxdTe4Ho2WRQ6KcfHWH Zc36rOJWuM/WktDCLHK/t6WD8Q8+wYMBcvdyI= Received: by 10.150.52.2 with SMTP id z2mr10306994ybz.49.1214908093724; Tue, 01 Jul 2008 03:28:13 -0700 (PDT) Received: by 10.151.12.7 with HTTP; Tue, 1 Jul 2008 03:28:13 -0700 (PDT) Message-ID: <2bbba3c10807010328y7ab73b5gbac5110b12dde2ed@mail.gmail.com> Date: Tue, 1 Jul 2008 12:28:13 +0200 From: "Ole Troan" To: "Mikael Abrahamsson" Subject: Re: new draft on IPv6 CPE router available for review Cc: "Shin Miyakawa" , wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080701.164616.226776039.miyakawa@nttv6.jp> <20080701.170327.104054108.miyakawa@nttv6.jp> X-Google-Sender-Auth: 1cd8ca45f8538c89 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> Even in this case, some software which is going to send a packet to the >> network >> from CPE, according to RFC3484 "Default Address Selection for IPv6", >> there is a certain reason why the WAN I/F's IP address should be used as >> its source address like follows. >> ---------------- from RFC3484 ---------------- >> It is RECOMMENDED that the candidate source addresses be the set of >> unicast addresses assigned to the interface that will be used to send >> to the destination. (The "outgoing" interface.) On routers, the >> candidate set MAY include unicast addresses assigned to any interface >> that forwards packets, subject to the restrictions described below. > > What is the reason for this recommendation? increased chance of path symmetry for one. check the ipng thread from 1999 "simple source address selection". e.g Message-Id: if an implementation handles unnumbered links (links without global addresses) or loopback interfaces then it has to implement the semi-strong or weak host model. are there router implementation which implements the strong host model? /ot From owner-v6ops@ops.ietf.org Tue Jul 1 04:39:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9D33A6B87 for ; Tue, 1 Jul 2008 04:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU-hju6JAan6 for ; Tue, 1 Jul 2008 04:39:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86ACA3A6866 for ; Tue, 1 Jul 2008 04:39:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDe8e-000Ou9-Mg for v6ops-data@psg.com; Tue, 01 Jul 2008 11:35:12 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDe8a-000Oop-8b for v6ops@ops.ietf.org; Tue, 01 Jul 2008 11:35:10 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m61BYevM001119; Tue, 1 Jul 2008 14:35:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 14:34:42 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 14:34:40 +0300 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_01C8DB6E.7340E457" Subject: RE: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 14:34:39 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjazbZEhWq/8Xu9TdqYgT/vjauSsQABugCgACXE9xA= References: From: To: , Cc: X-OriginalArrivalTime: 01 Jul 2008 11:34:40.0411 (UTC) FILETIME=[731B3EB0:01C8DB6E] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DB6E.7340E457 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Are you interested also to specifically cover similarly acting cellular phones in this document? If so, I might be able to contribute text on those aspects if needed. =20 In 3GPP there is discussion ongoing for supporting DHCPv6 PD for cellulars. I.e. the phone would get IPv6 address statelessly from the cellular network for its WAN interface, and with DHCPv6 PD it would get prefixes to be used in local WLAN/Bluetooth PAN/USB/LAN/whatever network. The same discussion will surely happen in WiMAX Forum and 3GPP2 if it already hasn't. It would be good if IETF would have a document to offer for those organizations. =20 The cellular case would likely be pretty similar to home deployment (well, mobile home), and the initial configuration would be provided by the service provider. The user of the cellular of course should not be required to do any configuration changes whatsoever, although there could be feature specific UI or web interface (accessible from local network) available. Service provider would most likely not do any active configuration, but of course could push updated settings if required (thus in cellular case there most likely would/should not be need for routing protocols/MIBs). =20 Best regards, =20 Teemu ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext Wes Beebee (wbeebee) Sent: 30 June, 2008 20:14 To: v6ops@ops.ietf.org Cc: Hemant Singh (shemant) Subject: new draft on IPv6 CPE router available for review =09 =09 v6ops folks, =20 Please review this draft. =20 =09 http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.txt =20 The Abstract of the draft is snipped below. =20 Abstract =09 This document recommends IPv6 behavior for Customer Premises Equipment (CPE) routers in Internet-enabled homes and small offices. =09 =20 Thanks. =20 Hemant & Wes. ------_=_NextPart_001_01C8DB6E.7340E457 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Are you interested also to specifically = cover=20 similarly acting cellular phones in this document? If so, I might be = able to=20 contribute text on those aspects if needed.
 
In 3GPP there is discussion ongoing for = supporting DHCPv6=20 PD for cellulars. I.e. the phone would get IPv6 address statelessly from = the=20 cellular network for its WAN interface, and with DHCPv6 PD it would get = prefixes=20 to be used in local WLAN/Bluetooth PAN/USB/LAN/whatever network. = The same=20 discussion will surely happen in WiMAX Forum and 3GPP2 if it already = hasn't. It=20 would be good if IETF would have a document to offer for those=20 organizations.
 
The cellular case would likely be pretty = similar to home=20 deployment (well, mobile home), and the initial configuration would be = provided=20 by the service provider. The user of the cellular of course should = not be=20 required to do any configuration changes whatsoever, although there = could be=20 feature specific UI or web interface (accessible from local network) = available.=20 Service provider would most likely not do any active configuration, but = of=20 course could push updated settings if required (thus in cellular = case there=20 most likely would/should not be need for routing=20 protocols/MIBs).
 
Best regards,
 
Teemu

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext Wes Beebee=20 (wbeebee)
Sent: 30 June, 2008 20:14
To:=20 v6ops@ops.ietf.org
Cc: Hemant Singh = (shemant)
Subject: new=20 draft on IPv6 CPE router available for review

v6ops folks,
 
Please review this = draft.
 
http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route= r-00.txt
 
The Abstract of the draft is snipped=20 below.
 
Abstract

   This document = recommends=20 IPv6 behavior for Customer Premises
   Equipment (CPE) = routers in=20 Internet-enabled homes and small offices.
 
Thanks.
 
Hemant &=20 Wes.
------_=_NextPart_001_01C8DB6E.7340E457-- From owner-v6ops@ops.ietf.org Tue Jul 1 06:41:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E74C3A6993 for ; Tue, 1 Jul 2008 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjn7WkS2l+8v for ; Tue, 1 Jul 2008 06:41:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8393F3A689B for ; Tue, 1 Jul 2008 06:41:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDg0x-000Jfa-S9 for v6ops-data@psg.com; Tue, 01 Jul 2008 13:35:23 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDg0u-000Jf2-0H for v6ops@ops.ietf.org; Tue, 01 Jul 2008 13:35:21 +0000 Received: (qmail 5346 invoked by uid 509); 1 Jul 2008 13:35:18 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.1/7597. spamassassin: 3.2.4. Clear:RC:1(211.28.128.246):. Processed in 0.043034 secs); 01 Jul 2008 13:35:18 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Tue, 01 Jul 2008 08:35:17 -0500 Cc: IETF V6OPS WG , yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com Message-Id: From: David Miles To: Mikael Abrahamsson , Shin Miyakawa , wbeebee@cisco.com, shemant@cisco.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 23:35:12 +1000 References: <20080701.102044.59751592.miyakawa@nttv6.jp> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Wes, Hemant and Shin, I would add my support to Mikael's request that the draft has the option of having a global unicast WAN address OR having link-local only WAN on a routing CPE. Would it be okay to incorporate the content of Shin's draft into the CPE discussion/draft? Ole raised the issue that a router would (almost by definition) need to implement a weak or semi-strong model, and I would support this view. I do believe the CPE must support the sending of IP datagrams to Internet hosts (for ICMPv6, management, etc) but see an option of using a loopback interface for this purpose (from the subscriber's delegated prefix). This allows a single subscriber to be represented by one prefix that may be operationally beneficial, or provide a more scalable BNG architecture. By supporting both options we can allow operators to deploy a model that makes the most sense for them. Best Regards, -David Miles On 01/07/2008, at 4:53 PM, Mikael Abrahamsson wrote: > On Tue, 1 Jul 2008, Shin Miyakawa wrote: > >> to terminate the IPv6 uplink by itself, so from practical point of >> view, we strongly recommend to assign a global IPv6 address. > > Well, my personal opinion is that this makes Vista unfit to be a > IPv6 CPE. We cannot adjust IPv6 address policy just because of > certain design decisions on behalf of Microsoft. > > It is my belief that customers (at least in the market I am in) will > need to have a small CPE that is not an end host, and this is what > the draft should be aimed at. Advocating PPP is also a very bad idea > as this cements the use of LAC/LNS and tunneling, which is a really > bad idea for future multicast use, as well as being more expensive > than necessary. > > My idea of a good IPv6 service is one that is purely IPv6 over > ethernet, optionally with 1-2 q tags or mac-in-mac in the ISP part > of the network, but definitely not involving PPP or L2TP anywhere in > the path. > > At least, how can we make the draft comply so that what I would like > to do doesn't violate any draft? I can understand if both options > are in there, but making my proposal a draft violation seems like a > bad idea, as we both seem to agree that it's the proper thing to do? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From owner-v6ops@ops.ietf.org Tue Jul 1 06:57:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D22C3A6819 for ; Tue, 1 Jul 2008 06:57:41 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UtjhcW5uAUW for ; Tue, 1 Jul 2008 06:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5420A3A6778 for ; Tue, 1 Jul 2008 06:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDgKZ-000NV6-Tq for v6ops-data@psg.com; Tue, 01 Jul 2008 13:55:39 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDgKF-000NSN-7T for v6ops@ops.ietf.org; Tue, 01 Jul 2008 13:55:25 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 59C11ADADF; Tue, 1 Jul 2008 15:55:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4E310ADADD; Tue, 1 Jul 2008 15:55:18 +0200 (CEST) Date: Tue, 1 Jul 2008 15:55:18 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Shin Miyakawa , wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <2bbba3c10807010328y7ab73b5gbac5110b12dde2ed@mail.gmail.com> Message-ID: References: <20080701.164616.226776039.miyakawa@nttv6.jp> <20080701.170327.104054108.miyakawa@nttv6.jp> <2bbba3c10807010328y7ab73b5gbac5110b12dde2ed@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 1 Jul 2008, Ole Troan wrote: > if an implementation handles unnumbered links (links without global > addresses) or loopback interfaces then it has to implement the > semi-strong or weak host model. are there router implementation which > implements the strong host model? Most routers will use outgoing interface IP address for creating IP packets, unless it's been specified that this service should originate from another interface. To use cisco example: With the following configuration line: ip telnet source-interface Loopback0 all telnet session initiated from the router CLI will have source IP of "loopback 0" interface. If this line is not present, the router defaults to using the outgoing interface (routingwise) IP address as source IP for the telnet TCP session. It's standard industry practice to use loopback addresses for almost everything control plane in routers, as then the IGP will handle reroutes and established TCP sessions are not affected by interfaces going up or down. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 1 08:04:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C2D3A67F7 for ; Tue, 1 Jul 2008 08:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm4fPYN1k9Fe for ; Tue, 1 Jul 2008 08:04:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 731CE3A67F1 for ; Tue, 1 Jul 2008 08:04:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDhL2-000AD4-EW for v6ops-data@psg.com; Tue, 01 Jul 2008 15:00:12 +0000 Received: from [192.16.199.17] (helo=dwalin.nikhef.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDhKu-000AC6-27 for v6ops@ops.ietf.org; Tue, 01 Jul 2008 15:00:06 +0000 Received: from borg.c-l-i.net (borg.c-l-i.net [192.16.192.99]) by dwalin.nikhef.nl (8.13.7/8.13.4) with ESMTP id m61ExmvY027055; Tue, 1 Jul 2008 16:59:49 +0200 Received: from borg.c-l-i.net (borg.c-l-i.net [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.c-l-i.net (Postfix) with ESMTP id 9A7B01EAB47; Tue, 1 Jul 2008 16:59:48 +0200 (CEST) Received: (from shane@localhost) by borg.c-l-i.net (8.13.7/8.13.7/Submit) id m61Exk59005152; Tue, 1 Jul 2008 16:59:46 +0200 Date: Tue, 1 Jul 2008 16:59:46 +0200 From: Shane Kerr To: "Wes Beebee (wbeebee)" Cc: v6ops@ops.ietf.org, "Hemant Singh (shemant)" Subject: Re: new draft on IPv6 CPE router available for review Message-ID: <20080701145946.GA5112@borg.c-l-i.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Wes, On Mon, Jun 30, 2008 at 01:14:22PM -0400, Wes Beebee (wbeebee) wrote: > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.txt 5.5. Stateful DHCPv6 server requirements for the CPE Router The CPE Router may support a stateful DHCPv6 server to serve clients on the CPE Router LAN interface(s). If the CPE Router needs to support a stateful DHCPv6 server, then more details will be added to this section specifying the minimal functionality that the stateful DHCPv6 server needs to support. Perhaps you could ask the good folks in the DHC working group to comment on this section? I think the state of DHCPv6 technology is too immature to require it for a CPE router (although DOCSIS 2.0 requires it, so maybe not), but it does have a lot of potential benefits (such as chaining information found in a prefix delegation from the Service Provider to hosts on the inside). -- Shane From owner-v6ops@ops.ietf.org Tue Jul 1 10:54:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD193A69A8 for ; Tue, 1 Jul 2008 10:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.446 X-Spam-Level: X-Spam-Status: No, score=-4.446 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d08oiFy4lV7l for ; Tue, 1 Jul 2008 10:54:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88E1B3A67D6 for ; Tue, 1 Jul 2008 10:54:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDjwk-000F9u-Fl for v6ops-data@psg.com; Tue, 01 Jul 2008 17:47:18 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDjwK-000F7F-RF for v6ops@ops.ietf.org; Tue, 01 Jul 2008 17:47:04 +0000 X-IronPort-AV: E=Sophos;i="4.27,732,1204520400"; d="scan'208";a="12868125" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2008 13:46:51 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m61HkppD017385 for ; Tue, 1 Jul 2008 13:46:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m61HkpHu006974 for ; Tue, 1 Jul 2008 17:46:51 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 13:46:51 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: FW: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 13:47:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjbXgYnTmPrINHxRQ2u3dy5SwGv/QALJwgQAASu+3AAASId0A== From: "Wes Beebee (wbeebee)" To: X-OriginalArrivalTime: 01 Jul 2008 17:46:51.0328 (UTC) FILETIME=[715EC400:01C8DBA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2989; t=1214934411; x=1215798411; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20FW=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20; bh=ZmIT3d+srCpM/TsJCfVZaCevIUG0Z9UwgjbekFsz4tc=; b=l2qQ3IOiCO9foGOSZdq7PXNcm7bJuuRkirlyWZ9IcCyeQrswIZsH9EDPIw Zx5xxozHEXjhEQ32I7WR/m/B7RTTM7qz/A0Tks8kPYtrojrPXa3Iw6or/bgn 3NZU2BBMMG; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For some reason, Hemant is unable to post to v6ops even though he is = subscribed to it. Therefore, I'm forwarding this e-mail. - Wes=20 -----Original Message----- From: Hemant Singh (shemant) Sent: Tuesday, July 01, 2008 11:38 AM To: 'Remi Denis-Courmont'; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review Remi, We missed seeing RFC4605 - thanks for its reference. We can shorten = section 6.1 to be very brief showing how RFC4605 will work between the = WAN and LAN interface(s). Further, right now we don't have strong = language in the draft for prefix sub-delegation, but we can consider = making it so for prefix sub-delegation - our preference is prefix = sub-delegation.=20 As for mcast, the CPE router maintains a Mcast Forwarding Information = Base (MFIB) that maps mcast group memberships to output LAN = interface(s). When a mcast packet on the CPE router downstream needs = forwarding from WAN interface to a LAN interface, the MFIB is looked up = for packet forwarding. Details on how the MFIB is populated are given in = the mcast section. Maybe we can add a picture showing CPE router = conceptual blocks for mcast and also demonstrate mcast forwarding with = an example if more folks don't understand this section. We do have v6-to-v4 and v4-to-v6 NAT in mind even though we haven't = added it to the CPE router draft. We didn't write those sections yet = because some functionality spans the CPE router IPv4 features when our = draft currently says any IPv4 feature is out of scope for the document. = We have to massage some text in the document and then write a NAT = section. We don't plan on recommending any v6-to-v6 NAT for the CPE = router since IPv6 standards also do not recommend it. Thanks. Hemant & Wes -----Original Message----- From: Remi Denis-Courmont [mailto:rdenis@simphalempin.com] Sent: Tuesday, July 01, 2008 5:37 AM To: Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; Hemant Singh (shemant) Subject: Re: new draft on IPv6 CPE router available for review On Mon, 30 Jun 2008 13:14:22 -0400, "Wes Beebee (wbeebee)" wrote: > Please review this draft. > =20 > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.t > xt Section 6.1 seems to be a reinvention of RFC4605. I am also confused as = to how multicast should be forwarded (or not) between the multiple LAN interfaces, if there are more than one. Also, IMHO, the document lacks (adequate) guidance on the chaining of = CPEs. This is a real life problem, which in IPv4 is typically "solved" through layering of NATs. It might not be wise to ignore the issue in IPv6. I = guess one solution is to have the CPE revert to bridging (but loops may = occur), while another solution is to _mandate_ support for prefix = sub-delegation. --=20 R=E9mi Denis-Courmont http://www.remlab.net From owner-v6ops@ops.ietf.org Tue Jul 1 10:54:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5773A69A8 for ; Tue, 1 Jul 2008 10:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPzGvcTBUKvx for ; Tue, 1 Jul 2008 10:54:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8B8B3A6851 for ; Tue, 1 Jul 2008 10:54:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDk07-000Fz3-1t for v6ops-data@psg.com; Tue, 01 Jul 2008 17:50:47 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDjzs-000Fse-Qw for v6ops@ops.ietf.org; Tue, 01 Jul 2008 17:50:36 +0000 X-IronPort-AV: E=Sophos;i="4.27,732,1204520400"; d="scan'208";a="12861008" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2008 13:50:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m61HoVot019771 for ; Tue, 1 Jul 2008 13:50:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m61HoVYf008992 for ; Tue, 1 Jul 2008 17:50:31 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 13:50:31 -0400 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 Subject: FW: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 13:50:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjbGMzJDcr+8mROSEWj+SYsuig26wAeG68AAAML9IAAAVHugA== From: "Wes Beebee (wbeebee)" To: X-OriginalArrivalTime: 01 Jul 2008 17:50:31.0138 (UTC) FILETIME=[F4631C20:01C8DBA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4569; t=1214934631; x=1215798631; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20FW=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20; bh=rt/3J3heKieakrY2aGgoTJYWdswCA846U+zIMa9JoQQ=; b=r5vu+BdnMJrjtsu6+wg4Q/yHnWcy9A92MCWLVKcfs6tqnuiHI6tPQt8JVt t5qtvgrhdau1zJCRM7o5ZVsO8jXijUNrBrHmR8GGaYAN5QIS3qCevPRCGuy7 GSSsZ+t/lR; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For some reason, Hemant is unable to post to v6ops even though he is subscribed to it. Therefore, I'm forwarding this e-mail. - Wes=20 -----Original Message----- From: Hemant Singh (shemant) Sent: Tuesday, July 01, 2008 12:20 PM To: 'Shin Miyakawa'; Wes Beebee (wbeebee); swmike@swm.pp.se; v6ops@ops.ietf.org Cc: yasuhiro@nttv6.jp; Hemant Singh (shemant) Subject: RE: new draft on IPv6 CPE router available for review Shin, I don't see any reason to incorporate anything from your draft because our document already mentions what your draft proposes. Please read our draft completely before sending such comments. It is very clear from our draft that the WAN interface acquires a global IPv6 address and the CPE router gets IA_PD, the prefix from which is sub-delegated to hosts connected to LAN interface(s) of the CPE router. Anyhow, Cable Labs has already proposed the same global address on WAN port over one year back in cable broadband networks. For others who have asked for only a link-local address on the WAN port and asked for a Loopback interface on the CPE router, we have already replied that we agree with such a recommendation and we will recommend that the CPE router support both models - one model where WAN port also acquires a global IPv6 address and another model where WAN interface only acquires a link-local address. In the model where the WAN interface has only a link-local address, the CPE router will use an optional Loopback interface which will be assigned a global IPv6 address sub-delegated from IA_PD via stateless DHCPv6. Thanks. Hemant -----Original Message----- From: Shin Miyakawa [mailto:miyakawa@nttv6.jp] Sent: Monday, June 30, 2008 9:21 PM To: Wes Beebee (wbeebee); swmike@swm.pp.se; Hemant Singh (shemant); v6ops@ops.ietf.org Cc: miyakawa@nttv6.jp; yasuhiro@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review Hello, I have a comment on the transfered message by Wes, > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > > In section 5.3 I would definitely like a CPE to work without having a=20 > WAN address (link local only). Actually, this does not work if a CPE use the strong host model implementation describing in RFC1122 or STD3 : Requirements for Internet Hosts - Communication Layers. > The rationale behind this is that we would like ISP routers have IPs=20 > in a core IP-range (which will be protected from DDOS by ratelimiters=20 > or filters) and have customers in their own IP space. > The handoff between distribution and CPE should be done via something=20 > that is not reachable from the internet, ie the CPE should never=20 > source packets from its WAN IP, instead it should source packets=20 > destined to the internet from a loopback IP which it should allocate=20 > to itself from DHCPv6-PD (it could also be a LAN interface IP). > So behavior would be "get link-local working, do DHCPv6-PD, allocate=20 > IP to itself from PD range, then use THAT to provision itself further=20 > and to communicate with everything". Originally, when we wrote RFC4241 (A Model of IPv6/IPv4 Dual Stack Internet Access Service) to start our IPv6/v4 dual stack native ADSL service, we also thought about same thing. So we can understand Mikael's will too. But now Microsoft Vista and Windows 2008 IPv6 implementation are based on the strong host model as default, (please see http://technet.microsoft.com/en-us/library/bb878108.aspx and http://technet.microsoft.com/en-us/magazine/cc137807.aspx ). Especially, if we think that the uplink is a "softwire" or the CPE is a brige, Vista is one of the most likely to be used operating systems to terminate the IPv6 uplink by itself, so from practical point of view, we strongly recommend to assign a global IPv6 address. We've just submitted a very short draft regarding this issue http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt and hope this could be merged to the section 5.3 of Wes's draft with its reasons. Best regards, Shin Miyakawa, Ph.D Director, Core Network Technology Team, Network Systems and Technologies, Innovative IP Architecture Center / Corporate Planning Department (concurrent position) NTT Communications Corporation Tokyo Opera City Tower 21st Floor 3-20-2 Nishi-Shinjuku, Shinjuku-Ku, Tokyo, Japan 163-1421 E-mail:miyakawa@nttv6.jp / shin.miyakawa@ntt.com / miyakawa@wide.ad.jp TEL:+81-3-6800-3262 / FAX:+81-3-5365-2990 Visiting Researcher, SFC Lab. KEIO University WIDE Project From owner-v6ops@ops.ietf.org Tue Jul 1 12:15:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1928F3A6911 for ; Tue, 1 Jul 2008 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMfwYMbvzunq for ; Tue, 1 Jul 2008 12:15:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3343C3A6784 for ; Tue, 1 Jul 2008 12:15:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDlFd-0004kN-Jw for v6ops-data@psg.com; Tue, 01 Jul 2008 19:10:53 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDlFU-0004i6-JP for v6ops@ops.ietf.org; Tue, 01 Jul 2008 19:10:50 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 525D9BDC08; Wed, 2 Jul 2008 04:10:43 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 1C93C6E358; Wed, 2 Jul 2008 04:10:43 +0900 (JST) Date: Wed, 02 Jul 2008 04:10:42 +0900 (JST) Message-Id: <20080702.041042.35038040.miyakawa@nttv6.jp> To: davidm@thetiger.com Cc: swmike@swm.pp.se, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080701.102044.59751592.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, David :-) > I would add my support to Mikael's request that the draft has the > option of having a global unicast WAN address OR having link-local > only WAN on a routing CPE. Would it be okay to incorporate the content > of Shin's draft into the CPE discussion/draft? David, as we have discussed this several months off from this mailing list in various places on the Earth, you know the reason why I said. Then.... "OR" means sometime ambiguous....... Actually, my opinion is (A) the draft should have "discussions" text to explain why those are recommended and this draft should be more generalized not only for cable TV systems. For example, section 1 in this draft's clearly said that "WAN interface is Ethernet encapsulated", but it should be converted to "WAN interface may be Ethernet encapsulated but not limited too" or something like that because we need to think about other semantics like PPP. (B) Because a strong host model is one of possible implemenation of CPE, so "Global unicast WAN address" MUST be supported and ^^^^ "Link-Local only WAN on a routing CPE" MAY be supported as the "access concentrator"'s specification which provides the service to the IPv6 CPE. Best wishes, Shin Miyakawa P.S. However I also prefer Mikael's model personally, we have to be very realistic and tolerant to any implemenations compatible with the standard. From owner-v6ops@ops.ietf.org Tue Jul 1 12:52:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA59D3A6893 for ; Tue, 1 Jul 2008 12:52:16 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et4T-5Oi9rWP for ; Tue, 1 Jul 2008 12:52:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F13BA3A67A2 for ; Tue, 1 Jul 2008 12:52:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDlrB-000BX7-R3 for v6ops-data@psg.com; Tue, 01 Jul 2008 19:49:41 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDlr6-000BT9-E4 for v6ops@ops.ietf.org; Tue, 01 Jul 2008 19:49:39 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86BABADADD; Tue, 1 Jul 2008 21:49:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 76ADBADAD9; Tue, 1 Jul 2008 21:49:32 +0200 (CEST) Date: Tue, 1 Jul 2008 21:49:32 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" cc: Shin Miyakawa , "Wes Beebee (wbeebee)" , v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <20080701.102044.59751592.miyakawa@nttv6.jp> <20080702.041042.35038040.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 1 Jul 2008, Hemant Singh (shemant) wrote: > router supporting the link-local only WAN model. Of course, we totally > want the first model to be a MUST for the CPE router to support - in > this model the WAN interface acquires a global IPv6 address. What are the downsides of making both models a MUST? I think any router should (MUST) be able to source packets from any interface chosen, including one that is not the outgoing interface. This would of course have the implications that some primary host implementations with optional routing capability might not comply with this right now, but would put pressure on vendors to implement this properly. I know there's been discussions regarding traceroute behaviour as well, with the industry standard being that the ICMP TTL-EXCEEDED message being sourced from the router IP where it was received, but goes out any interface (as per the routing table to the destination). I just would like to get future IPv6 implementations for routers working properly from the start, as most residential CPE vendors seem to not have implemented IPv6 support yet, I would like them to do both models as the model I'm advocating would have long term benefits for network stability. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 1 12:54:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54E63A6BA1 for ; Tue, 1 Jul 2008 12:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.525 X-Spam-Level: X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y163cT0IA1Tu for ; Tue, 1 Jul 2008 12:54:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDE803A67A2 for ; Tue, 1 Jul 2008 12:54:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDluz-000CBE-EJ for v6ops-data@psg.com; Tue, 01 Jul 2008 19:53:37 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDluu-000CAb-9t for v6ops@ops.ietf.org; Tue, 01 Jul 2008 19:53:34 +0000 X-IronPort-AV: E=Sophos;i="4.27,732,1204520400"; d="scan'208";a="12880163" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2008 15:53:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m61JrVhv004687 for ; Tue, 1 Jul 2008 15:53:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m61JrV3a018158 for ; Tue, 1 Jul 2008 19:53:31 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 15:53:31 -0400 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 Subject: FW: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 15:53:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjbrlYSXL7HorPBSQmvJRnSRu1GjwAAHlvgAAEygaAAABsNIA== From: "Wes Beebee (wbeebee)" To: X-OriginalArrivalTime: 01 Jul 2008 19:53:31.0178 (UTC) FILETIME=[233BD8A0:01C8DBB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2784; t=1214942011; x=1215806011; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20FW=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20; bh=b9wR/xtKrR/RNFvRF8T6kHSQGqHFRJCC5LDdlbReUZk=; b=Uy2hEzIzrOnZ6EctwTFAmMGzkvWEizgzQxSV7SjyR94iP4HILZ1VeEU1NF 2VptGO6jkEny/1BC8DPzpbp9dZLSmjqHf0rz91eOz6Vz+AktoWtEUEf8bn3u 5xne9i/W2V; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Forwarding for Hemant to continue the discussion... - Wes -----Original Message----- From: Hemant Singh (shemant) Sent: Tuesday, July 01, 2008 3:20 PM To: 'Shin Miyakawa'; davidm@thetiger.com Cc: swmike@swm.pp.se; Wes Beebee (wbeebee); v6ops@ops.ietf.org; yasuhiro@nttv6.jp; sven.ooghe@alcatel-lucent.com; Hemant Singh (shemant) Subject: RE: new draft on IPv6 CPE router available for review Shin, Thanks for your comments. We agree with (A) below. As for (B), we leave it to the mailer to decide if it's a MUST for the CPE router to support the link-local only WAN model or the MUST can be a MAY. As we said to Mikael's review yesterday, we see no technical problems with the CPE router supporting the link-local only WAN model. Of course, we totally want the first model to be a MUST for the CPE router to support - in this model the WAN interface acquires a global IPv6 address. Hemant & Wes. -----Original Message----- From: Shin Miyakawa [mailto:miyakawa@nttv6.jp] Sent: Tuesday, July 01, 2008 3:11 PM To: davidm@thetiger.com Cc: swmike@swm.pp.se; Wes Beebee (wbeebee); Hemant Singh (shemant); v6ops@ops.ietf.org; yasuhiro@nttv6.jp; sven.ooghe@alcatel-lucent.com; miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review Hello, David :-) > I would add my support to Mikael's request that the draft has the=20 > option of having a global unicast WAN address OR having link-local=20 > only WAN on a routing CPE. Would it be okay to incorporate the content > of Shin's draft into the CPE discussion/draft? David, as we have discussed this several months off from this mailing list in various places on the Earth, you know the reason why I said. Then.... "OR" means sometime ambiguous....... Actually, my opinion is (A) the draft should have "discussions" text to explain why those are recommended and this draft should be more generalized not only for cable TV systems. For example, section 1 in this draft's clearly said that "WAN interface is Ethernet encapsulated", but it should be converted to "WAN interface may be Ethernet encapsulated but not limited too"=20 or something like that because we need to think about other semantics like PPP. (B) Because a strong host model is one of possible implemenation of CPE, so "Global unicast WAN address" MUST be supported and ^^^^ "Link-Local only WAN on a routing CPE" MAY be supported as the "access concentrator"'s specification which provides the service to the IPv6 CPE. Best wishes, Shin Miyakawa P.S. However I also prefer Mikael's model personally, we have to be very realistic and tolerant to any implemenations compatible with the standard. From owner-v6ops@ops.ietf.org Tue Jul 1 13:01:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078553A6BCF for ; Tue, 1 Jul 2008 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yskyJ7WhKZEa for ; Tue, 1 Jul 2008 13:01:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03A403A6BC6 for ; Tue, 1 Jul 2008 13:01:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDm0u-000DCq-8F for v6ops-data@psg.com; Tue, 01 Jul 2008 19:59:44 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDm0g-000DB2-Ig for v6ops@ops.ietf.org; Tue, 01 Jul 2008 19:59:41 +0000 X-IronPort-AV: E=Sophos;i="4.27,732,1204520400"; d="scan'208";a="12880679" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2008 15:59:29 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m61JxTkN024532; Tue, 1 Jul 2008 15:59:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m61JxT7m018939; Tue, 1 Jul 2008 19:59:29 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 15:59:29 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 15:59:42 -0400 Message-ID: In-Reply-To: <20080701145946.GA5112@borg.c-l-i.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: Acjbizz+j6SyIC1MSNOtCBBdJ+4t0gAKTyDw From: "Wes Beebee (wbeebee)" To: "Shane Kerr" Cc: , "Hemant Singh (shemant)" X-OriginalArrivalTime: 01 Jul 2008 19:59:29.0278 (UTC) FILETIME=[F8AD91E0:01C8DBB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1564; t=1214942369; x=1215806369; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=22Shane=20Kerr=22=20; bh=u1NfbZtUA/B7enq0rQvXoteYbPLeHpflh88l189Bgbw=; b=MVljEjOBRE8NxMCcXCw5s2V3EvFKQADzdGpeO1RCCXsDc+2DIPKwVCZoUo ki9OS16DbIfXZr+MBMu31jtJgTDqA5FIpwUnL6fIOwnJqDPevilYtHW6BYmN EDFX5wZ4ID; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We can change the title from "Stateful DHCPv6 server requirements for the CPE Router" to "Stateful DHCPv6 server". In the section, please note that we say it "may support" a stateful DHCPv6 server. We agree that we cannot force a CPE router to support a stateful DHCPv6 server, although there are many benefits if it does. - Wes -----Original Message----- From: Shane Kerr [mailto:shane@time-travellers.org]=20 Sent: Tuesday, July 01, 2008 11:00 AM To: Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; Hemant Singh (shemant) Subject: Re: new draft on IPv6 CPE router available for review Wes, On Mon, Jun 30, 2008 at 01:14:22PM -0400, Wes Beebee (wbeebee) wrote: > =20 > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.t > xt 5.5. Stateful DHCPv6 server requirements for the CPE Router The CPE Router may support a stateful DHCPv6 server to serve clients on the CPE Router LAN interface(s). If the CPE Router needs to support a stateful DHCPv6 server, then more details will be added to this section specifying the minimal functionality that the stateful DHCPv6 server needs to support. Perhaps you could ask the good folks in the DHC working group to comment on this section? I think the state of DHCPv6 technology is too immature to require it for a CPE router (although DOCSIS 2.0 requires it, so maybe not), but it does have a lot of potential benefits (such as chaining information found in a prefix delegation from the Service Provider to hosts on the inside). -- Shane From owner-v6ops@ops.ietf.org Tue Jul 1 13:29:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97B83A6BCD for ; Tue, 1 Jul 2008 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJVtdyMex6CR for ; Tue, 1 Jul 2008 13:29:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E4663A6BAD for ; Tue, 1 Jul 2008 13:29:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDmPW-000HpQ-St for v6ops-data@psg.com; Tue, 01 Jul 2008 20:25:10 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDmPS-000Hoj-IC for v6ops@ops.ietf.org; Tue, 01 Jul 2008 20:25:08 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m61KOQWY026701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 13:24:26 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m61KOPCe016121; Tue, 1 Jul 2008 13:24:25 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m61KOOA6016108; Tue, 1 Jul 2008 13:24:25 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 13:24:23 -0700 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 13:24:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EE153@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjbGMzJDcr+8mROSEWj+SYsuig26wAeG68AAAML9IAAAVHugAAFY2Tg References: From: "Templin, Fred L" To: "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 01 Jul 2008 20:24:23.0153 (UTC) FILETIME=[7318CE10:01C8DBB8] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com]=20 >Sent: Tuesday, July 01, 2008 10:51 AM >To: v6ops@ops.ietf.org >Subject: FW: new draft on IPv6 CPE router available for review > >For some reason, Hemant is unable to post to v6ops even though he is >subscribed to it. Therefore, I'm forwarding this e-mail. > >- Wes=20 > >-----Original Message----- >From: Hemant Singh (shemant) >Sent: Tuesday, July 01, 2008 12:20 PM >To: 'Shin Miyakawa'; Wes Beebee (wbeebee); swmike@swm.pp.se; >v6ops@ops.ietf.org >Cc: yasuhiro@nttv6.jp; Hemant Singh (shemant) >Subject: RE: new draft on IPv6 CPE router available for review > >Shin, > >I don't see any reason to incorporate anything from your draft because >our document already mentions what your draft proposes. Please read our >draft completely before sending such comments. It is very=20 >clear from our >draft that the WAN interface acquires a global IPv6 address and the CPE >router gets IA_PD, the prefix from which is sub-delegated to hosts >connected to LAN interface(s) of the CPE router. Anyhow, Cable Labs has >already proposed the same global address on WAN port over one year back >in cable broadband networks. > >For others who have asked for only a link-local address on the WAN port >and asked for a Loopback interface on the CPE router, we have already >replied that we agree with such a recommendation and we will recommend >that the CPE router support both models - one model where WAN port also >acquires a global IPv6 address and another model where WAN interface >only acquires a link-local address. In the model where the WAN=20 >interface >has only a link-local address, the CPE router will use an optional >Loopback interface which will be assigned a global IPv6 address >sub-delegated from IA_PD via stateless DHCPv6. I agree with this latter as a necessary mode of operation. Fred fred.l.templin@boeing.com > >Thanks. > >Hemant > >-----Original Message----- >From: Shin Miyakawa [mailto:miyakawa@nttv6.jp] >Sent: Monday, June 30, 2008 9:21 PM >To: Wes Beebee (wbeebee); swmike@swm.pp.se; Hemant Singh (shemant); >v6ops@ops.ietf.org >Cc: miyakawa@nttv6.jp; yasuhiro@nttv6.jp >Subject: Re: new draft on IPv6 CPE router available for review > >Hello, > >I have a comment on the transfered message by Wes, > >> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >> >> >> In section 5.3 I would definitely like a CPE to work without=20 >having a=20 >> WAN address (link local only). > >Actually, this does not work if a CPE use the strong host model >implementation describing in RFC1122 or STD3 : Requirements=20 >for Internet >Hosts - Communication Layers. > >> The rationale behind this is that we would like ISP routers have IPs=20 >> in a core IP-range (which will be protected from DDOS by=20 >ratelimiters=20 >> or filters) and have customers in their own IP space. >> The handoff between distribution and CPE should be done via=20 >something=20 >> that is not reachable from the internet, ie the CPE should never=20 >> source packets from its WAN IP, instead it should source packets=20 >> destined to the internet from a loopback IP which it should allocate=20 >> to itself from DHCPv6-PD (it could also be a LAN interface IP). >> So behavior would be "get link-local working, do DHCPv6-PD, allocate=20 >> IP to itself from PD range, then use THAT to provision=20 >itself further=20 >> and to communicate with everything". > >Originally, when we wrote RFC4241 (A Model of IPv6/IPv4 Dual Stack >Internet Access Service) to start our IPv6/v4 dual stack native ADSL >service, we also thought about same thing. So we can=20 >understand Mikael's >will too. > >But now Microsoft Vista and Windows 2008 IPv6 implementation are based >on the strong host model as default, (please see >http://technet.microsoft.com/en-us/library/bb878108.aspx >and >http://technet.microsoft.com/en-us/magazine/cc137807.aspx ). > >Especially, if we think that the uplink is a "softwire" or the CPE is a >brige, Vista is one of the most likely to be used operating systems to >terminate the IPv6 uplink by itself, so from practical point=20 >of view, we >strongly recommend to assign a global IPv6 address. > >We've just submitted a very short draft regarding this issue > >http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt > >and hope this could be merged to the section 5.3 of Wes's=20 >draft with its >reasons. > >Best regards, > >Shin Miyakawa, Ph.D >Director, Core Network Technology Team, Network Systems and >Technologies, Innovative IP Architecture Center / Corporate Planning >Department (concurrent position) NTT Communications Corporation Tokyo >Opera City Tower 21st Floor >3-20-2 Nishi-Shinjuku, Shinjuku-Ku, Tokyo, Japan 163-1421 >E-mail:miyakawa@nttv6.jp / shin.miyakawa@ntt.com / miyakawa@wide.ad.jp >TEL:+81-3-6800-3262 / FAX:+81-3-5365-2990 Visiting Researcher, SFC Lab. >KEIO University WIDE Project > > From owner-v6ops@ops.ietf.org Tue Jul 1 19:15:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447553A68CC for ; Tue, 1 Jul 2008 19:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r31wVZFUGcrk for ; Tue, 1 Jul 2008 19:15:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CD2E3A67E5 for ; Tue, 1 Jul 2008 19:15:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDrmv-000HSV-Fc for v6ops-data@psg.com; Wed, 02 Jul 2008 02:09:41 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDrmr-000HQi-Sq for v6ops@ops.ietf.org; Wed, 02 Jul 2008 02:09:39 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 0025EBDC21; Wed, 2 Jul 2008 11:09:36 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id CDD136E358; Wed, 2 Jul 2008 11:09:36 +0900 (JST) Date: Wed, 02 Jul 2008 11:09:36 +0900 (JST) Message-Id: <20080702.110936.183118227.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: otroan@employees.org, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <2bbba3c10807010328y7ab73b5gbac5110b12dde2ed@mail.gmail.com> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, > It's standard industry practice to use loopback addresses for almost > everything control plane in routers, as then the IGP will handle reroutes > and established TCP sessions are not affected by interfaces going up or > down. In CPE router case, it is not true, isn't it ? Because in today's environment a CPE has only one IPv4 address which is assigned to the WAN interface of the CPE. Shin Miyakawa From owner-v6ops@ops.ietf.org Tue Jul 1 19:15:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D99F3A686B for ; Tue, 1 Jul 2008 19:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5weC2BgLYBqk for ; Tue, 1 Jul 2008 19:15:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A999E3A67E5 for ; Tue, 1 Jul 2008 19:15:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDrpo-000Hk7-58 for v6ops-data@psg.com; Wed, 02 Jul 2008 02:12:40 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDrpL-000HhY-JX for v6ops@ops.ietf.org; Wed, 02 Jul 2008 02:12:38 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 2F0EDBDC08; Wed, 2 Jul 2008 11:12:11 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id F29F06E358; Wed, 2 Jul 2008 11:12:10 +0900 (JST) Date: Wed, 02 Jul 2008 11:12:10 +0900 (JST) Message-Id: <20080702.111210.39239457.miyakawa@nttv6.jp> To: shemant@cisco.com, swmike@swm.pp.se, wbeebee@cisco.com, v6ops@ops.ietf.org Cc: miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant and Mikael, Let me clarify that your idea is that One CPE MUST support BOTH models ? This is quite important, because it defines operation scheme. Shin Miyakawa From: "Hemant Singh (shemant)" Subject: RE: new draft on IPv6 CPE router available for review Date: Tue, 1 Jul 2008 16:05:07 -0400 > Honestly, I don't see any downside to making support for both models as > a MUST. If anyone any objections to making both models a MUST, it's time > to speak up. > > Hemant > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, July 01, 2008 3:50 PM > To: Hemant Singh (shemant) > Cc: Shin Miyakawa; Wes Beebee (wbeebee); v6ops@ops.ietf.org > Subject: RE: new draft on IPv6 CPE router available for review > > On Tue, 1 Jul 2008, Hemant Singh (shemant) wrote: > > > router supporting the link-local only WAN model. Of course, we totally > > > want the first model to be a MUST for the CPE router to support - in > > this model the WAN interface acquires a global IPv6 address. > > What are the downsides of making both models a MUST? I think any router > should (MUST) be able to source packets from any interface chosen, > including one that is not the outgoing interface. > > This would of course have the implications that some primary host > implementations with optional routing capability might not comply with > this right now, but would put pressure on vendors to implement this > properly. > > I know there's been discussions regarding traceroute behaviour as well, > with the industry standard being that the ICMP TTL-EXCEEDED message > being sourced from the router IP where it was received, but goes out any > interface (as per the routing table to the destination). > > I just would like to get future IPv6 implementations for routers working > properly from the start, as most residential CPE vendors seem to not > have implemented IPv6 support yet, I would like them to do both models > as the model I'm advocating would have long term benefits for network > stability. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From owner-v6ops@ops.ietf.org Tue Jul 1 19:51:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0643A6993 for ; Tue, 1 Jul 2008 19:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfeOYi+c5Yul for ; Tue, 1 Jul 2008 19:51:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78D173A69E7 for ; Tue, 1 Jul 2008 19:51:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDsPu-000Lk3-Q0 for v6ops-data@psg.com; Wed, 02 Jul 2008 02:49:58 +0000 Received: from [2001:218:1f01:2::23] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDsPq-000Ljk-W1 for v6ops@ops.ietf.org; Wed, 02 Jul 2008 02:49:56 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 82477BDC24; Wed, 2 Jul 2008 11:49:54 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4FDE26E358; Wed, 2 Jul 2008 11:49:54 +0900 (JST) Date: Wed, 02 Jul 2008 11:49:54 +0900 (JST) Message-Id: <20080702.114954.179869009.miyakawa@nttv6.jp> To: davidm@thetiger.com Cc: swmike@swm.pp.se, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080701.102044.59751592.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David, > Ole raised the issue that a router would (almost by definition) need > to implement a weak or semi-strong model, and I would support this > view. I do believe the CPE must support the sending of IP datagrams to > Internet hosts (for ICMPv6, management, etc) but see an option of > using a loopback interface for this purpose (from the subscriber's > delegated prefix). Please note well that, if you'd like to assign a global IPv6 unicast address to the LoopBack interface, because loopback is the diffrent from LAN links behind the CPE, we have to assign at least two /64 prefies to the CPE (one /64 for LAN, one /64 for loopback, assuming that a /64 is the minimal unit of prefix delegation). > This allows a single subscriber to be represented > by one prefix that may be operationally beneficial, or provide a more > scalable BNG architecture. So, this consumes more than "one Global address for the WAN interface with one /64 for LAN" (as I called this as "1+/64" or for some reason, "1+/64s") model. How do you think about this fact ? Or forget about the loopback interface and use the CPE's LAN interface in the weak host model case ? Best wishes, Shin Miyakawa From owner-v6ops@ops.ietf.org Tue Jul 1 21:20:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719E73A683B for ; Tue, 1 Jul 2008 21:20:42 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEZj5TSCoOLy for ; Tue, 1 Jul 2008 21:20:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70F8E3A67A1 for ; Tue, 1 Jul 2008 21:20:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtlV-0005Qo-GJ for v6ops-data@psg.com; Wed, 02 Jul 2008 04:16:21 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtlR-0005Q7-FX for v6ops@ops.ietf.org; Wed, 02 Jul 2008 04:16:19 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9AC60ADADD; Wed, 2 Jul 2008 06:16:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DB8AADAD9; Wed, 2 Jul 2008 06:16:15 +0200 (CEST) Date: Wed, 2 Jul 2008 06:16:15 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: otroan@employees.org, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080702.110936.183118227.miyakawa@nttv6.jp> Message-ID: References: <2bbba3c10807010328y7ab73b5gbac5110b12dde2ed@mail.gmail.com> <20080702.110936.183118227.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 2 Jul 2008, Shin Miyakawa wrote: > Mikael, > >> It's standard industry practice to use loopback addresses for almost >> everything control plane in routers, as then the IGP will handle reroutes >> and established TCP sessions are not affected by interfaces going up or >> down. > > In CPE router case, it is not true, isn't it ? > Because in today's environment a CPE has only one IPv4 address > which is assigned to the WAN interface of the CPE. Well, I think in the IPv6 case that CPEs need to be more advanced than todays devices. I foresee 3G/4G backups for the WAN port for instance. Also, the reason for only assigning single global IPv4 space to customers is usually because of scarcity of IPv4 addresses, and the ISPs I know of who allow for multiple addresses, do this via kludges (local-proxy-arp for instance, which means that local traffic between customer computers risk going over the WAN). Also, I would have liked to do the core/customer IP block thing for IPv4 as well, it's just that the support for that in cheap customer CPEs just isn't there. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 1 21:20:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17FD3A683B for ; Tue, 1 Jul 2008 21:20:50 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-PHGZHchKJh for ; Tue, 1 Jul 2008 21:20:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01FC03A65A5 for ; Tue, 1 Jul 2008 21:20:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtma-0005YK-WC for v6ops-data@psg.com; Wed, 02 Jul 2008 04:17:29 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtmW-0005Xc-Gz for v6ops@ops.ietf.org; Wed, 02 Jul 2008 04:17:26 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id AE7CBADADD; Wed, 2 Jul 2008 06:17:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A3FEFADAD9; Wed, 2 Jul 2008 06:17:23 +0200 (CEST) Date: Wed, 2 Jul 2008 06:17:23 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080702.111210.39239457.miyakawa@nttv6.jp> Message-ID: References: <20080702.111210.39239457.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 2 Jul 2008, Shin Miyakawa wrote: > Hemant and Mikael, > > Let me clarify that your idea is that > > One CPE MUST support BOTH models ? > > This is quite important, because it defines operation scheme. Yes, I want the devices to support both models, and then the ISP can choose one. It also means CPE can hopefully be reused when a customer changes ISPs, or interacts with multiple ISPs (think one 4G wireless ISP and another wired ISP). -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 1 21:24:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B773A683B for ; Tue, 1 Jul 2008 21:24:27 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeaNZyLixKJ0 for ; Tue, 1 Jul 2008 21:24:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B3653A67AB for ; Tue, 1 Jul 2008 21:24:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtsk-0006IA-Q8 for v6ops-data@psg.com; Wed, 02 Jul 2008 04:23:50 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDtsg-0006HV-Vw for v6ops@ops.ietf.org; Wed, 02 Jul 2008 04:23:48 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0D440ADADD; Wed, 2 Jul 2008 06:23:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 03D62ADAD9; Wed, 2 Jul 2008 06:23:45 +0200 (CEST) Date: Wed, 2 Jul 2008 06:23:45 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: davidm@thetiger.com, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080702.114954.179869009.miyakawa@nttv6.jp> Message-ID: References: <20080701.102044.59751592.miyakawa@nttv6.jp> <20080702.114954.179869009.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 2 Jul 2008, Shin Miyakawa wrote: > Please note well that, if you'd like to assign a global IPv6 unicast address > to the LoopBack interface, > because loopback is the diffrent from LAN links behind the CPE, > we have to assign at least two /64 prefies to the CPE > (one /64 for LAN, one /64 for loopback, assuming that a /64 is the minimal unit > of prefix delegation). I want to assign either a /56 or /48 per residential user. > So, this consumes more than > "one Global address for the WAN interface with one /64 for LAN" (as > I called this as "1+/64" or for some reason, "1+/64s") model. > > How do you think about this fact ? I think it's very important that customers are able to use multiple IPv6 subnets in their home for a lot of reasons, where a DMZ might be one. > Or forget about the loopback interface and use the CPE's LAN interface in > the weak host model case ? That works for me as well, as long as the customer only originates globally routed traffic from the PD assigned block, I'm fine. Also, by doing link-local, I hope to save TCAM space in the distribution/PE router as well. Each adjacancy it has to keep will afaik consume router resources, not having a globally routable WAN address saves at least one TCAM entry, plus perhaps one more because my ACL in on the subinterface will not have to allow for both the customer /56 as well as the /64 and the link-local, it can now only allow for the customer /56 and the link-local, that's probably one more TCAM entry saved. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Wed Jul 2 06:53:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296AC3A6BE8 for ; Wed, 2 Jul 2008 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW7nUIBqBct4 for ; Wed, 2 Jul 2008 06:53:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331923A6AA7 for ; Wed, 2 Jul 2008 06:53:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE2fI-000PBY-4L for v6ops-data@psg.com; Wed, 02 Jul 2008 13:46:32 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE2fD-000PAy-JR for v6ops@ops.ietf.org; Wed, 02 Jul 2008 13:46:30 +0000 Received: (qmail 14602 invoked by uid 509); 2 Jul 2008 13:46:26 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.1/7613. spamassassin: 3.2.4. Clear:RC:1(211.28.128.246):. Processed in 0.042036 secs); 02 Jul 2008 13:46:26 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Wed, 02 Jul 2008 08:46:25 -0500 Cc: swmike@swm.pp.se, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com Message-Id: From: David Miles To: Shin Miyakawa In-Reply-To: <20080702.114954.179869009.miyakawa@nttv6.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Wed, 2 Jul 2008 23:46:19 +1000 References: <20080701.102044.59751592.miyakawa@nttv6.jp> <20080702.114954.179869009.miyakawa@nttv6.jp> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Shin, On 02/07/2008, at 12:49 PM, Shin Miyakawa wrote: > David, > >> Ole raised the issue that a router would (almost by definition) need >> to implement a weak or semi-strong model, and I would support this >> view. I do believe the CPE must support the sending of IP datagrams >> to >> Internet hosts (for ICMPv6, management, etc) but see an option of >> using a loopback interface for this purpose (from the subscriber's >> delegated prefix). > > Please note well that, if you'd like to assign a global IPv6 unicast > address > to the LoopBack interface, > because loopback is the diffrent from LAN links behind the CPE, > we have to assign at least two /64 prefies to the CPE > (one /64 for LAN, one /64 for loopback, assuming that a /64 is the > minimal unit > of prefix delegation). Yes, agree. > > >> This allows a single subscriber to be represented >> by one prefix that may be operationally beneficial, or provide a more >> scalable BNG architecture. > > So, this consumes more than > "one Global address for the WAN interface with one /64 for LAN" (as > I called this as "1+/64" or for some reason, "1+/64s") model. > > How do you think about this fact ? Sorry Shin, I had thought the /64 was an example for any delegated prefix-length. For prefix-lengths shorter than /64 do you see different options? > > > Or forget about the loopback interface and use the CPE's LAN > interface in > the weak host model case ? This is an option as well if we are concerned about the use of an entire /64 for CPE management. Given there has been some discussion recently on-list about using a /64 on point-to-point links as best practice, it would seem to suggest that a /64 should not be considered an excessive waste of IPv6 resource. There is also a potential for the LAN interface to be in a down state, and for the service provider to require management of the device. By binding the global-scope management address to either the loopback or the WAN interface the service provider can ensure management irrespective of LAN interface state. Further, the customer may choose to address their LAN interface however they see fit, which may not suit a service provider. Thus I prefer the options of using loopback or WAN interface. Again, I reiterate that I think both options are acceptable and may have different consequences that an operator should be informed on. I am not arguing against the /64+1 or even a /56+1, I am supporting the option of a link-local-only WAN interface. Best Regards, -David From owner-v6ops@ops.ietf.org Wed Jul 2 07:41:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0F53A6C78 for ; Wed, 2 Jul 2008 07:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+aJVpTsJIHC for ; Wed, 2 Jul 2008 07:41:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E39CA3A6A0F for ; Wed, 2 Jul 2008 07:41:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE3Uo-0007tG-Vo for v6ops-data@psg.com; Wed, 02 Jul 2008 14:39:46 +0000 Received: from [69.147.75.107] (helo=web62515.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE3Uk-0007sI-R5 for v6ops@ops.ietf.org; Wed, 02 Jul 2008 14:39:45 +0000 Received: (qmail 11507 invoked by uid 60001); 2 Jul 2008 14:39:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=umBAZlr2OnZMeAynoDJT8iwnm93uLeaOOFOtVKi1L3M1hwrjO37d4YXtylRRJeLhEvXuCd2XZ9pu9W3KCkyp+9y1EVXxpyAY60K4yHGvfIiCCep02qp2qIRuvD4ToMKFKiamKeDc2B/L/NuSqxmpmy4cAVu3P1fzdMkA/DU5ctc=; Received: from [193.49.124.107] by web62515.mail.re1.yahoo.com via HTTP; Wed, 02 Jul 2008 07:39:35 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Wed, 2 Jul 2008 07:39:35 -0700 (PDT) From: Francois-Xavier Le Bail Subject: Re: new draft on IPv6 CPE router available for review To: Shin Miyakawa , David Miles Cc: swmike@swm.pp.se, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <854412.11064.qm@web62515.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David, --- On Wed, 7/2/08, David Miles wrote: > There is also a potential for the LAN interface to be in a down state, > and for the service provider to require management of the device. > By binding the global-scope management address to either the loopback > or the WAN interface the > service provider can ensure management irrespective of LAN > interface state. > > -David The CPE must also support IPv4, and for using one subnet in IPv4 world, it's a practice to have a LAN bridge with Ethernet, Wifi, etc. interfaces adding to it. And this bridge is always up, even if the LAN interfaces are individualy down. So binding the global-scope management address to this LAN bridge can be a way to consider. Best Regards, Francois-Xavier From owner-v6ops@ops.ietf.org Wed Jul 2 13:17:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5623A690B for ; Wed, 2 Jul 2008 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfYUHnT+pIno for ; Wed, 2 Jul 2008 13:17:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6B693A69C1 for ; Wed, 2 Jul 2008 13:17:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8fg-000Nl7-BX for v6ops-data@psg.com; Wed, 02 Jul 2008 20:11:20 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8fc-000NkT-K9 for v6ops@ops.ietf.org; Wed, 02 Jul 2008 20:11:18 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 3F16ABDC21; Thu, 3 Jul 2008 05:11:16 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 1521B6E358; Thu, 3 Jul 2008 05:11:16 +0900 (JST) Date: Thu, 03 Jul 2008 05:11:15 +0900 (JST) Message-Id: <20080703.051115.189681710.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: <20080703.050938.104080059.miyakawa@nttv6.jp> References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: oops. > Also how about if a customer has only one PC (this is quite linkly situation) ? likely Shin From owner-v6ops@ops.ietf.org Wed Jul 2 13:17:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751453A69C1 for ; Wed, 2 Jul 2008 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc2Gl8lfhVO5 for ; Wed, 2 Jul 2008 13:17:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75BB23A690B for ; Wed, 2 Jul 2008 13:17:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8eC-000NYv-0G for v6ops-data@psg.com; Wed, 02 Jul 2008 20:09:48 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8e8-000NYS-EQ for v6ops@ops.ietf.org; Wed, 02 Jul 2008 20:09:46 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 18A89BDC26; Thu, 3 Jul 2008 05:09:39 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id DEC926E358; Thu, 3 Jul 2008 05:09:38 +0900 (JST) Date: Thu, 03 Jul 2008 05:09:38 +0900 (JST) Message-Id: <20080703.050938.104080059.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080702.111210.39239457.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, > > Let me clarify that your idea is that > > > > One CPE MUST support BOTH models ? > > > > This is quite important, because it defines operation scheme. > > Yes, I want the devices to support both models, and then the ISP can > choose one. This is a point. This means you are not allowing any CPE device which is (A)A machine will follow RFC3484 to select source address regardless if this machine is a strong host model or a weak host model (B)No routing function (for example, because there is no LAN behind) So, (X)Even if a machine terminates PPPoE, L2TP or whatever uplink by itself with no other machines in the customer premises, this machine must have BOTH models. Then, it seems to me that this is overkill. For example, if we create sensor networks, do we still need routing function on all the sensor devices ? I do not think so. Also how about if a customer has only one PC (this is quite linkly situation) ? At the same time, please note that we have no way to identify a CPE is a router or just a host. So, I strongly against this text "One CPE MUST support BOTH models". Of course, "The Service MUST support BOTH models" will be fine. =========== Best regards, Shin Miyakawa From owner-v6ops@ops.ietf.org Wed Jul 2 13:26:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36A13A6980 for ; Wed, 2 Jul 2008 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2s6u4DEmWxz for ; Wed, 2 Jul 2008 13:26:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CFE13A6937 for ; Wed, 2 Jul 2008 13:26:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8tc-000PRX-E0 for v6ops-data@psg.com; Wed, 02 Jul 2008 20:25:44 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KE8tY-000PQh-3z for v6ops@ops.ietf.org; Wed, 02 Jul 2008 20:25:42 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id ADD5BBDC26; Thu, 3 Jul 2008 05:25:39 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 7EC536FCD9; Thu, 3 Jul 2008 05:25:39 +0900 (JST) Date: Thu, 03 Jul 2008 05:25:39 +0900 (JST) Message-Id: <20080703.052539.112577921.miyakawa@nttv6.jp> To: davidm@thetiger.com Cc: swmike@swm.pp.se, wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, yasuhiro@nttv6.jp, sven.ooghe@alcatel-lucent.com, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080702.114954.179869009.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > "one Global address for the WAN interface with one /64 for LAN" (as > > I called this as "1+/64" or for some reason, "1+/64s") model. > > > > How do you think about this fact ? > > Sorry Shin, I had thought the /64 was an example for any delegated > prefix-length. For prefix-lengths shorter than /64 do you see > different options? Of course fine, for me. > > Or forget about the loopback interface and use the CPE's LAN > > interface in > > the weak host model case ? > > This is an option as well if we are concerned about the use of an > entire /64 for CPE management. sounds fine for me too. > Given there has been some discussion > recently on-list about using a /64 on point-to-point links as best > practice, it would seem to suggest that a /64 should not be considered > an excessive waste of IPv6 resource. OK. I agree with this. > There is also a potential for the > LAN interface to be in a down state, and for the service provider to > require management of the device. In this case, assigning a global IP address to the WAN I/F is easy way, isn't it ? > By binding the global-scope > management address to either the loopback or the WAN interface the > service provider can ensure management irrespective of LAN interface > state. If you think that some address from "delegated range" can be bind to the WAN interface, +-------uplink -------------(1) CPE #1 Access concentrator (x)-------+-------uplink -------------(2) CPE #2 +-------uplink -------------(3) CPE #3 If the interface at (x) has no global ip address and interfaces (1), (2) and (3) has global IP address from their delegated range, I don't think this is a good situation. > Further, the customer may choose to address their LAN interface > however they see fit, which may not suit a service provider. Thus I > prefer the options of using loopback or WAN interface. So, if you think that that address is from "delegated range" just like Mikael says, You should not use it on WAN I/F but loopback. > Again, I reiterate that I think both options are acceptable This is what I say. Mikael say more strict model. Please do not be confused. > I am supporting the option of a link-local-only WAN interface. Then, again, please try to modify RFC3484 first. Shin Miyakawa From owner-v6ops@ops.ietf.org Wed Jul 2 22:54:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FE73A6CC1 for ; Wed, 2 Jul 2008 22:54:21 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFH0cRTwVmrU for ; Wed, 2 Jul 2008 22:54:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 707F13A6930 for ; Wed, 2 Jul 2008 22:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEHe9-000IJY-SG for v6ops-data@psg.com; Thu, 03 Jul 2008 05:46:21 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEHe5-000IIp-IS for v6ops@ops.ietf.org; Thu, 03 Jul 2008 05:46:19 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 387D6ADAD9; Thu, 3 Jul 2008 07:46:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A782ADAD8; Thu, 3 Jul 2008 07:46:11 +0200 (CEST) Date: Thu, 3 Jul 2008 07:46:11 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080703.050938.104080059.miyakawa@nttv6.jp> Message-ID: References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 3 Jul 2008, Shin Miyakawa wrote: > (A)A machine will follow RFC3484 to select source address > regardless if this machine is a strong host model or a weak host model > (B)No routing function (for example, because there is no LAN behind) Correct. > (X)Even if a machine terminates PPPoE, L2TP or whatever uplink by itself > with no other machines in the customer premises, this machine must have BOTH models. I never said all IPv6 speaking HOSTS need to do this. For me a CPE is something that is involved in the delivery of a service, not an end user host device. I see two different services, one which is for connecting a single device and nothing else, and another service where the customer has a router and several hosts behind it. If this is another definition of a CPE, then I need to change my terminology to avoid confusion. Am I using the wrong terminology? > For example, if we create sensor networks, do we still need routing > function on all the sensor devices ? I do not think so. Of course not. > At the same time, please note that we have no way to identify a CPE is a router > or just a host. The customer will have to decide this at the time of purchase of the service. > Of course, "The Service MUST support BOTH models" will be fine. > =========== That is not what I want, quite the opposite. So, let me elaborate my view, and include my definitions which might make it more clear what I'm after. For me, a CPE is the device that connects the home network to the outside world, it might be a DSL modem, a NAT gateway, wireless access point or alike. It is NOT an end host. In 10 years time, I see people having all kinds of devices in their home, and the ISP does not want to keep state or forwarding resources for every device, thus we need to route IPv6 subnet to a router that is placed in the home, controlled by the customer (or a provisioning system in case of a managed CPE, but the customer will most likely be influencing how the CPE is configured thru a selfcare system that then configures the CPE). For people with only a single computer in their home, I want this to be a special case, and since they don't need triple play or alike, we might as well tunnel them over IPv4/ethernet in the interim, with 6to4, PPPoE or alike. So the ISP provides two different services whether the customer wants to have a home gateway with a LAN behind it, or if they want to just connect a single computer. So, my rationale is that any home gateway device needs to support both models (link-local only for WAN and the strong host model), end hosts only need to support the strong host model. Does this make my position more understandable? -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 3 01:51:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4223A6823 for ; Thu, 3 Jul 2008 01:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UbSYgNmiwPa for ; Thu, 3 Jul 2008 01:51:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3649C3A67F6 for ; Thu, 3 Jul 2008 01:51:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEKTA-000EEV-CR for v6ops-data@psg.com; Thu, 03 Jul 2008 08:47:12 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEKT6-000ECy-Nf for v6ops@ops.ietf.org; Thu, 03 Jul 2008 08:47:10 +0000 Received: (qmail 21378 invoked by uid 417); 3 Jul 2008 08:47:04 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 08:47:04 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 02:47:04 -0600 References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: Mikael Abrahamsson Cc: Shin Miyakawa , shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 02:47:04 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [192.117.238.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael Abrahamsson writes: > I never said all IPv6 speaking HOSTS need to do this. For me a CPE is > something that is involved in the delivery of a service, not an end user > host device. I see two different services, one which is for connecting a > single device and nothing else, and another service where the customer has > a router and several hosts behind it. If this is another definition of a > CPE, then I need to change my terminology to avoid confusion. Am I using > the wrong terminology? > It seems to me that there is a confusion in terminology that is feeding this mail chain. Common usage has CPE being both the edge device (1)(DSL modem with or without built in router), Router/Switch (2)(built in DSL, Ethernet, WiFi, etc.), and the end-user device (3) (PC, Laptop, PDA, dual function Mobile phone). This document seems to deal with 1 and 2 only while discussion is mostly on 3. It seems to me that we need to separate these topics to edge and End-user rather than the general CPE (what happens when these are mobile like with 802.16e). We know that almost all (I am tempted to say all) PCs and laptops support dual stack today, but I would love to hear about the other end-user devices the so called "internet devices" from companies like Nokia. Are they dual stack already? Eric From owner-v6ops@ops.ietf.org Thu Jul 3 04:20:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149703A6842 for ; Thu, 3 Jul 2008 04:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zmDYAhfS1eh for ; Thu, 3 Jul 2008 04:20:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 122713A6820 for ; Thu, 3 Jul 2008 04:20:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEMlw-00064a-Pj for v6ops-data@psg.com; Thu, 03 Jul 2008 11:14:44 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEMls-00063v-M4 for v6ops@ops.ietf.org; Thu, 03 Jul 2008 11:14:43 +0000 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m63BE9hH005694; Thu, 3 Jul 2008 14:14:20 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 14:14:08 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 14:14:04 +0300 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 14:14:03 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: Acjc6llyiSoAaHGXS62TI0liaj0QnwAEFCiA References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> From: To: , Cc: , , , X-OriginalArrivalTime: 03 Jul 2008 11:14:04.0851 (UTC) FILETIME=[E77B4030:01C8DCFD] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, >Common usage has CPE being both the edge device (1)(DSL modem with or=20 >without built in router), Router/Switch (2)(built in DSL,=20 >Ethernet, WiFi,=20 >etc.), and the end-user device (3) (PC, Laptop, PDA, dual=20 >function Mobile=20 >phone).=20 This is a good separation and I agree we need to get terminology clarified, as for me it is unclear whether a mobile phone that would support DHCPv6 PD for getting prefixes for the local area network can be called a CPE or not. I hear term "cellular router" also used in this context.=20 >We know that almost all (I am tempted to say all) PCs and=20 >laptops support dual stack today, but I would love to hear about the other=20 >end-user devices=20 >the so called "internet devices" from companies like Nokia.=20 >Are they dual stack already?=20 On the mobile side the situation generally is fuzzier than on "PC"-side. When looking just at the operating systems commonly used in mobile phones such as Symbian, Linux, Windows Mobile, and OS/X, they all by my understanding include both IPv4 and IPv6 stacks (most likely the other (proprietary) OS'es that are used have IPv6 support implemented as well). However, it is then totally different matter whether the actual products that are using those operating system have IPv6 enabled/compiled in - currently many products are sold as IPv4-only due to lack of demand for IPv6-support from operators and customers, but also many products being sold have both IPv4 and IPv6 enabled. Do you think it would be beneficial to have a BCP or something that would describe how the category (3) devices should behave? As category 3 devices are used in various networks and also often move pretty freely, it may be that different networks provide different services, and e.g. DHCPv6 PD is not available in all networks. Still these devices must provide good user experience, thus I believe they have to support ND proxies as well to always being able to provide connectivity for local network. There probably are other things to consider as well that would be good to document? Best regards, Teemu From owner-v6ops@ops.ietf.org Thu Jul 3 04:39:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E2F3A681B for ; Thu, 3 Jul 2008 04:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWrM3-nxu6+C for ; Thu, 3 Jul 2008 04:39:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7401C3A67EB for ; Thu, 3 Jul 2008 04:39:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEN8O-0008yp-9Z for v6ops-data@psg.com; Thu, 03 Jul 2008 11:37:56 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEN8D-0008xe-FA for v6ops@ops.ietf.org; Thu, 03 Jul 2008 11:37:47 +0000 X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="13095774" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2008 11:37:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m63BbieW001430; Thu, 3 Jul 2008 07:37:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m63Bbi7r002805; Thu, 3 Jul 2008 11:37:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 07:37:44 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 07:37:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: Acjc6Xk8uRq/OeEHQvqEZrlv3ZthwAAClJbQ References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> From: "Hemant Singh (shemant)" To: , "Mikael Abrahamsson" Cc: "Shin Miyakawa" , "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 03 Jul 2008 11:37:44.0262 (UTC) FILETIME=[35842E60:01C8DD01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3130; t=1215085064; x=1215949064; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20,=20=22Mikael=20Abrahamsson =22=20; bh=DkYap83LKUiE2r91oLvH1vEMcTRNvr3R9QmTm+2Y73I=; b=Sd8R6ZJbowzpaDXCaJn+UCxQhgO9HXJdZDr2TLxoPttbYPLomOTOwT7AUi 2KaLUmxKpOKmX5DQBUn13oEewDKst65l9Hs0Z9oi+qVjf80R+s4axP+vv/NI ZB5MfALvYk; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Oh, there is more confusion. Cable folks refer to a CPE as a host behind a cable modem where the host is a Windows or Mac OS PC. That is why in our draft we specifically refer in all places to a "CPE Router". In other worlds, I know CPE is also a generic term where the CPE means a DSL, cable, or FIOS modem. The modems may also have such a router embedded inside them but the box is still a CPE.=20 Our goal is to complete a document for a CPE Router that can be managed by the Service Provider, or managed by the user, or the CPE Router may be embedded in a broadband modem. We will see how the document evolves after feedback.=20 It is good to nail down Terminology otherwise we'll be thrashing a lot during discussion. Why not refer to the DSL or cable modem as the modem. Refer to the host behind the modem as a host, and the standalone Linksys-like router in the home as the CPE Router. Any router cascaded behind the CPE Router is, of course, just a router. Mobile is also not a good term for the home since Mobile reeks more of cellular Mobile. In the home, the most common term I have heard of in the US homes in wireless and WLAN. What do you mean this document is not discussing wireless in the CPE Router? It's not this document's business to discuss physical layer of wireless. WLAN is just another network for the CPE Router to forward packets to and from Hemant -----Original Message----- From: EricLKlein@softhome.net [mailto:EricLKlein@softhome.net]=20 Sent: Thursday, July 03, 2008 4:47 AM To: Mikael Abrahamsson Cc: Shin Miyakawa; Hemant Singh (shemant); Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Mikael Abrahamsson writes:=20 > I never said all IPv6 speaking HOSTS need to do this. For me a CPE is=20 > something that is involved in the delivery of a service, not an end=20 > user host device. I see two different services, one which is for=20 > connecting a single device and nothing else, and another service where > the customer has a router and several hosts behind it. If this is=20 > another definition of a CPE, then I need to change my terminology to=20 > avoid confusion. Am I using the wrong terminology? >=20 It seems to me that there is a confusion in terminology that is feeding this=20 mail chain.=20 Common usage has CPE being both the edge device (1)(DSL modem with or=20 without built in router), Router/Switch (2)(built in DSL, Ethernet, WiFi,=20 etc.), and the end-user device (3) (PC, Laptop, PDA, dual function Mobile=20 phone).=20 This document seems to deal with 1 and 2 only while discussion is mostly on=20 3. It seems to me that we need to separate these topics to edge and End-user=20 rather than the general CPE (what happens when these are mobile like with=20 802.16e).=20 We know that almost all (I am tempted to say all) PCs and laptops support=20 dual stack today, but I would love to hear about the other end-user devices=20 the so called "internet devices" from companies like Nokia. Are they dual=20 stack already?=20 Eric From owner-v6ops@ops.ietf.org Thu Jul 3 04:53:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F353A6864 for ; Thu, 3 Jul 2008 04:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5wFD3MvrssQ for ; Thu, 3 Jul 2008 04:53:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D75F3A685C for ; Thu, 3 Jul 2008 04:53:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KENLc-000Arm-M2 for v6ops-data@psg.com; Thu, 03 Jul 2008 11:51:36 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KENLY-000Aqx-BX for v6ops@ops.ietf.org; Thu, 03 Jul 2008 11:51:34 +0000 X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="13096619" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2008 11:51:31 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m63BpVOX005926; Thu, 3 Jul 2008 07:51:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m63BpVvW021775; Thu, 3 Jul 2008 11:51:31 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 07:51:31 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 07:51:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: Acjc6llyiSoAaHGXS62TI0liaj0QnwAEFCiAAAGoyyA= References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> From: "Hemant Singh (shemant)" To: , , Cc: , "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 03 Jul 2008 11:51:31.0292 (UTC) FILETIME=[2276F1C0:01C8DD03] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3192; t=1215085891; x=1215949891; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20,=20,=0A=20=20=20=20=20=20=20=20; bh=iU2cjhfUJTXD1nMPDG00GKPUXPQeXD42h9gb5eC+m8s=; b=VqOpo2afZBcyQaXNTKheGUqLePEN1EP2wQiqE/d/Ye6FdyJpVEGqsH4HYf 51mappHqYj78Ch2/c9uqRB19QuRU/hHQSWQtlY0MRUKCXfdt3dt7nDCGrcfy NRh9qjEamO; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: It does not make sense to bundle PC and laptop in the category of a device that will ask for IA_PD option from DHCPv6 server. Further this draft clearly says it's describing a home CPE Router in Internet enabled homes. Most common home Internet connection is cable or DSL. So where does the question come from for a cellular router in one's home? Are you talking about wireless Internet services for the home? Even if that is the case, so what? As far as there is a link from that wireless service device to the CPE Router, this draft covers even that deployment. I don't think the CPE Router discussion is ambiguous. We are just not discussing a mobile phone in this CPE Router discussion! Hemant -----Original Message----- From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]=20 Sent: Thursday, July 03, 2008 7:14 AM To: EricLKlein@softhome.net; swmike@swm.pp.se Cc: miyakawa@nttv6.jp; Hemant Singh (shemant); Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review Hi, >Common usage has CPE being both the edge device (1)(DSL modem with or=20 >without built in router), Router/Switch (2)(built in DSL, Ethernet,=20 >WiFi, etc.), and the end-user device (3) (PC, Laptop, PDA, dual=20 >function Mobile phone). This is a good separation and I agree we need to get terminology clarified, as for me it is unclear whether a mobile phone that would support DHCPv6 PD for getting prefixes for the local area network can be called a CPE or not. I hear term "cellular router" also used in this context.=20 >We know that almost all (I am tempted to say all) PCs and laptops=20 >support dual stack today, but I would love to hear about the other=20 >end-user devices >the so called "internet devices" from companies like Nokia.=20 >Are they dual stack already?=20 On the mobile side the situation generally is fuzzier than on "PC"-side. When looking just at the operating systems commonly used in mobile phones such as Symbian, Linux, Windows Mobile, and OS/X, they all by my understanding include both IPv4 and IPv6 stacks (most likely the other (proprietary) OS'es that are used have IPv6 support implemented as well). However, it is then totally different matter whether the actual products that are using those operating system have IPv6 enabled/compiled in - currently many products are sold as IPv4-only due to lack of demand for IPv6-support from operators and customers, but also many products being sold have both IPv4 and IPv6 enabled. Do you think it would be beneficial to have a BCP or something that would describe how the category (3) devices should behave? As category 3 devices are used in various networks and also often move pretty freely, it may be that different networks provide different services, and e.g. DHCPv6 PD is not available in all networks. Still these devices must provide good user experience, thus I believe they have to support ND proxies as well to always being able to provide connectivity for local network. There probably are other things to consider as well that would be good to document? Best regards, Teemu From owner-v6ops@ops.ietf.org Thu Jul 3 06:34:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E55B3A6922 for ; Thu, 3 Jul 2008 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTGsU+fD0Nou for ; Thu, 3 Jul 2008 06:34:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C2283A6864 for ; Thu, 3 Jul 2008 06:34:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEOtE-000MZX-Iu for v6ops-data@psg.com; Thu, 03 Jul 2008 13:30:24 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEOtA-000MZ0-Od for v6ops@ops.ietf.org; Thu, 03 Jul 2008 13:30:22 +0000 Received: (qmail 13519 invoked by uid 417); 3 Jul 2008 13:29:58 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 13:29:58 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 07:29:58 -0600 References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: teemu.savolainen@nokia.com Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 07:29:58 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [192.117.238.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: teemu.savolainen@nokia.com writes: >>We know that almost all (I am tempted to say all) PCs and >>laptops support dual stack today, but I would love to hear about the > other >>end-user devices >>the so called "internet devices" from companies like Nokia. >>Are they dual stack already? > > On the mobile side the situation generally is fuzzier than on "PC"-side. > > > When looking just at the operating systems commonly used in mobile > phones such as Symbian, Linux, Windows Mobile, and OS/X, they all by my > understanding include both IPv4 and IPv6 stacks (most likely the other > (proprietary) OS'es that are used have IPv6 support implemented as > well). > > However, it is then totally different matter whether the actual products > that are using those operating system have IPv6 enabled/compiled in - > currently many products are sold as IPv4-only due to lack of demand for > IPv6-support from operators and customers, but also many products being > sold have both IPv4 and IPv6 enabled. Thank you this is what I suspected. > Do you think it would be beneficial to have a BCP or something that > would describe how the category (3) devices should behave? As category 3 > devices are used in various networks and also often move pretty freely, > it may be that different networks provide different services, and e.g. > DHCPv6 PD is not available in all networks. Still these devices must > provide good user experience, thus I believe they have to support ND > proxies as well to always being able to provide connectivity for local > network. There probably are other things to consider as well that would > be good to document? Having looked at what 3GPP has documented, and listening to what the WiMAX Forum have been working on, it is clear to me that no one has fully considered the implications of mobile devices with IPv6, especially in regards to roaming to between either v4 and dual stack vs. completely dual stack networks vs v6 only networks. And the fact that CPE and end-user devices can be either v4 only (see my original comment above) or dual stack, but these different groups are contemplating v6 only networks and devices (which is several years in the future at this point). So in short, yes I think a BCP / use case document would be very helpful to both the vendors and service providers who are looking towards the future. Best regards, Eric From owner-v6ops@ops.ietf.org Thu Jul 3 06:40:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E9A3A67F5 for ; Thu, 3 Jul 2008 06:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm+E3jW7-l8a for ; Thu, 3 Jul 2008 06:40:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46D863A67A8 for ; Thu, 3 Jul 2008 06:40:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEP1k-000NZZ-AW for v6ops-data@psg.com; Thu, 03 Jul 2008 13:39:12 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEP1f-000NYs-Qu for v6ops@ops.ietf.org; Thu, 03 Jul 2008 13:39:09 +0000 Received: (qmail 27674 invoked by uid 417); 3 Jul 2008 13:38:26 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 13:38:26 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 07:38:26 -0600 References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 07:38:26 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > Oh, there is more confusion. Cable folks refer to a CPE as a host behind > a cable modem where the host is a Windows or Mac OS PC. That is why in > our draft we specifically refer in all places to a "CPE Router". In > other worlds, I know CPE is also a generic term where the CPE means a > DSL, cable, or FIOS modem. The modems may also have such a router > embedded inside them but the box is still a CPE. > > Our goal is to complete a document for a CPE Router that can be managed > by the Service Provider, or managed by the user, or the CPE Router may > be embedded in a broadband modem. We will see how the document evolves > after feedback. This explains the difference in terminology usage. I suspect that the rest of the list is either from IP router/ DSL based or Mobile (Cellular/Wireless Broadband) mentalities. > It is good to nail down Terminology otherwise we'll be thrashing a lot > during discussion. Why not refer to the DSL or cable modem as the modem. > Refer to the host behind the modem as a host, and the standalone > Linksys-like router in the home as the CPE Router. Any router cascaded > behind the CPE Router is, of course, just a router. > > Mobile is also not a good term for the home since Mobile reeks more of > cellular Mobile. In the home, the most common term I have heard of in > the US homes in wireless and WLAN. What do you mean this document is not > discussing wireless in the CPE Router? It's not this document's business > to discuss physical layer of wireless. WLAN is just another network for > the CPE Router to forward packets to and from Actually I was using Mobile as a combination of Cellular (3GPP etc) and Wireless Broadband (WiMAX etc.) rather than WiFi. In this case Mobile is represented by a laptop with built in wireless (either tech is already installed or road mapped) or via PCMCIA etc or Internet terminals/dual function phones (Nokia, Samsung, etc.). Eric From owner-v6ops@ops.ietf.org Thu Jul 3 06:43:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637953A6922 for ; Thu, 3 Jul 2008 06:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJeLLzTf-1SN for ; Thu, 3 Jul 2008 06:43:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73E2E3A6877 for ; Thu, 3 Jul 2008 06:43:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEP4x-000O0L-7T for v6ops-data@psg.com; Thu, 03 Jul 2008 13:42:31 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEP4r-000NzS-NY for v6ops@ops.ietf.org; Thu, 03 Jul 2008 13:42:29 +0000 Received: (qmail 32671 invoked by uid 417); 3 Jul 2008 13:41:27 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 13:41:27 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 07:41:27 -0600 References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 07:41:27 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > It does not make sense to bundle PC and laptop in the category of a > device that will ask for IA_PD option from DHCPv6 server. Further this > draft clearly says it's describing a home CPE Router in Internet enabled > homes. Most common home Internet connection is cable or DSL. So where > does the question come from for a cellular router in one's home? Are you > talking about wireless Internet services for the home? Even if that is > the case, so what? As far as there is a link from that wireless service > device to the CPE Router, this draft covers even that deployment. > > I don't think the CPE Router discussion is ambiguous. We are just not > discussing a mobile phone in this CPE Router discussion! Then you envision this document as being only for fixed services via Cable, DSL, WiMAX 802.16d, VSAT, where there is an edge device (cable modem, DSL modem, etc) that is both modem and router? Eric From owner-v6ops@ops.ietf.org Thu Jul 3 08:23:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51CB3A68DC for ; Thu, 3 Jul 2008 08:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SEVPw31wE3d for ; Thu, 3 Jul 2008 08:23:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D925F3A685C for ; Thu, 3 Jul 2008 08:23:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEQZi-000C8V-HT for v6ops-data@psg.com; Thu, 03 Jul 2008 15:18:22 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEQZe-000C7b-5U for v6ops@ops.ietf.org; Thu, 03 Jul 2008 15:18:20 +0000 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m63FHXQu001664; Thu, 3 Jul 2008 18:18:00 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 18:17:50 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 18:17:50 +0300 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 18:17:47 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: Acjc6llyiSoAaHGXS62TI0liaj0QnwAEFCiAAAGoyyAABu6XIA== References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> From: To: , , Cc: , , X-OriginalArrivalTime: 03 Jul 2008 15:17:50.0158 (UTC) FILETIME=[F4D7FEE0:01C8DD1F] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >It does not make sense to bundle PC and laptop in the category=20 >of a device that will ask for IA_PD option from DHCPv6 server.=20 Why not? >Further this draft clearly says it's describing a home CPE=20 >Router in Internet enabled homes. Most common home Internet=20 >connection is cable or DSL. So where does the question come=20 >from for a cellular router in one's home? Are you talking=20 >about wireless Internet services for the home? Even if that is=20 >the case, so what? As far as there is a link from that=20 >wireless service device to the CPE Router, this draft covers=20 >even that deployment. > >I don't think the CPE Router discussion is ambiguous. We are=20 >just not discussing a mobile phone in this CPE Router discussion! The speeds of cellular networks are becoming reasonably fast by introduction of HSDPA, EV-DO, 802.16e, LTE, and whatever further generations there are coming. Furthermore flat rates are also gaining popularity. While cable and DSL are the current choices for Internet connectivity for majority of people, I believe there are already, and in future will be more, people who are willing to pay for flat rate Internet just once, and they may choose to pay it only for their cellular connectivity - as they can take that with them wherever they go. It should be noted that the cellular device may not only be just handled _phone_, but it can be integrated into car, bus, train, laptop, or even be a square box that sits in fixed place - it just gets WAN connection via cellular network and shares it to local (W)LAN. The network itself should not care too much what the router behind the wired or wireless link looks like. I'm not saying that draft-wbeebee-ipv6-cpe-router should describe these uses, but I'm interested to learn that if it does not, then maybe it would be nice to have another document that would describe the uses cases and recommendations for such category of devices. In v4-only world some of these cellular devices already implement NAT and DHCP server to share to LAN the single IPv4 address they got from the network via point-to-point link. In v6 they should implement ND proxies and DHCPv6 PD (to avoid need to do IPv6 NAT). For providing IPv4 connectivity for legacy devices in LAN when having only IPv6-native access network, these devices shall implement some of those IPv4-over-IPv6 technologies and then NAT the IPv4 address obtained e.g. with DSMIPv6, MNAT-PT etc. for the devices in LAN and RFC1918 space. Best regards, Teemu From owner-v6ops@ops.ietf.org Thu Jul 3 09:17:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632133A677E for ; Thu, 3 Jul 2008 09:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFvoGWSo+sLs for ; Thu, 3 Jul 2008 09:17:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2ED23A6ACF for ; Thu, 3 Jul 2008 09:16:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERRo-000JfD-1X for v6ops-data@psg.com; Thu, 03 Jul 2008 16:14:16 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERRk-000JeZ-30 for v6ops@ops.ietf.org; Thu, 03 Jul 2008 16:14:14 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id AA9C6BDC21; Fri, 4 Jul 2008 01:14:11 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 7D45C6F48B; Fri, 4 Jul 2008 01:14:11 +0900 (JST) Date: Fri, 04 Jul 2008 01:14:11 +0900 (JST) Message-Id: <20080704.011411.193726649.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080703.050938.104080059.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, First of all, thank you for your reply. I think that your vision is quite important. > I never said all IPv6 speaking HOSTS need to do this. For me a CPE is > something that is involved in the delivery of a service, not an end user > host device. "Something that is involved in the delivery of a service", can be an end user host device. ^^^^^^ Or, how about any applications on the CPE router ? Please think about following picture. Access Concentorator <----- PPP or whatever upstream link -----> A CPE that is "Something that is involved in the delivery of a service" This CPE may be a router or a host. there is no difference between two of those from ISP point of view. Acutally, there are many service using just a PC to terminate ISP upstream. So, why you exclude this case from (v6)CPE ? > I see two different services, one which is for connecting a > single device and nothing else, and another service where the customer has > a router and several hosts behind it. If this is another definition of a > CPE, then I need to change my terminology to avoid confusion. Am I using > the wrong terminology? As other folks write to this mailing list, we have to clarify terminology. > > At the same time, please note that we have no way to identify a CPE is a router > > or just a host. > > The customer will have to decide this at the time of purchase of the > service. If so, I think that people will purchase "one IPv6 global address service for a host" and USE V6NAT to connect any device in their home network, because probably this service will be less expensive than "Prefix Delegated service for a routed CPE". That's too bad. So, I don't like this idea... "The customer will have to decide this at the time of purchase of the service." Best regards, Shin Miyakawa From owner-v6ops@ops.ietf.org Thu Jul 3 09:18:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4C23A6A67 for ; Thu, 3 Jul 2008 09:18:05 -0700 (PDT) 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.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUD2KmBztI8U for ; Thu, 3 Jul 2008 09:18:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 935E03A67BD for ; Thu, 3 Jul 2008 09:18:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERV8-000K8B-Cc for v6ops-data@psg.com; Thu, 03 Jul 2008 16:17:42 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERV4-000K7H-7E for v6ops@ops.ietf.org; Thu, 03 Jul 2008 16:17:40 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id CB032BDC21; Fri, 4 Jul 2008 01:17:37 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 941036F48B; Fri, 4 Jul 2008 01:17:37 +0900 (JST) Date: Fri, 04 Jul 2008 01:17:37 +0900 (JST) Message-Id: <20080704.011737.71137530.miyakawa@nttv6.jp> To: shemant@cisco.com Cc: EricLKlein@softhome.net, swmike@swm.pp.se, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > It is good to nail down Terminology otherwise we'll be thrashing a lot > during discussion. Why not refer to the DSL or cable modem as the modem. > Refer to the host behind the modem as a host, and the standalone > Linksys-like router in the home as the CPE Router. Any router cascaded > behind the CPE Router is, of course, just a router. Please, please do not forget the fact that a host can be a router and a router can be a host. Shin Miyakawa From owner-v6ops@ops.ietf.org Thu Jul 3 09:23:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F523A6AC5 for ; Thu, 3 Jul 2008 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2cGNWT0SgV2 for ; Thu, 3 Jul 2008 09:23:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2A0A3A6AB5 for ; Thu, 3 Jul 2008 09:23:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERYY-000Km5-6A for v6ops-data@psg.com; Thu, 03 Jul 2008 16:21:14 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KERYT-000Kjj-1Z for v6ops@ops.ietf.org; Thu, 03 Jul 2008 16:21:12 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 9A6BFBDC08; Fri, 4 Jul 2008 01:21:08 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 634786E358; Fri, 4 Jul 2008 01:21:08 +0900 (JST) Date: Fri, 04 Jul 2008 01:21:08 +0900 (JST) Message-Id: <20080704.012108.104075906.miyakawa@nttv6.jp> To: shemant@cisco.com Cc: teemu.savolainen@nokia.com, EricLKlein@softhome.net, swmike@swm.pp.se, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > It does not make sense to bundle PC and laptop in the category of a > device that will ask for IA_PD option from DHCPv6 server. No. It DOES MAKE sence. > Further this draft clearly says it's describing a home CPE Router in Internet enabled > homes. > Most common home Internet connection is cable or DSL. At least in Japan, most common home Internet connection is Fiber To The Home :-p > I don't think the CPE Router discussion is ambiguous. Again, a host can be a router. So, without this clarification, the CPE Router discussion is ambiguous. Shin Miyakawa From owner-v6ops@ops.ietf.org Thu Jul 3 11:08:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4283A6A11 for ; Thu, 3 Jul 2008 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlfjx3i98XdQ for ; Thu, 3 Jul 2008 11:08:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EEED3A6C0D for ; Thu, 3 Jul 2008 11:08:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETBf-0009Xb-Tf for v6ops-data@psg.com; Thu, 03 Jul 2008 18:05:43 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETBc-0009X6-04 for v6ops@ops.ietf.org; Thu, 03 Jul 2008 18:05:42 +0000 Received: (qmail 19171 invoked by uid 417); 3 Jul 2008 18:05:37 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 18:05:37 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 12:05:37 -0600 References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> In-Reply-To: <20080704.011411.193726649.miyakawa@nttv6.jp> From: EricLKlein@softhome.net To: Shin Miyakawa Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 12:05:37 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Shin Miyakawa writes: > If so, I think that people will purchase "one IPv6 global address service > for a host" and USE V6NAT to connect any device in their home network, > because probably this service will be less expensive than > "Prefix Delegated service for a routed CPE". > That's too bad. > There is no Nat in IPv6. See RFC4864 - Local Network Protection for IPv6 for more details. From owner-v6ops@ops.ietf.org Thu Jul 3 11:08:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D043A6C0D for ; Thu, 3 Jul 2008 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjCT+zRwYIYy for ; Thu, 3 Jul 2008 11:08:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B18F3A6A11 for ; Thu, 3 Jul 2008 11:08:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KET9X-0009Jl-O3 for v6ops-data@psg.com; Thu, 03 Jul 2008 18:03:31 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KET9T-0009IR-Ql for v6ops@ops.ietf.org; Thu, 03 Jul 2008 18:03:29 +0000 Received: (qmail 14860 invoked by uid 417); 3 Jul 2008 18:03:15 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 3 Jul 2008 18:03:15 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 03 Jul 2008 12:03:15 -0600 References: <20080702.111210.39239457.miyakawa@nttv6.jp> <20080703.050938.104080059.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: teemu.savolainen@nokia.com Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 03 Jul 2008 12:03:15 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: teemu.savolainen@nokia.com writes: > > In v4-only world some of these cellular devices already implement NAT > and DHCP server to share to LAN the single IPv4 address they got from > the network via point-to-point link. In v6 they should implement ND > proxies and DHCPv6 PD (to avoid need to do IPv6 NAT). For providing IPv4 > connectivity for legacy devices in LAN when having only IPv6-native > access network, these devices shall implement some of those > IPv4-over-IPv6 technologies and then NAT the IPv4 address obtained e.g. > with DSMIPv6, MNAT-PT etc. for the devices in LAN and RFC1918 space. > It is good that you are not looking for IPv6NAT does not exist as discussed in RFC4864 - Local Network Protection for IPv6. From owner-v6ops@ops.ietf.org Thu Jul 3 11:56:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EEA3A6959 for ; Thu, 3 Jul 2008 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGjxLcBbFQcA for ; Thu, 3 Jul 2008 11:56:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 069A13A690C for ; Thu, 3 Jul 2008 11:56:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETus-000F26-Rx for v6ops-data@psg.com; Thu, 03 Jul 2008 18:52:26 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETug-000F0d-56 for v6ops@ops.ietf.org; Thu, 03 Jul 2008 18:52:23 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id D4F04941; Thu, 3 Jul 2008 20:52:12 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: EricLKlein@softhome.net Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 21:52:10 +0300 User-Agent: KMail/1.9.9 Cc: Shin Miyakawa , v6ops@ops.ietf.org References: <20080704.011411.193726649.miyakawa@nttv6.jp> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807032152.11321.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le jeudi 3 juillet 2008 21:05:37 EricLKlein@softhome.net, vous avez =E9crit= =A0: > Shin Miyakawa writes: > > If so, I think that people will purchase "one IPv6 global address servi= ce > > for a host" and USE V6NAT to connect any device in their home network, > > because probably this service will be less expensive than > > "Prefix Delegated service for a routed CPE". > > That's too bad. > > There is no Nat in IPv6. See RFC4864 - Local Network Protection for IPv6 > for more details. I think Shin-san's point is that if PD delegation does not work=20 uniformly/satisfactorily enough, CPE vendors and ISPs will deploy IPv6 NATs= =20 rather than tell their customer "sorry you cannot access the Internet with= =20 more than one computer at a time". Whether that's a red herring, I will not debate here and now. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Thu Jul 3 12:34:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E405B3A6A1D for ; Thu, 3 Jul 2008 12:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C18ldeOfVvYn for ; Thu, 3 Jul 2008 12:34:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F176B3A69AD for ; Thu, 3 Jul 2008 12:34:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUWM-000JYx-HO for v6ops-data@psg.com; Thu, 03 Jul 2008 19:31:10 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUWI-000JYN-6m for v6ops@ops.ietf.org; Thu, 03 Jul 2008 19:31:08 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 08A7FADAD9; Thu, 3 Jul 2008 21:31:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EF712ADAD8; Thu, 3 Jul 2008 21:31:04 +0200 (CEST) Date: Thu, 3 Jul 2008 21:31:04 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080704.011411.193726649.miyakawa@nttv6.jp> Message-ID: References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, Shin Miyakawa wrote: > "Something that is involved in the delivery of a service", > can be an end user host device. > ^^^^^^ > > Or, how about any applications on the CPE router ? So, my vision of "CPE" is the same as the authors of the draft that started the discussion, a "CPE router". These are for me the same. A host is not a router (difference is that a router does IP forwarding, a host does not). > Please think about following picture. > > Access Concentorator <----- PPP or whatever upstream link -----> A CPE > that is "Something that is involved in the delivery of a service" > > This CPE may be a router or a host. there is no difference between > two of those from ISP point of view. Yes, and I think these need two different services. > Acutally, there are many service using just a PC to terminate ISP upstream. > So, why you exclude this case from (v6)CPE ? Because I don't want that model going forward, because I don't think that's going to be what the customer want. > If so, I think that people will purchase "one IPv6 global address > service for a host" and USE V6NAT to connect any device in their home > network, because probably this service will be less expensive than > "Prefix Delegated service for a routed CPE". That's too bad. Why would this be less expensive? I uses the same amount of ISP resources and could very well be less complicated for the ISP to deploy? There is no technical reason for it to be more expensive. > So, I don't like this idea... > "The customer will have to decide this at the time of purchase of the service." Well, I don't like the idea of end users connecting IPv6 only hosts directly to the ISP network, I want the customer to be required to have a router, and I don't want the customer to have the possibility to source packets in core IP space, and I don't want ISP routers to have IPs in the customer IP range. Personally, I want IPv6 native service to require the customer to have a CPE router, if they don't want that, then they can get IPv6 tunneled over 6to4, PPPoE, L2TP or alike, terminated at their computer. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 3 12:41:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458D03A67EF for ; Thu, 3 Jul 2008 12:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUkbiBweqEnV for ; Thu, 3 Jul 2008 12:41:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7935B3A6ACB for ; Thu, 3 Jul 2008 12:41:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUeh-000KTs-Gu for v6ops-data@psg.com; Thu, 03 Jul 2008 19:39:47 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUeO-000KRp-7l for v6ops@ops.ietf.org; Thu, 03 Jul 2008 19:39:37 +0000 X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="13154974" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2008 19:39:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m63JdR7D006857; Thu, 3 Jul 2008 15:39:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m63JdNx8003137; Thu, 3 Jul 2008 19:39:27 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 15:39:25 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 15:39:23 -0400 Message-ID: In-Reply-To: <200807032152.11321.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjdP+KNhLVYjnNsQaKcjN4UBI0KqQAAgc+A References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , Cc: "Shin Miyakawa" , X-OriginalArrivalTime: 03 Jul 2008 19:39:25.0046 (UTC) FILETIME=[7FB9D960:01C8DD44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2398; t=1215113967; x=1215977967; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20,=0A=20=20=20=20=20=20=20=20; bh=40swp2uCA4Jsv7B2QBVcY9UoXdh3XSCf7pk3up3fT0g=; b=QSU+m6cLRDWy59SrlPoweNxGSULrbAFGra0nQ9HyXwicdXTkmi/QXfEkce YQRuvnF7lfHIHK4A3+ge7fGjyh7cqJGLx4NaaZkQxvVd4Aw6vBickren7u/E VXWL0pYvGT; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Personally I and Wes both dislike using NAT for IPv6 since IPv6 doesn't = call for it. We will have to leave it to the Service Provider(s)(SP) to = comment on the cost model. Personally I prefer the SP dole out a PD. The = PD doling out from SP may have a hiccup or two depending upon who you = talk to at IETF but in general the deployment is expected to work. We = have personally tested such PD delegation to a embedded router in a = cable modem where the router modem was given a PD from DHCPv6 server = that lies in SP domain. This was some quick code we developed. The modem = obtained an IA_NA for its cable interface and obtained a IA_PD for it's = LAN interface. Then the PD was sub-delegated to SLAAC hosts behind the = modem. RIPv6 was used between the modem and cable aggregator to inject = routes from modem to the CMTS aggregator. We also tested IPv6 multicast = clients in such a deployment. Anyhow, indeed, even we do not want to debate such issues of one address = vs. PD, or things like if a PC needs to be given an IA_PD or not. Our = job is to produce a good document that works for, at least, both cable = and DSL, and then any network like FIOS.=20 Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of R=E9mi Denis-Courmont Sent: Thursday, July 03, 2008 2:52 PM To: EricLKlein@softhome.net Cc: Shin Miyakawa; v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Le jeudi 3 juillet 2008 21:05:37 EricLKlein@softhome.net, vous avez = =E9crit=A0: > Shin Miyakawa writes: > > If so, I think that people will purchase "one IPv6 global address=20 > > service for a host" and USE V6NAT to connect any device in their=20 > > home network, because probably this service will be less expensive=20 > > than "Prefix Delegated service for a routed CPE". > > That's too bad. > > There is no Nat in IPv6. See RFC4864 - Local Network Protection for=20 > IPv6 for more details. I think Shin-san's point is that if PD delegation does not work = uniformly/satisfactorily enough, CPE vendors and ISPs will deploy IPv6 = NATs rather than tell their customer "sorry you cannot access the = Internet with more than one computer at a time". Whether that's a red herring, I will not debate here and now. -- R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Thu Jul 3 12:56:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E613A682E for ; Thu, 3 Jul 2008 12:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uK+8Ubk+vwe for ; Thu, 3 Jul 2008 12:56:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 804B43A680E for ; Thu, 3 Jul 2008 12:56:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUtT-000MPD-W0 for v6ops-data@psg.com; Thu, 03 Jul 2008 19:55:04 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEUtP-000MOA-SR for v6ops@ops.ietf.org; Thu, 03 Jul 2008 19:55:01 +0000 X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="85077133" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 03 Jul 2008 19:54:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m63JsxSs017918 for ; Thu, 3 Jul 2008 12:54:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m63JstvP029119 for ; Thu, 3 Jul 2008 19:54:59 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 12:54:56 -0700 Received: from [192.168.1.104] ([10.21.119.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 12:54:56 -0700 Cc: Droms Ralph Message-Id: <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> From: Ralph Droms To: IPv6 Operations In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 15:54:54 -0400 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 03 Jul 2008 19:54:56.0435 (UTC) FILETIME=[AAE08830:01C8DD46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3087; t=1215114899; x=1215978899; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20; bh=wuqAVo+F5LQtA73YYXzh/jBckMi5fWlHDUBdSnq7+SY=; b=p8AxuxOBtBBX0B5wpTYY5d2C5d9xtXDgtM9CC0dSD/TsvPy2fqdlzFWhfj 2gCMfUj+ck3OvF1YmC7LLOfAa8CPXKJYJ9BivB8giHEBSGhC5FzfcmZsalAR c3oodYz+WK; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I think Shin is describing not so much a technical problem as an SP =20 business model problem. If SPs decide to continue the IPv4 practice =20 of charging by address, subscribers will, naturally, buy one address =20 and use NAT. If SPs use a business model based on IETF =20 recommendations and provide a prefix (shorter than /64) as basic =20 service (perhaps with variable pricing based on length of prefix?), =20 there won't be any motivation for NAT. - Ralph On Jul 3, 2008, at Jul 3, 2008,3:39 PM, Hemant Singh (shemant) wrote: > Personally I and Wes both dislike using NAT for IPv6 since IPv6 =20 > doesn't call for it. We will have to leave it to the Service =20 > Provider(s)(SP) to comment on the cost model. Personally I prefer =20 > the SP dole out a PD. The PD doling out from SP may have a hiccup or =20= > two depending upon who you talk to at IETF but in general the =20 > deployment is expected to work. We have personally tested such PD =20 > delegation to a embedded router in a cable modem where the router =20 > modem was given a PD from DHCPv6 server that lies in SP domain. This =20= > was some quick code we developed. The modem obtained an IA_NA for =20 > its cable interface and obtained a IA_PD for it's LAN interface. =20 > Then the PD was sub-delegated to SLAAC hosts behind the modem. RIPv6 =20= > was used between the modem and cable aggregator to inject routes =20 > from modem to the CMTS aggregator. We also tested IPv6 multicast =20 > clients in such a deployment. > > Anyhow, indeed, even we do not want to debate such issues of one =20 > address vs. PD, or things like if a PC needs to be given an IA_PD or =20= > not. Our job is to produce a good document that works for, at least, =20= > both cable and DSL, and then any network like FIOS. > > Hemant > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =20= > Behalf Of R=E9mi Denis-Courmont > Sent: Thursday, July 03, 2008 2:52 PM > To: EricLKlein@softhome.net > Cc: Shin Miyakawa; v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review > > Le jeudi 3 juillet 2008 21:05:37 EricLKlein@softhome.net, vous avez =20= > =E9crit : >> Shin Miyakawa writes: >>> If so, I think that people will purchase "one IPv6 global address >>> service for a host" and USE V6NAT to connect any device in their >>> home network, because probably this service will be less expensive >>> than "Prefix Delegated service for a routed CPE". >>> That's too bad. >> >> There is no Nat in IPv6. See RFC4864 - Local Network Protection for >> IPv6 for more details. > > I think Shin-san's point is that if PD delegation does not work =20 > uniformly/satisfactorily enough, CPE vendors and ISPs will deploy =20 > IPv6 NATs rather than tell their customer "sorry you cannot access =20 > the Internet with more than one computer at a time". > > Whether that's a red herring, I will not debate here and now. > > -- > R=E9mi Denis-Courmont > http://www.remlab.net/ > > From owner-v6ops@ops.ietf.org Thu Jul 3 13:49:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982793A6919 for ; Thu, 3 Jul 2008 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gykSGuc62KiH for ; Thu, 3 Jul 2008 13:49:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C06F3A68B4 for ; Thu, 3 Jul 2008 13:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEVgc-0002Rr-2i for v6ops-data@psg.com; Thu, 03 Jul 2008 20:45:50 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEVgY-0002RP-Nr for v6ops@ops.ietf.org; Thu, 03 Jul 2008 20:45:48 +0000 Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 4545426D30C; Thu, 3 Jul 2008 13:45:46 -0700 (PDT) Cc: IPv6 Operations Message-Id: From: David Conrad To: Ralph Droms In-Reply-To: <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Thu, 3 Jul 2008 13:45:45 -0700 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 3, 2008, at 12:54 PM, Ralph Droms wrote: > there won't be any motivation for NAT. Provider independence. Regards, -drc From owner-v6ops@ops.ietf.org Thu Jul 3 18:32:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA683A69C6 for ; Thu, 3 Jul 2008 18:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.28 X-Spam-Level: X-Spam-Status: No, score=-102.28 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NHpUVkB33-w for ; Thu, 3 Jul 2008 18:32:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34B9F3A6AB5 for ; Thu, 3 Jul 2008 18:31:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEa3S-000AiX-Gs for v6ops-data@psg.com; Fri, 04 Jul 2008 01:25:42 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEa3O-000Ahx-Q3 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 01:25:40 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id EA9D6BDC08; Fri, 4 Jul 2008 10:25:37 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id BE9DB6E358; Fri, 4 Jul 2008 10:25:37 +0900 (JST) Date: Fri, 04 Jul 2008 10:25:37 +0900 (JST) Message-Id: <20080704.102537.193760974.miyakawa@nttv6.jp> To: EricLKlein@softhome.net Cc: v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080704.011411.193726649.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > If so, I think that people will purchase "one IPv6 global address service > > for a host" and USE V6NAT to connect any device in their home network, > > because probably this service will be less expensive than > > "Prefix Delegated service for a routed CPE". > > That's too bad. > > > There is no Nat in IPv6. See RFC4864 - Local Network Protection for IPv6 > for more details. Eric, I know it. I just point out that some GLACELESS person can easily implement an IPv6 version of NAT to do something even it is prohibited in RFC. Of course, I also do not like this. So, as many people said to this mailing list I'd like to recommend to all the ISP to do prefix delegation to the customer. Again, that is the original motivation of mine when I wrote requirement for prefix delegation (RFC3769). At the sametime, even somebody does not like it, because RFC3484 is standard NOW, so I admit to say that any application on one router CPE is still recommeded to select its source address from addresses assigned to the WAN i/f. Especially, Mikael, how do you fix it ? This is still you have not answer yet. OK. Let me clarify what I want to say. I am recommending that following (A)+(B) as the way we go to allow all the implementation which is compatible with today's standard set can be compatible with the service. (A)A global IPv6 address is recommened to assign the WAN i/f to a CPE router or a host that terminates upstream link (B)Prefixes should be delegated by DHCPv6 to (especially) a CPE router Even if some ISP does not do assign global IPv6 address to the CPE, that's up to that ISP. But their customer should be noticed that some machine which is compatible IPv6 standard specification can not work correctly if that terminates upsteam link. Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt ------------------------------------------------------------------------------------- 5.3. Acquire IPv6 address and other configuration parameters The CPE Router must process RAs received on the WAN interface and as instructed by the RA message, acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. ------------------------------------------------------------------------------------- Best wishes, Shin Miyakawa From owner-v6ops@ops.ietf.org Thu Jul 3 18:53:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B779F3A685D for ; Thu, 3 Jul 2008 18:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA0xRmJMsS6l for ; Thu, 3 Jul 2008 18:53:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D417F3A6800 for ; Thu, 3 Jul 2008 18:53:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEaTL-000DlG-RN for v6ops-data@psg.com; Fri, 04 Jul 2008 01:52:27 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEaTI-000Dkn-51 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 01:52:25 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id C634FBDC21; Fri, 4 Jul 2008 10:52:23 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 90A526FCEE; Fri, 4 Jul 2008 10:52:23 +0900 (JST) Date: Fri, 04 Jul 2008 10:52:23 +0900 (JST) Message-Id: <20080704.105223.104107723.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080704.011411.193726649.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, > > Acutally, there are many service using just a PC to terminate ISP upstream. > > So, why you exclude this case from (v6)CPE ? > > Because I don't want that model going forward, because I don't think > that's going to be what the customer want. fmmm... Please note that I also do not like this and I do not recommend this model, but actually, at least in Japan, there are millions customer doing this today. Just because a bridged CPE is cheaper than a router CPE. We should swtich even those people to be v6 ready with less cost (no need to replace their CPE) to deploy IPv6 faster and step-by-step. > Well, I don't like the idea of end users connecting IPv6 only hosts > directly to the ISP network, and you do not like the sensor network..... I understand..... Shin Miyakawa From owner-v6ops@ops.ietf.org Thu Jul 3 19:45:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38073A682C for ; Thu, 3 Jul 2008 19:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSOeFgr24Q+D for ; Thu, 3 Jul 2008 19:44:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4C943A6813 for ; Thu, 3 Jul 2008 19:44:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEbEW-000Jcl-IB for v6ops-data@psg.com; Fri, 04 Jul 2008 02:41:12 +0000 Received: from [210.160.15.5] (helo=mgw1.noc.ntt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEbEJ-000JaS-Py for v6ops@ops.ietf.org; Fri, 04 Jul 2008 02:41:10 +0000 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id m642dw0Z003725 for ; Fri, 4 Jul 2008 11:40:58 +0900 (JST) Received: from mip3.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0K3G003C4NFQ48@ntt.com> for v6ops@ops.ietf.org; Fri, 04 Jul 2008 11:40:39 +0900 (JST) Date: Fri, 04 Jul 2008 11:40:15 +0900 From: "Tomohiro Nishitani" Subject: New I-D on Carrier Grade NAT To: v6ops@ops.ietf.org Message-id: <486D8D8F.1060009@ntt.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I submitted new draft on Carrier Grade NAT. "Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP" http://www.ietf.org/internet-drafts/draft-nishitani-cgn-00.txt Abstract of our draft is as follows: --- This document defines basic terminology for describing different types of carrier-grade Network Address Translation (NAT) behavior when handling Unicast UDP, TCP and ICMP. Developing carrier-grade NATs that meet this set of requirements increase transparency of data between carrier networks. --- Comments welcome. Thanks. Tomohiro Nishitani -- Tomohiro Nishitani Chief, Network Systems and Technologies, Innovative IP Architecture Center NTT Communications Corporation tomohiro.nishitani@ntt.com TEL: +81-3-6800-3214 From owner-v6ops@ops.ietf.org Thu Jul 3 21:32:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441123A6920 for ; Thu, 3 Jul 2008 21:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk-uf+7PRA-j for ; Thu, 3 Jul 2008 21:32:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EED63A6887 for ; Thu, 3 Jul 2008 21:32:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEcsd-0005Cd-PP for v6ops-data@psg.com; Fri, 04 Jul 2008 04:26:43 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEcsW-0005Bq-Ts for v6ops@ops.ietf.org; Fri, 04 Jul 2008 04:26:41 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 36E0DADAD9; Fri, 4 Jul 2008 06:26:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C888ADAD8; Fri, 4 Jul 2008 06:26:33 +0200 (CEST) Date: Fri, 4 Jul 2008 06:26:33 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080704.105223.104107723.miyakawa@nttv6.jp> Message-ID: References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.105223.104107723.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, Shin Miyakawa wrote: > Just because a bridged CPE is cheaper than a router CPE. In my market, almost everybody has a router CPE, if they have a CPE at all (in the ETTH with copper case, people often do not have a CPE at all, and if they do, it's a NAT box). I don't see the price difference of routed/bridged CPEs at all here. > We should swtich even those people to be v6 ready with less cost (no > need to replace their CPE) to deploy IPv6 faster and step-by-step. As stated, they can use a tunneled approach if they don't want to do it "for real". >> Well, I don't like the idea of end users connecting IPv6 only hosts >> directly to the ISP network, > > and you do not like the sensor network..... I understand..... Please elaborate. I don't understand why you're saying that I don't like sensor networks because I want a routed CPE. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 3 21:42:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161A43A6A1F for ; Thu, 3 Jul 2008 21:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eHN9E0yhN3Q for ; Thu, 3 Jul 2008 21:42:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E8663A6920 for ; Thu, 3 Jul 2008 21:42:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEd6V-0006xD-E4 for v6ops-data@psg.com; Fri, 04 Jul 2008 04:41:03 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEd6R-0006uP-6m for v6ops@ops.ietf.org; Fri, 04 Jul 2008 04:41:01 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 65F74ADAD9; Fri, 4 Jul 2008 06:40:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5C5CCADAD8; Fri, 4 Jul 2008 06:40:58 +0200 (CEST) Date: Fri, 4 Jul 2008 06:40:58 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: EricLKlein@softhome.net, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080704.102537.193760974.miyakawa@nttv6.jp> Message-ID: References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.102537.193760974.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, Shin Miyakawa wrote: > Especially, Mikael, how do you fix it ? This is still you have not answer yet. I don't write RFCs. I don't really read them a lot either, just when I absolutely need to. On the other hand, I know a lot about router architecture and network operational issues and I know what I think would be the best operational situation to have for IPv6 in 10 years, and that's why I'm advocating the solution I'm advocating. If you want to remove the merit of my proposal on the basis that I haven't supplied RFC quality text to support it, well, then the IETF process is broken because it doesn't listen to what the operational community has to say. I am supplying operational input here, not RFC proposals. > Even if some ISP does not do assign global IPv6 address to the CPE, > that's up to that ISP. If the draft doesn't put a strong emphesis on the POSSIBILITY of not assigning a WAN IP address (and how this case should be handled), most vendors will not implement it. > But their customer should be noticed that some machine which is compatible > IPv6 standard specification can not work correctly if that terminates upsteam link. I have no problem with that. Services always has restrictions and specifications. > Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt > > ------------------------------------------------------------------------------------- > 5.3. Acquire IPv6 address and other configuration parameters > > The CPE Router must process RAs received on the WAN interface and as > instructed by the RA message, acquire global IPv6 address for WAN > interface using SLAAC or DHCPv6. > ------------------------------------------------------------------------------------- I have no problem with this, apart from that it doesn't say what should be done if there is no WAN address received. I am not saying your solution shouldn't be done, I'm saying I want the possibility of both, and if these aren't included in material like this draft, my proposal won't be realistically possible anytime soon. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 3 23:39:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40283A6A62 for ; Thu, 3 Jul 2008 23:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjNVbQ3kg3+s for ; Thu, 3 Jul 2008 23:39:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A539B3A6A7D for ; Thu, 3 Jul 2008 23:39:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEesL-000LnY-AU for v6ops-data@psg.com; Fri, 04 Jul 2008 06:34:33 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEesH-000Ln6-7F for v6ops@ops.ietf.org; Fri, 04 Jul 2008 06:34:31 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m646XIHc013044; Fri, 4 Jul 2008 09:33:26 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 09:32:55 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 09:32:55 +0300 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Fri, 4 Jul 2008 09:32:54 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjdRCqNp1gO+MvpSFi2FnXN0bYRrgAVfVNw References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> From: To: , Cc: , , X-OriginalArrivalTime: 04 Jul 2008 06:32:55.0499 (UTC) FILETIME=[CAFA29B0:01C8DD9F] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, >So, my vision of "CPE" is the same as the authors of the draft=20 >that started the discussion, a "CPE router". These are for me=20 >the same. A host is not a router (difference is that a router=20 >does IP forwarding, a host does not). If the forwarding is the key differentiator, then isn't e.g. "host" computers running Microsoft Windows, Apple OS/X, and even certain mobile phones, also "routers" as they support "sharing of the network connection", which means forwarding packets from the uplink connection to local area network - possibly implementing DHCPv4 server, to allocate private IPv4 addresses for LAN, and NAT for address translation between LAN and uplink connection? If the "CPE router" would be defined as something that implements and executes routing protocols, has MIBs, is fully controllable by ISP then these hosts would not fit into that category.=20 Anyhow, in my mind a "host" is not so much of a name for a category of devices, but rather a behavioral pattern of a node. At any given moment a node can start to behave as a "router" (if that is defined only as doing packet forwarding). For a network the node may still look like a "host", if the node does this transparently for the network (i.e. with help of NAT).=20 >> This CPE may be a router or a host. there is no difference=20 >between two=20 >> of those from ISP point of view. > >Yes, and I think these need two different services. .... >Well, I don't like the idea of end users connecting IPv6 only=20 >hosts directly to the ISP network, I want the customer to be=20 >required to have a router, and I don't want the customer to=20 >have the possibility to source packets in core IP space, and I=20 >don't want ISP routers to have IPs in the customer IP range. I did not think that was the idea either? If the end hosts would use DHCPv6 PD, would that be an act of sourcing packets to IP core? If so, could the delegating DHCPv6 server locate somewhere where "hosts" could safely (from ISP point of view) talk? The talking to ISP core is one differentiator, then we might(?) have: (1) CPE router: - allowed to directly source packets to ISP core [host]---[CPE router]---[ISP]---[Internet] (2) "Host router": - not able to directly source packets to ISP core, but still able to forward packets and use DHCPv6 PD [host]---[host router]---[CPE router/access concentrator]---[ISP]---[Internet] The (1) case is what you are aiming I believe, and the (2) is what I'm trying to describe. An example of case (1) would be a DSL box at home/small office, and an example of case (2) would be a cellular device that: - connects with point-to-point link to operator's access concentrator (e.g. GGSN), and gets a /64 prefix for itself (SLAAC) - uses DHCPv6 PD to get more prefixes, and announces these prefixes to LAN - possibly implements DHCPv6 relay in order to enable other devices in LAN to utilize DHCPv6 PD as well Best regards, Teemu From owner-v6ops@ops.ietf.org Fri Jul 4 00:09:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C919C3A67D7 for ; Fri, 4 Jul 2008 00:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6ZD8V9jfL+8 for ; Fri, 4 Jul 2008 00:09:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E26E3A67B5 for ; Fri, 4 Jul 2008 00:09:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEfO5-0000Or-8y for v6ops-data@psg.com; Fri, 04 Jul 2008 07:07:21 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEfO0-0000NI-8z for v6ops@ops.ietf.org; Fri, 04 Jul 2008 07:07:19 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0D633ADAD9; Fri, 4 Jul 2008 09:07:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F2BC9ADAD8; Fri, 4 Jul 2008 09:07:10 +0200 (CEST) Date: Fri, 4 Jul 2008 09:07:10 +0200 (CEST) From: Mikael Abrahamsson To: teemu.savolainen@nokia.com cc: miyakawa@nttv6.jp, shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, teemu.savolainen@nokia.com wrote: > If the forwarding is the key differentiator, then isn't e.g. "host" > computers running Microsoft Windows, Apple OS/X, and even certain mobile > phones, also "routers" as they support "sharing of the network > connection", which means forwarding packets from the uplink connection > to local area network - possibly implementing DHCPv4 server, to allocate > private IPv4 addresses for LAN, and NAT for address translation between > LAN and uplink connection? Correct. > If the "CPE router" would be defined as something that implements and > executes routing protocols, has MIBs, is fully controllable by ISP then > these hosts would not fit into that category. For me, for instance a D-link 604 (NAT gateway) is a CPE router, if that helps. It doesn't do SNMP, no routing protocols, but some of those are provisionable via DHCP (will tftp download conf files). > Anyhow, in my mind a "host" is not so much of a name for a category of > devices, but rather a behavioral pattern of a node. At any given moment > a node can start to behave as a "router" (if that is defined only as > doing packet forwarding). For a network the node may still look like a > "host", if the node does this transparently for the network (i.e. with > help of NAT). Yes, I realise this, but I want my native IPv6 service offering to require a "router" class device, even if it means that this "router" only forwards traffic logically between the WAN link-local interface and it's internal loopback address (DHCPv6-PD assigned space). > I did not think that was the idea either? If the end hosts would use > DHCPv6 PD, would that be an act of sourcing packets to IP core? If so, > could the delegating DHCPv6 server locate somewhere where "hosts" could > safely (from ISP point of view) talk? > > The talking to ISP core is one differentiator, then we might(?) have: Hm, the problem is that i don't want customers in core IP space, and I don't want core in customer IP space. > (1) CPE router: > - allowed to directly source packets to ISP core > [host]---[CPE router]---[ISP]---[Internet] What adresses would be used between CPE router and ISP? I would like it to be link-local only. > (2) "Host router": > - not able to directly source packets to ISP core, but still able to > forward packets and use DHCPv6 PD > [host]---[host router]---[CPE router/access > concentrator]---[ISP]---[Internet] > > The (1) case is what you are aiming I believe, and the (2) is what I'm > trying to describe. Sounds about right, if (1) CPE-router <-> ISP is link-local. > An example of case (1) would be a DSL box at home/small office, and an > example of case (2) would be a cellular device that: > - connects with point-to-point link to operator's access concentrator > (e.g. GGSN), and gets a /64 prefix for itself (SLAAC) > - uses DHCPv6 PD to get more prefixes, and announces these prefixes to > LAN > - possibly implements DHCPv6 relay in order to enable other devices in > LAN to utilize DHCPv6 PD as well Yes, that sounds about right, but what adress space is used on the p-t-p link? Is that the /64? That would mean that the GGSN IP adress in this space is globally reachable, with the security implications that brings. Then again, I think tunneled approach is suboptimal as well, it usually involves CPU/network processors which have fairly low performance (compared to simple L3 switch devices using ASICs), so they can probably get into trouble even if the customer space is DDOSed anyway, and have to incorporate means to protect against that. A cheap and efficient service delivery or IPv6 for me is: [host]-PD-[CPE router]-ll-[L3 switch]-core The L2 and L3 device might be the same device, ie a L2/L3 switch with IPv6 capability, with either VDSL2 or Ethernet PHY. It will most likely have limited TCAM space (might be 1024 entries or something like that), does forwarding using ASICs and very limited CPU resources, thus the reason why I want to protect it from IP packets from the global Internet. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 4 00:24:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D023A67EE for ; Fri, 4 Jul 2008 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHN5c57tg2Uq for ; Fri, 4 Jul 2008 00:24:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B4623A6ABF for ; Fri, 4 Jul 2008 00:24:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEfd5-0003bJ-Q0 for v6ops-data@psg.com; Fri, 04 Jul 2008 07:22:51 +0000 Received: from [217.6.95.237] (helo=tcmail23.telekom.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEfd2-0003af-3d for v6ops@ops.ietf.org; Fri, 04 Jul 2008 07:22:50 +0000 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 4 Jul 2008 09:22:45 +0200 Received: from S4DE9JSAACY.ost.t-com.de ([10.125.177.233]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 09:22:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: new draft on IPv6 CPE router available for review Date: Fri, 4 Jul 2008 09:22:45 +0200 Message-Id: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: RE: new draft on IPv6 CPE router available for review Thread-index: AcjdRFC3qYuJ6fcuTBKJtXcguh3BtwAYYVkA References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> From: "Bonness, Olaf" To: , Cc: , , X-OriginalArrivalTime: 04 Jul 2008 07:22:45.0510 (UTC) FILETIME=[C129A260:01C8DDA6] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> Acutally, there are many service using just a PC to terminate ISP = upstream. >> So, why you exclude this case from (v6)CPE ? > > Because I don't want that model going forward, because I don't think = that's going to be what the customer want. You might not like this model but it's still reality and not clear until = when it will vanish. >> So, I don't like this idea... >> "The customer will have to decide this at the time of purchase of the = service." > Well, I don't like the idea of end users connecting IPv6 only hosts = directly to the ISP network, I want the customer to be required to have = a router, and I don't want the customer to have the possibility to = source packets in core IP space, and I don't want ISP routers to have = IPs in the customer IP range. Look above. Who will force the customers to buy a new DSL-box or CPE? = Nobody can. Agree regarding "ISP routers to have IPs in the customer IP range." Cu Olaf From owner-v6ops@ops.ietf.org Fri Jul 4 00:55:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3775D3A6B21 for ; Fri, 4 Jul 2008 00:55:55 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNiwPe6i7v3L for ; Fri, 4 Jul 2008 00:55:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61D5C3A67B5 for ; Fri, 4 Jul 2008 00:55:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEg4l-0007H9-Rn for v6ops-data@psg.com; Fri, 04 Jul 2008 07:51:27 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEg4g-0007GE-SM for v6ops@ops.ietf.org; Fri, 04 Jul 2008 07:51:25 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id F3EA6ADAD9; Fri, 4 Jul 2008 09:51:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E7EC7ADAD8; Fri, 4 Jul 2008 09:51:21 +0200 (CEST) Date: Fri, 4 Jul 2008 09:51:21 +0200 (CEST) From: Mikael Abrahamsson To: "Bonness, Olaf" cc: miyakawa@nttv6.jp, shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, Bonness, Olaf wrote: > You might not like this model but it's still reality and not clear until > when it will vanish. I don't want it to vanish, but I do want devices that support my model. I am not trying to make the standard model today (RA) to go away, but I want to be able to design a service per what I have written before, and that there are devices in the market that support it. > Look above. Who will force the customers to buy a new DSL-box or CPE? > Nobody can. For new deployments it should be ok. I'd say CPE routers are often churned out over 3-5 years. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 4 01:49:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4E33A69AB for ; Fri, 4 Jul 2008 01:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGQPD6EtWw9y for ; Fri, 4 Jul 2008 01:49:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76FC23A6B42 for ; Fri, 4 Jul 2008 01:49:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEgwM-000FML-HU for v6ops-data@psg.com; Fri, 04 Jul 2008 08:46:50 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEgwI-000FLp-2q for v6ops@ops.ietf.org; Fri, 04 Jul 2008 08:46:47 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id AA2B9BDC21; Fri, 4 Jul 2008 17:46:45 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 7BD236E358; Fri, 4 Jul 2008 17:46:45 +0900 (JST) Date: Fri, 04 Jul 2008 17:46:45 +0900 (JST) Message-Id: <20080704.174645.71101066.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: EricLKlein@softhome.net, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080704.102537.193760974.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, > If you want to remove the merit of my proposal on the basis that I haven't > supplied RFC quality text to support it, well, then the IETF process is > broken because it doesn't listen to what the operational community has to > say. I am supplying operational input here, not RFC proposals. No, no. at least, as I said, I think your input is quite important and usuful. But at the same time, please do not think that you're the ONLY person supplying operational input here. Please be noticed that we NTT is also one of ISPs have a lot of operational experiences for IPv6(and of course IPv4), has already deploying commercial IPv6 services at huge scale and I am supplying operational input here from our real operation and RFC proposals. === Also please do not disparage IETF activities and Please have respect for the standardization. If you just say what you want and ask somebody else to modify the text so that it should be compatible with YOUR opinion, I don't think that's fair. > > Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt > > > > ------------------------------------------------------------------------------------- > > 5.3. Acquire IPv6 address and other configuration parameters > > > > The CPE Router must process RAs received on the WAN interface and as > > instructed by the RA message, acquire global IPv6 address for WAN > > interface using SLAAC or DHCPv6. > > ------------------------------------------------------------------------------------- > > I have no problem with this, apart from that it doesn't say what should be > done if there is no WAN address received. Fmm.. sounds strange.. because according the above text, the CPE Router must acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. There is no possiblity to have no WAN address received, isn't it ? > I am not saying your solution shouldn't be done, I'm saying I want the > possibility of both, I see. OK Then, how about like this ? (This is actually just an idea. I think that Wes and Hemant are able to write better text than mine...) The CPE can acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. In this case, The CPE can be anything, a router CPE, a host, strong host model or week host model, following RFC3484 recommendation or even not. If operator that the CPE is going to connect, does not assign any global IPv6 address for WAN interface, there is a limitation on CPE architecture so that source address on it should be selected from PDed address which is not recommended in RFC3484. Best wishes, Shin Miyakawa From owner-v6ops@ops.ietf.org Fri Jul 4 03:04:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAFF3A6B52 for ; Fri, 4 Jul 2008 03:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU0riNIYqEZ9 for ; Fri, 4 Jul 2008 03:04:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A99B73A6B39 for ; Fri, 4 Jul 2008 03:04:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEi5i-000Pls-Qf for v6ops-data@psg.com; Fri, 04 Jul 2008 10:00:34 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEi5f-000Pl9-6m for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:00:33 +0000 Received: (qmail 11775 invoked by uid 417); 4 Jul 2008 10:00:27 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:00:27 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:00:27 -0600 References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: Mikael Abrahamsson Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:00:27 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael Abrahamsson writes: > > Well, I don't like the idea of end users connecting IPv6 only hosts > directly to the ISP network, I want the customer to be required to have a > router, and I don't want the customer to have the possibility to source > packets in core IP space, and I don't want ISP routers to have IPs in the > customer IP range. > > Personally, I want IPv6 native service to require the customer to have a > CPE router, if they don't want that, then they can get IPv6 tunneled over > 6to4, PPPoE, L2TP or alike, terminated at their computer. > This model will not work in the Cellular or Mobile worlds where the end device is a phone or mini internet device (MID). These will connect directly to the radio switch and will be aggregated into the network there. In the case of WiMAX or HSPDA this could be any of the next generation (out in this quarter) Intel ATOM, GTC, Nvidia, or other chip set based portable devices. These will be able to connect to WiMAX or GSM, EVDO, 3G, etc. network directly. So they will be (by definition) routers as well as end user devices. If the intention for the scope of this document discounts these devices (which currently out number desk top PCs almost 2 to 1) then the document is of too narrow a scope. Eric From owner-v6ops@ops.ietf.org Fri Jul 4 03:04:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DABB43A6B52 for ; Fri, 4 Jul 2008 03:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+2VH-zyDxv0 for ; Fri, 4 Jul 2008 03:04:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1B543A6B0D for ; Fri, 4 Jul 2008 03:04:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEi8p-0000HS-64 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:03:47 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEi8l-0000Gt-Mh for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:03:45 +0000 Received: (qmail 14643 invoked by uid 417); 4 Jul 2008 10:03:26 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:03:26 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:03:26 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> In-Reply-To: <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> From: EricLKlein@softhome.net To: Ralph Droms Cc: IPv6 Operations Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:03:26 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ralph Droms writes: > I think Shin is describing not so much a technical problem as an SP > business model problem. If SPs decide to continue the IPv4 practice of > charging by address, subscribers will, naturally, buy one address and use > NAT. If SPs use a business model based on IETF recommendations and > provide a prefix (shorter than /64) as basic service (perhaps with > variable pricing based on length of prefix?), there won't be any > motivation for NAT. > Ralph, If this business model happens then I expect to see some sort of extension of the IPv4 NAT models with v6 prefixes, and this will lead to breaking the net worse than NAT (and multiple nested NATs) do today. Eric From owner-v6ops@ops.ietf.org Fri Jul 4 03:07:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BA83A6AF8 for ; Fri, 4 Jul 2008 03:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8fV80FmuXS0 for ; Fri, 4 Jul 2008 03:07:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0EC743A6A82 for ; Fri, 4 Jul 2008 03:07:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiBx-0000rg-Et for v6ops-data@psg.com; Fri, 04 Jul 2008 10:07:01 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiBt-0000o2-RD for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:06:59 +0000 Received: (qmail 17517 invoked by uid 417); 4 Jul 2008 10:06:05 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:06:05 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:06:05 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> In-Reply-To: From: EricLKlein@softhome.net To: David Conrad Cc: IPv6 Operations Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:06:05 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David Conrad writes: > On Jul 3, 2008, at 12:54 PM, Ralph Droms wrote: >> there won't be any motivation for NAT. > > Provider independence. > This independence would be as easily served by changing the v6 prefix and keeping the /64 addresses the same. This kind of renumbering has been built into v6. While keeping the old thinking of NAT kills the end-to-end concept of v6 and hurts many applications that needed work arounds in v4 in order to work. We killed v6NAT once, let's not resurrect it again. From owner-v6ops@ops.ietf.org Fri Jul 4 03:09:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CB83A6B0D for ; Fri, 4 Jul 2008 03:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtIuVyO8-L9X for ; Fri, 4 Jul 2008 03:09:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF1623A69CF for ; Fri, 4 Jul 2008 03:09:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiE1-0001FN-H0 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:09:09 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiDx-0001Er-Us for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:09:07 +0000 Received: (qmail 20023 invoked by uid 417); 4 Jul 2008 10:08:58 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:08:58 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:08:58 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.102537.193760974.miyakawa@nttv6.jp> In-Reply-To: <20080704.102537.193760974.miyakawa@nttv6.jp> From: EricLKlein@softhome.net To: Shin Miyakawa Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:08:58 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Shin Miyakawa writes: > If so, I think that people will purchase "one IPv6 global address service >> > for a host" and USE V6NAT to connect any device in their home network, >> > because probably this service will be less expensive than >> > "Prefix Delegated service for a routed CPE". >> > That's too bad. >> > >> There is no Nat in IPv6. See RFC4864 - Local Network Protection for IPv6 >> for more details. > > Eric, I know it. > I just point out that some GLACELESS person can easily implement > an IPv6 version of NAT to do something even it is prohibited in RFC. > Of course, I also do not like this. Yes, but that does not mean that it will work with other applications that are RFC compliant. > So, as many people said to this mailing list > I'd like to recommend to all the ISP to do prefix delegation to the customer. > Again, that is the original motivation of mine > when I wrote requirement for prefix delegation (RFC3769). This still seems like the best solution. > At the sametime, even somebody does not like it, because RFC3484 is standard NOW, > so I admit to say that any application on one router CPE is still recommeded to > select its source address from addresses assigned to the WAN i/f. > > Especially, Mikael, how do you fix it ? This is still you have not answer yet. > > OK. Let me clarify what I want to say. > > I am recommending that following (A)+(B) as the way we go > to allow all the implementation which is compatible with today's standard set > can be compatible with the service. > > (A)A global IPv6 address is recommened to assign the WAN i/f to a CPE router or a > host that terminates upstream link > (B)Prefixes should be delegated by DHCPv6 to (especially) a CPE router > > Even if some ISP does not do assign global IPv6 address to the CPE, > that's up to that ISP. > But their customer should be noticed that some machine which is compatible > IPv6 standard specification can not work correctly if that terminates upsteam link. > Agreed From owner-v6ops@ops.ietf.org Fri Jul 4 03:19:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DD13A6B3E for ; Fri, 4 Jul 2008 03:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grU2LJ0ApBr5 for ; Fri, 4 Jul 2008 03:19:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F6523A69CF for ; Fri, 4 Jul 2008 03:19:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiMV-0002YW-B2 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:17:55 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiMI-0002X8-0J for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:17:52 +0000 Received: (qmail 28127 invoked by uid 417); 4 Jul 2008 10:17:00 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:17:00 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:17:00 -0600 References: <486D8D8F.1060009@ntt.com> In-Reply-To: <486D8D8F.1060009@ntt.com> From: EricLKlein@softhome.net To: "Tomohiro Nishitani" Cc: v6ops@ops.ietf.org Subject: Re: New I-D on Carrier Grade NAT Date: Fri, 04 Jul 2008 04:17:00 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Tomohiro Nishitani writes: > Hi, > > I submitted new draft on Carrier Grade NAT. > > "Carrier Grade Network Address Translator (NAT) Behavioral Requirements > for Unicast UDP, TCP and ICMP" > > http://www.ietf.org/internet-drafts/draft-nishitani-cgn-00.txt > > Abstract of our draft is as follows: > > --- > This document defines basic terminology for describing different > types of carrier-grade Network Address Translation (NAT) behavior > when handling Unicast UDP, TCP and ICMP. Developing carrier-grade > NATs that meet this set of requirements increase transparency of data > between carrier networks. > --- As much as I am all for killing NAT as soon as we can, I understand the potential need for such a device as currently carriers are doing just this using multiple devices (and frequently nesting NATs). I would prefer that the Abstract was changed to the following: This document defines basic terminology for describing different\types of carrier-grade IPv4 Network Address Translation (NAT) behavior when handling Unicast UDP, TCP and ICMP. Developing carrier-grade NATs that meet this set of requirements increase transparency of data between carrier networks. Where there is an emphasis on the fact that this is IPv4 only, not a backdoor for bringing NAT into v6. I also think you need to consider the requirements for non-stationary devices as these are starting to be more common and will complicate CGN to no end as they move from one cell site to another or into a new carrier while trying to maintain their IP session (most critical if it is UDP based). Eric Eric From owner-v6ops@ops.ietf.org Fri Jul 4 03:27:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6303A6B3E for ; Fri, 4 Jul 2008 03:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uyxQM6jSQVI for ; Fri, 4 Jul 2008 03:27:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B2803A6929 for ; Fri, 4 Jul 2008 03:27:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiUi-0003j5-Hg for v6ops-data@psg.com; Fri, 04 Jul 2008 10:26:24 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEiUf-0003i2-0W for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:26:22 +0000 Received: (qmail 4500 invoked by uid 417); 4 Jul 2008 10:25:39 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:25:39 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:25:39 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.102537.193760974.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: Mikael Abrahamsson Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:25:39 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael Abrahamsson writes: > On Fri, 4 Jul 2008, Shin Miyakawa wrote: > >> Especially, Mikael, how do you fix it ? This is still you have not answer >> yet. > > I don't write RFCs. I don't really read them a lot either, just when I > absolutely need to. On the other hand, I know a lot about router > architecture and network operational issues and I know what I think would > be the best operational situation to have for IPv6 in 10 years, and that's > why I'm advocating the solution I'm advocating. > > If you want to remove the merit of my proposal on the basis that I haven't > supplied RFC quality text to support it, well, then the IETF process is > broken because it doesn't listen to what the operational community has to > say. I am supplying operational input here, not RFC proposals. > This is fine, if there is a real need the text can be edited to match required format. The real questions are: 1. Is this really a need? 2. If so for all IPv6 end devices or just CPE routers that have other devices aggregated to them via copper, fiber, wireless? 3. What about other devices that act as a router but are the actual end-use device? Do we ignore them, create a diffrent RFC and then reference it? 4. Is there a consensus that these are worth the WG taking up and dealing with? > >> Again, so I like the following original text of >> draft-wbeebee-ipv6-cpe-router-00.txt >> >> ------------------------------------------------------------------------- >> ------------ >> 5.3. Acquire IPv6 address and other configuration parameters >> >> The CPE Router must process RAs received on the WAN interface and as >> instructed by the RA message, acquire global IPv6 address for WAN >> interface using SLAAC or DHCPv6. >> ------------------------------------------------------------------------- >> ------------ > > I have no problem with this, apart from that it doesn't say what should be > done if there is no WAN address received. Can you propose an addition or solution? From owner-v6ops@ops.ietf.org Fri Jul 4 03:37:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5A43A6929 for ; Fri, 4 Jul 2008 03:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrKHy4NTOvBC for ; Fri, 4 Jul 2008 03:37:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E42443A6CF6 for ; Fri, 4 Jul 2008 03:37:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEidV-0005Hj-SS for v6ops-data@psg.com; Fri, 04 Jul 2008 10:35:29 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEidG-0005DN-WD for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:35:17 +0000 Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 7F91835A525; Fri, 4 Jul 2008 12:35:12 +0200 (CEST) Message-ID: <486DFCDF.8000702@spaghetti.zurich.ibm.com> Date: Fri, 04 Jul 2008 12:35:11 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: IETF CC: IETF Ops Subject: Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers) References: <013301c8dca5$22ca0a80$685e1f80$@us> <20080703054752.GM6185@lark.songbird.com> <20080703134655.GA17472@boreas.isi.edu> <486CDD05.10802@bbiw.net> <20080704062213.GA32192@lark.songbird.com> In-Reply-To: <20080704062213.GA32192@lark.songbird.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6A514F058DA1360022D66BE" X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6A514F058DA1360022D66BE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable (That draft would basically be a BCP, cc'd to v6ops where this belongs) kent@songbird.com wrote: > I think I could have been clearer with my message.[..] > Instead, I was presenting what I thought was an interesting example of = a=20 > subtle problem that can come up in ipv6 deployment. =20 I think it is a good idea to document common examples of how one could=20 setup a datacenter, or at least a small network. One thing to note is=20 that people should stop thinking in IPv4 terms. Yes, IPv6 is in effect=20 only more bits, but those bits belong to you and you can use them to do=20 all kinds of new interesting setups as you are not limited any more to=20 what you are doing with respect to address usage. Generally the ideas for a network I follow are: - autoconfig (or if wanted DHCPv6) for hosts (client+server) Turn off RFC3041 on all hosts (it is just annoying IMHO :) - for servers use the autoconfigged address for 'management' purposes - for services, use a /64 per service, or just use one with all services. Call these 'service prefixes'. Thus DNS could be ::53/64. Then you can use quagga or similar to= do OSPF/BGP/whatsuitesyou on the server and announce that it is able to serve DNS, just announce the ::53/64 (or /128 or whatever) everything in the network can use ::53 for DNS resolutions. Of course the side-effect is that you can just setup another host and= do the same trick, then have some scripting on those hosts to check if the service is actually working and retract announces when needed.= Voila a very nice distributed-by-anycast-local-service setup. Repeat this trick for any service you want. Remember, if your service= becomes busy, just add another box, or just move it to another etc. Also, if the MAC of the box dies, it is unrelated to the actual service and outages will be kept to a minimum. This of course works for http-proxies/smtp-servers/imap-servers etc. Note that for the service prefix, as it is generally only for serving= local clients, one could quite well use a ULA prefix, which will thus will never change even if changing upstreams or disconnecting etc. YMMV on that one though. Note that you just need a route to that= ULA prefix and can avoid clients having to have a secondary address in that range. Benefit for ULA prefix is of course that automatically= it will be hard for external sites (The Big Bad Internet) to reach these services as they don't easily get a working TCP bidirectional path to it. - Forward/Reverse DNS, I simply register the EUI-64's in DNS, hardcoded. One can of course with DHCPv6/(Secure-)DDNS also do it dynamically if wanted. If you are a Windows-shop Active Directory can also help you out in this area. It depends a bit on what you require, how many hosts you have and also how much control you have over these hosts. - DNS resolving is configured either static (we have the service prefix= which will most likely never change anyway if lucky) or you could simply do it using DHCPv4||v6. - Don't forget to properly configure your firewalls ;) Another note for a lot of people who use a VPN when working from home=20 but where the VPN is only IPv4-capable. When you are at home you will=20 have a (public) IPv4 address, an IPv6 address and a VPN-IPv4 address,=20 but no VPN-IPv6 address, thus most likely the Internet-IPv6 address will = thus hit the firewall and die off there. Thus if you have=20 firewalled@work, AAAA's in the DNS you won't be able to reach them and=20 hilarity ensues as this will cause lots of connections delays due to=20 most firewalls dropping connections, not rejecting them. Thanks to our=20 marvelous IS team here though I found out that ISATAP is a perfect=20 solution to this problem as it automatically sets up tunnels locally=20 when needed, as the VPN IPv4 is 'local' the tunnel works and you can=20 reach resources which would be firewalled when using the global address. = Which reminds me to quickly write&submit another draft I had in my head=20 on that subject. > The mailserver in question uses a default redhat enterprise build (actu= ally > centos). ipv6 is either enabled by default, or just has a single check= box, > with no further information. The fact that ipv6 is enabled so triviall= y > carries the implication that just enabling ipv6 won't actually damage > anything.=20 Unfortunately if people just click they will open a lot of things that=20 are not needed and can cause issues, for them bot more importantly for=20 others. As that means that the box is not properly configured, clearly=20 as the 'admin' didn't care, why would anyone then even care to receive=20 mail/traffic from them? > Now I know different. Just enabling ipv6 on an otherwise correctly > configured and functioning ipv4 box *will* cause damage -- it will caus= e mail > that would have been delivered to not be delivered. I could be wrong, = but > this strikes me as a trap that lots of people could fall into.=20 People who make those mistakes are the same people who don't read the=20 manual/readme/mustread etc, unfortunately that also means that they will = never ever read a BCP even if someone wrote one up. > As I mentioned, my servers actually do reject mail if they can't find a= =20 > reverse dns for the senders IP. Some of those servers use ipv6; in lig= ht of all=20 > this I'm going to have to rethink that decision. For a server, the=20 > combination of enabling ipv6 and using this particular anti-spam techni= que=20 > may drastically increase the number of false positives -- especially as= ipv6=20 > gets more widely deployed. As I mentioned, servers/hosts which are not properly set up, are indeed=20 just that, not properly set up, as such they don't even deserve my time. Note also that if you open this loophole that for spammers it becomes=20 really easy to start spamming you from any host on the planet, and using = at least a /48 per IPv4 address and a large chunk of the Teredo /32 to=20 choose their source addresses from. Note also that it is quite difficult = to contact those people in general, because that is what they want, not=20 to be contacted. Thus my summary on this: if they don't care, why should you care? :) Greets, Jeroen --------------enigE6A514F058DA1360022D66BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIbfzfKaooUjM+fCMRAusKAKCMNTTB7QB+sVNDr5XWSlm4LWKWDwCeO4dJ 559XlUq3amfLqDrlIXxqbgY= =tWtb -----END PGP SIGNATURE----- --------------enigE6A514F058DA1360022D66BE-- From owner-v6ops@ops.ietf.org Fri Jul 4 03:47:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6A33A6C11 for ; Fri, 4 Jul 2008 03:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw517OP2GYr4 for ; Fri, 4 Jul 2008 03:47:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1E473A6B6B for ; Fri, 4 Jul 2008 03:47:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEino-00070l-F6 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:46:08 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEinf-0006zc-P1 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:46:06 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id E2A0FADADC; Fri, 4 Jul 2008 12:45:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D6C5CADAD9; Fri, 4 Jul 2008 12:45:58 +0200 (CEST) Date: Fri, 4 Jul 2008 12:45:58 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: EricLKlein@softhome.net, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080704.174645.71101066.miyakawa@nttv6.jp> Message-ID: References: <20080704.102537.193760974.miyakawa@nttv6.jp> <20080704.174645.71101066.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, Shin Miyakawa wrote: > But at the same time, please do not think that you're the ONLY person > supplying operational input here. Of course not. > Also please do not disparage IETF activities and > Please have respect for the standardization. I have great respect for the standardization, which is why I'm spending hours here trying to influence it. > If you just say what you want and ask somebody else to modify the text > so that it should be compatible with YOUR opinion, I don't think that's fair. Well, I prefer to have a discussion and achieve consensus about what needs to be done, before starting to modify documents. >>> Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt >>> >>> ------------------------------------------------------------------------------------- >>> 5.3. Acquire IPv6 address and other configuration parameters >>> >>> The CPE Router must process RAs received on the WAN interface and as >>> instructed by the RA message, acquire global IPv6 address for WAN >>> interface using SLAAC or DHCPv6. >>> ------------------------------------------------------------------------------------- >> >> I have no problem with this, apart from that it doesn't say what should be >> done if there is no WAN address received. > > Fmm.. sounds strange.. because according the above text, the CPE Router must > acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. > There is no possiblity to have no WAN address received, isn't it ? Exactly, which is why I have a problem with it. I want the option of not assigning a WAN IPv6 address. I might misunderstand the context here, if this is not applicable in this part of the text, then I am sorry and we can move on. Does the wording allow for "link-local only for WAN" and DHCPv6-PD, or does it need to be changed for this to be ok? > I see. OK Then, how about like this ? (This is actually just an idea. I think > that Wes and Hemant are able to write better text than mine...) > > The CPE can acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. > In this case, The CPE can be anything, a router CPE, a host, strong host model or > week host model, following RFC3484 recommendation or even not. > If operator that the CPE is going to connect, does not assign > any global IPv6 address for WAN interface, there is a limitation on CPE > architecture so that source address on it should be selected from > PDed address which is not recommended in RFC3484. This writing is technically correct in aspect to what I want, but the writing (at least to me) implies that not following RFC3484 in the "global IPv6 WAN address" aspect is a bad idea, which I think is a bit biased. If you cut out "which is not recommended in RFC3484." then it becomes more neutral. The writing in RFC3484 states: "They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection." So basically, my proposal doesn't violate RFC3484, even though it goes against the recommendations in it? I looked thru RFC3484 again just to make sure, and my 10 minute reading of it didn't yield anything my proposal de facto violates. I don't really understand why you so strongly oppose my idea? It doesn't stop or change any existing functionality, it just brings in requirement for new functionality (or not really new, it's rather describes a combination of functionalities already present in order to achieve a specific operational goal)? If the ISP highly values to have IP separation of customer IP space and ISP IP space, then they can deploy along my proposal, if they don't, well, then they can go along the lines of RFC3484 and indeed assign a globally routable IPv6 address to the WAN interface of the customer host/router. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 4 03:54:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E073A6B20 for ; Fri, 4 Jul 2008 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4GNcz2sNZoG for ; Fri, 4 Jul 2008 03:54:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D28253A6B18 for ; Fri, 4 Jul 2008 03:54:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEitf-0007i7-85 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:52:11 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEitb-0007hB-4S for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:52:09 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id AF06AADADF; Fri, 4 Jul 2008 12:52:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A5DEBADADD; Fri, 4 Jul 2008 12:52:05 +0200 (CEST) Date: Fri, 4 Jul 2008 12:52:05 +0200 (CEST) From: Mikael Abrahamsson To: EricLKlein@softhome.net cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.102537.193760974.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, EricLKlein@softhome.net wrote: > 2. If so for all IPv6 end devices or just CPE routers that have other > devices aggregated to them via copper, fiber, wireless? My requirement is only for home gateway devices, I don't want to change the behaviour of end-hosts. My proposal is also to not remove any functionality or limit it, just to add. I am not aware of my proposal being in violation of any current wording in any document, but if it is, I volunteer to participate in work in getting it fixed. > 3. What about other devices that act as a router but are the actual end-use > device? Do we ignore them, create a diffrent RFC and then reference it? I would say this is still a router, and it needs to choose a globally reachable PD-IP (either a LAN interface or a loopback interface) to use for communication with the outside world. > 4. Is there a consensus that these are worth the WG taking up and dealing > with? I believe there are at least two people who have chimed in saying that they think this is a good idea, plus the authors of the draft also stated that they were willing to bring in wording to allow for it. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 4 03:54:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3083A6B4F for ; Fri, 4 Jul 2008 03:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArHPimqS9kh for ; Fri, 4 Jul 2008 03:54:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A6DF3A6B20 for ; Fri, 4 Jul 2008 03:54:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEitc-0007hc-15 for v6ops-data@psg.com; Fri, 04 Jul 2008 10:52:08 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEitY-0007gu-DB for v6ops@ops.ietf.org; Fri, 04 Jul 2008 10:52:06 +0000 Received: (qmail 30304 invoked by uid 417); 4 Jul 2008 10:51:12 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 10:51:12 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 04:51:12 -0600 References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: Mikael Abrahamsson Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 04:51:12 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael Abrahamsson writes: > >> Anyhow, in my mind a "host" is not so much of a name for a category of >> devices, but rather a behavioral pattern of a node. At any given moment >> a node can start to behave as a "router" (if that is defined only as >> doing packet forwarding). For a network the node may still look like a >> "host", if the node does this transparently for the network (i.e. with >> help of NAT). > > Yes, I realise this, but I want my native IPv6 service offering to require > a "router" class device, even if it means that this "router" only forwards > traffic logically between the WAN link-local interface and it's internal > loopback address (DHCPv6-PD assigned space). Then I suspect you will be greatly disappointed as I do not see most of the devices that will be using IPv6 in the future fitting into this category. Cellular devices outnumber PCs today, and unless you plan to stretch the definition of CPE Router to include the ones at cell sites then you will find that more devices are not behind a CPE router than those that are. Look at the past 5 year trend to mobile internet (Cellular, WiMAX, etc.), RFIDs, Automotive and traffic systems, etc. These devices do not see a device that would fit into this document even though they eventually are served by a router. > >> I did not think that was the idea either? If the end hosts would use >> DHCPv6 PD, would that be an act of sourcing packets to IP core? If so, >> could the delegating DHCPv6 server locate somewhere where "hosts" could >> safely (from ISP point of view) talk? >> >> The talking to ISP core is one differentiator, then we might(?) have: I suggest that you try thinking of IPv6 as being used by non-ISP service providers, this may help with the differences we are discussing. > Hm, the problem is that i don't want customers in core IP space, and I > don't want core in customer IP space. > This is the old telco model, where there was a mandated telco owned CPE acting as a termination device. Cellular started the decline of this model as did ISDN modems inside of computers. It worked when cellular used very little data, but with devices moving to VoIP and full data applications there will be routing and other activities down to the end user device. I doubt that we will go back to it. Even today you have this where WiFi on laptops serve additional devices acting as a hot spot (router) for them. > I want to protect it from IP packets from the global Internet. I am sorry, these devices are like children, we have to let them out into the world unprotected. ;) Eric From owner-v6ops@ops.ietf.org Fri Jul 4 04:03:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A743A6B18 for ; Fri, 4 Jul 2008 04:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CjMkUsJdsUW for ; Fri, 4 Jul 2008 04:03:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41BFA3A6A16 for ; Fri, 4 Jul 2008 04:03:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEj1z-0009MB-LO for v6ops-data@psg.com; Fri, 04 Jul 2008 11:00:47 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEj1s-0009L2-50 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 11:00:41 +0000 Received: (qmail 6795 invoked by uid 417); 4 Jul 2008 11:00:10 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 4 Jul 2008 11:00:10 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 04 Jul 2008 05:00:10 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <20080704.102537.193760974.miyakawa@nttv6.jp> In-Reply-To: From: EricLKlein@softhome.net To: Mikael Abrahamsson Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 04 Jul 2008 05:00:10 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.74] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael Abrahamsson writes: > On Fri, 4 Jul 2008, EricLKlein@softhome.net wrote: > >> 2. If so for all IPv6 end devices or just CPE routers that have other >> devices aggregated to them via copper, fiber, wireless? > > My requirement is only for home gateway devices, I don't want to change > the behaviour of end-hosts. My proposal is also to not remove any > functionality or limit it, just to add. I am not aware of my proposal > being in violation of any current wording in any document, but if it is, I > volunteer to participate in work in getting it fixed. > >> 3. What about other devices that act as a router but are the actual >> end-use device? Do we ignore them, create a diffrent RFC and then >> reference it? > > I would say this is still a router, and it needs to choose a globally > reachable PD-IP (either a LAN interface or a loopback interface) to use > for communication with the outside world. > >> 4. Is there a consensus that these are worth the WG taking up and dealing >> with? > > I believe there are at least two people who have chimed in saying that > they think this is a good idea, plus the authors of the draft also stated > that they were willing to bring in wording to allow for it. > It sounds to me like there is some agreement that there is something here in need of defining/clarifying. I agree this would be good for the WG to work on towards a consensus provided we expand the scope a little to cover the rest of the situations where routing functions are required. Eric From owner-v6ops@ops.ietf.org Fri Jul 4 04:03:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF3B3A6B18 for ; Fri, 4 Jul 2008 04:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsPrq60KS-Ga for ; Fri, 4 Jul 2008 04:03:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8B073A6A16 for ; Fri, 4 Jul 2008 04:03:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEj3M-0009Zw-H7 for v6ops-data@psg.com; Fri, 04 Jul 2008 11:02:12 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEj3H-0009Xd-1U for v6ops@ops.ietf.org; Fri, 04 Jul 2008 11:02:09 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2A7FFADADC; Fri, 4 Jul 2008 13:02:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F9C7ADAD9; Fri, 4 Jul 2008 13:02:06 +0200 (CEST) Date: Fri, 4 Jul 2008 13:02:06 +0200 (CEST) From: Mikael Abrahamsson To: EricLKlein@softhome.net cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 4 Jul 2008, EricLKlein@softhome.net wrote: > Then I suspect you will be greatly disappointed as I do not see most of the > devices that will be using IPv6 in the future fitting into this category. > Cellular devices outnumber PCs today, and unless you plan to stretch the > definition of CPE Router to include the ones at cell sites then you will find > that more devices are not behind a CPE router than those that are. Look at > the past 5 year trend to mobile internet (Cellular, WiMAX, etc.), RFIDs, > Automotive and traffic systems, etc. These devices do not see a device that > would fit into this document even though they eventually are served by a > router. I have no problem broadening the scope of the document even further. I know very little of the mobile technologies you mention. > This is the old telco model, where there was a mandated telco owned CPE > acting as a termination device. Cellular started the decline of this model as In my market, for residential CPE routers, the telco doesn't own or manage the device to a large extent. Here, ISPs send out a list of "recommended CPEs" to use with the service, for which the ISP will be able to offer support/help in case of problems. If the customer runs into problems and has purchased other devices, the ISP will not be able to help with CPE router related problems. Some ISPs bundle a device when you purchase the service, as the cost of the CPE is quite low in comparison to other aspects of the turn-up process, but it's still managed by the customer (but comes with sensible defaults). -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 4 06:11:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8803A65A6 for ; Fri, 4 Jul 2008 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taqUGRhkcxuZ for ; Fri, 4 Jul 2008 06:11:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12533A6C26 for ; Fri, 4 Jul 2008 06:11:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEkzq-00049V-GO for v6ops-data@psg.com; Fri, 04 Jul 2008 13:06:42 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEkzm-00048u-K9 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 13:06:40 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m64D6GSh008317; Fri, 4 Jul 2008 08:06:22 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 16:06:17 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 16:06:09 +0300 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Fri, 4 Jul 2008 16:06:09 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjdpJw3KplVZlFcSsObDPBOQCrM7AALLySQ References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> From: To: Cc: , , , X-OriginalArrivalTime: 04 Jul 2008 13:06:09.0970 (UTC) FILETIME=[BA60B920:01C8DDD6] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, >Yes, I realise this, but I want my native IPv6 service=20 >offering to require a "router" class device, even if it means=20 >that this "router" only forwards traffic logically between the=20 >WAN link-local interface and it's internal loopback address=20 >(DHCPv6-PD assigned space). There definitely are different use-cases with different requirements.=20 You mentioned elsewhere that the scope of the document could be expanded. What do the authors think about that? Should we sit down in Dublin to discuss? >> (1) CPE router: >> - allowed to directly source packets to ISP core [host]---[CPE=20 >> router]---[ISP]---[Internet] > >What adresses would be used between CPE router and ISP? I=20 >would like it to be link-local only. No comment for this (I would need to study more on what issues link-local only could bring, but I trust others here are more knowledgeable). >> An example of case (1) would be a DSL box at home/small=20 >office, and an=20 >> example of case (2) would be a cellular device that: >> - connects with point-to-point link to operator's access=20 >concentrator=20 >> (e.g. GGSN), and gets a /64 prefix for itself (SLAAC) >> - uses DHCPv6 PD to get more prefixes, and announces these=20 >prefixes to=20 >> LAN >> - possibly implements DHCPv6 relay in order to enable other=20 >devices in=20 >> LAN to utilize DHCPv6 PD as well > >Yes, that sounds about right, but what adress space is used on=20 >the p-t-p link? Is that the /64? That would mean that the GGSN=20 >IP adress in this space is globally reachable, with the=20 >security implications that brings. Yes, /64, which is per mobile allocated by the network as the mobile usually acts as a host and needs a global address (it may implement RFC4941 as well). The mobile node itself is well positioned to attack GGSN, as by its nature it is on the same link with it, thus GGSN has to prepare well for attacks on its subscriber-facing interfaces (probably has all but necessary ports closed). For the attacks from the Internet, there is a firewall between GGSN and Internet.=20 I'm not sure if the GGSN even configures itself global address from the prefixes it gives to subscribers (does router have to configure an address for itself from the prefixes it sends out in RAs?). I was unable to verify this right now. Best regards, Teemu From owner-v6ops@ops.ietf.org Fri Jul 4 08:43:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DB93A68B9 for ; Fri, 4 Jul 2008 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4SId5imBS6e for ; Fri, 4 Jul 2008 08:43:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAD5F3A67F7 for ; Fri, 4 Jul 2008 08:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnMH-0002tg-W8 for v6ops-data@psg.com; Fri, 04 Jul 2008 15:38:01 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnME-0002rL-3c for v6ops@ops.ietf.org; Fri, 04 Jul 2008 15:38:00 +0000 Received: from [10.0.1.10] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id B8EE826EAE7; Fri, 4 Jul 2008 08:37:56 -0700 (PDT) Cc: IPv6 Operations Message-Id: <8DF03C59-15BE-4707-9607-6121A0706875@virtualized.org> From: David Conrad To: ericlklein@softhome.net In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Fri, 4 Jul 2008 08:37:55 -0700 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I do not wish to resurrect the anti-NAT wars, so this will be my last comment on this thread. On Jul 4, 2008, at 3:06 AM, ericlklein@softhome.net wrote: > David Conrad writes: >> On Jul 3, 2008, at 12:54 PM, Ralph Droms wrote: >>> there won't be any motivation for NAT. >> Provider independence. > This independence would be as easily served by changing the v6 > prefix and keeping the /64 addresses the same. This kind of > renumbering has been built into v6. Not really. Ask any non-trivial enterprise network operator or simply look at the rationales for the push at _all_ the RIRs for provider independent IPv6 allocation policies. IPv6 may make renumbering somewhat easier than IPv4, but it does not solve the issue. Filters, firewalls, network management systems, domain name servers, registries, and registrars are all just some of the places in which IPv6 literal addresses will get transcribed and have to be changed in the face of a prefix renumbering event. Because renumbering IPv6 prefixes will not be transparent, there will be a market for NATv6. The only question is whether the downsides of NATv6 will be sufficient to deter its use. Since people have been trained to accept NATv4, I am somewhat skeptical the vast majority of users will rebel against NATv6. Regards, -drc From owner-v6ops@ops.ietf.org Fri Jul 4 08:53:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D7B3A69C4 for ; Fri, 4 Jul 2008 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+sqS8RNyS88 for ; Fri, 4 Jul 2008 08:53:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD75A3A68FA for ; Fri, 4 Jul 2008 08:53:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnZv-0004p2-Or for v6ops-data@psg.com; Fri, 04 Jul 2008 15:52:07 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnZs-0004oZ-15 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 15:52:05 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 98CE3BDC21; Sat, 5 Jul 2008 00:52:03 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 6675A6FD47; Sat, 5 Jul 2008 00:52:03 +0900 (JST) Date: Sat, 05 Jul 2008 00:52:03 +0900 (JST) Message-Id: <20080705.005203.226765976.miyakawa@nttv6.jp> To: teemu.savolainen@nokia.com Cc: swmike@swm.pp.se, shemant@cisco.com, wbeebee@cisco.com, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: From: Subject: RE: new draft on IPv6 CPE router available for review Date: Fri, 4 Jul 2008 16:06:09 +0300 > Should we sit down in Dublin to discuss? This is very nice idea, and let us have good Irish beer there together :-) Shin Miyakawa From owner-v6ops@ops.ietf.org Fri Jul 4 08:53:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFA53A69C4 for ; Fri, 4 Jul 2008 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYisg3kIClk8 for ; Fri, 4 Jul 2008 08:53:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEDA23A68FA for ; Fri, 4 Jul 2008 08:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnZk-0004l0-BT for v6ops-data@psg.com; Fri, 04 Jul 2008 15:51:56 +0000 Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEnZf-0004kP-O5 for v6ops@ops.ietf.org; Fri, 04 Jul 2008 15:51:53 +0000 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 34F28BDC08; Sat, 5 Jul 2008 00:51:51 +0900 (JST) Received: from localhost (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id E8FA96E358; Sat, 5 Jul 2008 00:51:50 +0900 (JST) Date: Sat, 05 Jul 2008 00:51:50 +0900 (JST) Message-Id: <20080705.005150.193722360.miyakawa@nttv6.jp> To: swmike@swm.pp.se Cc: EricLKlein@softhome.net, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: new draft on IPv6 CPE router available for review From: Shin Miyakawa In-Reply-To: References: <20080704.174645.71101066.miyakawa@nttv6.jp> Organizaton: NTT Communications X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, I see. Then, next time, please refrain from using a bit offensive words such as > If you want to remove the merit of my proposal on the basis that I haven't > supplied RFC quality text to support it, well, then the IETF process is > broken because it doesn't listen to what the operational community has to > say. This sounds that YOU ARE the operational community ITSELF. But now I understand, it is not what you meant, but please understand it sounds ....... > Exactly, which is why I have a problem with it. I want the option of not > assigning a WAN IPv6 address. OK. You want the OPTION now. Sounds very nice. > > I see. OK Then, how about like this ? (This is actually just an idea. I think > > that Wes and Hemant are able to write better text than mine...) > > > > The CPE can acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. > > In this case, The CPE can be anything, a router CPE, a host, strong host model or > > week host model, following RFC3484 recommendation or even not. > > If operator that the CPE is going to connect, does not assign > > any global IPv6 address for WAN interface, there is a limitation on CPE > > architecture so that source address on it should be selected from > > PDed address which is not recommended in RFC3484. > > This writing is technically correct in aspect to what I want Very Good. I really appreciate that we are coming closer to achieve a consensus. > but the writing (at least to me) implies that not following RFC3484 in the "global > IPv6 WAN address" aspect is a bad idea, which I think is a bit biased. fmmm.. I see.. Of course, it still seems to me that RFC3484 recommends to select address from the addresses which are assigned to the WAN I/F. and some existing implementation (such as MS Vista) do this so... > If you cut out "which is not recommended in RFC3484." then it becomes more > neutral. But, if you think this is a matter of controversial, it is OK for me to cut out "which is not recommended in RFC3484" from above text. Let us do so. > I don't really understand why you so strongly oppose my idea? Of course, I did not really understand why you so strongly opposed my idea too :-p === == OK. If your idea is allowing the link-local only model is an option, then fine for me. ========= If your idea is the link-local only model is the only choice, then I oppose it. Please understand that I "prefered" (and actually still prefer) your idea originally, Otherwise we did not write RFC4241 that contains following text ----------- from RFC4241 -------------- >2.4. Address Assignment > > Because a link-local address is already assigned to the CPE's > upstream interface, global-scope address assignment for that > interface is optional. ----------- from RFC4241 -------------- But now, because I think that we should allow all the implementation which is compatible with today's standard set can be compatible with the service (This's the STANDARDIZATION, isn't it ?), the SERVICE should be ready to assign global IPv6 address for WAN interface of the CPE. > If the ISP highly values to have IP separation of customer IP space and > ISP IP space, then they can deploy along my proposal, maybe. or maybe not. But if the ISP highly values to allow any implementation which is compatible with IPv6 standard set to be used by its customers, then they will not deploy along your proposal. Best wishes, Shin Miyakawa From owner-v6ops@ops.ietf.org Sat Jul 5 03:02:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFF23A6845 for ; Sat, 5 Jul 2008 03:02:49 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvm1JiHB0usd for ; Sat, 5 Jul 2008 03:02:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D815A3A6810 for ; Sat, 5 Jul 2008 03:02:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KF4Sb-0008gE-0C for v6ops-data@psg.com; Sat, 05 Jul 2008 09:53:41 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KF4SX-0008fh-39 for v6ops@ops.ietf.org; Sat, 05 Jul 2008 09:53:38 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7D355ADADE; Sat, 5 Jul 2008 11:53:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 71AC5ADADD; Sat, 5 Jul 2008 11:53:34 +0200 (CEST) Date: Sat, 5 Jul 2008 11:53:34 +0200 (CEST) From: Mikael Abrahamsson To: Shin Miyakawa cc: EricLKlein@softhome.net, v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review In-Reply-To: <20080705.005150.193722360.miyakawa@nttv6.jp> Message-ID: References: <20080704.174645.71101066.miyakawa@nttv6.jp> <20080705.005150.193722360.miyakawa@nttv6.jp> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, 5 Jul 2008, Shin Miyakawa wrote: > OK. You want the OPTION now. Sounds very nice. Yes, that was my intention all along, sorry for my inability to communicate this. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Sat Jul 5 05:23:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119883A6982 for ; Sat, 5 Jul 2008 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQSU5P2X8OAP for ; Sat, 5 Jul 2008 05:23:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4083E3A688C for ; Sat, 5 Jul 2008 05:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KF6iy-0003LL-MD for v6ops-data@psg.com; Sat, 05 Jul 2008 12:18:44 +0000 Received: from [69.147.75.107] (helo=web62515.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KF6iu-0003Km-Qv for v6ops@ops.ietf.org; Sat, 05 Jul 2008 12:18:42 +0000 Received: (qmail 36240 invoked by uid 60001); 5 Jul 2008 12:18:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=tbLywPgT2O9M5yEmPFBAfpIckbUmL0DqxF4WIciZEn0IMsfxg3nMbNg5dR9gvcRaXbMXNXtFP0Ka8WXHhWY+MR74td3/Fz5wduVZ1yAfHpkfwkn+sT7xtMNwUuTR4jSTVeUNrIptellctiFpRvedBNw/iNbSWx7d3E9UV6B2z7s=; Received: from [90.31.236.66] by web62515.mail.re1.yahoo.com via HTTP; Sat, 05 Jul 2008 05:18:25 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Sat, 5 Jul 2008 05:18:25 -0700 (PDT) From: Francois-Xavier Le Bail Subject: Re: new draft on IPv6 CPE router available for review To: wbeebee@cisco.com, shemant@cisco.com Cc: v6ops@ops.ietf.org In-Reply-To: <854412.11064.qm@web62515.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <903236.34425.qm@web62515.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Wed, 7/2/08, Francois-Xavier Le Bail wrote: > The CPE must also support IPv4, and for using one subnet in > IPv4 world, it's a practice to have a LAN bridge with > Ethernet, Wifi, etc. interfaces adding to it. > And this bridge is always up, even if the LAN interfaces > are individualy down. > So binding the global-scope management address to this LAN > bridge can be a way to consider. When the CPE router has only a link-local address on the WAN port, if the CPE has a LAN bridge, I hope there is an option to have the global-scope address set on the LAN bridge (from IA_PD via DHCPv6) as an alternative to loopback solution. Do you agree ? Best Regards, Francois-Xavier From c.nowosad@resolvelocums.com Sat Jul 5 06:49:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F563A692B; Sat, 5 Jul 2008 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.803 X-Spam-Level: X-Spam-Status: No, score=-81.803 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D9styNU+lcu; Sat, 5 Jul 2008 06:49:39 -0700 (PDT) Received: from pc-59-1-104-200.cm.vtr.net (pc-59-1-104-200.cm.vtr.net [200.104.1.59]) by core3.amsl.com (Postfix) with SMTP id 4E5613A6869; Sat, 5 Jul 2008 06:49:31 -0700 (PDT) X-Originating-IP: 2.155.192.225 by smtp.200.104.1.59; Sat, 05 Jul 2008 09:49:42 -0500 Message-ID: From: "Clare Nixon" Reply-To: "Clare Nixon" To: provreg-archive@megatron.ietf.org Subject: No time to look for watch? Prestige Replicas Date: Sat, 05 Jul 2008 09:49:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://Elbagebafo.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://Elbagebafo.blogspot.com/ From c.janisch@backstage.at Sat Jul 5 07:47:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148B03A6B95; Sat, 5 Jul 2008 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.365 X-Spam-Level: X-Spam-Status: No, score=-73.365 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik+0ynAybf7v; Sat, 5 Jul 2008 07:47:04 -0700 (PDT) Received: from 79.109.59.70.dyn.user.ono.com (79.109.59.70.dyn.user.ono.com [79.109.59.70]) by core3.amsl.com (Postfix) with SMTP id 597D53A6952; Sat, 5 Jul 2008 07:46:44 -0700 (PDT) X-Originating-IP: 170.175.245.166 by smtp.79.109.59.70; Sat, 05 Jul 2008 10:46:54 -0500 Message-ID: From: "Lowell Beck" Reply-To: "Lowell Beck" To: tools-discuss@ietf.org Subject: Reliable watches for everyone at Prestige Replicas Date: Sat, 05 Jul 2008 10:46:54 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://Odessapiwim.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://Odessapiwim.blogspot.com/ From c.marker@ameritrustlends.com Sat Jul 5 08:23:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207793A6BCE; Sat, 5 Jul 2008 08:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.209 X-Spam-Level: X-Spam-Status: No, score=-79.209 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZVAYI4q2b7a; Sat, 5 Jul 2008 08:23:46 -0700 (PDT) Received: from adsl-200-172.teol.net (adsl-200-172.teol.net [89.111.200.172]) by core3.amsl.com (Postfix) with SMTP id A6D8A3A6BEB; Sat, 5 Jul 2008 08:23:15 -0700 (PDT) X-Originating-IP: 157.119.88.4 by smtp.89.111.200.172; Sat, 05 Jul 2008 11:23:25 -0500 Message-ID: From: "Bernard Hargrove" Reply-To: "Bernard Hargrove" To: tools-discuss@ietf.org Subject: Prestige Replicas Offer variety replica watches Date: Sat, 05 Jul 2008 11:23:25 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://Kristyfacofu.blogspot.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://Kristyfacofu.blogspot.com/ From owner-v6ops@ops.ietf.org Sun Jul 6 05:23:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3DA3A68D7 for ; Sun, 6 Jul 2008 05:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Aaa5MfZ8xkv for ; Sun, 6 Jul 2008 05:23:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB8D63A63C9 for ; Sun, 6 Jul 2008 05:23:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFT8K-000KOu-GP for v6ops-data@psg.com; Sun, 06 Jul 2008 12:14:24 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFT8A-000KNh-1B for v6ops@ops.ietf.org; Sun, 06 Jul 2008 12:14:22 +0000 X-IronPort-AV: E=Sophos;i="4.30,310,1212364800"; d="scan'208";a="13312306" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2008 12:14:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m66CEAWV032495; Sun, 6 Jul 2008 08:14:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m66CEAKn011668; Sun, 6 Jul 2008 12:14:10 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jul 2008 08:14:10 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Sun, 6 Jul 2008 08:14:10 -0400 Message-ID: In-Reply-To: <903236.34425.qm@web62515.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjemTzL3voGkmQURbKOGMuRy8175AAx3zLA References: <854412.11064.qm@web62515.mail.re1.yahoo.com> <903236.34425.qm@web62515.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 06 Jul 2008 12:14:10.0520 (UTC) FILETIME=[CBDDED80:01C8DF61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1238; t=1215346450; x=1216210450; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee) =22=20; bh=Gi8k6ASXVub9DrW34qJse5QikOnqd++QOomQa9dywiU=; b=iXSLcRkN7sSo01cdD9Wmg1OKcw01LdS/597CNF+tnDYKkyQO78E3V+Zb0P /SXe9wFrZJBCuzzL64dnregwmKDKSQBe4MV1KtfvDode3IkU5e6zWPoipgAs Ll4l5TAnGu; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: If the Service Provider has doled out an IA_PD option, then the CPE Router always has the option to use a set of IPv6 address(es) from the IA_PD to configure on the LAN interface(s) of the CPE Router. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Saturday, July 05, 2008 8:18 AM To: Wes Beebee (wbeebee); Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review --- On Wed, 7/2/08, Francois-Xavier Le Bail wrote: > The CPE must also support IPv4, and for using one subnet in > IPv4 world, it's a practice to have a LAN bridge with Ethernet, Wifi,=20 > etc. interfaces adding to it. > And this bridge is always up, even if the LAN interfaces are=20 > individualy down. > So binding the global-scope management address to this LAN bridge can=20 > be a way to consider. When the CPE router has only a link-local address on the WAN port, if the CPE has a LAN bridge, I hope there is an option to have the global-scope address set on the LAN bridge (from IA_PD via DHCPv6) as an alternative to loopback solution. Do you agree ? Best Regards, Francois-Xavier =20 From owner-v6ops@ops.ietf.org Sun Jul 6 09:47:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAA43A6820 for ; Sun, 6 Jul 2008 09:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I4llYIuE0YF for ; Sun, 6 Jul 2008 09:47:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C72743A67AF for ; Sun, 6 Jul 2008 09:47:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFXIp-00053L-8n for v6ops-data@psg.com; Sun, 06 Jul 2008 16:41:31 +0000 Received: from [69.147.75.97] (helo=web62505.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFXIl-00052n-L5 for v6ops@ops.ietf.org; Sun, 06 Jul 2008 16:41:29 +0000 Received: (qmail 12511 invoked by uid 60001); 6 Jul 2008 16:41:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=r+xu9IViHnl/fcav9XmHtOJd59cINhls9giMKtwSBcYBM+rGp32ooSop/2SfctM55g5x9McGLXUC7Qr4efPJoaul5hHDHklNhtzOUmp4G6kzD+i3VFLn+rv6dIRRPy3bhL9+hLhxX3TTyEpTSqE9R0411q1w38yTxY2IfM1ydk0=; Received: from [90.31.236.66] by web62505.mail.re1.yahoo.com via HTTP; Sun, 06 Jul 2008 09:41:26 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Sun, 6 Jul 2008 09:41:26 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: new draft on IPv6 CPE router available for review To: "Wes Beebee \(wbeebee\)" , "Hemant Singh \(shemant\)" Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <883759.12448.qm@web62505.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: You're right. I must explain more clearly my proposal. For the model where WAN interface only acquires a link-local address, I see two options for the interface which will be assigned a global IPv6 address sub-delegated from IA_PD via DHCPv6 : - If there is a logical LAN bridge, which is always up even if the LAN interfaces attached to it are individualy down, CPE will use the bridge which will be assigned such a global IPv6 address. These is no need to add a loopback interface. - Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address. Francois-Xavier --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: new draft on IPv6 CPE router available for review > To: "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" > Cc: v6ops@ops.ietf.org > Date: Sunday, July 6, 2008, 8:14 AM > If the Service Provider has doled out an IA_PD option, then > the CPE > Router always has the option to use a set of IPv6 > address(es) from the > IA_PD to configure on the LAN interface(s) of the CPE > Router. > > Hemant > > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Saturday, July 05, 2008 8:18 AM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for > review > > --- On Wed, 7/2/08, Francois-Xavier Le Bail > wrote: > > > The CPE must also support IPv4, and for using one > subnet in > > IPv4 world, it's a practice to have a LAN bridge > with Ethernet, Wifi, > > etc. interfaces adding to it. > > And this bridge is always up, even if the LAN > interfaces are > > individualy down. > > So binding the global-scope management address to this > LAN bridge can > > be a way to consider. > > When the CPE router has only a link-local address on the > WAN port, if > the CPE has a LAN bridge, I hope there is an option to have > the > global-scope address set on the LAN bridge (from IA_PD via > DHCPv6) as an > alternative to loopback solution. > > Do you agree ? > > Best Regards, > > Francois-Xavier From owner-v6ops@ops.ietf.org Sun Jul 6 17:26:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AF33A6807 for ; Sun, 6 Jul 2008 17:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apfPmPUm+3Ap for ; Sun, 6 Jul 2008 17:26:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E10823A6765 for ; Sun, 6 Jul 2008 17:26:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFeSN-000HPU-4I for v6ops-data@psg.com; Mon, 07 Jul 2008 00:19:51 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFeSC-000HMh-61 for v6ops@ops.ietf.org; Mon, 07 Jul 2008 00:19:42 +0000 X-IronPort-AV: E=Sophos;i="4.30,312,1212364800"; d="scan'208";a="13352581" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2008 00:19:38 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m670JcFo013841; Sun, 6 Jul 2008 20:19:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m670Jct2015061; Mon, 7 Jul 2008 00:19:38 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jul 2008 20:19:38 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Sun, 6 Jul 2008 20:19:37 -0400 Message-ID: In-Reply-To: <883759.12448.qm@web62505.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuw References: <883759.12448.qm@web62505.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" Cc: , "MILES DAVID" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 07 Jul 2008 00:19:38.0338 (UTC) FILETIME=[2477DC20:01C8DFC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3240; t=1215389978; x=1216253978; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee) =22=20; bh=xa1M8np4WB5Z7n79Wp6efSXr5QVHza0M57/P30GNkd8=; b=scUzxnMdWMG+RPbOSeIp4NOQAvPhl6/2AFETVpybTQlKNO68dgO4+d/Tnx esK2cdGUZUnSEw0oIbV+f5+ZL0dHZ/qZ1eXBbTMDm/WNKGID1s/fHxf2mDic rvhHRis2yB; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, Thanks for everyone's proposals and ideas, but we are not seriously looking at ideas from individual folks - it's not proving to be very productive. If you are a DSL or FIOS person, please send your proposals to David Miles who can collate all proposals and he will also work with Mark Townsley who works on DSL. We are working with David Miles and have already incorporated his requests from DSL folks in our next version of the draft. We don't need any proposals or ideas for cable industry since we have that covered ourselves.=20 Any other industry will be dealt by us on a case by case basis. Thanks. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Sunday, July 06, 2008 12:41 PM To: Wes Beebee (wbeebee); Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review You're right. I must explain more clearly my proposal. For the model where WAN interface only acquires a link-local address, I see two options for the interface which will be assigned a global IPv6 address sub-delegated from IA_PD via DHCPv6 : - If there is a logical LAN bridge, which is always up even if the LAN interfaces attached to it are individualy down, CPE will use the bridge which will be assigned such a global IPv6 address. These is no need to add a loopback interface. - Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address. Francois-Xavier --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: new draft on IPv6 CPE router available for review > To: "Francois-Xavier Le Bail" , "Wes Beebee=20 > (wbeebee)" > Cc: v6ops@ops.ietf.org > Date: Sunday, July 6, 2008, 8:14 AM > If the Service Provider has doled out an IA_PD option, then the CPE=20 > Router always has the option to use a set of IPv6 > address(es) from the > IA_PD to configure on the LAN interface(s) of the CPE Router. >=20 > Hemant >=20 > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Saturday, July 05, 2008 8:18 AM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review >=20 > --- On Wed, 7/2/08, Francois-Xavier Le Bail =20 > wrote: >=20 > > The CPE must also support IPv4, and for using one > subnet in > > IPv4 world, it's a practice to have a LAN bridge > with Ethernet, Wifi, > > etc. interfaces adding to it. > > And this bridge is always up, even if the LAN > interfaces are > > individualy down. > > So binding the global-scope management address to this > LAN bridge can > > be a way to consider. >=20 > When the CPE router has only a link-local address on the WAN port, if=20 > the CPE has a LAN bridge, I hope there is an option to have the=20 > global-scope address set on the LAN bridge (from IA_PD via > DHCPv6) as an > alternative to loopback solution. >=20 > Do you agree ? >=20 > Best Regards, >=20 > Francois-Xavier =20 From owner-v6ops@ops.ietf.org Mon Jul 7 02:22:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476CB28C12E for ; Mon, 7 Jul 2008 02:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJaG1+KFEoCE for ; Mon, 7 Jul 2008 02:22:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D9FB28C149 for ; Mon, 7 Jul 2008 02:22:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFmns-0005fz-7K for v6ops-data@psg.com; Mon, 07 Jul 2008 09:14:36 +0000 Received: from [2002:58bf:2aa0:339b:f654:e10e:317f:e6fa] (helo=moog.chdir.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFmnT-0005dY-AV for v6ops@ops.ietf.org; Mon, 07 Jul 2008 09:14:23 +0000 Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KFmnP-0000gN-Cw for v6ops@ops.ietf.org; Mon, 07 Jul 2008 11:14:07 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: v6ops@ops.ietf.org Subject: Comments on draft-ietf-v6ops-ra-guard-00.txt References: <20080701054501.D8E3E3A67D7@core3.amsl.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080707:internet-drafts@ietf.org::4uyU3w+RNf5HWVeB:00000000000000000000000000000000000000VsZ X-Hashcash: 1:20:080707:i-d-announce@ietf.org::JgPkn9SAxqsVK5tq:00000000000000000000000000000000000000003mlb X-Hashcash: 1:20:080707:v6ops@ops.ietf.org::DqC3T5KlpLX+QMjf:00000000000000000000000000000000000000000006Cl+ Date: Mon, 07 Jul 2008 11:13:31 +0200 In-Reply-To: <20080701054501.D8E3E3A67D7@core3.amsl.com> (Internet-Drafts@ietf.org's message of "Mon, 30 Jun 2008 22:45:01 -0700 (PDT)") Message-ID: <874p723vlw.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --=-=-= Content-Transfer-Encoding: quoted-printable Hi, Some typos and comments/questions inline below. Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IET= F. > > > Title : IPv6 RA-Guard > Author(s) : G. Van de Velde, et al. > Filename : draft-ietf-v6ops-ra-guard-00.txt > Pages : 9 > Date : 2008-06-30 > > When using IPv6 within a single L2 network segment it is neccesary to ^^^^^^^^^ necessary > ensure that all routers advertising their services within it are > valid. In cases where it is not convinient or possible to use SeND ^^^^^^^^^^ convenient > [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent > by accident due to misconfiguraton or ill intended. Simple solutions > for protecting against rogue RAs are beneficial in complementing SeND > in securing the L2 domain for ceratin types of devices or in certain ^^^^^^^ certain > transitional situations. > This document proposes a solution to reduce the threat of rogue RAs > by enabling layer 2 devices to forward only RAs received over > designated ports. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > v6ops Working Group G. Van de Velde > Internet-Draft E. Levy-Abegnoli > Expires: January 2, 2009 C. Popoviciu > Cisco Systems > J. Mohacsi > NIIF/Hungarnet > July 1, 2008 > > > IPv6 RA-Guard > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 2, 2009. > > Abstract > > When using IPv6 within a single L2 network segment it is neccesary ^^^^^^^^^ necessary > ensure that all routers advertising their services within it are > valid. In cases where it is not convinient or possible to use SeND ^^^^^^^^^^ convenient > [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent > by accident due to misconfiguraton or ill intended. Simple solutions > for protecting against rogue RAs are beneficial in complementing SeND > in securing the L2 domain for ceratin types of devices or in certain > transitional situations. [snip] > 1. Introduction > > When operating IPv6 in a shared L2 network segment without complete > SeND support by all devices connected or without the availability of > the infrastructure neccesary to support SeND, there is always the ^^^^^^^^^ necessary > risk of facing operational problems due to rogue Router > Advertisements generated malliciously or unintentionaly by ^^^^^^^^^^^^ ^^^^^^^^^^^^^^ maliciously nally ? > unauthorized or improperly configured routers connecting to the > segment. > > There are several examples of work done on this topic which resulted > in several related studies [reference1] [reference2] > [reference3].This document describes a solution framework to the > rogue-RA problem where network segments are designed around a single > or a set of L2-switching devices capable of identifying invalid RAs > and blocking them. The solutions developed within this framework can > span the spectrum from basic (where the port of the L2 device is > statically instructed to forward or not to forward RAs received from > the connected device) to advanced (where a criteria is used by the L2 > device to dynamically validate or invalidate a received RA, this > criteria can even be based on SeND mechanisms). > > > 2. RA-guard as a deployment complement to SEND > > RA-guard does not intend to provide a substitute for SeND based > solutions. It actually intends to provide complementary solutions in > those environments where SeND might not be suitable or fully > supported by all devices involved. It may take time untill SeND is ^^^^^^ until > ubiquitous in IPv6 networks and some of its large scale deployment > aspects are sorted out such as provisioning hosts with trust anchors. > It is also reasonable to expect that some devices might not consider > implementing SeND at all such as IPv6 enabled sensors. The RA-guard > "SeND-validating" RA on behalf of hosts would potentially simplify > some of these challenges. > > RA-guard can be seen as a superset of SEND with regard to router > authorization. Its purpose is to filter Router Advertizements based > on a set of criterias, from a simplistic "RA dis-allowed on a given ^^^^^^^^^^^ disallowed > interface" to "RA allowed from pre-defined sources" and up to full > SEND fledge "RA allowed from authorized sources only". > > In addition to this granularity on the criteria for filtering out > Router Advertizements, RA-guard introduces the concept of router ^^^^^^^^^^^^^^=20 Advertisements > authorization proxy. Instead of each node on the link analysing RAs > and making an individual decision, a legitimate node-in-the-middle > performs the analysis on behalf of all other nodes on the link. The > analysis itself is not different from what each node would do: if > > > > Van de Velde, et al. Expires January 2, 2009 [Page 3] > > Internet-Draft IPv6 RA-Guard July 2008 > > > SeND is enabled, the RA is checked against X.509 certificates. If > any other criteria is in use, such as known L3 (addresses) or L2 > (link-layer address, port number) legitimate sources of RAs, the > node-in-the middle can use this criteria and filter out any RA that > does not comply. If this node-in-the-middle is a L2 device, it will > not change the content of the validated RA, and avoid any of the nd- > proxy pitfalls. > > RA-guard intends to provide simple solutions to the rogue-RA problem > in contexts where simplicity is required while leveraging SeND in > context with a mix of SeND capable devices (L2 switches and routers) > and devices that do not consistently use SeND. Futhermore, RA-guard > is useful to simplify SeND deployments, as only the L2 switch and the > routers are required to carry certificates -their own and the trust > anchor certificates-. For what purpose would the switches need their own certificate if they should act transparently (maybe it's simply the sentence) ? > 3. RA-Guard state-machine > > RA-Guard runs on devices that provide connectivity between hosts and > other hosts or networking devices. An example of such RA-Guard > capable device would be an OSI Layer-2 switch. The capability can be > enabled globally at device level or at interface level. > > When RA-Guard is SEND-based, the timing of the learning phase, as > well as the overall behavior of the device doing RA-guard is as- > defined in [RFC3971]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What does it mean, *precisely* ? > When RA-guard is using more static criterias, the state-machine of > the RA-Guard capability consists of three different states: > State 1: OFF > State 2: LEARNING > State 3: ACTIVE > > The transition between these states can be triggered by manual > configuration or by meeting a pre-defined criteria. > > 3.1. RA-Guard state: OFF > > A device or interface in RA-Guard "OFF" state, operates as if the RA- > Guard capability is not available. > > 3.2. RA-Guard state: LEARNING > > A device or interface in the RA-Guard "Learning" state is actively > acquiring information about the devices connected to its interfaces. > The learning process takes place over a pre-defined period of time by > capturing router advertisments or it can be event triggered. The ^^^^^^^^^^^^^^ advertisements > > > > Van de Velde, et al. Expires January 2, 2009 [Page 4] > > Internet-Draft IPv6 RA-Guard July 2008 > > > information gathered is compared against pre-defined criteria which > qualify the validity of the RAs. > > In this state, the RA-Guard enabled device or interface is either > blocking all RAs until their validity is verified or, alternatively > it can temporarily forward the RAs until the decision is being made. > > 3.3. RA-Guard state: ACTIVE > > A device or interface running RA-Guard and in Active state will block > ingress RA-messages deemed invalid and will forward those deemed > valid based on a pre-defined criteria defined. ^^^^^^^ to be removed > 4. RA-Guard interface states > > The interfaces of devices with the RA-guard capability enabled can be > in three possible states related to RA handling: Learning, Blocking > and Forwarding. > > 4.1. RA-Blocking interface > > An interface in the RA Blocking state blocks all ingress RA messages > when RA-Guard capability is activated on a device. > > 4.2. RA-Forwarding interface > > An interface in the RA Forwarding state forwards all ingress RA > messages deemed valid when RA-Guard capability is activated on a > device. > > 4.3. RA-Learning interface > > An interface in a RA Learning state snoops all received RAs and > compares them against the criteria identifying valid RAs. While in > this state, the RAs can be blocked or forwarded until a decission ^^^^^^^^^ decision > is taken regarding their validity. > > 4.4. RA-Guard interface state transition > > In the simplest cases, an RA-Guard enabled interface can be manually > set in an RA-Blocking or RA-Forwarding state. By default, the > interfaces of a legitimate node-in-the-middle could be set in RA- > Blocking mode and enabled for forwarding by the network > administrator. In the more general case, the interface acquires RA > information during the RA Learning state and by using a pre-defined > validity criteria (see section 2) decides whether the analyzed RAs > should be forwarded or blocked. Based on this decission, the ^^^^^^^^^ decision > interface transitions into the RA Blocking or the RA Forwarding > state. > > Upon detecting new RAs, a port can transition back into an RA-Guard > Learning state. ^^^ ambiguous, too vague > 5. RA-Guard Use Considerations >=20 > The RA-Guard mechanism is effective only when all mesages between ^^^^^^^ messages > IPv6 devices in the target environment traverse the controlled L2 > networking devices. When on a shared media such as an Ethernet hub, > devices can communicate directly without going through an RA-Guard > capable L2 networking device. In this scenario, the RA- Guard > feature cannot protect against rogue-RAs. >=20 > RA-Guard mecahnism does not protect against tunneled IPv6 traffic. [snip] > 7. Security Considerations > > There are no extra Security consideration for this document. really ? ;-) [snip] a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcd5GAlWVfAR6UCYRAukFAKCTRlmq/VGBe3V9zOkcZ8wgQXgYZQCgg0it JLoE8lrOapv3oAnupIU7rbM= =Kym6 -----END PGP SIGNATURE----- --=-=-=-- From owner-v6ops@ops.ietf.org Mon Jul 7 07:51:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC323A6872 for ; Mon, 7 Jul 2008 07:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQrOdrB6o-tZ for ; Mon, 7 Jul 2008 07:51:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77FB03A697B for ; Mon, 7 Jul 2008 07:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFrwV-000N9S-Nf for v6ops-data@psg.com; Mon, 07 Jul 2008 14:43:51 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFrwO-000N8U-L2 for v6ops@ops.ietf.org; Mon, 07 Jul 2008 14:43:49 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3N000904WVC5@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 09:43:44 -0500 (CDT) Received: from Kaippal73647 ([10.124.12.111]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3N00GTZ4WQOL@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 09:43:42 -0500 (CDT) Date: Mon, 07 Jul 2008 09:43:33 -0500 From: John Kaippallimalil Subject: new draft on IPv6 in Broadband Networks To: v6ops@ops.ietf.org Message-id: <006401c8e03f$d80fe160$6f0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcjgP9RK6h4XG+33QM+p5W0h5EPTQw== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: v6ops folks, Please review this draft: http://www.ietf.org/internet-drafts/draft-kaippallimalil-v6ops-ipv6-bbnet-00 .txt The abstract of the draft is snipped below: Abstract This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. Thanks, John & Frank From owner-v6ops@ops.ietf.org Mon Jul 7 08:58:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0961F3A65A6 for ; Mon, 7 Jul 2008 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLNAVM+tOCpE for ; Mon, 7 Jul 2008 08:58:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDEA23A6A69 for ; Mon, 7 Jul 2008 08:58:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFt3L-0006nP-Dv for v6ops-data@psg.com; Mon, 07 Jul 2008 15:54:59 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFt3D-0006mW-9b for v6ops@ops.ietf.org; Mon, 07 Jul 2008 15:54:55 +0000 X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="13410577" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2008 15:54:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m67FsndJ031921; Mon, 7 Jul 2008 11:54:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m67FsnnT012210; Mon, 7 Jul 2008 15:54:49 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 11:54:49 -0400 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 Subject: RE: new draft on IPv6 in Broadband Networks Date: Mon, 7 Jul 2008 11:56:02 -0400 Message-ID: In-Reply-To: <006401c8e03f$d80fe160$6f0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 in Broadband Networks Thread-Index: AcjgP9RK6h4XG+33QM+p5W0h5EPTQwAB7WYQ References: <006401c8e03f$d80fe160$6f0c7c0a@china.huawei.com> From: "Chip Popoviciu (cpopovic)" To: "John Kaippallimalil" , X-OriginalArrivalTime: 07 Jul 2008 15:54:49.0698 (UTC) FILETIME=[C971EC20:01C8E049] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1885; t=1215446089; x=1216310089; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=20=22Chip=20Popoviciu=20(cpopovic)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20in=20Broadban d=20Networks |Sender:=20 |To:=20=22John=20Kaippallimalil=22=20, =20; bh=I9IzCn2Rc3+mmE0NYMC5jvy8mQcARbaeY+pgCsGCXZE=; b=W/kETdWAUDpTDqimj6tFBjdjiy497YoGz1pc01B2OMD4oGMqa3r1UqjVhU 46/MHe551bWr4uIaOKIA6t90iFXMvoYyHpeNHdkk53/xILUCA9uf6LFCXPl4 rYQmG/KSq6; Authentication-Results: rtp-dkim-1; header.From=cpopovic@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: John, This is a well written document. It seems to me that this document describes in great detail the deployment options summarized in Section 7.2.1 of RFC 4779 (which does covers not only DSL but also Cable and Ethernet as well)? In writing RFC 4779, we started with the same level of detail however, the WG thought and we agreed that it was too much information, especially considering the many types of environments and deployment options covered. The reader should be able to identify the details based on the deployment guidelines. If however we think that is not the case, then a detailed description such as the one in your document might be valuable. In that case, this might open the door for similar documents covering each of the other leading broadband access environments. Besides the detailed description of the proposals in RFC 4779, does this document bring something conceptually new in terms of deployment options for this access environment?=20 Best Regards, Chip=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of John Kaippallimalil Sent: Monday, July 07, 2008 10:44 AM To: v6ops@ops.ietf.org Subject: new draft on IPv6 in Broadband Networks v6ops folks, Please review this draft: http://www.ietf.org/internet-drafts/draft-kaippallimalil-v6ops-ipv6-bbne t-00 .txt The abstract of the draft is snipped below: Abstract This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. Thanks, John & Frank From owner-v6ops@ops.ietf.org Mon Jul 7 09:11:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEECE3A68F5 for ; Mon, 7 Jul 2008 09:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAn4Ao5SUVo1 for ; Mon, 7 Jul 2008 09:11:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 523C83A68D7 for ; Mon, 7 Jul 2008 09:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFtI8-00095o-M2 for v6ops-data@psg.com; Mon, 07 Jul 2008 16:10:16 +0000 Received: from [216.82.245.115] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFtI4-000954-Cr for v6ops@ops.ietf.org; Mon, 07 Jul 2008 16:10:14 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1215447010!25845431!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 12339 invoked from network); 7 Jul 2008 16:10:10 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 7 Jul 2008 16:10:10 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m67GA932019884; Mon, 7 Jul 2008 12:10:10 -0400 Received: from 01GAF5142010625.AD.BLS.COM ([139.76.131.31]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m67GA5Db019823; Mon, 7 Jul 2008 12:10:05 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Jul 2008 12:10:05 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Jul 2008 12:10:04 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 12:10:03 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review thread-index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" CC: , "MILES DAVID" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 07 Jul 2008 16:10:04.0716 (UTC) FILETIME=[EAD696C0:01C8E04B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'm sorry -- I just subscribed to this group last week (at the suggestion of David Miles and Mark Townsley). Can you please explain what you're saying here? I don't want to misinterpret what you're saying -- but to me it sounds as if you're asking DSL and FIOS access providers to not participate in the discussions on this list, or to provide feedback directly to the list? That we are only "permitted" to provide input via David or Mark? Since that's a very un-IETF way of doing things (where generally all individual opinions are welcome, independent of what company they work for), I want to be sure I didn't misunderstand. I was about to comment on some of the items discussed in this thread, but wanted to be sure, first, that I understood this particular email about who was "welcome" to participate. I thought that Mark and David were providing an interface for providers and operators not comfortable with direct participation on IETF lists, and not that we were somehow "required" to go through them to have our opinions heard. Thanks, Barbara Barbara Stark AT&T -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Sunday, July 06, 2008 8:20 PM To: Francois-Xavier Le Bail; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; MILES DAVID; Mark Townsley (townsley) Subject: RE: new draft on IPv6 CPE router available for review Folks, Thanks for everyone's proposals and ideas, but we are not seriously looking at ideas from individual folks - it's not proving to be very productive. If you are a DSL or FIOS person, please send your proposals to David Miles who can collate all proposals and he will also work with Mark Townsley who works on DSL. We are working with David Miles and have already incorporated his requests from DSL folks in our next version of the draft. We don't need any proposals or ideas for cable industry since we have that covered ourselves.=20 Any other industry will be dealt by us on a case by case basis. Thanks. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Sunday, July 06, 2008 12:41 PM To: Wes Beebee (wbeebee); Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review You're right. I must explain more clearly my proposal. For the model where WAN interface only acquires a link-local address, I see two options for the interface which will be assigned a global IPv6 address sub-delegated from IA_PD via DHCPv6 : - If there is a logical LAN bridge, which is always up even if the LAN interfaces attached to it are individualy down, CPE will use the bridge which will be assigned such a global IPv6 address. These is no need to add a loopback interface. - Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address. Francois-Xavier --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: new draft on IPv6 CPE router available for review > To: "Francois-Xavier Le Bail" , "Wes Beebee=20 > (wbeebee)" > Cc: v6ops@ops.ietf.org > Date: Sunday, July 6, 2008, 8:14 AM > If the Service Provider has doled out an IA_PD option, then the CPE=20 > Router always has the option to use a set of IPv6 > address(es) from the > IA_PD to configure on the LAN interface(s) of the CPE Router. >=20 > Hemant >=20 > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Saturday, July 05, 2008 8:18 AM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review >=20 > --- On Wed, 7/2/08, Francois-Xavier Le Bail =20 > wrote: >=20 > > The CPE must also support IPv4, and for using one > subnet in > > IPv4 world, it's a practice to have a LAN bridge > with Ethernet, Wifi, > > etc. interfaces adding to it. > > And this bridge is always up, even if the LAN > interfaces are > > individualy down. > > So binding the global-scope management address to this > LAN bridge can > > be a way to consider. >=20 > When the CPE router has only a link-local address on the WAN port, if=20 > the CPE has a LAN bridge, I hope there is an option to have the=20 > global-scope address set on the LAN bridge (from IA_PD via > DHCPv6) as an > alternative to loopback solution. >=20 > Do you agree ? >=20 > Best Regards, >=20 > Francois-Xavier =20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 From owner-v6ops@ops.ietf.org Mon Jul 7 10:02:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392A53A69AF for ; Mon, 7 Jul 2008 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQj-3-EWHCK0 for ; Mon, 7 Jul 2008 10:02:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD0583A6AC1 for ; Mon, 7 Jul 2008 10:02:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFu2n-000G22-4o for v6ops-data@psg.com; Mon, 07 Jul 2008 16:58:29 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFu2Y-000Fyi-9n for v6ops@ops.ietf.org; Mon, 07 Jul 2008 16:58:21 +0000 X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="63261071" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 16:57:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67Gvi7t007151; Mon, 7 Jul 2008 09:57:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m67Gvi9l005488; Mon, 7 Jul 2008 16:57:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 12:57:43 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 12:57:43 -0400 Message-ID: In-Reply-To: <487247CF.7070909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjgUK1Djx9avhSZRMCk7M6T55EC3QAAP5HA References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <487247CF.7070909@cisco.com> From: "Hemant Singh (shemant)" To: "Mark Townsley (townsley)" , "Stark, Barbara" Cc: "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" , , "MILES DAVID" X-OriginalArrivalTime: 07 Jul 2008 16:57:43.0724 (UTC) FILETIME=[92F096C0:01C8E052] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8009; t=1215449864; x=1216313864; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20; bh=+Y/XUGS3xKdk/4ki3TOpA+zTT0uBJfb2lpuq3qGVhKQ=; b=w9RVTj4toTphiMkWbUeQMFySOHGLEB7rTPl0caHRvHfA3aKTTztwFS7P3M Kvyx7WlgwPQWUXfvQ5CFUtmsIrwLhUuk/rCbk+glBrPr1uI1AibYDechYzAY M2aLPAV8M9; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark, Sounds fine. I do apologize for anointing you and David on this work on the fly. I thought since I saw David's email to the DSL Forum saying he'd work with us from DSL land to give us firm requirements, I mentioned David's name. Then knowing you work to liaise IETF and DSL, you may be another good candidate. I also sent this email because quite a few emails on our draft were not productive for us or that new folks had not read the earlier comments from us or others. That is why I thought if other folks are from DSL land, they could all get together and give us one stock requirement.=20 Anyhow, seeing where the winds are blowing now, moving forward, I and Wes can handle all the requests including understanding ourselves what the DSL requirements are.=20 I will reply to Barbara's email shortly. Hemant -----Original Message----- From: Mark Townsley (townsley)=20 Sent: Monday, July 07, 2008 12:44 PM To: Stark, Barbara Cc: Hemant Singh (shemant); Francois-Xavier Le Bail; Wes Beebee (wbeebee); v6ops@ops.ietf.org; MILES DAVID Subject: Re: new draft on IPv6 CPE router available for review Barbara, please feel free to discuss IPv6 issues on this list freely. I can only imagine that Hemant feels a bit overloaded with comments from a number of places since the introduction of his draft document (which is a good indicator that there is a lot of pent-up desire for work around this topic). Note that his document is an individual submission at this stage, not a product of the WG. If Hemant needs to step back a little, that's OK, there are plenty of other people on this list with something to say. Hemant, I don't think David or I should be anointed as the central source for collecting input on DSL requirements for a future v6ops document. At some point, if v6ops creates a WG document on IPv6 CPE/RG requirements, the editor(s) of that document will be responsible for ensuring that WG consensus, achieved on this list, is recorded properly. So, that means discussion happens on the list and the editors are only recording what the WG ultimately wants to express, not the other way around. In the end, there might be a diversion between the RG requirements for Cable vs. DSL vs. FTTH, etc, but I would hope these to be as congruent and complimentary as possible - at least for all of the "fixed wire" cases. - Mark Stark, Barbara wrote: > I'm sorry -- I just subscribed to this group last week (at the=20 > suggestion of David Miles and Mark Townsley). Can you please explain=20 > what you're saying here? I don't want to misinterpret what you're=20 > saying > -- but to me it sounds as if you're asking DSL and FIOS access=20 > providers to not participate in the discussions on this list, or to=20 > provide feedback directly to the list? That we are only "permitted" to > provide input via David or Mark? Since that's a very un-IETF way of=20 > doing things (where generally all individual opinions are welcome,=20 > independent of what company they work for), I want to be sure I didn't misunderstand. > > I was about to comment on some of the items discussed in this thread,=20 > but wanted to be sure, first, that I understood this particular email=20 > about who was "welcome" to participate. I thought that Mark and David=20 > were providing an interface for providers and operators not=20 > comfortable with direct participation on IETF lists, and not that we=20 > were somehow "required" to go through them to have our opinions heard. > > Thanks, > Barbara > > Barbara Stark > AT&T > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Hemant Singh (shemant) > Sent: Sunday, July 06, 2008 8:20 PM > To: Francois-Xavier Le Bail; Wes Beebee (wbeebee) > Cc: v6ops@ops.ietf.org; MILES DAVID; Mark Townsley (townsley) > Subject: RE: new draft on IPv6 CPE router available for review > > Folks, > > Thanks for everyone's proposals and ideas, but we are not seriously=20 > looking at ideas from individual folks - it's not proving to be very=20 > productive. If you are a DSL or FIOS person, please send your=20 > proposals to David Miles who can collate all proposals and he will=20 > also work with Mark Townsley who works on DSL. We are working with=20 > David Miles and have already incorporated his requests from DSL folks=20 > in our next version of the draft. We don't need any proposals or ideas > for cable industry since we have that covered ourselves. > > Any other industry will be dealt by us on a case by case basis. > > Thanks. > > Hemant > > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Sunday, July 06, 2008 12:41 PM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: RE: new draft on IPv6 CPE router available for review > > You're right. > > I must explain more clearly my proposal. > > For the model where WAN interface only acquires a link-local address,=20 > I see two options for the interface which will be assigned a global=20 > IPv6 address sub-delegated from IA_PD via DHCPv6 : > > - If there is a logical LAN bridge, which is always up even if the LAN > interfaces attached to it are individualy down, CPE will use the=20 > bridge which will be assigned such a global IPv6 address. > These is no need to add a loopback interface. > > - Else the CPE router will use a Loopback interface which will be=20 > assigned such a global IPv6 address. > > Francois-Xavier > > --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > > =20 >> From: Hemant Singh (shemant) >> Subject: RE: new draft on IPv6 CPE router available for review >> To: "Francois-Xavier Le Bail" , "Wes Beebee=20 >> (wbeebee)" >> Cc: v6ops@ops.ietf.org >> Date: Sunday, July 6, 2008, 8:14 AM >> If the Service Provider has doled out an IA_PD option, then the CPE=20 >> Router always has the option to use a set of IPv6 >> address(es) from the >> IA_PD to configure on the LAN interface(s) of the CPE Router. >> >> Hemant >> >> -----Original Message----- >> From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] >> Sent: Saturday, July 05, 2008 8:18 AM >> To: Wes Beebee (wbeebee); Hemant Singh (shemant) >> Cc: v6ops@ops.ietf.org >> Subject: Re: new draft on IPv6 CPE router available for review >> >> --- On Wed, 7/2/08, Francois-Xavier Le Bail >> wrote: >> >> =20 >>> The CPE must also support IPv4, and for using one >>> =20 >> subnet in >> =20 >>> IPv4 world, it's a practice to have a LAN bridge >>> =20 >> with Ethernet, Wifi, >> =20 >>> etc. interfaces adding to it. >>> And this bridge is always up, even if the LAN >>> =20 >> interfaces are >> =20 >>> individualy down. >>> So binding the global-scope management address to this >>> =20 >> LAN bridge can >> =20 >>> be a way to consider. >>> =20 >> When the CPE router has only a link-local address on the WAN port, if >> the CPE has a LAN bridge, I hope there is an option to have the=20 >> global-scope address set on the LAN bridge (from IA_PD via >> DHCPv6) as an >> alternative to loopback solution. >> >> Do you agree ? >> >> Best Regards, >> >> Francois-Xavier >> =20 > > > =20 > > > ***** > > The information transmitted is intended only for the person or entity=20 > to which it is addressed and may contain confidential, proprietary,=20 > and/or privileged material. Any review, retransmission, dissemination=20 > or other use of, or taking of any action in reliance upon this=20 > information by persons or entities other than the intended recipient=20 > is prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. GA625 > > > > =20 From owner-v6ops@ops.ietf.org Mon Jul 7 10:36:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CD53A6915 for ; Mon, 7 Jul 2008 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp3idFKwl6cF for ; Mon, 7 Jul 2008 10:36:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A664F3A67E3 for ; Mon, 7 Jul 2008 10:36:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFubu-000KiI-KM for v6ops-data@psg.com; Mon, 07 Jul 2008 17:34:46 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFubh-000Kea-HT for v6ops@ops.ietf.org; Mon, 07 Jul 2008 17:34:44 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3N004F8CTIRS@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 12:34:30 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3N00IZNCTGXF@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 12:34:29 -0500 (CDT) Date: Mon, 07 Jul 2008 12:34:28 -0500 From: Frank Xia Subject: Re: new draft on IPv6 in Broadband Networks To: "Chip Popoviciu (cpopovic)" , v6ops@ops.ietf.org Cc: John Kaippallimalil Message-id: <006a01c8e057$b5aab7e0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <006401c8e03f$d80fe160$6f0c7c0a@china.huawei.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Chip As a co-author, I would like to share my idea before John's reply. IPv6 deployment is currently one of main topics in DSL forum. There are many arguments when applying IPv6 to DSL networks, even though IETF has multiple documents regarding IPv6 deployment. IMHO, there are two reasons for the disagreement: 1)Lacking communication between the two SDOs. 2)Generality of these documents resulting in ambiguity. This draft is trying to bridge the two SDOs, and provide enough detail for DSL deployment. Please see my other inline reply... BR Frank ----- Original Message ----- From: "Chip Popoviciu (cpopovic)" To: "John Kaippallimalil" ; Sent: Monday, July 07, 2008 10:56 AM Subject: RE: new draft on IPv6 in Broadband Networks John, This is a well written document. It seems to me that this document describes in great detail the deployment options summarized in Section 7.2.1 of RFC 4779 (which does covers not only DSL but also Cable and Ethernet as well)? In writing RFC 4779, we started with the same level of detail however, the WG thought and we agreed that it was too much information, especially considering the many types of environments and deployment options covered. The reader should be able to identify the details based on the deployment guidelines. Frank=>Unfortunately, there is no unanimous in DSL forum. If however we think that is not the case, then a detailed description such as the one in your document might be valuable. In that case, this might open the door for similar documents covering each of the other leading broadband access environments. Frank=>IMHO, it is better to have such kind of documents. 3GPP/WiMAX have already had the corresponding documents. Besides the detailed description of the proposals in RFC 4779, does this document bring something conceptually new in terms of deployment options for this access environment? Frank=>RFC4779 mainly focuses on ATM DSL architecture, while this draft is about Ethernet which is now popular. We introduce point-to-point and shared link model which are not new in IETF. Best Regards, Chip -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of John Kaippallimalil Sent: Monday, July 07, 2008 10:44 AM To: v6ops@ops.ietf.org Subject: new draft on IPv6 in Broadband Networks v6ops folks, Please review this draft: http://www.ietf.org/internet-drafts/draft-kaippallimalil-v6ops-ipv6-bbne t-00 .txt The abstract of the draft is snipped below: Abstract This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. Thanks, John & Frank From owner-v6ops@ops.ietf.org Mon Jul 7 11:06:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0689728C16A for ; Mon, 7 Jul 2008 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJgnJwON5s0O for ; Mon, 7 Jul 2008 11:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7854828C0E8 for ; Mon, 7 Jul 2008 11:06:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFv2R-000OCY-L3 for v6ops-data@psg.com; Mon, 07 Jul 2008 18:02:11 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFv25-000O8z-Bi for v6ops@ops.ietf.org; Mon, 07 Jul 2008 18:02:00 +0000 X-IronPort-AV: E=Sophos;i="4.30,317,1212364800"; d="scan'208";a="49633087" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2008 18:01:48 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67I1m7a006048; Mon, 7 Jul 2008 11:01:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m67I1clH011872; Mon, 7 Jul 2008 18:01:48 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 14:01:47 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 14:01:47 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oA== References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Francois-Xavier Le Bail" , "Wes Beebee (wbeebee)" Cc: , "MILES DAVID" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 07 Jul 2008 18:01:47.0389 (UTC) FILETIME=[85F152D0:01C8E05B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6347; t=1215453708; x=1216317708; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20; bh=ew+2iy499Y9tDiXQ+8zWrAEfKoLGgy/hacRDjSfAlJk=; b=CwnhxJq5AkCb3WH5KeI6rS99/n3s9O05iC5IZU/n4DFIHVeNqU95AjWY/x ZFevNRnvxDMVIKIW6e1KBDxEaEOWkxM6YNJ20RRdTxhiN4Rm93pU6PYjxbcT jj1dH3IaTY; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, I (Hemant) already replied to Mark's email and explained why I sent my email over the weekend. I have no problem with anyone stepping in and commenting - I was mistaken in thinking that we'd work with David Miles as one single contact from DSL folks. We, especially, welcome feedback from Service Provider (SP) operators since it is their network that gets affected by such a device. We published a new version of the draft today. This version caters to two big requests that came to us since posting of the -00 version. The requests were (a) to support only a link-local address on the WAN interface, and (b) to support a LAN up first before WAN behavior of the CPE Router. Please see Change Log for new version of the draft. =20 http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.txt Regards. Hemant & Wes -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Monday, July 07, 2008 12:10 PM To: Hemant Singh (shemant); Francois-Xavier Le Bail; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; MILES DAVID; Mark Townsley (townsley) Subject: RE: new draft on IPv6 CPE router available for review I'm sorry -- I just subscribed to this group last week (at the suggestion of David Miles and Mark Townsley). Can you please explain what you're saying here? I don't want to misinterpret what you're saying -- but to me it sounds as if you're asking DSL and FIOS access providers to not participate in the discussions on this list, or to provide feedback directly to the list? That we are only "permitted" to provide input via David or Mark? Since that's a very un-IETF way of doing things (where generally all individual opinions are welcome, independent of what company they work for), I want to be sure I didn't misunderstand. I was about to comment on some of the items discussed in this thread, but wanted to be sure, first, that I understood this particular email about who was "welcome" to participate. I thought that Mark and David were providing an interface for providers and operators not comfortable with direct participation on IETF lists, and not that we were somehow "required" to go through them to have our opinions heard. Thanks, Barbara Barbara Stark AT&T -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Sunday, July 06, 2008 8:20 PM To: Francois-Xavier Le Bail; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; MILES DAVID; Mark Townsley (townsley) Subject: RE: new draft on IPv6 CPE router available for review Folks, Thanks for everyone's proposals and ideas, but we are not seriously looking at ideas from individual folks - it's not proving to be very productive. If you are a DSL or FIOS person, please send your proposals to David Miles who can collate all proposals and he will also work with Mark Townsley who works on DSL. We are working with David Miles and have already incorporated his requests from DSL folks in our next version of the draft. We don't need any proposals or ideas for cable industry since we have that covered ourselves.=20 Any other industry will be dealt by us on a case by case basis. Thanks. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] Sent: Sunday, July 06, 2008 12:41 PM To: Wes Beebee (wbeebee); Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review You're right. I must explain more clearly my proposal. For the model where WAN interface only acquires a link-local address, I see two options for the interface which will be assigned a global IPv6 address sub-delegated from IA_PD via DHCPv6 : - If there is a logical LAN bridge, which is always up even if the LAN interfaces attached to it are individualy down, CPE will use the bridge which will be assigned such a global IPv6 address. These is no need to add a loopback interface. - Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address. Francois-Xavier --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: new draft on IPv6 CPE router available for review > To: "Francois-Xavier Le Bail" , "Wes Beebee=20 > (wbeebee)" > Cc: v6ops@ops.ietf.org > Date: Sunday, July 6, 2008, 8:14 AM > If the Service Provider has doled out an IA_PD option, then the CPE=20 > Router always has the option to use a set of IPv6 > address(es) from the > IA_PD to configure on the LAN interface(s) of the CPE Router. >=20 > Hemant >=20 > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Saturday, July 05, 2008 8:18 AM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review >=20 > --- On Wed, 7/2/08, Francois-Xavier Le Bail > wrote: >=20 > > The CPE must also support IPv4, and for using one > subnet in > > IPv4 world, it's a practice to have a LAN bridge > with Ethernet, Wifi, > > etc. interfaces adding to it. > > And this bridge is always up, even if the LAN > interfaces are > > individualy down. > > So binding the global-scope management address to this > LAN bridge can > > be a way to consider. >=20 > When the CPE router has only a link-local address on the WAN port, if=20 > the CPE has a LAN bridge, I hope there is an option to have the=20 > global-scope address set on the LAN bridge (from IA_PD via > DHCPv6) as an > alternative to loopback solution. >=20 > Do you agree ? >=20 > Best Regards, >=20 > Francois-Xavier =20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 From owner-v6ops@ops.ietf.org Mon Jul 7 11:37:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0543A683A for ; Mon, 7 Jul 2008 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjuCvvJnIVO4 for ; Mon, 7 Jul 2008 11:37:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 614383A6824 for ; Mon, 7 Jul 2008 11:37:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvZJ-0003Wp-Kg for v6ops-data@psg.com; Mon, 07 Jul 2008 18:36:09 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvZF-0003WN-Qp for v6ops@ops.ietf.org; Mon, 07 Jul 2008 18:36:07 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 759F5365; Mon, 7 Jul 2008 20:36:04 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: "Hemant Singh (shemant)" Subject: Re: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 21:36:02 +0300 User-Agent: KMail/1.9.9 Cc: "Wes Beebee (wbeebee)" , v6ops@ops.ietf.org References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807072136.03154.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le lundi 7 juillet 2008 21:01:47 Hemant Singh (shemant), vous avez =E9crit= =A0: > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.txt Note that if the home does not cascade CPE routers, then ULA's are not needed for the LAN interfaces, since link-local addresses are sufficient for configuration. After the WAN interface initializes, then the LAN interface(s) can acquire global unicast addresses. This is simply not true. Most (at least quite many) IPv6 applications are=20 incapable of using link-local addresses, owing to the peculiar way the sock= et=20 API deals with them. Namely, it requires that the socket address scope ID b= e=20 set. The only way to have fully operational LAN communications is to keep a= n=20 ULA prefix always, regardless of cascading. And it should preferably remain= =20 present even if the WAN connection has succeeded, so that: - pre-existing connections don't break needlessly when the WAN goes up, - boxes can easily check if a host is "outside" or "inside", - connections don't break if the delegated prefix changes. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 7 12:02:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386923A6B04 for ; Mon, 7 Jul 2008 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJRHkKOXo08k for ; Mon, 7 Jul 2008 12:02:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A42B3A6B1B for ; Mon, 7 Jul 2008 12:02:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvwK-0006f3-FU for v6ops-data@psg.com; Mon, 07 Jul 2008 18:59:56 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvwG-0006ec-Ez for v6ops@ops.ietf.org; Mon, 07 Jul 2008 18:59:54 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3N00D7HGROH8@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 13:59:49 -0500 (CDT) Received: from Kaippal73647 ([10.124.12.111]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3N00GYRGRJOL@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Mon, 07 Jul 2008 13:59:48 -0500 (CDT) Date: Mon, 07 Jul 2008 13:59:43 -0500 From: John Kaippallimalil Subject: RE: new draft on IPv6 in Broadband Networks In-reply-to: <006a01c8e057$b5aab7e0$5c0c7c0a@china.huawei.com> To: 'Frank Xia' , "'Chip Popoviciu (cpopovic)'" , v6ops@ops.ietf.org Message-id: <007701c8e063$9e9ea3c0$6f0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcjgV7X7Ym83eVmTRMSWpCmqcL2giwACT7cg Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Chip, I agree that this draft focuses on the point-to-point model in section 7.2.1 of RFC4779 with respect to addressing. There are a few more details in this draft especially with regard to the routed model with DHCP-PD and bridged model which we think is necessary for nomadic clients. As Frank mentions, we would like to draw on the expertise in v6ops to see if the recommendations we make regarding IPv6 are sound. Best Regards, John -----Original Message----- From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Monday, July 07, 2008 12:34 PM To: Chip Popoviciu (cpopovic); v6ops@ops.ietf.org Cc: John Kaippallimalil Subject: Re: new draft on IPv6 in Broadband Networks Hi Chip As a co-author, I would like to share my idea before John's reply. IPv6 deployment is currently one of main topics in DSL forum. There are many arguments when applying IPv6 to DSL networks, even though IETF has multiple documents regarding IPv6 deployment. IMHO, there are two reasons for the disagreement: 1)Lacking communication between the two SDOs. 2)Generality of these documents resulting in ambiguity. This draft is trying to bridge the two SDOs, and provide enough detail for DSL deployment. Please see my other inline reply... BR Frank ----- Original Message ----- From: "Chip Popoviciu (cpopovic)" To: "John Kaippallimalil" ; Sent: Monday, July 07, 2008 10:56 AM Subject: RE: new draft on IPv6 in Broadband Networks John, This is a well written document. It seems to me that this document describes in great detail the deployment options summarized in Section 7.2.1 of RFC 4779 (which does covers not only DSL but also Cable and Ethernet as well)? In writing RFC 4779, we started with the same level of detail however, the WG thought and we agreed that it was too much information, especially considering the many types of environments and deployment options covered. The reader should be able to identify the details based on the deployment guidelines. Frank=>Unfortunately, there is no unanimous in DSL forum. If however we think that is not the case, then a detailed description such as the one in your document might be valuable. In that case, this might open the door for similar documents covering each of the other leading broadband access environments. Frank=>IMHO, it is better to have such kind of documents. 3GPP/WiMAX have already had the corresponding documents. Besides the detailed description of the proposals in RFC 4779, does this document bring something conceptually new in terms of deployment options for this access environment? Frank=>RFC4779 mainly focuses on ATM DSL architecture, while this draft is about Ethernet which is now popular. We introduce point-to-point and shared link model which are not new in IETF. Best Regards, Chip -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of John Kaippallimalil Sent: Monday, July 07, 2008 10:44 AM To: v6ops@ops.ietf.org Subject: new draft on IPv6 in Broadband Networks v6ops folks, Please review this draft: http://www.ietf.org/internet-drafts/draft-kaippallimalil-v6ops-ipv6-bbne t-00 .txt The abstract of the draft is snipped below: Abstract This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture. Thanks, John & Frank From owner-v6ops@ops.ietf.org Mon Jul 7 12:33:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60213A6AAB for ; Mon, 7 Jul 2008 12:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN4kG6bDhzNX for ; Mon, 7 Jul 2008 12:33:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19E4D3A6B02 for ; Mon, 7 Jul 2008 12:33:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFwPe-000AcB-1b for v6ops-data@psg.com; Mon, 07 Jul 2008 19:30:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFwPa-000Abl-D1 for v6ops@ops.ietf.org; Mon, 07 Jul 2008 19:30:12 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 14EE93A6B00; Mon, 7 Jul 2008 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-tunnel-security-concerns-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707193002.14EE93A6B00@core3.amsl.com> Date: Mon, 7 Jul 2008 12:30:02 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : Security Concerns With Tunneling Author(s) : J. Hoagland, et al. Filename : draft-ietf-v6ops-tunnel-security-concerns-00.txt Pages : 20 Date : 2008-07-07 A number of security concerns with tunnels are documented. The primary intent of this document is to raise the awareness regarding the security issues with tunnels as deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-security-concerns-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-tunnel-security-concerns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-07122840.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Jul 7 13:24:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B1C3A68DF for ; Mon, 7 Jul 2008 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.27 X-Spam-Level: X-Spam-Status: No, score=-4.27 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC3mM0Kcwd4F for ; Mon, 7 Jul 2008 13:24:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0ECD3A680F for ; Mon, 7 Jul 2008 13:24:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxEd-000Hiw-HG for v6ops-data@psg.com; Mon, 07 Jul 2008 20:22:55 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxEY-000Hi3-K4 for v6ops@ops.ietf.org; Mon, 07 Jul 2008 20:22:52 +0000 X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="13443773" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2008 20:22:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67KMnNd021513; Mon, 7 Jul 2008 16:22:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m67KMnxa017495; Mon, 7 Jul 2008 20:22:49 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 16:22:49 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 16:22:49 -0400 Message-ID: In-Reply-To: <200807072136.03154.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjgYGBMpEnl+UXVTv+4kAwHcdb17AABds0g References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <200807072136.03154.rdenis@simphalempin.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Cc: "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 07 Jul 2008 20:22:49.0537 (UTC) FILETIME=[39C6A310:01C8E06F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2258; t=1215462169; x=1216326169; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20; bh=LC5tDA284aTb4gV0OV6Cp80VdxASFmkCTRD77aVSO6k=; b=q5JkESl8UkJZZiAolgJuBwcQa5DfKorX9Y+ZBr6nyMKVo2g1VItCDMkTsD Pkj8SlsVB67vldpC85+El1YeJiP9iLK5FwUMfiSamtwkCnRdfSN8l0K6zjP+ uyoPrlteY+; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Remi, Please see in line below between " and ".=20 -----Original Message----- From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com]=20 Sent: Monday, July 07, 2008 2:36 PM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Le lundi 7 juillet 2008 21:01:47 Hemant Singh (shemant), vous avez = =E9crit=A0: > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.t > xt Note that if the home does not cascade CPE routers, then ULA's are not needed for the LAN interfaces, since link-local addresses are sufficient for configuration. After the WAN interface initializes, then the LAN interface(s) can acquire global unicast addresses. This is simply not true. Most (at least quite many) IPv6 applications = are incapable of using link-local addresses, owing to the peculiar way = the socket API deals with them. Namely, it requires that the socket = address scope ID be set. The only way to have fully operational LAN = communications is to keep an ULA prefix always, regardless of cascading. = And it should preferably remain present even if the WAN connection has = succeeded, so that: - pre-existing connections don't break needlessly when the WAN goes up, We know a web browser can access the CPE Router on the same IPv6 LAN = segment using a link-local address - no denying that. Please tell us = what application that uses socket API is needed during manual = configuration when the CPE Router is being configured via the web? Or = what else needs to be done on the CPE Router besides manual = configuration (via web) for which sockets API break because the LAN = interface is assigned only a link-local address? As a side note, we do say in the draft once ULA is configured on the LAN = interface(s), the ULA co-exists with GUA (Global Unique Address). The = GUA gets assigned to the LAN interface(s) later when the WAN interface = completes acquisition of IA_PD. Hemant & Wes. - boxes can easily check if a host is "outside" or "inside", - connections don't break if the delegated prefix changes. -- R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 7 13:43:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3082428C17A for ; Mon, 7 Jul 2008 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39AllM8kb09z for ; Mon, 7 Jul 2008 13:43:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE7563A6B03 for ; Mon, 7 Jul 2008 13:43:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxVW-000JsX-7V for v6ops-data@psg.com; Mon, 07 Jul 2008 20:40:22 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxVE-000Jqt-Qn for v6ops@ops.ietf.org; Mon, 07 Jul 2008 20:40:13 +0000 X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="13453739" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2008 20:40:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67Ke3E1030903; Mon, 7 Jul 2008 16:40:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m67Ke3oQ020697; Mon, 7 Jul 2008 20:40:03 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 16:40:03 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 16:40:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACrnBJA= From: "Wes Beebee (wbeebee)" To: "Hemant Singh (shemant)" , "Francois-Xavier Le Bail" Cc: , "MILES DAVID" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 07 Jul 2008 20:40:03.0443 (UTC) FILETIME=[A2082C30:01C8E071] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3880; t=1215463203; x=1216327203; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22Francois-Xavier=20Le=20Bail =22=20; bh=E9D7QhS4hMxed3v4leuQqV1XVGedLojBcC3Bp8lfBj8=; b=sock36ZNOtQO1QENU+ljxOPWJ4n6NH/B+a39bFK4iLFfmethOYbD794ii3 NBiPslBvCBu6GrnJbQVrqGvbXpP2hmfmOJ44+0KFoRQg2eOvt+p9XQU4yJEK IbEufmML0V; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I just want to reiterate that we are happy to receive any comments that the WG members may have regarding our draft in the interest of making the draft better represent the WG consensus. In the future, we will make sure that we make frequent and timely updates to the draft so that we can ensure that the discussion moves in a forward direction. - Wes=20 -----Original Message----- From: Hemant Singh (shemant)=20 Sent: Sunday, July 06, 2008 8:20 PM To: 'Francois-Xavier Le Bail'; Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org; MILES DAVID; Mark Townsley (townsley) Subject: RE: new draft on IPv6 CPE router available for review Folks, Thanks for everyone's proposals and ideas, but we are not seriously looking at ideas from individual folks - it's not proving to be very productive. If you are a DSL or FIOS person, please send your proposals to David Miles who can collate all proposals and he will also work with Mark Townsley who works on DSL. We are working with David Miles and have already incorporated his requests from DSL folks in our next version of the draft. We don't need any proposals or ideas for cable industry since we have that covered ourselves.=20 Any other industry will be dealt by us on a case by case basis. Thanks. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] Sent: Sunday, July 06, 2008 12:41 PM To: Wes Beebee (wbeebee); Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review You're right. I must explain more clearly my proposal. For the model where WAN interface only acquires a link-local address, I see two options for the interface which will be assigned a global IPv6 address sub-delegated from IA_PD via DHCPv6 : - If there is a logical LAN bridge, which is always up even if the LAN interfaces attached to it are individualy down, CPE will use the bridge which will be assigned such a global IPv6 address. These is no need to add a loopback interface. - Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address. Francois-Xavier --- On Sun, 7/6/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: new draft on IPv6 CPE router available for review > To: "Francois-Xavier Le Bail" , "Wes Beebee=20 > (wbeebee)" > Cc: v6ops@ops.ietf.org > Date: Sunday, July 6, 2008, 8:14 AM > If the Service Provider has doled out an IA_PD option, then the CPE=20 > Router always has the option to use a set of IPv6 > address(es) from the > IA_PD to configure on the LAN interface(s) of the CPE Router. >=20 > Hemant >=20 > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Saturday, July 05, 2008 8:18 AM > To: Wes Beebee (wbeebee); Hemant Singh (shemant) > Cc: v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review >=20 > --- On Wed, 7/2/08, Francois-Xavier Le Bail > wrote: >=20 > > The CPE must also support IPv4, and for using one > subnet in > > IPv4 world, it's a practice to have a LAN bridge > with Ethernet, Wifi, > > etc. interfaces adding to it. > > And this bridge is always up, even if the LAN > interfaces are > > individualy down. > > So binding the global-scope management address to this > LAN bridge can > > be a way to consider. >=20 > When the CPE router has only a link-local address on the WAN port, if=20 > the CPE has a LAN bridge, I hope there is an option to have the=20 > global-scope address set on the LAN bridge (from IA_PD via > DHCPv6) as an > alternative to loopback solution. >=20 > Do you agree ? >=20 > Best Regards, >=20 > Francois-Xavier =20 From owner-v6ops@ops.ietf.org Mon Jul 7 13:45:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F4F3A6B03 for ; Mon, 7 Jul 2008 13:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evG2WhvXvqJJ for ; Mon, 7 Jul 2008 13:45:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 391F628C21E for ; Mon, 7 Jul 2008 13:45:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxa1-000KYM-UC for v6ops-data@psg.com; Mon, 07 Jul 2008 20:45:01 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxZo-000KWr-Rl for v6ops@ops.ietf.org; Mon, 07 Jul 2008 20:44:59 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id DF05833F6; Mon, 7 Jul 2008 22:44:47 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: "Hemant Singh (shemant)" Subject: Re: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 23:44:46 +0300 User-Agent: KMail/1.9.9 Cc: "Wes Beebee (wbeebee)" , v6ops@ops.ietf.org References: <200807072136.03154.rdenis@simphalempin.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807072344.46609.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le lundi 7 juillet 2008 23:22:49 Hemant Singh (shemant), vous avez =E9crit= =A0: > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com] > Sent: Monday, July 07, 2008 2:36 PM > To: Hemant Singh (shemant) > Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review > > Le lundi 7 juillet 2008 21:01:47 Hemant Singh (shemant), vous avez =E9cri= t=A0: > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.t > > xt > > Note that if the home does not cascade CPE routers, then ULA's are > not needed for the LAN interfaces, since link-local addresses are > sufficient for configuration. After the WAN interface initializes, > then the LAN interface(s) can acquire global unicast addresses. > > This is simply not true. Most (at least quite many) IPv6 applications are > incapable of using link-local addresses, owing to the peculiar way the > socket API deals with them. Namely, it requires that the socket address > scope ID be set. The only way to have fully operational LAN communications > is to keep an ULA prefix always, regardless of cascading. And it should > preferably remain present even if the WAN connection has succeeded, so > that: - pre-existing connections don't break needlessly when the WAN goes > up, > > > We know a web browser can access the CPE Router on the same IPv6 LAN > segment using a link-local address - no denying that. Please tell us what > application that uses socket API is needed during manual configuration wh= en > the CPE Router is being configured via the web? Or what else needs to be > done on the CPE Router besides manual configuration (via web) for which > sockets API break because the LAN interface is assigned only a link-local > address? I tried two different browsers. In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a=20 connection failure. I had to type=20 http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI=20 spec, and requires that I know how my network interface is called. Also, any protocol that embeds IPv6 addresses will fail, since the scope=20 specifier is host-specific such that there is no sane way to convey it acro= ss=20 the network. > As a side note, we do say in the draft once ULA is configured on the LAN > interface(s), the ULA co-exists with GUA (Global Unique Address). The GUA > gets assigned to the LAN interface(s) later when the WAN interface > completes acquisition of IA_PD. I am well aware of that. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 7 13:59:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455883A6B64 for ; Mon, 7 Jul 2008 13:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HseSV9tNeYPs for ; Mon, 7 Jul 2008 13:59:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09CF23A6B5B for ; Mon, 7 Jul 2008 13:59:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxma-000MOw-95 for v6ops-data@psg.com; Mon, 07 Jul 2008 20:58:00 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFxmV-000MOR-O9 for v6ops@ops.ietf.org; Mon, 07 Jul 2008 20:57:57 +0000 X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="13447874" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2008 20:57:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m67KvsaB007895; Mon, 7 Jul 2008 16:57:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m67KvsF9003176; Mon, 7 Jul 2008 20:57:54 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 16:57:54 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 7 Jul 2008 16:58:11 -0400 Message-ID: In-Reply-To: <200807072344.46609.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjgcmGiaBiOfbIbR6StIGrVLYvyyAAAVm/w From: "Wes Beebee (wbeebee)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Hemant Singh (shemant)" Cc: X-OriginalArrivalTime: 07 Jul 2008 20:57:54.0799 (UTC) FILETIME=[209C1FF0:01C8E074] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3423; t=1215464274; x=1216328274; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20,=0A=20=20=20=20=20=20=20=20=22Hemant=20 Singh=20(shemant)=22=20; bh=VItm0+m3m2XY3ifnyzTosxueosIZBLx9i/HBpvRYxlY=; b=n0IruZr41pn+czLWFNx0fxgUwlOdsVYWHVUmXWdwvhraBPIzTvpAU9IkUB mCPkqNVgxqpecvDiZFK7qWfmkk3Sq0FFWz/YVlsyqLCd8Ul3uZIsmZ6XHGEB DdG28pB+Uh; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Note that while it is possible to use link-locals to configure the CPE = Router (when they are not cascaded), it may be inconvenient to do so as = you point out. Therefore, we will remove the following sentence from = the draft: "Note that if the home does not cascade CPE routers, then ULA's are not = needed for the LAN interfaces, since link-local addresses are sufficient = for configuration." Thanks, - Wes and Hemant -----Original Message----- From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com]=20 Sent: Monday, July 07, 2008 4:45 PM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: Re: new draft on IPv6 CPE router available for review Le lundi 7 juillet 2008 23:22:49 Hemant Singh (shemant), vous avez = =E9crit=A0: > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com] > Sent: Monday, July 07, 2008 2:36 PM > To: Hemant Singh (shemant) > Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org > Subject: Re: new draft on IPv6 CPE router available for review > > Le lundi 7 juillet 2008 21:01:47 Hemant Singh (shemant), vous avez = =E9crit=A0: > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01 > > .t > > xt > > Note that if the home does not cascade CPE routers, then ULA's are > not needed for the LAN interfaces, since link-local addresses are > sufficient for configuration. After the WAN interface initializes, > then the LAN interface(s) can acquire global unicast addresses. > > This is simply not true. Most (at least quite many) IPv6 applications=20 > are incapable of using link-local addresses, owing to the peculiar way = > the socket API deals with them. Namely, it requires that the socket=20 > address scope ID be set. The only way to have fully operational LAN=20 > communications is to keep an ULA prefix always, regardless of=20 > cascading. And it should preferably remain present even if the WAN=20 > connection has succeeded, so > that: - pre-existing connections don't break needlessly when the WAN=20 > goes up, > > > We know a web browser can access the CPE Router on the same IPv6 LAN=20 > segment using a link-local address - no denying that. Please tell us=20 > what application that uses socket API is needed during manual=20 > configuration when the CPE Router is being configured via the web? Or=20 > what else needs to be done on the CPE Router besides manual=20 > configuration (via web) for which sockets API break because the LAN=20 > interface is assigned only a link-local address? I tried two different browsers. In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a = connection failure. I had to type = http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI = spec, and requires that I know how my network interface is called. Also, any protocol that embeds IPv6 addresses will fail, since the scope = specifier is host-specific such that there is no sane way to convey it = across the network. > As a side note, we do say in the draft once ULA is configured on the=20 > LAN interface(s), the ULA co-exists with GUA (Global Unique Address). = > The GUA gets assigned to the LAN interface(s) later when the WAN=20 > interface completes acquisition of IA_PD. I am well aware of that. -- R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 7 17:15:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C5A28C36B for ; Mon, 7 Jul 2008 17:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO5dGwyAD0To for ; Mon, 7 Jul 2008 17:15:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DF0D28C35E for ; Mon, 7 Jul 2008 17:15:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG0l1-000LKn-Jg for v6ops-data@psg.com; Tue, 08 Jul 2008 00:08:35 +0000 Received: from [64.233.166.179] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG0ky-000LKQ-1S for v6ops@ops.ietf.org; Tue, 08 Jul 2008 00:08:33 +0000 Received: by py-out-1112.google.com with SMTP id d32so1130552pye.19 for ; Mon, 07 Jul 2008 17:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GMv7PGGDMNvorus84tUHuTr9vQQLmizD9+e0zBX+qvM=; b=l+qbblVUy+rS/e4P0wuPpeEm9d0OwW8T8YjBHEPklKqDdFKcr7GihDewdUlCsSQYMV kJ+lN5ZB56P+z/yOLUxpZP/xkRGYtkzTNN0BWhH4LVIDDPb5D36E2CP2CCk3q48M4cf0 ImpPb1fY5JLMU2LyLheC45HUyRh67e0sBamd4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=dRAqjFLuNfGgWanMHhxfxXqdBAqkqMzA6agnH+Ac07eA41TE0S3HV3y2e3o6UpoD3W cTnJUmWm7wlJHuA65jPOP0Tjpv0Ph3tDkd3b9z8ujqBgVzjk1er8wIN4n3wlKQZ4BjZF NOPs4rlkxGxyo4ziXUssBYWTQKL0sKhhrWURg= Received: by 10.114.196.1 with SMTP id t1mr7216687waf.80.1215475709236; Mon, 07 Jul 2008 17:08:29 -0700 (PDT) Received: from ?10.1.1.4? ( [118.93.5.148]) by mx.google.com with ESMTPS id l28sm5988175waf.5.2008.07.07.17.08.27 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Jul 2008 17:08:28 -0700 (PDT) Message-ID: <4872982B.40309@gmail.com> Date: Tue, 08 Jul 2008 10:26:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Conrad CC: Ralph Droms , IPv6 Operations Subject: Re: new draft on IPv6 CPE router available for review References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-04 08:45, David Conrad wrote: > On Jul 3, 2008, at 12:54 PM, Ralph Droms wrote: >> there won't be any motivation for NAT. > > Provider independence. For domestic subscribers (i.e. the mass market for CPE) this simply isn't an issue. Each time they restart the CPE they will get new addresses via SLAAC; that's no different than getting new v4 addresses via DHCP. It's a matter of total indifference whether they get an RFC1918 address, a public v4 address, or a v6 address, for the mass market user. As long as it works. Brian From owner-v6ops@ops.ietf.org Mon Jul 7 17:15:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1BD28C36B for ; Mon, 7 Jul 2008 17:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZRTxWOzEEM3 for ; Mon, 7 Jul 2008 17:15:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3683328C368 for ; Mon, 7 Jul 2008 17:15:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG0l3-000LLF-PS for v6ops-data@psg.com; Tue, 08 Jul 2008 00:08:37 +0000 Received: from [209.85.146.183] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG0kz-000LKa-S4 for v6ops@ops.ietf.org; Tue, 08 Jul 2008 00:08:35 +0000 Received: by wa-out-1112.google.com with SMTP id j37so1488333waf.23 for ; Mon, 07 Jul 2008 17:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xvs0fKOwaL/mCbAMssM9D/eB9cqxQZsNhBFBEDzNfdQ=; b=kewoEDTO+3xDh/rnA9Ia726rQuLgPrd15Zc6O3xDTdPiO20+NybglfnZj8e/XSAJLx XdEMt2/6FqeEHmGOTPzT3GVOo7WRBAx/f7yd9ryUBdt32CyFWqh9BwqM0ImwmrpxoqJY Ql7PMFr5cgnCk2V0gCi+Lth7ufpfB2fhTFj5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tC3sZwfbiARMBvpdzl8VGmfOoICvV32QsEtM6B+bXGuBhXZjjNfnY9mibqRbcs3+Bd bBTsEjPU5+kdSzC2TcXcSf6Fje+9c9r5CM5EkrVqA1Q1glIqdhyDXKA2gmXEMVhs62S5 Sm+ITcj6dwfaLpK7FfPLhE6ZbPDslpiYADXRk= Received: by 10.115.18.1 with SMTP id v1mr7209120wai.81.1215475713326; Mon, 07 Jul 2008 17:08:33 -0700 (PDT) Received: from ?10.1.1.4? ( [118.93.5.148]) by mx.google.com with ESMTPS id k37sm5966830waf.31.2008.07.07.17.08.31 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Jul 2008 17:08:32 -0700 (PDT) Message-ID: <4872A3D4.4060104@gmail.com> Date: Tue, 08 Jul 2008 11:16:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt References: <20080630153001.52D673A6AC3@core3.amsl.com> In-Reply-To: <20080630153001.52D673A6AC3@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, some comments on other points. > 5.3. Acquire IPv6 address and other configuration parameters I suggest that if address acquistion by DHCPv6 fails, there should be a (configurable) option to discover a 6to4 relay. CPE routers were in fact a target when 6to4 was designed. It only needs a few lines and a reference to RFC 3056 and 3068. Also I suggest that there should be a configurable option to generate and support a ULA prefix. Again, a few lines and a reference to RFC 4193. > 6. IPv6 Data forwarding ... > Each protocol that the CPE > Router can forward packets for must have a separate routing table. I've read that sentence several times and can't understand it. Do you simply mean that the IPv6 table is separate from IPv4? ... > Before forwarding a packet > in any direction from CPE router, the CPE Router will perform a MAC > rewrite operation that rewrites the source L2 address of the packet > with CPE Router's WAN or LAN interface MAC address. I also don't understand that sentence. Surely a router moves an L3 packet from one L2 interface to another, and removing and creating L2 headers is nothing to do with routing as such? > 7.1. Path MTU Discovery Support > > GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the > CPE Router), This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has nothing to do with GRE. In fact any kind of Protocol 41 tunnel can interfere with MTU too - do you expect a typical CPE to support generic Protocol 41 tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"? > 8. Quality Of Service(QoS) > > The CPE router may map the IPv6 Traffic Class field from [RFC2460] to > individual queues of different priority to provide differentiated > classes of service for traffic either destined to the LAN or WAN > interfaces (e.g. for IPTV service). You shouldn't use the word 'priority' because the diffserv model is not about priority. Better to use 'behavior' plus a reference to RFC 2474. In fact, the whole thing can be expressed as The CPE router MAY support differentiated services [RFC2474]. Brian From owner-v6ops@ops.ietf.org Mon Jul 7 19:33:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5655C3A6AB2 for ; Mon, 7 Jul 2008 19:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.675 X-Spam-Level: X-Spam-Status: No, score=0.675 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBgf656yHduZ for ; Mon, 7 Jul 2008 19:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75ECD3A69B9 for ; Mon, 7 Jul 2008 19:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG2wc-000CP7-Bg for v6ops-data@psg.com; Tue, 08 Jul 2008 02:28:42 +0000 Received: from [210.160.15.5] (helo=mgw1.noc.ntt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG2wP-000CNq-EK for v6ops@ops.ietf.org; Tue, 08 Jul 2008 02:28:40 +0000 Received: from mop3.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id m682Qe4i002604 for ; Tue, 8 Jul 2008 11:28:28 +0900 (JST) Received: from mip1.noc.ntt.com (mvi1.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0K3O001LQ1I8ZF@ntt.com> for v6ops@ops.ietf.org; Tue, 08 Jul 2008 11:27:45 +0900 (JST) Date: Tue, 08 Jul 2008 11:26:39 +0900 From: "Tomohiro Nishitani" Subject: Re: New I-D on Carrier Grade NAT In-reply-to: Cc: v6ops@ops.ietf.org Message-id: <4872D05F.6040606@ntt.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) References: <486D8D8F.1060009@ntt.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Eric. > Tomohiro Nishitani writes: >> Hi, >> I submitted new draft on Carrier Grade NAT. >> "Carrier Grade Network Address Translator (NAT) Behavioral Requirements >> for Unicast UDP, TCP and ICMP" >> http://www.ietf.org/internet-drafts/draft-nishitani-cgn-00.txt >> Abstract of our draft is as follows: >> --- >> This document defines basic terminology for describing different >> types of carrier-grade Network Address Translation (NAT) behavior >> when handling Unicast UDP, TCP and ICMP. Developing carrier-grade >> NATs that meet this set of requirements increase transparency of data >> between carrier networks. >> --- > > As much as I am all for killing NAT as soon as we can, I understand > the potential need for such a device as currently carriers are doing > just this using multiple devices (and frequently nesting NATs). > I would prefer that the Abstract was changed to the following: > This document defines basic terminology for describing different\types > of carrier-grade IPv4 Network Address Translation (NAT) behavior when > handling Unicast UDP, TCP and ICMP. Developing carrier-grade NATs that > meet this set of requirements increase transparency of data between > carrier networks. > Where there is an emphasis on the fact that this is IPv4 only, not a > backdoor for bringing NAT into v6. > I also think you need to consider the requirements for non-stationary > devices as these are starting to be more common and will complicate > CGN to no end as they move from one cell site to another or into a new > carrier while trying to maintain their IP session (most critical if it > is UDP based). > Eric > Eric > I appreciate the decirption that developing carrier-grade NATs that meet this set of requirements increase transparency of data between carrier networks. As you indicated, I don't consider movable devices. If a carrier supplies wireless access services, it may be need to consider your indication. I think trying to maintain their IP session may not be behavior of CGN but CPE or teminal. Best Regard, Tomohiro Nishitani -- Tomohiro Nishitani Chief, Network Systems and Technologies, Innovative IP Architecture Center NTT Communications Corporation tomohiro.nishitani@ntt.com TEL: +81-3-6800-3214 From qujnlgyewc@glenncarter.com Mon Jul 7 21:42:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15AB43A68B4; Mon, 7 Jul 2008 21:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.888 X-Spam-Level: *** X-Spam-Status: No, score=3.888 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlJU7ez2lWjt; Mon, 7 Jul 2008 21:42:04 -0700 (PDT) Received: from proxyrouter1.eatontownpolice.com (unknown [81.214.33.221]) by core3.amsl.com (Postfix) with SMTP id 205BC3A6405; Mon, 7 Jul 2008 21:41:55 -0700 (PDT) Received: from 64.127.111.2038 (l13.mypoints.com) (64.127.111.2038) by smtp160.mail.re6.girlday.com with SMTP; Mon, 07 Jul 2008 21:42:04 -0800 Message-ID: Date: Mon, 07 Jul 2008 21:42:04 -0800 (PDT) From: "maegan" Reply-to: "maegan" To: v6ops-archive@lists.ietf.org Subject: it`s maegan MIME-Version: 1.0 Content-Type: text/plain hello, I am pretty russian girl, bored tonight. would you like to chat with me and see my pics? if so then email me at emaegan1@hugdr.info From owner-v6ops@ops.ietf.org Mon Jul 7 22:43:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868EF3A68B4 for ; Mon, 7 Jul 2008 22:43:21 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISzOMRWkRSjR for ; Mon, 7 Jul 2008 22:43:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7519B3A67D9 for ; Mon, 7 Jul 2008 22:43:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG5sU-0008Hp-GL for v6ops-data@psg.com; Tue, 08 Jul 2008 05:36:38 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG5sQ-0008HK-4B for v6ops@ops.ietf.org; Tue, 08 Jul 2008 05:36:36 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 03069ADAD9; Tue, 8 Jul 2008 07:36:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E6664ADAD8; Tue, 8 Jul 2008 07:36:31 +0200 (CEST) Date: Tue, 8 Jul 2008 07:36:31 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" cc: "Wes Beebee (wbeebee)" , v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review In-Reply-To: Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 7 Jul 2008, Hemant Singh (shemant) wrote: > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.txt Hi, I am happy with the writing of the first chapter of 5.3.2, but the second chapter perhaps needs to be lifted out of 5.3.2 as it refers to text both in 5.3.1 and 5.3.2 ? Perhaps the second chapter of 5.3.2 needs to be 5.3.3? If indeed intended for 5.3.2, perhaps the mention of WAN globally routable IP address is a typo? In 9, would it make sense to also mention other queuing and marking mechanisms? I think home users would be very much helped by other queuing mechanisms than a few fifo queues? To my home (I use cisco routers) I have a fairly advanced set of bandwidth reservation queues and do fair-queue on the rest of the traffic, and this helps a lot compared to just fifo in each queue. I would love to see this functionality in smaller devices as well, as this would most likely help the "I have 24/1 ADSL and when I run bittorrent and upload, my download speeds drop)", as a more advanced queuing algorithm could prioritize TCP ACK packets (or just small packets in general). I believe Linux already has a lot of this, so for a vendor using embedded Linux, this would be fairly easy to enable and recommending it in the draft might help them in their decision to do so. Apart from that, I am grateful that you included the unnumbered model as an option in the draft. Thanks a lot! Regards, -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 8 00:39:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E721D3A686B for ; Tue, 8 Jul 2008 00:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LblnpOS6CoK for ; Tue, 8 Jul 2008 00:39:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F8D73A67B3 for ; Tue, 8 Jul 2008 00:39:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG7jB-000PRm-Uo for v6ops-data@psg.com; Tue, 08 Jul 2008 07:35:09 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG7j7-000PR9-W1 for v6ops@ops.ietf.org; Tue, 08 Jul 2008 07:35:08 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id D31C033EC; Tue, 8 Jul 2008 09:35:04 +0200 (CEST) To: v6ops@ops.ietf.org Subject: Re: MIME-Version: 1.0 Date: Tue, 08 Jul 2008 09:35:04 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: mid:100 References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 Message-ID: X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 08 Jul 2008 11:16:36 +1200, wrote: > I suggest that if address acquistion by DHCPv6 fails, there > should be a (configurable) option to discover a 6to4 > relay. CPE routers were in fact a target when 6to4 was designed. > It only needs a few lines and a reference to RFC 3056 and 3068. While I don't necessarily disagree with the high-level idea, I am not a big fan of automatically configuring 6to4 gatewaying on the sole basis of having an IPv4 address. I have had multiple cases of public IPv4 addresses with non working 6to4 relay: - no anycast 6to4 routing, - anycast 6to4 relay temporarily broken, - public IPv4 address space behind a NAT (!), - stateless firewall that drops proto-41, - statefull firewall that tracks proto-41 "bindings"... I wish private IPv4 addresses had the same scope as public IPv4 addresses within RFC3484 - then broken 6to4 would not be so much of a problem anymore. > Also I suggest that there should be a configurable option > to generate and support a ULA prefix. Again, a few lines > and a reference to RFC 4193. Yes. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Tue Jul 8 03:06:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CE83A6875 for ; Tue, 8 Jul 2008 03:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lln4ZZ55x3Qd for ; Tue, 8 Jul 2008 03:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCAF93A686B for ; Tue, 8 Jul 2008 03:06:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG9yY-000Hnt-Un for v6ops-data@psg.com; Tue, 08 Jul 2008 09:59:10 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KG9yL-000HmL-KZ for v6ops@ops.ietf.org; Tue, 08 Jul 2008 09:59:05 +0000 Received: (qmail 5117 invoked by uid 417); 8 Jul 2008 09:57:50 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 8 Jul 2008 09:57:50 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Tue, 08 Jul 2008 03:57:50 -0600 References: <486D8D8F.1060009@ntt.com> <4872D05F.6040606@ntt.com> In-Reply-To: <4872D05F.6040606@ntt.com> From: EricLKlein@softhome.net To: "Tomohiro Nishitani" Cc: v6ops@ops.ietf.org Subject: Re: New I-D on Carrier Grade NAT Date: Tue, 08 Jul 2008 03:57:50 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [192.117.238.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Tomohiro, Tomohiro Nishitani writes: >> I also think you need to consider the requirements for non-stationary >> devices as these are starting to be more common and will complicate >> CGN to no end as they move from one cell site to another or into a new >> carrier while trying to maintain their IP session (most critical if it >> is UDP based). >> Eric >> Eric >> > I appreciate the decirption that developing carrier-grade NATs that meet > this set of > requirements increase transparency of data between carrier networks. > > As you indicated, I don't consider movable devices. If a carrier > supplies wireless access > services, it may be need to consider your indication. I think trying to > maintain their IP session > may not be behavior of CGN but CPE or teminal. I am not sure how it works in 3GPP or other cellular data networks, but in 802.16e WiMAX there is an ASN (Access Service Network ), this is a device that is responsible for maintaining the session as the device crosses between cell sites, and carriers. (The Access Service Network in WiMAX: The Role of ASN-GW" http://www.mustafaergen.com/asn-gw.pdf)) This device may also be the one responsible for DHCP(v4 and v6). I am not sure how a CPE would be capable of telling the network where to pass an UDP session on to the next base station (cell site) without loosing the session, thus it is a feature of the CGN (as represented by the ASN gateway). Eric From owner-v6ops@ops.ietf.org Tue Jul 8 07:31:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67363A68D6 for ; Tue, 8 Jul 2008 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFixBwT4HFm2 for ; Tue, 8 Jul 2008 07:31:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CBA73A68A0 for ; Tue, 8 Jul 2008 07:31:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGE8A-000J46-Nz for v6ops-data@psg.com; Tue, 08 Jul 2008 14:25:22 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGE83-000J3M-HM for v6ops@ops.ietf.org; Tue, 08 Jul 2008 14:25:17 +0000 X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="13524019" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2008 14:25:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m68EPCJF009973; Tue, 8 Jul 2008 10:25:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m68EPCUG010267; Tue, 8 Jul 2008 14:25:12 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 10:25:12 -0400 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 Subject: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Date: Tue, 8 Jul 2008 10:25:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Thread-Index: AcjgkB9/KedfdDzKSEiuPoc8eGk5SwAb2FNAAAGrpyA= From: "Wes Beebee (wbeebee)" To: , X-OriginalArrivalTime: 08 Jul 2008 14:25:12.0213 (UTC) FILETIME=[6EA09450:01C8E106] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4712; t=1215527112; x=1216391112; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20FW=3A=20I-D=20Action=3Adraft-wbeebee-ipv6-cpe-r outer-00.txt |Sender:=20 |To:=20,=20; bh=iNNHFDD3tz6SPwBVg7MWXsT2ATvE3RBqpTUNue6hfY4=; b=Q5wX4uye7zDfl0JiG/SUI2JuxKlikeWji+Egkb08S/mS/tMFhBYaVkvVwj QhnhEZoZnb09b04EeHuqHNno0kLzDThQTksqcTH5lbHFICKV/Zp8jGHkT+bc 3QGpc7fLX3; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, Thanks for the comments. Please see in line below between comments and .=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 07, 2008 7:17 PM To: IPv6 Operations Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Hi, some comments on other points. > 5.3. Acquire IPv6 address and other configuration parameters I suggest that if address acquistion by DHCPv6 fails, there should be a (configurable) option to discover a 6to4 relay. CPE routers were in fact a target when 6to4 was designed. It only needs a few lines and a reference to RFC 3056 and 3068. Sorry, we don't agree. Also times have changed since 2001 when RFC3056 of RFC3068 were authored. This CPE Router can also be deployed in a cable deployment which is IPv6 ready between the home and aggregator (CMTS). Since the CPE Router initiated DHCPv6, the Service Provider router in the upstream has issued an RA to the CPE Router. Therefore if DHCPv6 fails, something is wrong in the Service Provider network for provisioning. Of course, there could be a malformed DHCPv6 message from the CPE Router as well - but that's not the point. In a totally IPv6 ready network it doesn't make sense for the CPE Router to fall back to discover any 6to4 relay. If DHCPv6 fails in such a deployment, the Router's IPv6 functionality is dead. For DSL, which is not an IPv6 ready network yet, one plan I have seen from industry is softwires. The softwire creates a L2TP tunnel to carry ipv6 traffic in a ipv4 tunnel: http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08 In the softwire case, the L2TP tunnel is already created before DHCPv6 is initiated, so if DHCPv6 fails, then even this deployment has IPv6 services dead. Discovering a 6to4 relay is adding extra states to the state machine of the CPE Router. We are very careful adding any extra state machine to the CPE Router. We could configure whether you want 6to4 tunnel or DHCPv6 before the state machine for either DHCPv6 or 6to4 starts. That would simplify the state machine.=20 Also I suggest that there should be a configurable option to generate and support a ULA prefix. Again, a few lines and a reference to RFC 4193. Please see the -01 draft where we discuss assignment of ULA to LAN interface(s) of the CPE Router. > 6. IPv6 Data forwarding ... > Each protocol that the CPE > Router can forward packets for must have a separate routing table. I've read that sentence several times and can't understand it. Do you simply mean that the IPv6 table is separate from IPv4? Yes. This statement is kind of obvious and probably doesn't need to be stated. ... > Before forwarding a packet > in any direction from CPE router, the CPE Router will perform a MAC > rewrite operation that rewrites the source L2 address of the packet > with CPE Router's WAN or LAN interface MAC address. =20 I also don't understand that sentence. Surely a router moves an L3 packet from one L2 interface to another, and removing and creating L2 headers is nothing to do with routing as such? Yes, but it's only a router that performs a mac rewrite. A bridge or switch does not do that. That is why such text exists in our draft. We would like to keep it.=20 > 7.1. Path MTU Discovery Support >=20 > GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the > CPE Router), This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has nothing to do with GRE. In fact any kind of Protocol 41 tunnel can interfere with MTU too - do you expect a typical CPE to support generic Protocol 41 tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"? Sorry, we didn't use correct terminology. We did mean IPv6 in IPv4. We'll change the text to say IPv6 in IPv4. =20 > 8. Quality Of Service(QoS) >=20 > The CPE router may map the IPv6 Traffic Class field from [RFC2460] to > individual queues of different priority to provide differentiated > classes of service for traffic either destined to the LAN or WAN > interfaces (e.g. for IPTV service). You shouldn't use the word 'priority' because the diffserv model is not about priority. Better to use 'behavior' plus a reference to RFC 2474. In fact, the whole thing can be expressed as The CPE router MAY support differentiated services [RFC2474]. Great suggestion. We will take it. Thanks. Wes & Hemant Brian From owner-v6ops@ops.ietf.org Tue Jul 8 07:50:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3734E3A6A73 for ; Tue, 8 Jul 2008 07:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLXnyKdC43Os for ; Tue, 8 Jul 2008 07:50:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B40E3A6A38 for ; Tue, 8 Jul 2008 07:50:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGETM-000LI6-AC for v6ops-data@psg.com; Tue, 08 Jul 2008 14:47:16 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGET1-000LGD-S0 for v6ops@ops.ietf.org; Tue, 08 Jul 2008 14:47:02 +0000 X-IronPort-AV: E=Sophos;i="4.30,323,1212364800"; d="scan'208";a="13518480" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2008 14:46:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m68EksXo022525; Tue, 8 Jul 2008 10:46:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m68Ekscd019702; Tue, 8 Jul 2008 14:46:54 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 10:46:54 -0400 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Tue, 8 Jul 2008 10:46:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjgvJtqZWFHOWdmSjmvv+vu+f+M8gAS9f/g References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" Cc: "Wes Beebee (wbeebee)" , X-OriginalArrivalTime: 08 Jul 2008 14:46:54.0627 (UTC) FILETIME=[76ED2F30:01C8E109] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2402; t=1215528414; x=1216392414; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router= 20available=20for=20review |Sender:=20 |To:=20=22Mikael=20Abrahamsson=22=20; bh=6nDOtqyLXRrvelMGi5FxqduQLBnjMW71IlQi7B2KhQM=; b=EiqkpezWWCy3yyFN894j1kjp4MSK6ZzvLd9LWIBugcIeGYhYDEzuPZgojb 8BssjyaGYSSlxjQIODYvaIxvSicRv/1V9kk6FFYnimDl+8ArhY0cY6X1XnAj 34b15ZBPP2; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, What you are referring to as a "chapter", I call it a paragraph. Yes, indeed, the second paragraph at the end of section 5.3.2 is meant for both sections 5.3.1 and 5.3.2, but xml formatting makes it look like the paragraph is for section 5.3.2 only. We'll see what we can do about that. =20 As for section 9, we don't plan to get into suggestions for queuing. It's left to the CPE Router vendor to do what they want. However, if the community would like us to add more details to this section for queuing algorithms, we can add that. But more people have to ask for it. Thanks. Hemant -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, July 08, 2008 1:37 AM To: Hemant Singh (shemant) Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org Subject: RE: new draft on IPv6 CPE router available for review On Mon, 7 Jul 2008, Hemant Singh (shemant) wrote: > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.t > xt Hi, I am happy with the writing of the first chapter of 5.3.2, but the second chapter perhaps needs to be lifted out of 5.3.2 as it refers to text both in 5.3.1 and 5.3.2 ? Perhaps the second chapter of 5.3.2 needs to be 5.3.3? If indeed intended for 5.3.2, perhaps the mention of WAN globally routable IP address is a typo? In 9, would it make sense to also mention other queuing and marking mechanisms? I think home users would be very much helped by other queuing mechanisms than a few fifo queues? To my home (I use cisco routers) I have a fairly advanced set of bandwidth reservation queues and do fair-queue on the rest of the traffic, and this helps a lot compared to just fifo in each queue. I would love to see this functionality in smaller devices as well, as this would most likely help the "I have 24/1 ADSL and when I run bittorrent and upload, my download speeds drop)", as a more advanced queuing algorithm could prioritize TCP ACK packets (or just small packets in general). I believe Linux already has a lot of this, so for a vendor using embedded Linux, this would be fairly easy to enable and recommending it in the draft might help them in their decision to do so. Apart from that, I am grateful that you included the unnumbered model as an option in the draft. Thanks a lot! Regards, --=20 Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Tue Jul 8 10:00:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF823A6810 for ; Tue, 8 Jul 2008 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTk663k6IAOw for ; Tue, 8 Jul 2008 10:00:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B22B3A6AA7 for ; Tue, 8 Jul 2008 10:00:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGGT5-0008KK-Qd for v6ops-data@psg.com; Tue, 08 Jul 2008 16:55:07 +0000 Received: from [64.65.64.68] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGGT2-0008Js-5K for v6ops@ops.ietf.org; Tue, 08 Jul 2008 16:55:05 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 1D4DED0064; Tue, 8 Jul 2008 06:49:54 -1000 (HST) Date: Tue, 8 Jul 2008 06:49:54 -1000 (HST) From: Antonio Querubin To: "Wes Beebee (wbeebee)" cc: brian.e.carpenter@gmail.com, v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 8 Jul 2008, Wes Beebee (wbeebee) wrote: > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > > Hi, some comments on other points. >> Before forwarding a packet >> in any direction from CPE router, the CPE Router will perform a MAC >> rewrite operation that rewrites the source L2 address of the packet >> with CPE Router's WAN or LAN interface MAC address. > > I also don't understand that sentence. Surely a router moves an L3 > packet from one L2 interface to another, and removing and creating > L2 headers is nothing to do with routing as such? > > > Yes, but it's only a router that performs a mac rewrite. A bridge or > switch does not do that. That is why such text exists in our draft. We > would like to keep it. > Is 'rewriting' actually a valid description of what's happening? Suppose one of those interfaces has no MAC? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 8 10:00:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B363A6AA7 for ; Tue, 8 Jul 2008 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCl34ES1OGrl for ; Tue, 8 Jul 2008 10:00:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCC693A6909 for ; Tue, 8 Jul 2008 10:00:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGGTq-0008PH-QV for v6ops-data@psg.com; Tue, 08 Jul 2008 16:55:54 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGGTZ-0008Nn-GR for v6ops@ops.ietf.org; Tue, 08 Jul 2008 16:55:46 +0000 X-IronPort-AV: E=Sophos;i="4.30,324,1212364800"; d="scan'208";a="13534982" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2008 16:55:36 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m68Gtaa8030275; Tue, 8 Jul 2008 12:55:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m68Gtaab019052; Tue, 8 Jul 2008 16:55:36 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 12:55:36 -0400 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 Subject: RE: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Date: Tue, 8 Jul 2008 12:55:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Thread-Index: AcjhGrh4AKvM0tWQTSeotCsU8+mjfQAAFWdg From: "Wes Beebee (wbeebee)" To: "Antonio Querubin" Cc: , X-OriginalArrivalTime: 08 Jul 2008 16:55:36.0040 (UTC) FILETIME=[713F4E80:01C8E11B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1517; t=1215536136; x=1216400136; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20FW=3A=20I-D=20Action=3Adraft-wbeebee-ip v6-cpe-router-00.txt |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=NPXhk8ha4cIIORGJmVpZz48p1/eWvpGyWcOm96OZcJA=; b=pYwemK07NtTDwtqkarnq4KdytUia4Ob/aqjxbMjVQkuBDKnDgle9N2lbn9 nFriu6AKSbo2CCJ7XsxdzXIgKFttrTD0d3AZ7qYWFn2AgZAcc4bQ9cclEkAp 0uman5eXXA; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We could say instead: "The CPE router will convert the packet from one L2 domain to another (e.g. through MAC rewrite) when the packet crosses L2 domains (e.g. from WAN to LAN or LAN to WAN)".=20 - Wes -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Tuesday, July 08, 2008 12:50 PM To: Wes Beebee (wbeebee) Cc: brian.e.carpenter@gmail.com; v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt On Tue, 8 Jul 2008, Wes Beebee (wbeebee) wrote: > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Brian E Carpenter > > Hi, some comments on other points. >> Before forwarding a packet >> in any direction from CPE router, the CPE Router will perform a MAC >> rewrite operation that rewrites the source L2 address of the packet >> with CPE Router's WAN or LAN interface MAC address. > > I also don't understand that sentence. Surely a router moves an L3=20 > packet from one L2 interface to another, and removing and creating > L2 headers is nothing to do with routing as such? > > > Yes, but it's only a router that performs a mac rewrite. A bridge or=20 > switch does not do that. That is why such text exists in our draft. We > would like to keep it. > Is 'rewriting' actually a valid description of what's happening? Suppose one of those interfaces has no MAC? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 8 11:25:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58533A67B4 for ; Tue, 8 Jul 2008 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.195 X-Spam-Level: X-Spam-Status: No, score=-104.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfkMBKg2ajQJ for ; Tue, 8 Jul 2008 11:25:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D39928C228 for ; Tue, 8 Jul 2008 11:25:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGHnH-000HWG-Oc for v6ops-data@psg.com; Tue, 08 Jul 2008 18:20:03 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGHnD-000HVD-99 for v6ops@ops.ietf.org; Tue, 08 Jul 2008 18:20:01 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1215541196!20248822!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 19846 invoked from network); 8 Jul 2008 18:19:57 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-2.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 8 Jul 2008 18:19:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m68IJulO014401 for ; Tue, 8 Jul 2008 14:19:56 -0400 Received: from 01GAF5142010623.AD.BLS.COM ([139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m68IJjVT014130 for ; Tue, 8 Jul 2008 14:19:49 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jul 2008 14:19:48 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jul 2008 14:19:48 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 8 Jul 2008 14:19:47 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt thread-index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQ References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> From: "Stark, Barbara" To: X-OriginalArrivalTime: 08 Jul 2008 18:19:48.0763 (UTC) FILETIME=[34E7A6B0:01C8E127] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Hemant and Wes, Thanks for the update of this draft. I think it could potentially be quite useful to the industry. But, just so you understand my focus, I'm more interested in how such a work could drive the behavior of retail "CPE routers", than I am in how it can drive specifications for routers that service providers (SPs) source and provide to end users. I pretty much know what I want in a CPE router -- my biggest unknown is how to interact with retail routers on the LAN-side of my SP CPE router, because I'm not sure how they'll behave. I also want to try and make sure that these retail routers can operate, with minimal or no configuration, without a SP router between them and the SP access network (where applicable). With that in mind, here are a few comments. 1. Based on what I'm hearing from the access network side of my company, I'm expecting for retail CPE routers (in the US) to continue to need to support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet and IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable option that defaults to IP/Ethernet. I would expect that to be the default with IPv6, as well. If a device is configured to do IPv4 over PPP, I would expect it to do IPv6 over PPP (preferably over the same PPP session) when running in dual stack. The "PPPoE" stack will use IPv6CP for WAN IP address configuration, and DHCPv6 for other config options. 2. The document seems to suggest that "numbered" vs. "unnumbered" model is a configuration option (section 5.3.2). I think the CPE router needs to be able to automatically detect what the access network is giving it. It should be pretty apparent if the access network is giving it a global IP address or not. 3. I disagree with the behavior suggested for "unnumbered" model. I don't think a CPE router should automatically open up a maintenance loopback interface just because it doesn't get a global IP address. If this is a retail CPE router, I think it really shouldn't be setting up a maintenance loopback interface by default. Our access network is definitely considering not giving out global addresses to the WAN interface, but we have no requirements for any "loopback" maintenance interfaces at all. We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option. As a default, we believe that the global address that the CPE router selects for its LAN interface is sufficient for all WAN-side Internet communication, including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests from the router when my WAN is having problems]. The option for separate IP address for maintenance would need to be configurable whether or not the CPE router gets a global address on its WAN interface. It's not just for the "unnumbered" model. By the way, when I hear about IPv6 and loopback interface in the same sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I associate loopback network interfaces with SNMP. I've never heard that phrase used with respect to a TR-069 interface. We do not support SNMP for management of consumer and small business CPE routers. If you want to have a configurable option for a maintenance interface that uses a different IP address, I would prefer using more generic language, instead of SNMP language. That would also prevent confusion between ::1 and loopback "network" interfaces, for people like me. I also find other references to SNMP MIBs to be, umm, not of interest to me (e.g., section 4). But since there's no requirement to support SNMP, I don't really care -- I just find it odd that there seems to be an underlying implicit assumption that SNMP is used for management. When a CPE router does not get a global IP address on its WAN, I don't understand why it would be recommended for the CPE router to use its maintenance interface to launch subsequent DHCPv6 messages. I would expect the link-local address on the regular WAN interface to be sufficient for this (especially since I want to be able to have no global address on the WAN, and no special maintenance interface). Even if a router is configured to have a special maintenance (TR-069) interface, I would only want to see that set up after getting the global prefix, and would want the general WAN interface used for all DHCPv6 and SLAAC. 4. I find it interesting that "LAN initialization before WAN initialization" is considered a "mode" of operation in 5.5.1. It's simply that LAN initialization must have no dependency on the existence of any WAN IP interface. Link-local and ULA happen no matter what. Then if the WAN gets a global prefix, the router does what it needs to do to get global addresses to the host devices. 5. In section 6 it says "If the CPE router supports cascading of routers through automatic prefix sub-delegation, the CPE router must support a DHCPv6 server or DHCPv6 relay agent." I think that all CPE routers need to be able to operate in a cascaded network, because that's what users are doing today and will continue to do. I would like to see all CPE routers be able to operate in a cascaded network, be able to hand out prefixes (if there are prefixes to hand out), and be able to operate as a DHCPv6 relay agent if the upstream router has no prefixes to hand out (because the upstream router only has a /64 itself). I don't think this should be an "if" statement.=20 Barbara Barbara Stark AT&T ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 From owner-v6ops@ops.ietf.org Tue Jul 8 13:19:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AD33A6B0C for ; Tue, 8 Jul 2008 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.12 X-Spam-Level: X-Spam-Status: No, score=-4.12 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezJXe50BM1WS for ; Tue, 8 Jul 2008 13:19:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A29643A6B07 for ; Tue, 8 Jul 2008 13:19:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGJa7-0003eU-UU for v6ops-data@psg.com; Tue, 08 Jul 2008 20:14:35 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGJZu-0003c6-BD for v6ops@ops.ietf.org; Tue, 08 Jul 2008 20:14:26 +0000 X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="13559836" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2008 20:14:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m68KEEOb009892; Tue, 8 Jul 2008 16:14:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m68KEEG9004630; Tue, 8 Jul 2008 20:14:14 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 16:14:14 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 8 Jul 2008 16:14:13 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAAq/iSA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , X-OriginalArrivalTime: 08 Jul 2008 20:14:14.0407 (UTC) FILETIME=[3125C970:01C8E137] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10277; t=1215548054; x=1216412054; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20; bh=Y5IdAdKLTzHnRkGwyrAEnqZvMtt6h/a24HMSX0zKIwA=; b=FcZZT9LaR03Hhnd46kNbfx8PQJUeKtG9P+F6AVPwyQsswRZc0WfD7jicy0 fCydDImJZuwxLhapx2UxwZq1hp8m9qiRZQUiNrIcaBOsh8mWckVkqi576QJY VCPQzaSNsN; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Thanks for your input and review. Please see in line below between and . -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, July 08, 2008 2:20 PM To: v6ops@ops.ietf.org Subject: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Hi Hemant and Wes, Thanks for the update of this draft. I think it could potentially be quite useful to the industry. But, just so you understand my focus, I'm more interested in how such a work could drive the behavior of retail "CPE routers", than I am in how it can drive specifications for routers that service providers (SPs) source and provide to end users. I pretty much know what I want in a CPE router -- my biggest unknown is how to interact with retail routers on the LAN-side of my SP CPE router, because I'm not sure how they'll behave. I also want to try and make sure that these retail routers can operate, with minimal or no configuration, without a SP router between them and the SP access network (where applicable). With that in mind, here are a few comments. 1. Based on what I'm hearing from the access network side of my company, I'm expecting for retail CPE routers (in the US) to continue to need to support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet and IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable option that defaults to IP/Ethernet. I would expect that to be the default with IPv6, as well. If a device is configured to do IPv4 over PPP, I would expect it to do IPv6 over PPP (preferably over the same PPP session) when running in dual stack. The "PPPoE" stack will use IPv6CP for WAN IP address configuration, and DHCPv6 for other config options. I don't see a problem with this PPP scenario for IPv6, especially after we wrote our new section of 5.5.1 in the -01 draft. If we don't find any gotchas with supporting dual-stack over the same PPP session, we will mention the fact in the draft as a "nice thing to have" or maybe even a must. If the DSL network supports IPv6 between the home and the Service Provider(SP) network, then the PPP model you describe above should work for IPv6. However, if DSL takes some time to be IPv6 ready between home and the SP, then one model we are thinking of is for the CPE Router to initiate a softwire to carry IPv6 over IPv4 in L2TPv2 tunnels. Thanks to Mark Townsley for clueing us in on softwires (http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08). We plan to add a softwire section to -02 draft. 2. The document seems to suggest that "numbered" vs. "unnumbered" model is a configuration option (section 5.3.2). I think the CPE router needs to be able to automatically detect what the access network is giving it. It should be pretty apparent if the access network is giving it a global IP address or not. You are correct. We kept the "numbered" vs. "unnumbered" model as a configuration option because the unnumbered model is spawning a Loopback interface. We wanted to make sure that if unnumbered model is configured the SP or user knows a Loopback interface is being spawned. Other than that I agree with you that the CPE Router knows if the access network is giving it a global IPv6 address or not. 3. I disagree with the behavior suggested for "unnumbered" model. I don't think a CPE router should automatically open up a maintenance loopback interface just because it doesn't get a global IP address. If this is a retail CPE router, I think it really shouldn't be setting up a maintenance loopback interface by default. Our access network is definitely considering not giving out global addresses to the WAN interface, but we have no requirements for any "loopback" maintenance interfaces at all. We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option. As a default, we believe that the global address that the CPE router selects for its LAN interface is sufficient for all WAN-side Internet communication, including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests from the router when my WAN is having problems]. No problem. So if the SP is not doling out an IPv6 address to the WAN interface, is the SP doling out an IA_PD option to the CPE Router? If yes, then when global IPv6 addresses from the IA_PD get assigned to the LAN interface(s) of the CPE Router, one can always use one more global address to configure on the WAN interface. However, if an SP does not like assigning of a global IPv6 address to the WAN interface, that's is fine with he CPE Router for PPP. Further, if the SP does not dole out an IA_PD but assigns one IPv6 global address to the LAN interface(s), that's a model the CPE Router also does not have a problem with supporting for PPP. However, for non-PPP cases, the CPE Router will need a global IPv6 address on the WAN interface and the WAN prefix must be different from the LAN prefixes because the WAN and LAN interface(s) are two separate routing domains of the CPE Router. We have received feedback from you (AT&T), NTT (Japan), and some folks in Europe. We will work on the text of our document to be general enough that we satisfy all folks. The option for separate IP address for maintenance would need to be configurable whether or not the CPE router gets a global address on its WAN interface. It's not just for the "unnumbered" model. By the way, when I hear about IPv6 and loopback interface in the same sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I associate loopback network interfaces with SNMP. I've never heard that phrase used with respect to a TR-069 interface. We do not support SNMP for management of consumer and small business CPE routers. If you want to have a configurable option for a maintenance interface that uses a different IP address, I would prefer using more generic language, instead of SNMP language. That would also prevent confusion between ::1 and loopback "network" interfaces, for people like me. I also find other references to SNMP MIBs to be, umm, not of interest to me (e.g., section 4). But since there's no requirement to support SNMP, I don't really care -- I just find it odd that there seems to be an underlying implicit assumption that SNMP is used for management. Loopback interfaces are also frequently used when discussing routing protocols (not just SNMP), and have become commonplace in discussion of router behavior. Configuring a loopback interface on a router should not be an onorous requirement.=20 When a CPE router does not get a global IP address on its WAN, I don't understand why it would be recommended for the CPE router to use its maintenance interface to launch subsequent DHCPv6 messages. I would expect the link-local address on the regular WAN interface to be sufficient for this (especially since I want to be able to have no global address on the WAN, and no special maintenance interface).=20 The reason is because DHCPv6 needs to ride on the link-local address of the network interface initiating the DHCPv6. We are assigning a global IPv6 address to the Loopback interface using DHCPv6. The WAN interface has to remain with just a link-local address. It's funny as heck to have the WAN interface initiate DHCPv6 using the link-local address of the WAN interface but after DHCPv6 is completed, the IA_NA from DHCPv6 gets assigned to the loopback interface. The draft clearly says, the Loopback interface on the CPE Router also acquires a link-local address.=20 Even if a router is configured to have a special maintenance (TR-069) interface, I would only want to see that set up after getting the global prefix, and would want the general WAN interface used for all DHCPv6 and SLAAC. 4. I find it interesting that "LAN initialization before WAN initialization" is considered a "mode" of operation in 5.5.1. It's simply that LAN initialization must have no dependency on the existence of any WAN IP interface. Link-local and ULA happen no matter what. Then if the WAN gets a global prefix, the router does what it needs to do to get global addresses to the host devices. It's a boot mode, not a mode of operation. We had to call it something because our document is general enough that this CPE Router can be embedded in a cable or DSL modem or any other device. Then the "LAN initialization before WAN initialization" is not applicable. Cable standards have already defined a "WAN initialization before LAN initialization" embedded router specification in a cable modem. We have to take care of that deployment too. 5. In section 6 it says "If the CPE router supports cascading of routers through automatic prefix sub-delegation, the CPE router must support a DHCPv6 server or DHCPv6 relay agent." I think that all CPE routers need to be able to operate in a cascaded network, because that's what users are doing today and will continue to do. I would like to see all CPE routers be able to operate in a cascaded network, be able to hand out prefixes (if there are prefixes to hand out), and be able to operate as a DHCPv6 relay agent if the upstream router has no prefixes to hand out (because the upstream router only has a /64 itself). I don't think this should be an "if" statement.=20 Again, the cable standards have specified a eRouter cable modem specification that may not support cascading of routers. We will keep the if.=20 Thanks. Hemant & Wes. Barbara Barbara Stark AT&T ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 From owner-v6ops@ops.ietf.org Tue Jul 8 20:02:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A713A6810 for ; Tue, 8 Jul 2008 20:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhcoHSQsuwHv for ; Tue, 8 Jul 2008 20:02:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 164153A67FD for ; Tue, 8 Jul 2008 20:02:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGPqS-000FU6-N0 for v6ops-data@psg.com; Wed, 09 Jul 2008 02:55:52 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGPqF-000FT1-SK for v6ops@ops.ietf.org; Wed, 09 Jul 2008 02:55:50 +0000 Received: (qmail 8471 invoked by uid 509); 9 Jul 2008 02:55:37 -0000 Received: from 74.53.155.170 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.1/7661. spamassassin: 3.2.4. Clear:RC:1(74.53.155.170):. Processed in 0.360926 secs); 09 Jul 2008 02:55:37 -0000 Received: from wibble.focb.co.nz (74.53.155.170) by 0 with SMTP; Tue, 08 Jul 2008 21:55:37 -0500 Date: Tue, 8 Jul 2008 21:55:37 -0500 (CDT) From: David Miles X-X-Sender: davidm@wibble.focb.co.nz To: v6ops@ops.ietf.org Subject: [dhcwg] I-D ACTION:draft-miles-dhc-dhcpv6-ldra-00.txt (fwd) Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Copied to v6ops for those that may not be part of DHC WG. --- We have posted a new draft that described a possible Lightweight DHCPv6 Relay Agent (LDRA) for non-routing nodes. Abstract: This document proposes a lightweight DHCPv6 relay agent that can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. http://www.ietf.org/internet-drafts/draft-miles-dhc-dhcpv6-ldra-00.txt This is equivalent to the L2 DHCP RA (draft-joshi-dhc-l2ra-00) but for DHCPv6. Like the L2 DHCP RA, the LDRA may be used to insert relay-agent options into DHCPv6 messages (such as Interface-ID). Comments most welcome in the DHCWG list (dhcwg@ietf.org). Best Regards, David Miles Alcatel-Lucent Senior Architect IP Division Level 3, 215 Spring Street Melbourne VIC 3000, Australia Email: david.miles@alcatel-lucent.com.au Phone: +61 3 9664 3308 Mobile: +61 417 684 617 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From owner-v6ops@ops.ietf.org Tue Jul 8 21:06:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0A73A6976 for ; Tue, 8 Jul 2008 21:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-knukabKEiW for ; Tue, 8 Jul 2008 21:06:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 461A33A691C for ; Tue, 8 Jul 2008 21:06:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGQtA-000L0v-2D for v6ops-data@psg.com; Wed, 09 Jul 2008 04:02:44 +0000 Received: from [209.85.200.170] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGQsx-000Kzg-2v for v6ops@ops.ietf.org; Wed, 09 Jul 2008 04:02:42 +0000 Received: by wf-out-1314.google.com with SMTP id 26so2935073wfd.32 for ; Tue, 08 Jul 2008 21:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2CmxHz+IVRj1srZxk/V22qsxlHnJZFfvGbHozOQKg2g=; b=sGAOjpnP6Q3WG6HZ6KasaOC5Mm58CzHyAPHhYfRnxPc81DvtksV9icQqsr69Km9BE2 QImCvW2EkFZ3kNi/k7a8+L+gCMU/SNvBPg9D/4Y31r0Bhi84+u8sQihEGz0YmbOOl48j zHXbTE5qtQpTIk31h8c2rbzmvraJjZf11CwuU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=sspeWBEhSc4+NKDZtBshtxp02IbKY7Y+Iof44+wZ+1f+I6R79OsSKyHtw/MkGdWPrn FsBN0kt1CUtew3qiFEibP8nB5scC6uZGEqGEHjL78/MHkiEL/xbOMk74hbBExLTZZtai 51StVVcbSwK28TLBBBnxnxSiFGT0tl1yqWX/U= Received: by 10.142.81.7 with SMTP id e7mr2088749wfb.320.1215576146696; Tue, 08 Jul 2008 21:02:26 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id 32sm9326279wfa.8.2008.07.08.21.02.25 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Jul 2008 21:02:26 -0700 (PDT) Message-ID: <48743860.1040003@gmail.com> Date: Wed, 09 Jul 2008 16:02:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Wes Beebee (wbeebee)" CC: v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-09 02:25, Wes Beebee (wbeebee) wrote: > Brian, > > Thanks for the comments. Please see in line below between comments > and . > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, July 07, 2008 7:17 PM > To: IPv6 Operations > Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt > > Hi, some comments on other points. > >> 5.3. Acquire IPv6 address and other configuration parameters > > I suggest that if address acquistion by DHCPv6 fails, there should be a > (configurable) option to discover a 6to4 relay. CPE routers were in fact > a target when 6to4 was designed. > It only needs a few lines and a reference to RFC 3056 and 3068. > > > Sorry, we don't agree. Also times have changed since 2001 when RFC3056 > of RFC3068 were authored. This CPE Router can also be deployed in a > cable deployment which is IPv6 ready between the home and aggregator > (CMTS). Since the CPE Router initiated DHCPv6, the Service Provider > router in the upstream has issued an RA to the CPE Router. Therefore if > DHCPv6 fails, something is wrong in the Service Provider network for > provisioning. Of course, there could be a malformed DHCPv6 message from > the CPE Router as well - but that's not the point. In a totally IPv6 > ready network it doesn't make sense for the CPE Router to fall back to > discover any 6to4 relay. If DHCPv6 fails in such a deployment, the > Router's IPv6 functionality is dead. The key statement here is "in such a deployment". What about a CPE that is sold off the shelf to a user whose ISP knows nothing about IPv6? What is the harm in a CPE that can implement 6to4? It certainly is a MAY implement that MUST be configurable on or off, but if a CPE vendor wishes to add this code, why not? > For DSL, which is not an IPv6 ready > network yet, one plan I have seen from industry is softwires. The > softwire creates a L2TP tunnel to carry ipv6 traffic in a ipv4 tunnel: > > http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08 > > In the softwire case, the L2TP tunnel is already created before DHCPv6 > is initiated, so if DHCPv6 fails, then even this deployment has IPv6 > services dead. Discovering a 6to4 relay is adding extra states to the > state machine of the CPE Router. We are very careful adding any extra > state machine to the CPE Router. We could configure whether you want > 6to4 tunnel or DHCPv6 before the state machine for either DHCPv6 or 6to4 > starts. That would simplify the state machine. Sure. That will be more for hobbyists than for random citizens, but I think that's where 6to4 should play. > > > Also I suggest that there should be a configurable option to generate > and support a ULA prefix. Again, a few lines and a reference to RFC > 4193. > > > Please see the -01 draft where we discuss assignment of ULA to LAN > interface(s) of the CPE Router. > > >> 6. IPv6 Data forwarding > ... >> Each protocol that the CPE >> Router can forward packets for must have a separate routing table. > > I've read that sentence several times and can't understand it. Do you > simply mean that the IPv6 table is separate from IPv4? > > > Yes. This statement is kind of obvious and probably doesn't need to be > stated. > > > ... >> Before forwarding a packet >> in any direction from CPE router, the CPE Router will perform a MAC >> rewrite operation that rewrites the source L2 address of the packet >> with CPE Router's WAN or LAN interface MAC address. > > I also don't understand that sentence. Surely a router moves an L3 > packet from one L2 interface to another, and removing and creating > L2 headers is nothing to do with routing as such? > > > Yes, but it's only a router that performs a mac rewrite. A bridge or > switch does not do that. That is why such text exists in our draft. We > would like to keep it. > But it's the wrong conceptual model. Even if what you actually do is tweak an existing Ethernet header, logically you are decapsulating the L3 packet and re-encapsulating it. Your description makes it sound like an L2 NAT instead of a perfectly normally forwarding action. Brian > >> 7.1. Path MTU Discovery Support >> >> GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the >> CPE Router), > > This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has nothing > to do with GRE. In fact any kind of Protocol 41 tunnel can interfere > with MTU too - do you expect a typical CPE to support generic Protocol > 41 tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"? > > > Sorry, we didn't use correct terminology. We did mean IPv6 in IPv4. > We'll change the text to say IPv6 in IPv4. > > >> 8. Quality Of Service(QoS) >> >> The CPE router may map the IPv6 Traffic Class field from [RFC2460] > to >> individual queues of different priority to provide differentiated >> classes of service for traffic either destined to the LAN or WAN >> interfaces (e.g. for IPTV service). > > You shouldn't use the word 'priority' because the diffserv model is not > about priority. Better to use 'behavior' plus a reference to RFC 2474. > In fact, the whole thing can be expressed as > > The CPE router MAY support differentiated services [RFC2474]. > > > Great suggestion. We will take it. > > > Thanks. > > Wes & Hemant > > > Brian > > > From owner-v6ops@ops.ietf.org Tue Jul 8 21:08:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C7F3A698D for ; Tue, 8 Jul 2008 21:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.813 X-Spam-Level: X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlzWvOc2VMNt for ; Tue, 8 Jul 2008 21:08:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A354E3A6976 for ; Tue, 8 Jul 2008 21:08:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGQxz-000LOo-Oh for v6ops-data@psg.com; Wed, 09 Jul 2008 04:07:43 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGQxv-000LOQ-Rz for v6ops@ops.ietf.org; Wed, 09 Jul 2008 04:07:41 +0000 Received: by wa-out-1112.google.com with SMTP id j37so1734022waf.23 for ; Tue, 08 Jul 2008 21:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Vp+0dvv4mi6AUVHhJzgYLo+Hhyu4fjE95tmABMQvIew=; b=iurkh1w75htjpbYeuB4otBS0gXA1sicuFP+rglbRYd6T1Y4PFq1nsRrVecmRi7jjiu SG/44TFetsMtzyKqQAyLCXpzeKISgca59fZIpD44R0Nxy5J4BCbAUIioyxmj/qGvxeub OpMmAcegs+SXMISLILrvD4VtYbiNzcGf+/gmE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Nu85Ecl/kOImk7yTVN4bKT2JiTZ4yhrk4l3ykM/Hww4W3p39dN0rgq4NXZP3b0Rav0 gr9v9WTAbVQGlad7kJLxcLMFfVCMh5HzB85ZYVqIzWHtrnxLv3zRVoQVIXkG4nifhptJ U9U7dORezDEIP85PjGSigfbz+ZggZvj7BTzpU= Received: by 10.114.241.15 with SMTP id o15mr8780885wah.96.1215576459561; Tue, 08 Jul 2008 21:07:39 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j38sm10735031waf.56.2008.07.08.21.07.38 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Jul 2008 21:07:39 -0700 (PDT) Message-ID: <48743999.7070808@gmail.com> Date: Wed, 09 Jul 2008 16:07:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: v6ops@ops.ietf.org Subject: Re: References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-08 19:35, R=C3=A9mi Denis-Courmont wrote: > On Tue, 08 Jul 2008 11:16:36 +1200, wrote: >=20 >> I suggest that if address acquistion by DHCPv6 fails, there >> should be a (configurable) option to discover a 6to4 >> relay. CPE routers were in fact a target when 6to4 was designed. >> It only needs a few lines and a reference to RFC 3056 and 3068. >=20 >=20 > While I don't necessarily disagree with the high-level idea, I am not a= big > fan of automatically configuring 6to4 gatewaying on the sole basis of > having an IPv4 address. >=20 >=20 > I have had multiple cases of public IPv4 addresses with non working 6to= 4 > relay: >=20 > - no anycast 6to4 routing, >=20 > - anycast 6to4 relay temporarily broken, >=20 > - public IPv4 address space behind a NAT (!), >=20 > - stateless firewall that drops proto-41, >=20 > - statefull firewall that tracks proto-41 "bindings"... >=20 Yes, that's why 6to4 absolutely needs to be configurable, preferably by something less obscure than netsh interface ipv6 6to4 set state state=3Denabled Brian >=20 > I wish private IPv4 addresses had the same scope as public IPv4 address= es > within RFC3484 - then broken 6to4 would not be so much of a problem > anymore. >=20 >=20 >=20 >> Also I suggest that there should be a configurable option >=20 >> to generate and support a ULA prefix. Again, a few lines >=20 >> and a reference to RFC 4193. >=20 >=20 >=20 > Yes. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 9 01:18:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2615D3A6A24 for ; Wed, 9 Jul 2008 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnkQ0PETUfnf for ; Wed, 9 Jul 2008 01:18:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06F8E3A69AA for ; Wed, 9 Jul 2008 01:18:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGUnS-000Kdp-4a for v6ops-data@psg.com; Wed, 09 Jul 2008 08:13:06 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGUnF-000Kbo-RG for v6ops@ops.ietf.org; Wed, 09 Jul 2008 08:12:56 +0000 Received: (qmail 3641 invoked by uid 1007); 9 Jul 2008 08:12:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=ZSspdm+5vAGVCbTJiFBt1cRBPGI2yrP6w0eB8tfuFQMi0wqcm9mQjKcgnK8ROthk ; Date: Wed, 9 Jul 2008 10:12:52 +0200 From: Gert Doering To: "Wes Beebee \(wbeebee\)" Cc: Antonio Querubin , brian.e.carpenter@gmail.com, v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Message-ID: <20080709081252.GU11038@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Tue, Jul 08, 2008 at 12:55:54PM -0400, Wes Beebee (wbeebee) wrote: > We could say instead: > "The CPE router will convert the packet from one L2 domain to another > (e.g. through MAC rewrite) when the packet crosses L2 domains (e.g. from > WAN to LAN or LAN to WAN)". This should just be dropped. It's obvious that a router needs to do that, and not specific to "IPv6 CPE" - and this is just distracting the reader with specific L2 details that have no relevance to the *IPv6* part. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 owner-v6ops@ops.ietf.org Wed Jul 9 11:25:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E97D3A6B40 for ; Wed, 9 Jul 2008 11:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.706 X-Spam-Level: X-Spam-Status: No, score=-4.706 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCugXLI9wBHL for ; Wed, 9 Jul 2008 11:25:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA03A3A6B3E for ; Wed, 9 Jul 2008 11:25:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGeF4-0002v8-OP for v6ops-data@psg.com; Wed, 09 Jul 2008 18:18:14 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGeF0-0002uO-5I for v6ops@ops.ietf.org; Wed, 09 Jul 2008 18:18:12 +0000 X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="13701316" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2008 18:17:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m69IHlnh029179; Wed, 9 Jul 2008 14:17:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69IHlP6004285; Wed, 9 Jul 2008 18:17:47 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:17:46 -0400 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 Subject: RE: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Date: Wed, 9 Jul 2008 14:17:46 -0400 Message-ID: In-Reply-To: <20080709081252.GU11038@Space.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Thread-Index: AcjhnJmiTY7Ywy28SnS1Lsv6H15CXwAU2g0Q References: <20080709081252.GU11038@Space.Net> From: "Hemant Singh (shemant)" To: "Gert Doering" , "Wes Beebee (wbeebee)" Cc: "Antonio Querubin" , , X-OriginalArrivalTime: 09 Jul 2008 18:17:46.0957 (UTC) FILETIME=[16B747D0:01C8E1F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1323; t=1215627467; x=1216491467; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20FW=3A=20I-D=20Action=3Adraft-wbeebee-ip v6-cpe-router-00.txt |Sender:=20 |To:=20=22Gert=20Doering=22=20,=0A=20=20=20 =20=20=20=20=20=22Wes=20Beebee=20(wbeebee)=22=20; bh=AZewy7umuhNhXXEL/aQ+9kx6peW6PjXAkyBDEOOL0kw=; b=jmEKWgJ/6Ufknmkmj1+Lw2lCOftFxbxne2cvPfCFqpD06tWkmpaosa/hBQ XvS/SriHjE49r09myl6I3RL3fWARDZD0R1mLttVAUCNAC0RjKc0T2DyCb8Vz caJFoS9N25; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ok, we will remove the text from our draft since its obvious to folks. Thanks. Hemant & Wes.=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Gert Doering Sent: Wednesday, July 09, 2008 4:13 AM To: Wes Beebee (wbeebee) Cc: Antonio Querubin; brian.e.carpenter@gmail.com; v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Hi, On Tue, Jul 08, 2008 at 12:55:54PM -0400, Wes Beebee (wbeebee) wrote: > We could say instead: > "The CPE router will convert the packet from one L2 domain to another=20 > (e.g. through MAC rewrite) when the packet crosses L2 domains (e.g.=20 > from WAN to LAN or LAN to WAN)". This should just be dropped. It's obvious that a router needs to do that, and not specific to "IPv6 CPE" - and this is just distracting the reader with specific L2 details that have no relevance to the *IPv6* part. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 owner-v6ops@ops.ietf.org Wed Jul 9 13:26:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52C53A684E for ; Wed, 9 Jul 2008 13:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrl99lqYCyLe for ; Wed, 9 Jul 2008 13:26:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41C293A680C for ; Wed, 9 Jul 2008 13:26:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGgAG-000ErY-1G for v6ops-data@psg.com; Wed, 09 Jul 2008 20:21:24 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGgAB-000Eqr-1y for v6ops@ops.ietf.org; Wed, 09 Jul 2008 20:21:21 +0000 X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="13724343" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2008 20:21:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69KL9MN002354; Wed, 9 Jul 2008 16:21:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69KL8st029637; Wed, 9 Jul 2008 20:21:09 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 16:21:09 -0400 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 Subject: RE: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Date: Wed, 9 Jul 2008 16:21:08 -0400 Message-ID: In-Reply-To: <48743860.1040003@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt Thread-Index: AcjheWdp2in96fH2Qimfht5ANPWpGgAh3JBw References: <48743860.1040003@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 09 Jul 2008 20:21:09.0032 (UTC) FILETIME=[52B24A80:01C8E201] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6811; t=1215634869; x=1216498869; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20FW=3A=20I-D=20Action=3Adraft-wbeebee-ip v6-cpe-router-00.txt |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebe e)=22=20; bh=yx9kWxwfDaRcx4F7NM78gyxW7i0IrY8bieYnT5NTWQ8=; b=sL17YVpLNdpz/FVwxA2kRSG4FHCfJKObH/DDKRcxaEsKlnKL7hPbBg8zpS plarJbq4XLcKAHfG/YLADtHxxESVUypO1JOKlJGRaWOELD+aOVf77MrZsIs3 9yDpKBXjZJ; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, You said:=20 "The key statement here is "in such a deployment". What about a CPE that is sold off the shelf to a user whose ISP knows nothing about IPv6? What is the harm in a CPE that can implement 6to4? It certainly is a MAY implement that MUST be configurable on or off, but if a CPE vendor wishes to add this code, why not?" Even a standalone CPE router sold off the shelf for IPv4 currently needs manual configuration for either DHCP or PPPOE, PPTP, L2TP, etc. for the WAN interface - it's not that plug and play. However, your point is valid. We will mull over this request and see what we can do. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, July 09, 2008 12:03 AM To: Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt On 2008-07-09 02:25, Wes Beebee (wbeebee) wrote: > Brian, >=20 > Thanks for the comments. Please see in line below between comments=20 > and . >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Brian E Carpenter > Sent: Monday, July 07, 2008 7:17 PM > To: IPv6 Operations > Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt >=20 > Hi, some comments on other points. >=20 >> 5.3. Acquire IPv6 address and other configuration parameters >=20 > I suggest that if address acquistion by DHCPv6 fails, there should be=20 > a > (configurable) option to discover a 6to4 relay. CPE routers were in=20 > fact a target when 6to4 was designed. > It only needs a few lines and a reference to RFC 3056 and 3068. >=20 > > Sorry, we don't agree. Also times have changed since 2001 when RFC3056 > of RFC3068 were authored. This CPE Router can also be deployed in a=20 > cable deployment which is IPv6 ready between the home and aggregator=20 > (CMTS). Since the CPE Router initiated DHCPv6, the Service Provider=20 > router in the upstream has issued an RA to the CPE Router. Therefore=20 > if > DHCPv6 fails, something is wrong in the Service Provider network for=20 > provisioning. Of course, there could be a malformed DHCPv6 message=20 > from the CPE Router as well - but that's not the point. In a totally=20 > IPv6 ready network it doesn't make sense for the CPE Router to fall=20 > back to discover any 6to4 relay. If DHCPv6 fails in such a deployment, > the Router's IPv6 functionality is dead. The key statement here is "in such a deployment". What about a CPE that is sold off the shelf to a user whose ISP knows nothing about IPv6? What is the harm in a CPE that can implement 6to4? It certainly is a MAY implement that MUST be configurable on or off, but if a CPE vendor wishes to add this code, why not? > For DSL, which is not an IPv6 ready > network yet, one plan I have seen from industry is softwires. The=20 > softwire creates a L2TP tunnel to carry ipv6 traffic in a ipv4 tunnel: >=20 > http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08 >=20 > In the softwire case, the L2TP tunnel is already created before DHCPv6 > is initiated, so if DHCPv6 fails, then even this deployment has IPv6=20 > services dead. Discovering a 6to4 relay is adding extra states to the=20 > state machine of the CPE Router. We are very careful adding any extra=20 > state machine to the CPE Router. We could configure whether you want > 6to4 tunnel or DHCPv6 before the state machine for either DHCPv6 or=20 > 6to4 starts. That would simplify the state machine. Sure. That will be more for hobbyists than for random citizens, but I think that's where 6to4 should play. > >=20 > Also I suggest that there should be a configurable option to generate=20 > and support a ULA prefix. Again, a few lines and a reference to RFC=20 > 4193. >=20 > > Please see the -01 draft where we discuss assignment of ULA to LAN > interface(s) of the CPE Router. > >=20 >> 6. IPv6 Data forwarding > ... >> Each protocol that the CPE >> Router can forward packets for must have a separate routing table. >=20 > I've read that sentence several times and can't understand it. Do you=20 > simply mean that the IPv6 table is separate from IPv4? >=20 > > Yes. This statement is kind of obvious and probably doesn't need to=20 > be stated. > >=20 > ... >> Before forwarding a packet >> in any direction from CPE router, the CPE Router will perform a MAC >> rewrite operation that rewrites the source L2 address of the packet >> with CPE Router's WAN or LAN interface MAC address. =20 >=20 > I also don't understand that sentence. Surely a router moves an L3=20 > packet from one L2 interface to another, and removing and creating > L2 headers is nothing to do with routing as such? >=20 > > Yes, but it's only a router that performs a mac rewrite. A bridge or=20 > switch does not do that. That is why such text exists in our draft. We > would like to keep it. > But it's the wrong conceptual model. Even if what you actually do is tweak an existing Ethernet header, logically you are decapsulating the L3 packet and re-encapsulating it. Your description makes it sound like an L2 NAT instead of a perfectly normally forwarding action. Brian >=20 >> 7.1. Path MTU Discovery Support >> >> GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the >> CPE Router), >=20 > This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has=20 > nothing to do with GRE. In fact any kind of Protocol 41 tunnel can=20 > interfere with MTU too - do you expect a typical CPE to support=20 > generic Protocol > 41 tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"? >=20 > > Sorry, we didn't use correct terminology. We did mean IPv6 in IPv4. > We'll change the text to say IPv6 in IPv4. =20 > >=20 >> 8. Quality Of Service(QoS) >> >> The CPE router may map the IPv6 Traffic Class field from [RFC2460] > to >> individual queues of different priority to provide differentiated >> classes of service for traffic either destined to the LAN or WAN >> interfaces (e.g. for IPTV service). >=20 > You shouldn't use the word 'priority' because the diffserv model is=20 > not about priority. Better to use 'behavior' plus a reference to RFC 2474. > In fact, the whole thing can be expressed as >=20 > The CPE router MAY support differentiated services [RFC2474]. >=20 > > Great suggestion. We will take it. > >=20 > Thanks. >=20 > Wes & Hemant >=20 >=20 > Brian >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Jul 11 06:51:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A843A67E3 for ; Fri, 11 Jul 2008 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q20B7a5eyrW2 for ; Fri, 11 Jul 2008 06:51:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D38B53A6768 for ; Fri, 11 Jul 2008 06:51:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHIuR-000M2y-0M for v6ops-data@psg.com; Fri, 11 Jul 2008 13:43:39 +0000 Received: from [80.12.242.26] (helo=smtp20.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHIuN-000M2P-8X for v6ops@ops.ietf.org; Fri, 11 Jul 2008 13:43:37 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2001.orange.fr (SMTP Server) with ESMTP id 704D21C0008F; Fri, 11 Jul 2008 15:43:30 +0200 (CEST) Received: from mix-amiens-111-4-253.w193-248.abo.wanadoo.fr (Mix-Amiens-111-4-253.w193-248.abo.wanadoo.fr [193.248.85.253]) by mwinf2001.orange.fr (SMTP Server) with ESMTP id 69EFE1C00086; Fri, 11 Jul 2008 15:43:29 +0200 (CEST) X-ME-UUID: 20080711134329433.69EFE1C00086@mwinf2001.orange.fr Message-ID: <48776366.4040306@free.fr> Date: Fri, 11 Jul 2008 15:43:02 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun Cc: v6ops Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> In-Reply-To: <485A9E8C.8080907@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Marcello. However strange it may seem, I now put the APBP approach in stanby, probably to finally simply give it up. Reasons: - The tunnel-to-NAT44 approach is IMHO so advanced, and probably "good enough", so that the work on APBP, even if pertinent, would arrive too late. - Some server applications are reported to require that related TCP connections do have the same client IP address. This conflicts with the possible load balancing between several APBP servers, one of their nice scalability features. - Some of the underlying concepts of APBP may be better applied in a different context (a combination of multi-homing and IPv6 private addressing, but this is another story, not related to your draft). I therefore no longer suggest that having APBP mentioned in your next version(s) is desirable. In any case thanks for your openness to reflect received comments on it. Regards. Rémi marcelo bagnulo braun - Le 6/19/08 7:59 PM : > In the next version, i will try to reflect the received comments indeed > Rémi Després escribió: >> Please remember what Teemu Savolainen wrote to you in >> http://psg.com/lists/v6ops/v6ops.2008/msg00800.html >> Also you can note what Brian Carpenter answered to Iljitsch van >> Beijnum, in >> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html From owner-v6ops@ops.ietf.org Mon Jul 14 09:59:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6387B3A6BD2 for ; Mon, 14 Jul 2008 09:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWHLVAMXjZUq for ; Mon, 14 Jul 2008 09:59:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FFD73A6B65 for ; Mon, 14 Jul 2008 09:59:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIRKh-000AXS-Hj for v6ops-data@psg.com; Mon, 14 Jul 2008 16:55:27 +0000 Received: from [80.12.242.138] (helo=smtp2a.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIRKc-000AWc-E0 for v6ops@ops.ietf.org; Mon, 14 Jul 2008 16:55:24 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a04.orange.fr (SMTP Server) with ESMTP id 732A27000090; Mon, 14 Jul 2008 18:55:21 +0200 (CEST) Received: from mix-amiens-111-2-222.w193-248.abo.wanadoo.fr (Mix-Amiens-111-2-222.w193-248.abo.wanadoo.fr [193.248.83.222]) by mwinf2a04.orange.fr (SMTP Server) with ESMTP id 6C84C700008F; Mon, 14 Jul 2008 18:55:20 +0200 (CEST) X-ME-UUID: 20080714165520444.6C84C700008F@mwinf2a04.orange.fr Message-ID: <487B84D8.6000502@free.fr> Date: Mon, 14 Jul 2008 18:54:48 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun Cc: v6ops Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> <48776366.4040306@free.fr> In-Reply-To: <48776366.4040306@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Following some privatly received comments of Dan Wing, the standby phase hasn't be long, and the idea to possibly give up APBP stands no longer ! I just posted draft-01, with I believe substantial simplifications and improved applicability. Sorry for the one more change. Rémi Rémi Després - Le 7/11/08 3:43 PM : > > Marcello. > > However strange it may seem, I now put the APBP approach in stanby, > probably to finally simply give it up. > > Reasons: > - The tunnel-to-NAT44 approach is IMHO so advanced, and probably "good > enough", so that the work on APBP, even if pertinent, would arrive too > late. > - Some server applications are reported to require that related TCP > connections do have the same client IP address. This conflicts with > the possible load balancing between several APBP servers, one of their > nice scalability features. > - Some of the underlying concepts of APBP may be better applied in a > different context (a combination of multi-homing and IPv6 private > addressing, but this is another story, not related to your draft). > > I therefore no longer suggest that having APBP mentioned in your next > version(s) is desirable. > > In any case thanks for your openness to reflect received comments on it. > > Regards. > > Rémi > > > marcelo bagnulo braun - Le 6/19/08 7:59 PM : >> In the next version, i will try to reflect the received comments indeed > >> Rémi Després escribió: > >>> Please remember what Teemu Savolainen wrote to you in >>> http://psg.com/lists/v6ops/v6ops.2008/msg00800.html > >>> Also you can note what Brian Carpenter answered to Iljitsch van >>> Beijnum, in >>> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html > > > > From owner-v6ops@ops.ietf.org Mon Jul 14 12:38:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021723A6B02 for ; Mon, 14 Jul 2008 12:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.064 X-Spam-Level: X-Spam-Status: No, score=-5.064 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+3uzpIR5FTb for ; Mon, 14 Jul 2008 12:38:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E72D23A6A18 for ; Mon, 14 Jul 2008 12:38:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITpk-00029q-7b for v6ops-data@psg.com; Mon, 14 Jul 2008 19:35:40 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITpb-00028U-5I for v6ops@ops.ietf.org; Mon, 14 Jul 2008 19:35:37 +0000 X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="14275074" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2008 19:35:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6EJZUhP012155 for ; Mon, 14 Jul 2008 15:35:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EJZTfi001200 for ; Mon, 14 Jul 2008 19:35:30 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 15:35:29 -0400 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 Subject: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 14 Jul 2008 15:35:29 -0400 Message-ID: In-Reply-To: <48743999.7070808@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpA References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@gmail.com> From: "Hemant Singh (shemant)" To: Cc: "Hemant Singh (shemant)" , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 14 Jul 2008 19:35:29.0911 (UTC) FILETIME=[C61E5870:01C8E5E8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=427; t=1216064130; x=1216928130; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20New=20(-02)=20version=20of=20IPv6=20CPE=20Route r=20draft=20is=20available=20for=20review |Sender:=20 |To:=20; bh=pwsxWjByMQ6PYq5iXyb9gXE9d3Z4kke3NNPQlk7vEq0=; b=T4FVXPG14D1tIb8MhCFTjV2e1V5ZbC+H80ZwHWWJaHkqqMzcoJgA8XZ9Dk VlWSxAD6jwYyOtK8U6qfjwupYL4b/P3HiFuszUEVUlSnsHIpzXfexG1dAU8d KIR6XNnsqJ; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, Before IETF locks down any new I-D submission today for IETF Dublin, we thought we'd submit this new copy since we had completed new sections for PPP over IPv6 and Softwires to accommodate DSL folks. Other minor review comments have been taken care of as well. Please refer to Change Log for complete change details. http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-02.txt Hemant & Wes. From owner-v6ops@ops.ietf.org Mon Jul 14 14:10:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2EF628C33E for ; Mon, 14 Jul 2008 14:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tID7rPhV5OFk for ; Mon, 14 Jul 2008 14:10:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E84A3A6CA5 for ; Mon, 14 Jul 2008 14:10:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIVFh-000CWn-G1 for v6ops-data@psg.com; Mon, 14 Jul 2008 21:06:33 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIVFa-000CVu-IN for v6ops@ops.ietf.org; Mon, 14 Jul 2008 21:06:31 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 98A58D015E; Mon, 14 Jul 2008 11:06:18 -1000 (HST) Date: Mon, 14 Jul 2008 11:06:18 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 14 Jul 2008, Hemant Singh (shemant) wrote: > Before IETF locks down any new I-D submission today for IETF Dublin, we > thought we'd submit this new copy since we had completed new sections > for PPP over IPv6 and Softwires to accommodate DSL folks. Other minor > review comments have been taken care of as well. Please refer to Change > Log for complete change details. > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-02.txt I missed this earlier but the definition of WAN interface seems a bit restrictive: "WAN interface - a single network interface on the CPE Router that is used to connect the router to the access network of the Service Provider." Remove the word single as some vendors may want to have the option of providing additional interfaces on the WAN link for bridging additional devices to the subnet directly connected to the service provider. Additional WAN interfaces are particularly helpful for facilitating troubleshooting of the Service Provider to customer link. Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN". Antonio Querubin whois: AQ7-ARIN From c.money@cowboyweb.net Mon Jul 14 22:26:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302253A6A10; Mon, 14 Jul 2008 22:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.319 X-Spam-Level: X-Spam-Status: No, score=-8.319 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdSkYfy-i3x9; Mon, 14 Jul 2008 22:26:24 -0700 (PDT) Received: from 212-42-117-172.elcat.kg (212-42-117-172.elcat.kg [212.42.117.172]) by core3.amsl.com (Postfix) with SMTP id 980B93A6A27; Mon, 14 Jul 2008 22:26:15 -0700 (PDT) X-Originating-IP: 5.104.41.132 by smtp.212.42.117.172; Tue, 15 Jul 2008 01:26:49 -0500 Message-ID: From: "Olivia Marion" Reply-To: "Olivia Marion" To: provreg-archive@megatron.ietf.org Subject: Watches from simple to luxurious at Prestige Replicas Date: Tue, 15 Jul 2008 01:26:49 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://www.wellsoe.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://www.wellsoe.com/ From owner-v6ops@ops.ietf.org Tue Jul 15 08:39:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBEC28C152 for ; Tue, 15 Jul 2008 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMOjZPE4DFJM for ; Tue, 15 Jul 2008 08:39:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8778728C14E for ; Tue, 15 Jul 2008 08:39:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KImY3-0003Nn-Cn for v6ops-data@psg.com; Tue, 15 Jul 2008 15:34:39 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KImXv-0003Mc-Kn for v6ops@ops.ietf.org; Tue, 15 Jul 2008 15:34:37 +0000 X-IronPort-AV: E=Sophos;i="4.30,367,1212364800"; d="scan'208";a="14358006" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 15:34:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FFYUZu023593; Tue, 15 Jul 2008 11:34:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FFYUSZ007447; Tue, 15 Jul 2008 15:34:30 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 11:34:30 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 11:34:29 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , Cc: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 15:34:30.0314 (UTC) FILETIME=[45F0B0A0:01C8E690] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8896; t=1216136070; x=1217000070; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20; bh=Qf90Jj0XxUuiZ+8OE3krnYm0kBm7Ef3gJZIZvDN+2rA=; b=UmqARTU+/+SfTBmBtF25IZAjYp/uo0Fw0U34lKeOf/96/cE6whBkZQKujs sVaIR6lzeH7Ygh+YhjmGKxHiLXO/2g9rhqe765eFfFLXJbE6+9K4Qz2QMlik X5iJRjmbAd; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Since Antonio also raised a point about IPv6 addresses assigned to the WAN interface (and the number of WAN interface(s)), we are combining a reply to both you and Antonio.=20 Barbara, when you say,=20 "We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a=20 configurable option." could you please elaborate. Does this separate IPv6 address get assigned to the WAN side of the CPE Router? If yes, if the WAN interface is only assigned a link-local address, then what network interface on the WAN side does this IPv6 address get assigned to? One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. Also, when reviewers ask for another network interface on the WAN side, or another IPv6 address on the WAN side, could reviewers please appreciate the fact that another WAN interface can mean two things for a router. Either we have second physical WAN interface with a new mac-address or we still have one WAN interface and the second WAN interface is just a logical interface bound to the physical WAN interface such that both the physical WAN interface and the logical interface share a mac-address between them. Antonio and Barbara, which one of these two interfaces are you talking about? Further, if one is spawning logical interfaces on any router, once doesn't have to stop at one extra interface. Go ahead and spawn more if one wants.=20 Further, Antonio, when you say, "Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN"." In such a case, the WAN interface is a logical interface that bridges the CPE Router to the broadband modem. We clarified the WAN interface definition as follows with new text WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 When we publish our next revision of the draft, we will include new text for the WAN interface definition. Thanks. Hemant & Wes. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Stark, Barbara Sent: Tuesday, July 08, 2008 2:20 PM To: v6ops@ops.ietf.org Subject: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Hi Hemant and Wes, Thanks for the update of this draft. I think it could potentially be quite useful to the industry. But, just so you understand my focus, I'm more interested in how such a work could drive the behavior of retail "CPE routers", than I am in how it can drive specifications for routers that service providers (SPs) source and provide to end users. I pretty much know what I want in a CPE router -- my biggest unknown is how to interact with retail routers on the LAN-side of my SP CPE router, because I'm not sure how they'll behave. I also want to try and make sure that these retail routers can operate, with minimal or no configuration, without a SP router between them and the SP access network (where applicable). With that in mind, here are a few comments. 1. Based on what I'm hearing from the access network side of my company, I'm expecting for retail CPE routers (in the US) to continue to need to support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet and IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable option that defaults to IP/Ethernet. I would expect that to be the default with IPv6, as well. If a device is configured to do IPv4 over PPP, I would expect it to do IPv6 over PPP (preferably over the same PPP session) when running in dual stack. The "PPPoE" stack will use IPv6CP for WAN IP address configuration, and DHCPv6 for other config options. 2. The document seems to suggest that "numbered" vs. "unnumbered" model is a configuration option (section 5.3.2). I think the CPE router needs to be able to automatically detect what the access network is giving it. It should be pretty apparent if the access network is giving it a global IP address or not. 3. I disagree with the behavior suggested for "unnumbered" model. I don't think a CPE router should automatically open up a maintenance loopback interface just because it doesn't get a global IP address. If this is a retail CPE router, I think it really shouldn't be setting up a maintenance loopback interface by default. Our access network is definitely considering not giving out global addresses to the WAN interface, but we have no requirements for any "loopback" maintenance interfaces at all. We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option. As a default, we believe that the global address that the CPE router selects for its LAN interface is sufficient for all WAN-side Internet communication, including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests from the router when my WAN is having problems]. The option for separate IP address for maintenance would need to be configurable whether or not the CPE router gets a global address on its WAN interface. It's not just for the "unnumbered" model. By the way, when I hear about IPv6 and loopback interface in the same sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I associate loopback network interfaces with SNMP. I've never heard that phrase used with respect to a TR-069 interface. We do not support SNMP for management of consumer and small business CPE routers. If you want to have a configurable option for a maintenance interface that uses a different IP address, I would prefer using more generic language, instead of SNMP language. That would also prevent confusion between ::1 and loopback "network" interfaces, for people like me. I also find other references to SNMP MIBs to be, umm, not of interest to me (e.g., section 4). But since there's no requirement to support SNMP, I don't really care -- I just find it odd that there seems to be an underlying implicit assumption that SNMP is used for management. When a CPE router does not get a global IP address on its WAN, I don't understand why it would be recommended for the CPE router to use its maintenance interface to launch subsequent DHCPv6 messages. I would expect the link-local address on the regular WAN interface to be sufficient for this (especially since I want to be able to have no global address on the WAN, and no special maintenance interface). Even if a router is configured to have a special maintenance (TR-069) interface, I would only want to see that set up after getting the global prefix, and would want the general WAN interface used for all DHCPv6 and SLAAC. 4. I find it interesting that "LAN initialization before WAN initialization" is considered a "mode" of operation in 5.5.1. It's simply that LAN initialization must have no dependency on the existence of any WAN IP interface. Link-local and ULA happen no matter what. Then if the WAN gets a global prefix, the router does what it needs to do to get global addresses to the host devices. 5. In section 6 it says "If the CPE router supports cascading of routers through automatic prefix sub-delegation, the CPE router must support a DHCPv6 server or DHCPv6 relay agent." I think that all CPE routers need to be able to operate in a cascaded network, because that's what users are doing today and will continue to do. I would like to see all CPE routers be able to operate in a cascaded network, be able to hand out prefixes (if there are prefixes to hand out), and be able to operate as a DHCPv6 relay agent if the upstream router has no prefixes to hand out (because the upstream router only has a /64 itself). I don't think this should be an "if" statement.=20 Barbara Barbara Stark AT&T ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 From owner-v6ops@ops.ietf.org Tue Jul 15 10:25:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080B53A6B47 for ; Tue, 15 Jul 2008 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.345 X-Spam-Level: X-Spam-Status: No, score=-104.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11hZVpSHcLjF for ; Tue, 15 Jul 2008 10:25:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A9DA3A6B2D for ; Tue, 15 Jul 2008 10:25:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIoDG-000Del-KP for v6ops-data@psg.com; Tue, 15 Jul 2008 17:21:18 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIoDB-000DeG-HG for v6ops@ops.ietf.org; Tue, 15 Jul 2008 17:21:16 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-15.tower-203.messagelabs.com!1216142456!26484091!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 10321 invoked from network); 15 Jul 2008 17:20:56 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-15.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2008 17:20:56 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6FHL97P009964; Tue, 15 Jul 2008 13:21:11 -0400 Received: from 01GAF5142010625.AD.BLS.COM ([139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6FHJfTo006370; Tue, 15 Jul 2008 13:21:06 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 13:14:54 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 13:14:53 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 13:14:48 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBAAA1e/MA== References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , Cc: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 17:14:53.0543 (UTC) FILETIME=[4C107F70:01C8E69E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Comments in-line.=20 Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Tuesday, July 15, 2008 11:34 AM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Since Antonio also raised a point about IPv6 addresses assigned to the WAN interface (and the number of WAN interface(s)), we are combining a reply to both you and Antonio.=20 Barbara, when you say,=20 "We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a=20 configurable option." could you please elaborate. Does this separate IPv6 address get assigned to the WAN side of the CPE Router?=20 One idea is that if a CPE router acquires a global address (SLAAC or DHCPv6 on the WAN), that it would use this for the TR-069 management interface, and it would use a global address from the prefix its given for all other Internet communication. Some people think it would improve security of that management interface (because of the ability in the access network to control what traffic goes to/from that IP address). Others consider it unnecessarily complex. The preferred approach (by those who think having a separate management interface is too complex) would be for CPE routers to use one of the addresses from the assigned prefix for all Internet communication (between the CPE router and the Internet), independent of whether it acquired a global address through SLAAC/DHCPv6. The address acquired through SLAAC/DHCPv6 would only be used to communicate with the access network (DHCPv6, ND, etc.). If yes, if the WAN interface is only assigned a link-local address, then what network interface on the WAN side does this IPv6 address get assigned to?=20 I'm experiencing some confusion here -- I thought that any given "interface" could have multiple IPv6 addresses associated with it, and it would simply need to have rules as to which address to use for which traffic. The CPE router uses the address acquired from the access network for DHCPv6, ND, etc., and it uses a global address from the prefix for communication with other global addresses (not in its prefix). Why do you believe separate interfaces may be needed? One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. We don't have such a LAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start. Also, when reviewers ask for another network interface on the WAN side, or another IPv6 address on the WAN side, could reviewers please appreciate the fact that another WAN interface can mean two things for a router. Either we have second physical WAN interface with a new mac-address or we still have one WAN interface and the second WAN interface is just a logical interface bound to the physical WAN interface such that both the physical WAN interface and the logical interface share a mac-address between them. Antonio and Barbara, which one of these two interfaces are you talking about? Further, if one is spawning logical interfaces on any router, once doesn't have to stop at one extra interface. Go ahead and spawn more if one wants.=20 I mostly agree with this description of logical and physical interfaces, although it can be more complex with DSL, and I consider Ethernet PHY to be physical, but Ethernet link layer to be logical. A single physical ADSL connection can have multiple ATM PVCs. An ATM PVC can support multiple PPPoE sessions (although each ATM PVC only has a single Ethernet "interface"), in which case each PPPoE session would also be an "interface". It's also possible to bond multiple physical DSL connections into a single logical connection (at the ATM or Ethernet layer). I think that in these IPv6 discussions, I'm referring to an interface at the Ethernet link layer. I think that should be considered "logical", and physical would be DSL PHY, Ethernet PHY, etc. I'm definitely not referring to the PHY interface. PHY needs to be completely independent of IPv6 (and IPv4) discussions, IMO. Further, Antonio, when you say, "Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN"." In such a case, the WAN interface is a logical interface that bridges the CPE Router to the broadband modem. We clarified the WAN interface definition as follows with new text WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 I really think that we should focus on WAN interface at the Ethernet link layer. Each MAC address presented to the WAN is a separate interface. Since I'd also like for this document to apply equally to Ethernet-PHY-to-the-WAN CPE routers (including ones that may get cascaded inside the LAN), I would recommend a more general and simpler description, such as: WAN interface - an Ethernet link layer interface on the CPE Router that is used to connect the router to the access network of the Service Provider or to other CPE routers that are between it and the access network.=20 When there is a single WAN interface enabled on a CPE router, it's not necessary to use RIP or have static routing entries to determine how to route traffic to the WAN. When there are multiple WAN interfaces enabled, it is necessary. When there are multiple WAN interfaces with an IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and request a prefix. If each is assigned a prefix, I would expect each of them to place IPv6 addresses from that prefix on the various LAN interfaces, and to advertise that prefix or assign addresses from it to devices on the LAN. That is, each WAN interface would meet the requirements in this document.=20 It's also possible to have multiple PPPoE sessions over a single Ethernet link layer interface. In this case, each PPPoE session would need to behave like a "WAN interface". But I don't see the need to go into that level of detail in this document. When we publish our next revision of the draft, we will include new text for the WAN interface definition. Thanks. Hemant & Wes. --- Barbara snipped off the rest of the original email --- From owner-v6ops@ops.ietf.org Tue Jul 15 11:02:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9A93A68E8 for ; Tue, 15 Jul 2008 11:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.059 X-Spam-Level: X-Spam-Status: No, score=-103.059 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr8S1vMEpLHE for ; Tue, 15 Jul 2008 11:02:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F08283A67DD for ; Tue, 15 Jul 2008 11:02:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIop4-000HBx-Vq for v6ops-data@psg.com; Tue, 15 Jul 2008 18:00:22 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIop0-000HB0-CA for v6ops@ops.ietf.org; Tue, 15 Jul 2008 18:00:20 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id A6BF2D0152; Tue, 15 Jul 2008 08:00:08 -1000 (HST) Date: Tue, 15 Jul 2008 08:00:08 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN > side does this IPv6 address get assigned to? One choice we have is to > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new > mac-address or we still have one WAN interface and the second WAN > interface is just a logical interface bound to the physical WAN > interface such that both the physical WAN interface and the logical > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN" interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges > the CPE Router to the broadband modem. We clarified the WAN interface > definition as follows with new text > > WAN interface - a single physical network interface on the standalone > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 11:21:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C7A3A6995 for ; Tue, 15 Jul 2008 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.395 X-Spam-Level: X-Spam-Status: No, score=-104.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhJaJNREryKr for ; Tue, 15 Jul 2008 11:21:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 266813A6A5F for ; Tue, 15 Jul 2008 11:21:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIp8b-000Js1-KA for v6ops-data@psg.com; Tue, 15 Jul 2008 18:20:33 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIp8Y-000Jra-0A for v6ops@ops.ietf.org; Tue, 15 Jul 2008 18:20:31 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1216146022!4166338!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 21208 invoked from network); 15 Jul 2008 18:20:22 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-13.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2008 18:20:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6FIKJg5017380; Tue, 15 Jul 2008 14:20:20 -0400 Received: from 01GAF5142010623.AD.BLS.COM ([139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6FIKC3S016779; Tue, 15 Jul 2008 14:20:15 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 14:20:14 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 14:20:14 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 14:20:13 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDE7D2@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt thread-index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBAAA1e/MAAFHrsA References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> From: "Stark, Barbara" To: "Stark, Barbara" , "Hemant Singh (shemant)" , CC: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 18:20:14.0582 (UTC) FILETIME=[6D2F9160:01C8E6A7] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I meant to say in my previous email: "We don't have such a WAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start." Barbara --------------------------------------------------------- ---- snip ----- One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. We don't have such a LAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 From owner-v6ops@ops.ietf.org Tue Jul 15 12:11:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87E33A6B6A for ; Tue, 15 Jul 2008 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.006 X-Spam-Level: X-Spam-Status: No, score=-5.006 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtZ2NSe5Q6jM for ; Tue, 15 Jul 2008 12:11:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 778123A6B69 for ; Tue, 15 Jul 2008 12:11:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIpst-000Osg-AC for v6ops-data@psg.com; Tue, 15 Jul 2008 19:08:23 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIpsn-000OrL-RA for v6ops@ops.ietf.org; Tue, 15 Jul 2008 19:08:20 +0000 X-IronPort-AV: E=Sophos;i="4.30,367,1212364800"; d="scan'208";a="14386389" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 19:08:16 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FJ8GNO022203; Tue, 15 Jul 2008 15:08:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FJ8Fnd019789; Tue, 15 Jul 2008 19:08:16 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 15:08:14 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 15:08:14 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBAAA1e/MAADulwA References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , Cc: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 19:08:14.0796 (UTC) FILETIME=[21ED58C0:01C8E6AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9170; t=1216148896; x=1217012896; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20; bh=kcDjzU9Io1lX3Pk2olelViigGf77FTb/YRcHj9rGbLc=; b=CdnbXwVkAj6PAoA7QFUReFGdaZy16lo1nyqqHGzIDYaWffJnaxiMwxlHWg WRbYaR+yBYMPdfQQDsWFiie10X3D6gdbKu8Y4GhWwzNyBZFvgmT6f2LR7FV6 a6raW4+zRe; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Comments in line below between and .=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 1:15 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Comments in-line.=20 Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 11:34 AM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Since Antonio also raised a point about IPv6 addresses assigned to the WAN interface (and the number of WAN interface(s)), we are combining a reply to both you and Antonio.=20 Barbara, when you say,=20 "We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option." could you please elaborate. Does this separate IPv6 address get assigned to the WAN side of the CPE Router?=20 One idea is that if a CPE router acquires a global address (SLAAC or DHCPv6 on the WAN), that it would use this for the TR-069 management interface, and it would use a global address from the prefix its given for all other Internet communication. Some people think it would improve security of that management interface (because of the ability in the access network to control what traffic goes to/from that IP address). Others consider it unnecessarily complex. The preferred approach (by those who think having a separate management interface is too complex) would be for CPE routers to use one of the addresses from the assigned prefix for all Internet communication (between the CPE router and the Internet), independent of whether it acquired a global address through SLAAC/DHCPv6. The address acquired through SLAAC/DHCPv6 would only be used to communicate with the access network (DHCPv6, ND, etc.). If yes, if the WAN interface is only assigned a link-local address, then what network interface on the WAN side does this IPv6 address get assigned to?=20 I'm experiencing some confusion here -- I thought that any given "interface" could have multiple IPv6 addresses associated with it, and it would simply need to have rules as to which address to use for which traffic. The CPE router uses the address acquired from the access network for DHCPv6, ND, etc., and it uses a global address from the prefix for communication with other global addresses (not in its prefix). Why do you believe separate interfaces may be needed? Ah, just confusion on our side and also because we haven't read the TR-069 document yet. We thought, it's another network interface being discussed for management. To make sure we understand your statements above, here is what we think you are saying: The WAN interface gets a link-local address that is used by DHCPv6 and ND. The WAN interface also gets a global IPv6 address (doesn't matter, if the global is an IA_NA from DHCPv6 or an address out of the IA_PD prefix doled out to the WAN interface) that is used for management and any other communication. One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. We don't have such a LAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start. The CPE Router is a router for which a network Loopback interface is very normal. Other folks have asked us for this Loopback interface, so we are going to be very careful changing the draft for the Loopback interface. However, it's optional to be configured. But then you will have to use the Numbered model of our document and assign a global IPV6 to the WAN interface. Also, when reviewers ask for another network interface on the WAN side, or another IPv6 address on the WAN side, could reviewers please appreciate the fact that another WAN interface can mean two things for a router. Either we have second physical WAN interface with a new mac-address or we still have one WAN interface and the second WAN interface is just a logical interface bound to the physical WAN interface such that both the physical WAN interface and the logical interface share a mac-address between them. Antonio and Barbara, which one of these two interfaces are you talking about? Further, if one is spawning logical interfaces on any router, once doesn't have to stop at one extra interface. Go ahead and spawn more if one wants.=20 I mostly agree with this description of logical and physical interfaces, although it can be more complex with DSL, and I consider Ethernet PHY to be physical, but Ethernet link layer to be logical. A single physical ADSL connection can have multiple ATM PVCs. An ATM PVC can support multiple PPPoE sessions (although each ATM PVC only has a single Ethernet "interface"), in which case each PPPoE session would also be an "interface". It's also possible to bond multiple physical DSL connections into a single logical connection (at the ATM or Ethernet layer). I think that in these IPv6 discussions, I'm referring to an interface at the Ethernet link layer. I think that should be considered "logical", and physical would be DSL PHY, Ethernet PHY, etc. I'm definitely not referring to the PHY interface. PHY needs to be completely independent of IPv6 (and IPv4) discussions, IMO. Yes, the OSI model says PHY needs to be independent of IPv6 and IPv4 at layer 3. So are we on the same page that you and Antonio need only one Ethernet physical WAN interface, but there may, of course, be any number of logical interfaces bound to the physical Ethernet interface. Please let's make sure, if anyone needs more than one physical port for the WAN side of the CPE Router - please speak up if you do. Further, Antonio, when you say, "Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN"." In such a case, the WAN interface is a logical interface that bridges the CPE Router to the broadband modem. We clarified the WAN interface definition as follows with new text WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 I really think that we should focus on WAN interface at the Ethernet link layer. Each MAC address presented to the WAN is a separate interface. Since I'd also like for this document to apply equally to Ethernet-PHY-to-the-WAN CPE routers (including ones that may get cascaded inside the LAN), I would recommend a more general and simpler description, such as: WAN interface - an Ethernet link layer interface on the CPE Router that is used to connect the router to the access network of the Service Provider or to other CPE routers that are between it and the access network.=20 Good suggestion. We'll consider this text when we prepare a new definition of the WAN interface based on other people's reply too. When there is a single WAN interface enabled on a CPE router, it's not necessary to use RIP or have static routing entries to determine how to route traffic to the WAN.=20 Not quite. What happens to the traffic from the Service Provider (SP) to the home? The aggregation router (agg rtr) needs to know routes to the home to send data to the home. RIPv6 is one option via which the home sends its route information (routes to PD) to the agg rtr. Alternatively, the agg rtr may snoop DHCPv6 message and inject routes in the agg rtr for the PD's in DHCPv6 messages. There may be yet a third solution that we are not going into. Thanks. Hemant & Wes When there are multiple WAN interfaces enabled, it is necessary. When there are multiple WAN interfaces with an IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and request a prefix. If each is assigned a prefix, I would expect each of them to place IPv6 addresses from that prefix on the various LAN interfaces, and to advertise that prefix or assign addresses from it to devices on the LAN. That is, each WAN interface would meet the requirements in this document.=20 It's also possible to have multiple PPPoE sessions over a single Ethernet link layer interface. In this case, each PPPoE session would need to behave like a "WAN interface". But I don't see the need to go into that level of detail in this document. From owner-v6ops@ops.ietf.org Tue Jul 15 13:20:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672583A6A2F for ; Tue, 15 Jul 2008 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.42 X-Spam-Level: X-Spam-Status: No, score=-104.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtbCEaU3m63l for ; Tue, 15 Jul 2008 13:20:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7C613A67D8 for ; Tue, 15 Jul 2008 13:20:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIqxt-00069p-Aa for v6ops-data@psg.com; Tue, 15 Jul 2008 20:17:37 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIqxo-000696-C1 for v6ops@ops.ietf.org; Tue, 15 Jul 2008 20:17:34 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1216153047!12567332!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 9781 invoked from network); 15 Jul 2008 20:17:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-10.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2008 20:17:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6FKHRCC002350; Tue, 15 Jul 2008 16:17:27 -0400 Received: from 01GAF5142010621.AD.BLS.COM ([139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6FKHKtQ001752; Tue, 15 Jul 2008 16:17:20 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 16:17:20 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 16:17:19 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 16:17:18 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt thread-index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkg References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> From: "Stark, Barbara" To: "Antonio Querubin" , "Hemant Singh (shemant)" CC: X-OriginalArrivalTime: 15 Jul 2008 20:17:19.0620 (UTC) FILETIME=[C86F4C40:01C8E6B7] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN > side does this IPv6 address get assigned to? One choice we have is to > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new > mac-address or we still have one WAN interface and the second WAN > interface is just a logical interface bound to the physical WAN > interface such that both the physical WAN interface and the logical > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is=20 integrated into the CPE router. For discussion purposes, in a general=20 network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially=20 encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be=20 accessible to the consumer via external physical ports. If they are=20 physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence=20 my earlier suggestion of using different names for the modem-router=20 interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges > the CPE Router to the broadband modem. We clarified the WAN interface > definition as follows with new text > > WAN interface - a single physical network interface on the standalone > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal=20 router: WAN interface - a network interface on the CPE Router that is used to=20 connect the router to the access network of the Service Provider. When a=20 CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface=20 that connects the internal router to the internal bridge. Some devices=20 which can have an embedded CPE router are: a cable or DSL modem, or a=20 cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network=20 interface that is bridged to the WAN interface and directly connects to=20 the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the=20 physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to=20 connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service=20 provider via a non-ethernet connection, this physical interface is bridged=20 to the router via an internal modem. Some devices which can have an=20 embedded CPE router are: a cable or DSL modem, or a cellular telephone,=20 etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface=20 that is bridged to the WAN interface and provides additional direct access=20 to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 From owner-v6ops@ops.ietf.org Tue Jul 15 13:40:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6D63A67DF for ; Tue, 15 Jul 2008 13:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7z7u7wbg1rj for ; Tue, 15 Jul 2008 13:40:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22DA63A67D8 for ; Tue, 15 Jul 2008 13:40:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrJF-0008B2-CR for v6ops-data@psg.com; Tue, 15 Jul 2008 20:39:41 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrJA-0008AS-K2 for v6ops@ops.ietf.org; Tue, 15 Jul 2008 20:39:38 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 3122CD00FB; Tue, 15 Jul 2008 10:39:36 -1000 (HST) Date: Tue, 15 Jul 2008 10:39:36 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > > Yes, the OSI model says PHY needs to be independent of IPv6 and IPv4 at > layer 3. So are we on the same page that you and Antonio need only one > Ethernet physical WAN interface, but there may, of course, be any number > of logical interfaces bound to the physical Ethernet interface. Please > let's make sure, if anyone needs more than one physical port for the WAN > side of the CPE Router - please speak up if you do. > If you're talking about an ethernet interface bridged to the WAN side, then I'd say it's highly recommended. If the device is an all-in-one integrated device and you have to test the provisioning of the service provider connection, it's easy to just have the customer move a PC temporarilly onto the extra WAN access port and troubleshoot from there. The only thing between the PC being used for diagnosis and the Service Provider is the internal modem. Furthermore, some customers may want to have a plug-n-play DMZ outside of their router firewall domain. For simplicity of managing policy, this latter scenario probably would imply that the /64 assigned to the WAN link shouldn't overlap with the prefix delegated to the LAN interface(s) of the router but even that's not necessarilly a hard requirement. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 13:40:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18ADC3A67DF for ; Tue, 15 Jul 2008 13:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.435 X-Spam-Level: X-Spam-Status: No, score=-104.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awJXC0cofV9p for ; Tue, 15 Jul 2008 13:40:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B65513A67D8 for ; Tue, 15 Jul 2008 13:40:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrIo-00088H-4b for v6ops-data@psg.com; Tue, 15 Jul 2008 20:39:14 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrIj-00087f-9x for v6ops@ops.ietf.org; Tue, 15 Jul 2008 20:39:11 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1216154347!4180260!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 21366 invoked from network); 15 Jul 2008 20:39:07 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-13.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2008 20:39:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6FKd6SA019568; Tue, 15 Jul 2008 16:39:07 -0400 Received: from 01GAF5142010625.AD.BLS.COM ([139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6FKd1bM019034; Tue, 15 Jul 2008 16:39:01 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 16:39:00 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 16:39:01 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 16:38:59 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBAAA1e/MAADulwAAAWQk/A= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , Cc: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 20:39:01.0310 (UTC) FILETIME=[D04D6DE0:01C8E6BA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I disagree that if the loopback interface is not configured "you will have to use the Numbered model of our document and assign a global IPV6 to the WAN interface". Just to be sure, I think you're saying that the CPE router will need to get a global IPv6 address via SLAAC or stateful DHCPv6, from the access network. I do not see any reason why the CPE router cannot use one of the addresses from its assigned prefix. Since we are definitely considering using the "unnumbered model", and we have no loopback interface in our devices (and have no intention of having them), I think I'm going to have to try to get a second opinion on this. Does anyone else have an opinion on whether or not the "unnumbered model" will only work in the presence of a loopback interface? By the way, I've never seen such a loopback interface in any mass market retail CPE routers. To me, the capabilities found in such mass market routers should be the benchmark for "very normal". I'm also not familiar with it in DSL routers. DSL routers are also "very normal", worldwide. I've been trying to search the Internet for products that include this interface, and all I can find are Cisco products with IOS. I'm curious as to whether any other vendors implement this interface, and, if so, on what sorts of mass market products. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Tuesday, July 15, 2008 3:08 PM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Comments in line below between and .=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 1:15 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Comments in-line.=20 Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 11:34 AM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Since Antonio also raised a point about IPv6 addresses assigned to the WAN interface (and the number of WAN interface(s)), we are combining a reply to both you and Antonio.=20 Barbara, when you say,=20 "We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option." could you please elaborate. Does this separate IPv6 address get assigned to the WAN side of the CPE Router?=20 One idea is that if a CPE router acquires a global address (SLAAC or DHCPv6 on the WAN), that it would use this for the TR-069 management interface, and it would use a global address from the prefix its given for all other Internet communication. Some people think it would improve security of that management interface (because of the ability in the access network to control what traffic goes to/from that IP address). Others consider it unnecessarily complex. The preferred approach (by those who think having a separate management interface is too complex) would be for CPE routers to use one of the addresses from the assigned prefix for all Internet communication (between the CPE router and the Internet), independent of whether it acquired a global address through SLAAC/DHCPv6. The address acquired through SLAAC/DHCPv6 would only be used to communicate with the access network (DHCPv6, ND, etc.). If yes, if the WAN interface is only assigned a link-local address, then what network interface on the WAN side does this IPv6 address get assigned to?=20 I'm experiencing some confusion here -- I thought that any given "interface" could have multiple IPv6 addresses associated with it, and it would simply need to have rules as to which address to use for which traffic. The CPE router uses the address acquired from the access network for DHCPv6, ND, etc., and it uses a global address from the prefix for communication with other global addresses (not in its prefix). Why do you believe separate interfaces may be needed? Ah, just confusion on our side and also because we haven't read the TR-069 document yet. We thought, it's another network interface being discussed for management. To make sure we understand your statements above, here is what we think you are saying: The WAN interface gets a link-local address that is used by DHCPv6 and ND. The WAN interface also gets a global IPv6 address (doesn't matter, if the global is an IA_NA from DHCPv6 or an address out of the IA_PD prefix doled out to the WAN interface) that is used for management and any other communication. One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. We don't have such a LAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start. The CPE Router is a router for which a network Loopback interface is very normal. Other folks have asked us for this Loopback interface, so we are going to be very careful changing the draft for the Loopback interface. However, it's optional to be configured. But then you will have to use the Numbered model of our document and assign a global IPV6 to the WAN interface. Also, when reviewers ask for another network interface on the WAN side, or another IPv6 address on the WAN side, could reviewers please appreciate the fact that another WAN interface can mean two things for a router. Either we have second physical WAN interface with a new mac-address or we still have one WAN interface and the second WAN interface is just a logical interface bound to the physical WAN interface such that both the physical WAN interface and the logical interface share a mac-address between them. Antonio and Barbara, which one of these two interfaces are you talking about? Further, if one is spawning logical interfaces on any router, once doesn't have to stop at one extra interface. Go ahead and spawn more if one wants.=20 I mostly agree with this description of logical and physical interfaces, although it can be more complex with DSL, and I consider Ethernet PHY to be physical, but Ethernet link layer to be logical. A single physical ADSL connection can have multiple ATM PVCs. An ATM PVC can support multiple PPPoE sessions (although each ATM PVC only has a single Ethernet "interface"), in which case each PPPoE session would also be an "interface". It's also possible to bond multiple physical DSL connections into a single logical connection (at the ATM or Ethernet layer). I think that in these IPv6 discussions, I'm referring to an interface at the Ethernet link layer. I think that should be considered "logical", and physical would be DSL PHY, Ethernet PHY, etc. I'm definitely not referring to the PHY interface. PHY needs to be completely independent of IPv6 (and IPv4) discussions, IMO. Yes, the OSI model says PHY needs to be independent of IPv6 and IPv4 at layer 3. So are we on the same page that you and Antonio need only one Ethernet physical WAN interface, but there may, of course, be any number of logical interfaces bound to the physical Ethernet interface. Please let's make sure, if anyone needs more than one physical port for the WAN side of the CPE Router - please speak up if you do. Further, Antonio, when you say, "Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN"." In such a case, the WAN interface is a logical interface that bridges the CPE Router to the broadband modem. We clarified the WAN interface definition as follows with new text WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 I really think that we should focus on WAN interface at the Ethernet link layer. Each MAC address presented to the WAN is a separate interface. Since I'd also like for this document to apply equally to Ethernet-PHY-to-the-WAN CPE routers (including ones that may get cascaded inside the LAN), I would recommend a more general and simpler description, such as: WAN interface - an Ethernet link layer interface on the CPE Router that is used to connect the router to the access network of the Service Provider or to other CPE routers that are between it and the access network.=20 Good suggestion. We'll consider this text when we prepare a new definition of the WAN interface based on other people's reply too. When there is a single WAN interface enabled on a CPE router, it's not necessary to use RIP or have static routing entries to determine how to route traffic to the WAN.=20 Not quite. What happens to the traffic from the Service Provider (SP) to the home? The aggregation router (agg rtr) needs to know routes to the home to send data to the home. RIPv6 is one option via which the home sends its route information (routes to PD) to the agg rtr. Alternatively, the agg rtr may snoop DHCPv6 message and inject routes in the agg rtr for the PD's in DHCPv6 messages. There may be yet a third solution that we are not going into. Thanks. Hemant & Wes When there are multiple WAN interfaces enabled, it is necessary. When there are multiple WAN interfaces with an IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and request a prefix. If each is assigned a prefix, I would expect each of them to place IPv6 addresses from that prefix on the various LAN interfaces, and to advertise that prefix or assign addresses from it to devices on the LAN. That is, each WAN interface would meet the requirements in this document.=20 It's also possible to have multiple PPPoE sessions over a single Ethernet link layer interface. In this case, each PPPoE session would need to behave like a "WAN interface". But I don't see the need to go into that level of detail in this document. From owner-v6ops@ops.ietf.org Tue Jul 15 13:51:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE393A6863 for ; Tue, 15 Jul 2008 13:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSi5LzCPAQXM for ; Tue, 15 Jul 2008 13:51:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C80C3A696C for ; Tue, 15 Jul 2008 13:51:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrUC-0009Yi-9e for v6ops-data@psg.com; Tue, 15 Jul 2008 20:51:00 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrU7-0009Xz-ON for v6ops@ops.ietf.org; Tue, 15 Jul 2008 20:50:58 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14399740" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 20:50:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FKorGM031592; Tue, 15 Jul 2008 16:50:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FKorvP013880; Tue, 15 Jul 2008 20:50:53 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 16:50:53 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 16:50:52 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 15 Jul 2008 20:50:53.0518 (UTC) FILETIME=[78CFBEE0:01C8E6BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8879; t=1216155053; x=1217019053; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20=22Anto nio=20Querubin=22=20; bh=2LY6iBG9NYxv21LnUMnOO1vFB3VsmZ7N2EWzXOLu8xs=; b=U6d0zxM0XecFmB3B6DVLa6DyryKYl56dn5FEYafOUZQ6f5GsLe7C/RnsAa 1v7dQU4XnsA7XbgOB2MwMWQm81McBYYAzgPGJv2Mx464oWgkaDkl6eSw7Q4Z fl+4rH4TcW; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 From owner-v6ops@ops.ietf.org Tue Jul 15 13:52:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6363A6863 for ; Tue, 15 Jul 2008 13:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.329 X-Spam-Level: X-Spam-Status: No, score=-103.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6B6JZFGuQkf for ; Tue, 15 Jul 2008 13:52:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98CD73A696C for ; Tue, 15 Jul 2008 13:52:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrUL-0009Zn-Hp for v6ops-data@psg.com; Tue, 15 Jul 2008 20:51:09 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrUH-0009ZH-Nv for v6ops@ops.ietf.org; Tue, 15 Jul 2008 20:51:07 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 3948FD0060; Tue, 15 Jul 2008 10:51:05 -1000 (HST) Date: Tue, 15 Jul 2008 10:51:05 -1000 (HST) From: Antonio Querubin To: "Stark, Barbara" cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 15 Jul 2008, Stark, Barbara wrote: > I don't understand the relevance of mentioning PHY interfaces, PHY > modems, or pure Ethernet switches, in a document about IPv6 behavior of > CPE routers. A physical instantiation of a CPE router may indeed contain > a PHY modem and Ethernet switch, but I don't see why that's relevant or > needs to be called out in this document. Only because the definition of WAN thus far specifically mentions a strict single physical interface port count. If however, we want to get away from that wording altogether, then I would concur with you. It's then up to the vendor to decide if they want to provide the extra functionality of additional interfaces bridged to the WAN. There are good reasons for doing so but I agree they do not need to be in this document. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 14:10:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963493A6872 for ; Tue, 15 Jul 2008 14:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.968 X-Spam-Level: X-Spam-Status: No, score=-4.968 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRiol-lDgTzM for ; Tue, 15 Jul 2008 14:10:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 561ED3A67BD for ; Tue, 15 Jul 2008 14:10:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrmF-000BhR-9R for v6ops-data@psg.com; Tue, 15 Jul 2008 21:09:39 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIrmA-000Bgj-Gy for v6ops@ops.ietf.org; Tue, 15 Jul 2008 21:09:36 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14418365" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 21:09:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FL9XdF015069; Tue, 15 Jul 2008 17:09:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FL9UiC007969; Tue, 15 Jul 2008 21:09:33 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 17:09:32 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 17:09:32 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjfhyV9066O8UZyS96wRlbR6oqM7AAPnKuwACEdEaAABE5/oAApO9bQAWFFzBAAA1e/MAADulwAAAWQk/AAASpbwA== References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , Cc: "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 21:09:32.0725 (UTC) FILETIME=[13E92E50:01C8E6BF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12544; t=1216156173; x=1217020173; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20; bh=Bgflh8qBqXKRoXR33nuTk47+m79P7bAq328OlsNSv8A=; b=sTrpYoaNRVODYZph4jCfYSNhKxVi7dEybMUSJfw2JuBz6sBNoevzHYRhYh uApcWa1BbSEgHp4WSeeCQB5P7SqnNH1Id7YL3sP3yxE07Ma8+0P/PA7vq7n7 SY/aS7LoDI; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I and Wes are working with NTT, Japan as well and they clearly support the WAN interface on the CPE Router to acquire a global IPv6 address. NTT also happens to have a functional IPv6 ADSL deployment that is few years old. We listen more to working deployments than any requests from folks that still not don't seem to be complete with their IPv6 thinking for DSL. I am meeting with NTT folks in Dublin to iron out some details for the CPE Router - unless I close with them, our CPE Router document is still subject to change. We will certainly work with AT&T till we have a plan in place for them too.=20 BTW, I and Wes work in the Cable industry and build cable aggregation routers (CMTS) for a living. Our cable deployment has completed standards, and CMTS and cable modems working as of 2 years back for IPv6. Our deployment also uses a global IPV6 address for the WAN interface of the cable modem. I have a simple bottom-line. The CPE Router does have two separate routing domains in the WAN and LAN interface(s). Routing domains need their own global IPv6 addresses and different subnets. There is also no dearth of IPv6 global addresses, so I don't see what the problem is if the WAN interface get a global IPv6 address. I agree with you that Loopback interfaces are not common to home Linksys-like routers. But, IPv6 being a new and different space (everything from IPv4 cannot map as is to IPv6), if a Loopback meets a requirement for one operator, it was worth considering.=20 Hemant =20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 4:39 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I disagree that if the loopback interface is not configured "you will have to use the Numbered model of our document and assign a global IPV6 to the WAN interface". Just to be sure, I think you're saying that the CPE router will need to get a global IPv6 address via SLAAC or stateful DHCPv6, from the access network. I do not see any reason why the CPE router cannot use one of the addresses from its assigned prefix. Since we are definitely considering using the "unnumbered model", and we have no loopback interface in our devices (and have no intention of having them), I think I'm going to have to try to get a second opinion on this. Does anyone else have an opinion on whether or not the "unnumbered model" will only work in the presence of a loopback interface? By the way, I've never seen such a loopback interface in any mass market retail CPE routers. To me, the capabilities found in such mass market routers should be the benchmark for "very normal". I'm also not familiar with it in DSL routers. DSL routers are also "very normal", worldwide. I've been trying to search the Internet for products that include this interface, and all I can find are Cisco products with IOS. I'm curious as to whether any other vendors implement this interface, and, if so, on what sorts of mass market products. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 3:08 PM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Comments in line below between and .=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 1:15 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Comments in-line.=20 Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 11:34 AM To: Stark, Barbara; v6ops@ops.ietf.org Cc: Antonio Querubin Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Since Antonio also raised a point about IPv6 addresses assigned to the WAN interface (and the number of WAN interface(s)), we are combining a reply to both you and Antonio.=20 Barbara, when you say,=20 "We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option." could you please elaborate. Does this separate IPv6 address get assigned to the WAN side of the CPE Router?=20 One idea is that if a CPE router acquires a global address (SLAAC or DHCPv6 on the WAN), that it would use this for the TR-069 management interface, and it would use a global address from the prefix its given for all other Internet communication. Some people think it would improve security of that management interface (because of the ability in the access network to control what traffic goes to/from that IP address). Others consider it unnecessarily complex. The preferred approach (by those who think having a separate management interface is too complex) would be for CPE routers to use one of the addresses from the assigned prefix for all Internet communication (between the CPE router and the Internet), independent of whether it acquired a global address through SLAAC/DHCPv6. The address acquired through SLAAC/DHCPv6 would only be used to communicate with the access network (DHCPv6, ND, etc.). If yes, if the WAN interface is only assigned a link-local address, then what network interface on the WAN side does this IPv6 address get assigned to?=20 I'm experiencing some confusion here -- I thought that any given "interface" could have multiple IPv6 addresses associated with it, and it would simply need to have rules as to which address to use for which traffic. The CPE router uses the address acquired from the access network for DHCPv6, ND, etc., and it uses a global address from the prefix for communication with other global addresses (not in its prefix). Why do you believe separate interfaces may be needed? Ah, just confusion on our side and also because we haven't read the TR-069 document yet. We thought, it's another network interface being discussed for management. To make sure we understand your statements above, here is what we think you are saying: The WAN interface gets a link-local address that is used by DHCPv6 and ND. The WAN interface also gets a global IPv6 address (doesn't matter, if the global is an IA_NA from DHCPv6 or an address out of the IA_PD prefix doled out to the WAN interface) that is used for management and any other communication. One choice we have is to assign the IPv6 address to the Loopback interface facing the WAN side. We don't have such a LAN-facing loopback interface in any of our mass market CPE, that I'm aware of. And I don't think we intend to start. The CPE Router is a router for which a network Loopback interface is very normal. Other folks have asked us for this Loopback interface, so we are going to be very careful changing the draft for the Loopback interface. However, it's optional to be configured. But then you will have to use the Numbered model of our document and assign a global IPV6 to the WAN interface. Also, when reviewers ask for another network interface on the WAN side, or another IPv6 address on the WAN side, could reviewers please appreciate the fact that another WAN interface can mean two things for a router. Either we have second physical WAN interface with a new mac-address or we still have one WAN interface and the second WAN interface is just a logical interface bound to the physical WAN interface such that both the physical WAN interface and the logical interface share a mac-address between them. Antonio and Barbara, which one of these two interfaces are you talking about? Further, if one is spawning logical interfaces on any router, once doesn't have to stop at one extra interface. Go ahead and spawn more if one wants.=20 I mostly agree with this description of logical and physical interfaces, although it can be more complex with DSL, and I consider Ethernet PHY to be physical, but Ethernet link layer to be logical. A single physical ADSL connection can have multiple ATM PVCs. An ATM PVC can support multiple PPPoE sessions (although each ATM PVC only has a single Ethernet "interface"), in which case each PPPoE session would also be an "interface". It's also possible to bond multiple physical DSL connections into a single logical connection (at the ATM or Ethernet layer). I think that in these IPv6 discussions, I'm referring to an interface at the Ethernet link layer. I think that should be considered "logical", and physical would be DSL PHY, Ethernet PHY, etc. I'm definitely not referring to the PHY interface. PHY needs to be completely independent of IPv6 (and IPv4) discussions, IMO. Yes, the OSI model says PHY needs to be independent of IPv6 and IPv4 at layer 3. So are we on the same page that you and Antonio need only one Ethernet physical WAN interface, but there may, of course, be any number of logical interfaces bound to the physical Ethernet interface. Please let's make sure, if anyone needs more than one physical port for the WAN side of the CPE Router - please speak up if you do. Further, Antonio, when you say, "Additionally, for those vendors that wish to integrate the layer 2 (DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation is not ethernet), perhaps a separately named interface definition might be appropriate to avoid confusion with "WAN"." In such a case, the WAN interface is a logical interface that bridges the CPE Router to the broadband modem. We clarified the WAN interface definition as follows with new text WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 I really think that we should focus on WAN interface at the Ethernet link layer. Each MAC address presented to the WAN is a separate interface. Since I'd also like for this document to apply equally to Ethernet-PHY-to-the-WAN CPE routers (including ones that may get cascaded inside the LAN), I would recommend a more general and simpler description, such as: WAN interface - an Ethernet link layer interface on the CPE Router that is used to connect the router to the access network of the Service Provider or to other CPE routers that are between it and the access network.=20 Good suggestion. We'll consider this text when we prepare a new definition of the WAN interface based on other people's reply too. When there is a single WAN interface enabled on a CPE router, it's not necessary to use RIP or have static routing entries to determine how to route traffic to the WAN.=20 Not quite. What happens to the traffic from the Service Provider (SP) to the home? The aggregation router (agg rtr) needs to know routes to the home to send data to the home. RIPv6 is one option via which the home sends its route information (routes to PD) to the agg rtr. Alternatively, the agg rtr may snoop DHCPv6 message and inject routes in the agg rtr for the PD's in DHCPv6 messages. There may be yet a third solution that we are not going into. Thanks. Hemant & Wes When there are multiple WAN interfaces enabled, it is necessary. When there are multiple WAN interfaces with an IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and request a prefix. If each is assigned a prefix, I would expect each of them to place IPv6 addresses from that prefix on the various LAN interfaces, and to advertise that prefix or assign addresses from it to devices on the LAN. That is, each WAN interface would meet the requirements in this document.=20 It's also possible to have multiple PPPoE sessions over a single Ethernet link layer interface. In this case, each PPPoE session would need to behave like a "WAN interface". But I don't see the need to go into that level of detail in this document. From owner-v6ops@ops.ietf.org Tue Jul 15 14:36:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A78D3A6A37 for ; Tue, 15 Jul 2008 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.445 X-Spam-Level: X-Spam-Status: No, score=-104.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SZx+DCSes-l for ; Tue, 15 Jul 2008 14:36:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BC5A3A67DD for ; Tue, 15 Jul 2008 14:36:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIs9l-000Ehf-Aj for v6ops-data@psg.com; Tue, 15 Jul 2008 21:33:57 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIs9g-000Ege-Iv for v6ops@ops.ietf.org; Tue, 15 Jul 2008 21:33:54 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1216157630!2214136!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 27226 invoked from network); 15 Jul 2008 21:33:50 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2008 21:33:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6FLXn1q009327; Tue, 15 Jul 2008 17:33:50 -0400 Received: from 01GAF5142010622.AD.BLS.COM ([139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6FLXjBm008810; Tue, 15 Jul 2008 17:33:46 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 17:33:46 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 15 Jul 2008 17:33:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 17:33:43 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt thread-index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYA== References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Antonio Querubin" CC: X-OriginalArrivalTime: 15 Jul 2008 21:33:45.0833 (UTC) FILETIME=[7607DD90:01C8E6C2] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 From owner-v6ops@ops.ietf.org Tue Jul 15 14:45:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B07C3A6AC2 for ; Tue, 15 Jul 2008 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.383 X-Spam-Level: X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaSMDien71UU for ; Tue, 15 Jul 2008 14:45:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 967F628C167 for ; Tue, 15 Jul 2008 14:45:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIsKS-000Fu3-Qx for v6ops-data@psg.com; Tue, 15 Jul 2008 21:45:00 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIsKP-000FtV-4Q for v6ops@ops.ietf.org; Tue, 15 Jul 2008 21:44:58 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 9869AD0060; Tue, 15 Jul 2008 11:44:56 -1000 (HST) Date: Tue, 15 Jul 2008 11:44:56 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Thanks for this email. For the purposes of description of behavior of a > CPE Router, all we are asking for is how many physical WAN interface On the one hand you say ^^^^^^^^ > ports will the CPE Router have? We have recommended one. We could care > less about any other physical layer behavior. We are defining routing > behavior that sits abstracted from link or physical layers. Where a ^^^^^^^^^^^^^^^ ^^^^^^^^ On the other hand you say > layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP > address acquisition does not perform DAD. Why not just call it a routed interface and get away from the word physical altogether? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 15:37:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878E23A67BD for ; Tue, 15 Jul 2008 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdth-EfyuJ8b for ; Tue, 15 Jul 2008 15:37:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4118A3A67AE for ; Tue, 15 Jul 2008 15:37:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIt6D-000LIl-1Z for v6ops-data@psg.com; Tue, 15 Jul 2008 22:34:21 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIt68-000LHW-8H for v6ops@ops.ietf.org; Tue, 15 Jul 2008 22:34:18 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14425469" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 22:34:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FMYFBK017194; Tue, 15 Jul 2008 18:34:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FMYFmK007984; Tue, 15 Jul 2008 22:34:15 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 18:34:15 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 18:34:14 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAACB5KQ References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 15 Jul 2008 22:34:15.0096 (UTC) FILETIME=[E93D7380:01C8E6CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11669; t=1216161255; x=1217025255; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20=22Anto nio=20Querubin=22=20; bh=74HtawNrtVdJtVrmjbNcAfk+MGAG1UVp/ej4GnOlDHs=; b=SH1ViC9uhMDBqxh8AWSyvqsuTMsPTKRFa86i8w54lBmHqC5uEY2X/8Pfe8 mzZx1FUhtgHEHPwSWvkD0Lt0ToDg3CGIfEu8juoMPnbn65l9xRQm/kchyVRi bOkKJd5xBH; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Thanks very much for this feedback from the DSL world. I agree with you then that any mention of physical interfaces can be skipped. BTW, do note that we have tried to keep our LAN interfaces of the CPE Router behavior very agnostic to number of LAN interfaces or jacks or physical port - I believe we have done alright with that. So it won't be a problem for us to keep the WAN interface text from being one WAN physical interface centric to WAN interface(s).=20 BTW, in cable industry, we also do bond multiple physical channels with docsis 3.0, but we still have one single RF connector out of the cable modem. That is why we are used to referring to one physical WAN interface and also not seeing the need for more than one WAN physical interface. If no one objects, we will make such an update to our next version of the draft. My cohort is away on vacation till mid next week. Anyhow, I believe we cannot publish a new version of our draft to IETF till after August 1st when IETF 72 ends. We will try to clear up some more things in our draft during August. Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Tue Jul 15 15:57:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8CA3A67D8 for ; Tue, 15 Jul 2008 15:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYN9HWoPn645 for ; Tue, 15 Jul 2008 15:57:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AB823A67CF for ; Tue, 15 Jul 2008 15:57:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItRF-000NLK-NL for v6ops-data@psg.com; Tue, 15 Jul 2008 22:56:05 +0000 Received: from [209.85.198.236] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItRC-000NKs-02 for v6ops@ops.ietf.org; Tue, 15 Jul 2008 22:56:03 +0000 Received: by rv-out-0506.google.com with SMTP id b25so6379084rvf.41 for ; Tue, 15 Jul 2008 15:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=2awf/SvcYNmLQ+EF9T+QHWNkph02NI6ThX8iKYjFJs0=; b=CqQPv/Oyi4wAWacIgjzAFS0hrzFLLH4CuH9MyfljIQuFI454EKz1DLLrt9ZB86M7IZ J2U1pCvPWJWeRbmtebT4LdX6Q2X6wdW17n4cdQ/Fo/sjdquhyJpgWYTyzS5HgK7YfqCD iMs+f6kivPY8/hn5OzHZgWldIGB0MKWjZcGTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SFizKS6RuITeN/HOiC/3hUcDgMdFjhD6akGsXkCtn6bZQV24fHSG1wN3IqKXtgv3Ff /nftkSOusmzC5qaJTH14BWzxFK1XRfkA2hNxsm4vG633Q2AXql4pTPZDK0DRiyuI2xim UZSB+o0OhC9YmNKZ8WIpY4t37PsnCadp7Fq5s= Received: by 10.140.161.11 with SMTP id j11mr4555686rve.134.1216162561737; Tue, 15 Jul 2008 15:56:01 -0700 (PDT) Received: by 10.141.203.3 with HTTP; Tue, 15 Jul 2008 15:56:01 -0700 (PDT) Message-ID: <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> Date: Wed, 16 Jul 2008 00:56:01 +0200 From: "Ole Troan" To: "Stark, Barbara" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Antonio Querubin" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> X-Google-Sender-Auth: 0f4685c44ba4a8a6 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, > I disagree that if the loopback interface is not configured "you will > have to use the Numbered model of our document and assign a global IPV6 > to the WAN interface". Just to be sure, I think you're saying that the > CPE router will need to get a global IPv6 address via SLAAC or stateful > DHCPv6, from the access network. I do not see any reason why the CPE > router cannot use one of the addresses from its assigned prefix. Since > we are definitely considering using the "unnumbered model", and we have > no loopback interface in our devices (and have no intention of having > them), I think I'm going to have to try to get a second opinion on this. > Does anyone else have an opinion on whether or not the "unnumbered > model" will only work in the presence of a loopback interface? > > By the way, I've never seen such a loopback interface in any mass market > retail CPE routers. To me, the capabilities found in such mass market > routers should be the benchmark for "very normal". I'm also not familiar > with it in DSL routers. DSL routers are also "very normal", worldwide. > I've been trying to search the Internet for products that include this > interface, and all I can find are Cisco products with IOS. I'm curious > as to whether any other vendors implement this interface, and, if so, on > what sorts of mass market products. the loopback interface is a red herring. the unnumbered model will work just fine without it. /ot From owner-v6ops@ops.ietf.org Tue Jul 15 15:57:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1CC3A685C for ; Tue, 15 Jul 2008 15:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.936 X-Spam-Level: X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6IIHsFtBIJM for ; Tue, 15 Jul 2008 15:57:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADEC03A67CF for ; Tue, 15 Jul 2008 15:57:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItSO-000NSa-7I for v6ops-data@psg.com; Tue, 15 Jul 2008 22:57:16 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItSJ-000NRx-4A for v6ops@ops.ietf.org; Tue, 15 Jul 2008 22:57:14 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14426787" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 22:57:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FMvAfD017974; Tue, 15 Jul 2008 18:57:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FMvAnr028196; Tue, 15 Jul 2008 22:57:10 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 18:57:09 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 18:57:09 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmxAjR6CQpiOGrTDehGVBYFQMvXgABvjBw References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Stark, Barbara" , X-OriginalArrivalTime: 15 Jul 2008 22:57:09.0927 (UTC) FILETIME=[1CB40370:01C8E6CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3125; t=1216162630; x=1217026630; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=j6igWT5QKJ5bGxeAsaDOdVSIlFvmv97LXSzNscmsQoQ=; b=G1utB6badX651gNtBM1cyqTjsxd8rrrN6TvRTERohYft9sWqxsghENCSzd uqWyXw1B28zCaP6qqhA3joCvNBevFJYKwbs0drzgmE89rUVMmzINM/iOhOu6 DTpwv/bfe5; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Antonio, BTW, we don't mention physical interfaces anywhere in the draft from day one of -00 to -02 versions of the draft. I am just asking a question if anyone sees a need for more than one physical WAN ports on the CPE Router. Barbara has already replied and I replied to her - we are not going to add any mention of number of physical WAN ports for the CPE Router.=20 As for your comment below, even a router needs to run ND at layer 2. Besides, routing, we do plan to cover minor and relevant ND behavior for the CPE Router in our draft. We had to mention physical interface in the attempt for a new definition of the WAN interface to clarify the WAN interface on the standalone CPE Router vs. the WAN interface when the CPE Router gets embedded in a device like a broadband modem. I thought we were clear from our new definition (shown below) from this morning to delineate between embedded CPE Router vs. standalone CPE Router.=20 WAN interface - a single physical network interface on the standalone CPE Router that is used to connect the router to the access network of the Service=20 ^^^^^^^^ ^^^^^^^^^^ Provider. When the CPE Router is embedded in a device that connects to the WAN, this interface is a logical network interface that bridges the device to the CPE Router. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.=20 I know now, "single" doesn't work above - that can be easily massaged out of the definition. Further, it's not that easy to call the WAN interface as a routed interface because soon as the interface becomes an internal interface in an embedded device, the WAN interface is a bridge to the broadband modem internal interface so that the CPE Router gets all IPv6 traffic from the broadband modem.=20 We have heard your comments. We'll see what we can do to make the text more clear for WAN interface and embedded vs. standalone delineation.=20 Thanks. Hemant -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Tuesday, July 15, 2008 5:45 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Thanks for this email. For the purposes of description of behavior of=20 > a CPE Router, all we are asking for is how many physical WAN interface On the one hand you say ^^^^^^^^ > ports will the CPE Router have? We have recommended one. We could care > less about any other physical layer behavior. We are defining routing=20 > behavior that sits abstracted from link or physical layers. Where a ^^^^^^^^^^^^^^^ ^^^^^^^^ On the other hand you say > layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP=20 > address acquisition does not perform DAD. Why not just call it a routed interface and get away from the word physical altogether? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 16:09:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7013A683B for ; Tue, 15 Jul 2008 16:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.921 X-Spam-Level: X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1jFcbW8yqZC for ; Tue, 15 Jul 2008 16:09:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CC9A3A67CC for ; Tue, 15 Jul 2008 16:09:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItd7-000Ojs-5D for v6ops-data@psg.com; Tue, 15 Jul 2008 23:08:21 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItd2-000OiN-VZ for v6ops@ops.ietf.org; Tue, 15 Jul 2008 23:08:19 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14427472" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 23:08:15 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FN8FET028044; Tue, 15 Jul 2008 19:08:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FN8FQD001394; Tue, 15 Jul 2008 23:08:15 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:08:15 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 19:08:15 -0400 Message-ID: In-Reply-To: <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmzgSoypMitMaQSC2A5m0kSA/t0wAAKbNg References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" , "Stark, Barbara" Cc: , "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 23:08:15.0765 (UTC) FILETIME=[A992D450:01C8E6CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4524; t=1216163295; x=1217027295; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20,=20=22Sta rk,=20Barbara=22=20; bh=yKW8RYOa9Af0ZbkqiFoF90ovcAd/eP/TRT6iT8VQPwM=; b=SEGsZqGr4aFKmjOfSBOM+rWW0Ty34kyDRiDQfplGZU0YrHCX8UUY7Qqhgm g3UxcaAQ7RAQn5BtnvosrRjjN0fbTeD4jfAHCofnP9/fYxQI4dOwskh7+2mI ElA++a8RK+; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: BTW, we have already replied to Barabara on July 8th that unnumbered model that she proposed by giving global IPv6 addresses to LAN interface(s) and only a link-local to WAN interface(s) is fine for the CPE Router. See the email exchange below. I was just warning today that for routing functionality, we just need a global IPv6 address on the WAN interface. After all, the CPE Router is a router. 3. I disagree with the behavior suggested for "unnumbered" model. I don't think a CPE router should automatically open up a maintenance loopback interface just because it doesn't get a global IP address. If this is a retail CPE router, I think it really shouldn't be setting up a maintenance loopback interface by default. Our access network is definitely considering not giving out global addresses to the WAN interface, but we have no requirements for any "loopback" maintenance interfaces at all. We have considered the possibility of a separate IP address for our TR-069 management of the CPE routers that we supply, but would want this to be a configurable option. As a default, we believe that the global address that the CPE router selects for its LAN interface is sufficient for all WAN-side Internet communication, including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests from the router when my WAN is having problems]. No problem. So if the SP is not doling out an IPv6 address to the WAN interface, is the SP doling out an IA_PD option to the CPE Router? If yes, then when global IPv6 addresses from the IA_PD get assigned to the LAN interface(s) of the CPE Router, one can always use one more global address to configure on the WAN interface. However, if an SP does not like assigning of a global IPv6 address to the WAN interface, that's is fine with he CPE Router for PPP. Further, if the SP does not dole out an IA_PD but assigns one IPv6 global address to the LAN interface(s), that's a model the CPE Router also does not have a problem with supporting for PPP. However, for non-PPP cases, the CPE Router will need a global IPv6 address on the WAN interface and the WAN prefix must be different from the LAN prefixes because the WAN and LAN interface(s) are two separate routing domains of the CPE Router. We have received feedback from you (AT&T), NTT (Japan), and some folks in Europe. We will work on the text of our document to be general enough that we satisfy all folks. However, we didn't still not make any change in our -02 draft for Loopback interface because we want to first see if a common model for the CPE Router can be found between AT&T, NTT, and other European DSL folks.=20 Hemant -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Tuesday, July 15, 2008 6:56 PM To: Stark, Barbara Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Antonio Querubin Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, > I disagree that if the loopback interface is not configured "you will=20 > have to use the Numbered model of our document and assign a global=20 > IPV6 to the WAN interface". Just to be sure, I think you're saying=20 > that the CPE router will need to get a global IPv6 address via SLAAC=20 > or stateful DHCPv6, from the access network. I do not see any reason=20 > why the CPE router cannot use one of the addresses from its assigned=20 > prefix. Since we are definitely considering using the "unnumbered=20 > model", and we have no loopback interface in our devices (and have no=20 > intention of having them), I think I'm going to have to try to get a second opinion on this. > Does anyone else have an opinion on whether or not the "unnumbered=20 > model" will only work in the presence of a loopback interface? > > By the way, I've never seen such a loopback interface in any mass=20 > market retail CPE routers. To me, the capabilities found in such mass=20 > market routers should be the benchmark for "very normal". I'm also not > familiar with it in DSL routers. DSL routers are also "very normal", worldwide. > I've been trying to search the Internet for products that include this > interface, and all I can find are Cisco products with IOS. I'm curious > as to whether any other vendors implement this interface, and, if so,=20 > on what sorts of mass market products. the loopback interface is a red herring. the unnumbered model will work just fine without it. /ot From owner-v6ops@ops.ietf.org Tue Jul 15 16:10:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A7D3A6931 for ; Tue, 15 Jul 2008 16:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.907 X-Spam-Level: X-Spam-Status: No, score=-4.907 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv9sbk60jWDb for ; Tue, 15 Jul 2008 16:10:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9CF3A68DB for ; Tue, 15 Jul 2008 16:10:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItfA-000P1n-W7 for v6ops-data@psg.com; Tue, 15 Jul 2008 23:10:28 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KItf6-000P1J-Bk for v6ops@ops.ietf.org; Tue, 15 Jul 2008 23:10:26 +0000 X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14410850" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 23:10:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6FNAMGa022221; Tue, 15 Jul 2008 19:10:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FNAMFt019311; Tue, 15 Jul 2008 23:10:22 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:10:22 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 19:10:22 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhg References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 15 Jul 2008 23:10:22.0424 (UTC) FILETIME=[F5117580:01C8E6CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10760; t=1216163422; x=1217027422; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20=22Anto nio=20Querubin=22=20; bh=y3p1It9Vk9SEVGUWSznZSJhP5Nyuz/oA/yqFR3sBFKw=; b=LeItMqBWcSt64qnAUBYGAXUnFptnDpWk5YRkASJNtDEN6hSxU6YlzJAoXh s/aPN0c/OaRaiFu0A7OdmpI4czdCRA33742fCnzQ6IlX6eYf53XWO3hngEoM CtIdbYhHFI; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Did you get a chance to look at our -02 draft and its reference to RFC4241? Please read RFC4241 to see what has NTT done in Japan to their ADSL IPv6 services. Thanks. Hemant=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Tue Jul 15 16:13:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2B83A68DB for ; Tue, 15 Jul 2008 16:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtQI3kbLpY40 for ; Tue, 15 Jul 2008 16:13:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB3A13A68CD for ; Tue, 15 Jul 2008 16:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIthL-000PIl-V5 for v6ops-data@psg.com; Tue, 15 Jul 2008 23:12:43 +0000 Received: from [209.85.198.236] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIthH-000PI1-LJ for v6ops@ops.ietf.org; Tue, 15 Jul 2008 23:12:41 +0000 Received: by rv-out-0506.google.com with SMTP id b25so6382929rvf.41 for ; Tue, 15 Jul 2008 16:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LWOWyxv/qrfyiCq1lucaItIrvSyd+be2msFs3bY/bBk=; b=L2u3++Kmjm6MXx5AF9+QMXhxO3Ie4U5dXuCzhMBnVtlqdeCEtYNX6uAY8xgV3/Oifo cskEF/l+rFfEVNfarViVYA69KEz8d9gzD8QeGwg2sj5g/dCEzIXD1dPhjtpwlA+T9oS3 PXf2ao6/1mfDgc/zM1gd4hm5/xGqUgrP22QoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=YkqtCkOq4AIWsIZWjjIWO065Ydae+FTQHV5lEGpYnbUhZwl3XOpdAL6Ckd067v0YHs alJ4ABm+UHuvs8EBkymD9rk3vi9VsnaCrRv0xT2wou3ZLzbjI7xZgWvGTHHfoRZqp0jC /pyAnkwVEOEqb58RK8X85kWXqHE2zrvkvyGcU= Received: by 10.140.204.7 with SMTP id b7mr7813359rvg.175.1216163559440; Tue, 15 Jul 2008 16:12:39 -0700 (PDT) Received: by 10.141.203.3 with HTTP; Tue, 15 Jul 2008 16:12:39 -0700 (PDT) Message-ID: <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> Date: Wed, 16 Jul 2008 01:12:39 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Stark, Barbara" , v6ops@ops.ietf.org, "Antonio Querubin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> X-Google-Sender-Auth: db80fc14cb37b280 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > BTW, we have already replied to Barabara on July 8th that unnumbered > model that she proposed by giving global IPv6 addresses to LAN > interface(s) and only a link-local to WAN interface(s) is fine for the > CPE Router. See the email exchange below. I was just warning today that > for routing functionality, we just need a global IPv6 address on the WAN > interface. After all, the CPE Router is a router. I don't understand your last sentence. why do you need a global address on the WAN interface because the CPE router is a router?? /ot From owner-v6ops@ops.ietf.org Tue Jul 15 16:57:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882E03A67AF for ; Tue, 15 Jul 2008 16:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6W1TdFdkMwG for ; Tue, 15 Jul 2008 16:57:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8606D3A6782 for ; Tue, 15 Jul 2008 16:57:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIuLk-0004CJ-0D for v6ops-data@psg.com; Tue, 15 Jul 2008 23:54:28 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIuLf-0004By-QJ for v6ops@ops.ietf.org; Tue, 15 Jul 2008 23:54:25 +0000 X-IronPort-AV: E=Sophos;i="4.30,369,1212364800"; d="scan'208";a="14430005" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 23:54:22 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FNsMZT009582; Tue, 15 Jul 2008 19:54:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FNsMpW002160; Tue, 15 Jul 2008 23:54:22 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:54:22 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 15 Jul 2008 19:54:21 -0400 Message-ID: In-Reply-To: <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: Acjm0EnqXfJyiq0hRK2jV+lqTzSTNwABUIsw References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Stark, Barbara" , , "Antonio Querubin" X-OriginalArrivalTime: 15 Jul 2008 23:54:22.0474 (UTC) FILETIME=[1AA91EA0:01C8E6D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1496; t=1216166062; x=1217030062; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=RlDdBlSpxClAjf4scd1Qtg4NSJLcEMAXK0lqDNXrCfk=; b=GpM86N3O/vJf88YrYdd7BkhO009Jf2zX799K1dWoF28drrwv5druqCRNIU DNi55/cTnMwdwpfQHde83Zq08PFsoMhxBdqGT5wsDl3tKtbnw3StPdDEfQEC /C/IgQfyYs; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ole said: why do you need a global address on the WAN interface because the CPE router is a router?? RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, due to security concerns, the router should drop the incoming packet. If the WAN interface of the CPE Router does not have a global IPV6 address, how is RPF going to work? RPF needs global IPv6 addresses. We haven't looked at the problem with a fine tooth and comb but when we do we will list all cases for what IPv6 routing and data forwarding breaks down if a routed interface of a router has only a link-local address. Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Tuesday, July 15, 2008 7:13 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org; Antonio Querubin Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > BTW, we have already replied to Barabara on July 8th that unnumbered=20 > model that she proposed by giving global IPv6 addresses to LAN > interface(s) and only a link-local to WAN interface(s) is fine for the > CPE Router. See the email exchange below. I was just warning today=20 > that for routing functionality, we just need a global IPv6 address on=20 > the WAN interface. After all, the CPE Router is a router. I don't understand your last sentence. why do you need a global address on the WAN interface because the CPE router is a router?? /ot From owner-v6ops@ops.ietf.org Tue Jul 15 17:02:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A943A6782 for ; Tue, 15 Jul 2008 17:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJIVCVU9vCS8 for ; Tue, 15 Jul 2008 17:02:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5825B3A65A6 for ; Tue, 15 Jul 2008 17:02:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIuSu-0004nt-HB for v6ops-data@psg.com; Wed, 16 Jul 2008 00:01:52 +0000 Received: from [209.85.198.235] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIuSr-0004nU-3y for v6ops@ops.ietf.org; Wed, 16 Jul 2008 00:01:50 +0000 Received: by rv-out-0506.google.com with SMTP id b25so6394853rvf.41 for ; Tue, 15 Jul 2008 17:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Ki9tYJOYtlNCQeDu5d5d3ay0IE4RVZM2xfNsrdpUldg=; b=u44k8x3DZyczJKJBlqPcQhbaLP0twfKEHNZ3AGfJ8QaFCrO0Ryh+JjDmqM4f8jmMyB sd5/xwDbXPjOoUoqcSzyG0L9nWCMnjMd6YFbETPwEX8GCSQ5GUxnaI4TCmcIDsGSbmAQ unpwRTWEqPdxvMhu/gKTW87x5EUAoPT/WJH7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=HNG7YhrXItGOqbCK9s4MTFevDvVN/oNcMBhvsErlT+Be0X29+ZsQtM4koWxWcEqz6s tBFyGRw51DoTIw4FXBa/H423ybScvMLvLUvmYyWTQ7g8hnQdLM5kBWMQM3eqcV0HDq0x NfQ8//g8iQEt070qfptX+aIXwrbwfr7cpGx7o= Received: by 10.140.185.1 with SMTP id i1mr7849289rvf.102.1216166508451; Tue, 15 Jul 2008 17:01:48 -0700 (PDT) Received: by 10.141.203.3 with HTTP; Tue, 15 Jul 2008 17:01:48 -0700 (PDT) Message-ID: <2bbba3c10807151701k29e340ddm2bb1350c0d9dda5a@mail.gmail.com> Date: Wed, 16 Jul 2008 02:01:48 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Stark, Barbara" , v6ops@ops.ietf.org, "Antonio Querubin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> X-Google-Sender-Auth: ea41e7d64dd15af8 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > Ole said: why do you need a global address on the WAN interface because > the CPE router is a router?? > > RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, > due to security concerns, the router should drop the incoming packet. If > the WAN interface of the CPE Router does not have a global IPV6 address, > how is RPF going to work? RPF needs global IPv6 addresses. that is incorrect. you do not need a global address to verify the SA. we could go into details on "RPF checking", but before that, why do you even want RPF checking on a CPE router, that belongs on the provider edge. > We haven't looked at the problem with a fine tooth and comb but when we > do we will list all cases for what IPv6 routing and data forwarding > breaks down if a routed interface of a router has only a link-local > address. as I have said multiple times before I am not aware of any, nor have I seen anyone else cite any examples. /ot From owner-v6ops@ops.ietf.org Tue Jul 15 18:20:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CB23A6885 for ; Tue, 15 Jul 2008 18:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.419 X-Spam-Level: X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv6rklY3472n for ; Tue, 15 Jul 2008 18:20:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B8E03A67AF for ; Tue, 15 Jul 2008 18:20:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIve7-000D0J-OI for v6ops-data@psg.com; Wed, 16 Jul 2008 01:17:31 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIve3-000CzT-OI for v6ops@ops.ietf.org; Wed, 16 Jul 2008 01:17:29 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id DF556D0071; Tue, 15 Jul 2008 15:17:24 -1000 (HST) Date: Tue, 15 Jul 2008 15:17:24 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Ole Troan , "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Ole said: why do you need a global address on the WAN interface because > the CPE router is a router?? > > RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, > due to security concerns, the router should drop the incoming packet. If > the WAN interface of the CPE Router does not have a global IPV6 address, > how is RPF going to work? RPF needs global IPv6 addresses. I'm confused. How would RPF fail if the router will normally have a default route out the WAN interface? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 15 18:21:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8888E3A67D0 for ; Tue, 15 Jul 2008 18:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.445 X-Spam-Level: X-Spam-Status: No, score=-103.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncEu-uPMTOcP for ; Tue, 15 Jul 2008 18:21:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA3013A67AF for ; Tue, 15 Jul 2008 18:21:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIvi3-000DMt-5X for v6ops-data@psg.com; Wed, 16 Jul 2008 01:21:35 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIvhz-000DMR-I7 for v6ops@ops.ietf.org; Wed, 16 Jul 2008 01:21:33 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id D08A2D00EF; Tue, 15 Jul 2008 15:21:30 -1000 (HST) Date: Tue, 15 Jul 2008 15:21:30 -1000 (HST) From: Antonio Querubin To: Ole Troan cc: "Hemant Singh (shemant)" , "Stark, Barbara" , v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: <2bbba3c10807151701k29e340ddm2bb1350c0d9dda5a@mail.gmail.com> Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> <2bbba3c10807151701k29e340ddm2bb1350c0d9dda5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 16 Jul 2008, Ole Troan wrote: > that is incorrect. you do not need a global address to verify the SA. > we could go into details on "RPF checking", but before that, why do > you even want RPF checking on a CPE router, that belongs on the > provider edge. On the WAN side to prevent spoofed packets from entering the customer's network. On the LAN side to prevent a customer's network that's been overrun from sending spoofed packets to the service provider's network. Doing it at the CPE prevents those packets from overwhelming the WAN link. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Wed Jul 16 04:48:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF323A6868 for ; Wed, 16 Jul 2008 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.582 X-Spam-Level: X-Spam-Status: No, score=-4.582 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otwQlxc83PqM for ; Wed, 16 Jul 2008 04:48:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A69D93A6A81 for ; Wed, 16 Jul 2008 04:48:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5QQ-000CEn-6l for v6ops-data@psg.com; Wed, 16 Jul 2008 11:44:02 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5QF-000CDD-EI for v6ops@ops.ietf.org; Wed, 16 Jul 2008 11:44:00 +0000 X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14464786" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2008 11:43:48 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GBhmab012456; Wed, 16 Jul 2008 07:43:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6GBhmoq019659; Wed, 16 Jul 2008 11:43:48 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 07:43:48 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Wed, 16 Jul 2008 07:43:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: Acjm4cHqr+uhFFzYQze9iDcg15pK7wAVaqBw References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Ole Troan" , "Stark, Barbara" , X-OriginalArrivalTime: 16 Jul 2008 11:43:48.0116 (UTC) FILETIME=[35C2A540:01C8E739] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2687; t=1216208628; x=1217072628; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=z0UnX6uvgHEgNQZpeUuy8lS34yHBixqGmAjBvFs1fbk=; b=qswbZXq51mY6rcc+t6X5v6r1Gyy1mvRnmdmkkcyllpnwBE/kSzxai6jcpI YNrqq0WbnFPMLZhvrx6NuTiM+GKTxaHaU9QweKJYqUNrQ4QgFsMsyZrRXqR/ TUzgMVVH6U; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Even if the CPE Router has a default router out the WAN interface to the SP router, RPF may support a knob where "Allow default route to match when checking source address" is not allowed. One can configure a router to disable checking the default route to match src-addr by RPF. shark(config-if)#ipv6 verify unicast source reachable-via rx ? WORD Access-list name allow-default Allow default route to match when checking source address I have a spoofed packet with global src-addr input to the WAN interface of a standalone CPE Router - the destination of this packet is the global IPv6 address of a LAN interface. Strict uRPF check will check if the src-addr is reachable by a path thru the input interface which is the WAN interface. The WAN interface, which is also a routed port has only a link-local address. So how can the global address have a path thru the WAN interface that is assigned only a link-local address? In general, if one even issues a ping to a global address and the ping has to go out the WAN interface which only has a link-local address configured, the ping will fail to head out because there is no valid source address for destination. See a test from my IPv6 Cisco router where I have assigned only a link-local address to the network interface (FE80::205:FF:FEE0:74CE) that is supposed to send the ping out.=20 shark#ping 2001:420:3800:800:203:BAFF:FE11:B644 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:420:3800:800:203:BAFF:FE11:B644, timeout is 2 seconds: % No valid source address for destination Success rate is 0 percent (0/1) shark# shark#sh ipv6 int br Ethernet0/0/0 [up/up] unassigned FastEthernet0/0/0 [up/up] FE80::205:FF:FEE0:74CE Hemant =20 -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Tuesday, July 15, 2008 9:17 PM To: Hemant Singh (shemant) Cc: Ole Troan; Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Ole said: why do you need a global address on the WAN interface=20 > because the CPE router is a router?? > > RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, > due to security concerns, the router should drop the incoming packet.=20 > If the WAN interface of the CPE Router does not have a global IPV6=20 > address, how is RPF going to work? RPF needs global IPv6 addresses. I'm confused. How would RPF fail if the router will normally have a default route out the WAN interface? Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Wed Jul 16 04:53:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D903A6A81 for ; Wed, 16 Jul 2008 04:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T8YdhrBmNeO for ; Wed, 16 Jul 2008 04:53:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC6903A6868 for ; Wed, 16 Jul 2008 04:53:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5Z2-000DJi-Jl for v6ops-data@psg.com; Wed, 16 Jul 2008 11:52:56 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5Yv-000DIr-Lc for v6ops@ops.ietf.org; Wed, 16 Jul 2008 11:52:51 +0000 X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14465273" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2008 11:52:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GBqmoK015162; Wed, 16 Jul 2008 07:52:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GBqmqu029262; Wed, 16 Jul 2008 11:52:48 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 07:52:48 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Wed, 16 Jul 2008 07:52:48 -0400 Message-ID: In-Reply-To: <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmzgSoypMitMaQSC2A5m0kSA/t0wAazoRg References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" , "Stark, Barbara" Cc: , "Antonio Querubin" X-OriginalArrivalTime: 16 Jul 2008 11:52:48.0645 (UTC) FILETIME=[77F0D350:01C8E73A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2564; t=1216209168; x=1217073168; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20,=20=22Sta rk,=20Barbara=22=20; bh=hMUDvqoH0Z4ccdeIXLuj6DHpjYEl01lvtyaSH5AY5O4=; b=x/40TsKjYk2/aJ7PTVf3I1nLP0tZ/kfqgNI/Q8suMDVJR0zBCT1+Ih85dM flzLgytJ8om8oLL6+1WV6CnxfJ1KlyFyoDekRVpLR7XnQzAcmPi8Gs0L7zLB oBgSwZwOfX; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: See RFC4241 and section 2.8 that says: [To achieve this requirement, for example, once the prefix 2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6 Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and DHCPv6-PD are up for the upstream direction. Because some implementations couldn't reply when 2001:db8:ffff::/64 was assigned to its downstream physical interface and the interface was down, such an implementation should assign 2001:db8:ffff::/64 for the loopback interface, which is always up, and 2001:db8:ffff:1::/64, 2001:db8:ffff:2::/64, etc., to physical interfaces.] NTT's ADSL deployment is already using a Loopback interface and why. Hemant =20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Tuesday, July 15, 2008 6:56 PM To: Stark, Barbara Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Antonio Querubin Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, > I disagree that if the loopback interface is not configured "you will=20 > have to use the Numbered model of our document and assign a global=20 > IPV6 to the WAN interface". Just to be sure, I think you're saying=20 > that the CPE router will need to get a global IPv6 address via SLAAC=20 > or stateful DHCPv6, from the access network. I do not see any reason=20 > why the CPE router cannot use one of the addresses from its assigned=20 > prefix. Since we are definitely considering using the "unnumbered=20 > model", and we have no loopback interface in our devices (and have no=20 > intention of having them), I think I'm going to have to try to get a second opinion on this. > Does anyone else have an opinion on whether or not the "unnumbered=20 > model" will only work in the presence of a loopback interface? > > By the way, I've never seen such a loopback interface in any mass=20 > market retail CPE routers. To me, the capabilities found in such mass=20 > market routers should be the benchmark for "very normal". I'm also not > familiar with it in DSL routers. DSL routers are also "very normal", worldwide. > I've been trying to search the Internet for products that include this > interface, and all I can find are Cisco products with IOS. I'm curious > as to whether any other vendors implement this interface, and, if so,=20 > on what sorts of mass market products. the loopback interface is a red herring. the unnumbered model will work just fine without it. /ot From owner-v6ops@ops.ietf.org Wed Jul 16 05:20:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597E53A699D for ; Wed, 16 Jul 2008 05:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.927 X-Spam-Level: * X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a54+Rs3tYtbw for ; Wed, 16 Jul 2008 05:20:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2924E3A699C for ; Wed, 16 Jul 2008 05:20:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5yR-000GZk-TD for v6ops-data@psg.com; Wed, 16 Jul 2008 12:19:11 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ5yL-000GYv-UM for v6ops@ops.ietf.org; Wed, 16 Jul 2008 12:19:09 +0000 Received: by yx-out-2324.google.com with SMTP id 8so2165704yxb.71 for ; Wed, 16 Jul 2008 05:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=lxDOmvyXPoFEGUyMFmMf9h2v23ZX8Y4SfS8B6i3+91I=; b=duJypaPj+SW1YHujPsd92lPdCbKDzVAvy7N5WyCVNu7zUKQ9t7IrwTkdeQfiU8K/Vp yaghWZFI2b1OBfoTNmBrysmmhQKo04aBvKAMKHOUND34MjQ1P9MT/gkI5VBh2UwE4I6a clwH9pwBxQz4x4E93uoJjrbk3SSYpTRCq4SvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=OFv8+RY9uBtPwKbyixnrPCGtvm1l/Qw/MxZ2oHQCCD6V1cEQNvBkCTKYBL0nfPuVSt IOD3E/tbCQxP+z53d0w5gX33VI1ZkDb8uRYvxVJSgVQVe4HzQoeeNpruzH1u2fi5Vxy6 L7eAKmg9ETBZIbHTNJ3nKI+sT83tahY/dY3DE= Received: by 10.141.151.18 with SMTP id d18mr8245633rvo.152.1216210744430; Wed, 16 Jul 2008 05:19:04 -0700 (PDT) Received: by 10.141.203.3 with HTTP; Wed, 16 Jul 2008 05:19:04 -0700 (PDT) Message-ID: <2bbba3c10807160519h6955d63ajd8342a6a00001f4a@mail.gmail.com> Date: Wed, 16 Jul 2008 14:19:04 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Antonio Querubin" , "Stark, Barbara" , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> X-Google-Sender-Auth: e6ff9f3978ac56c7 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Even if the CPE Router has a default router out the WAN interface to the > SP router, RPF may support a knob where "Allow default route to match > when checking source address" is not allowed. One can configure a > router to disable checking the default route to match src-addr by RPF. > > shark(config-if)#ipv6 verify unicast source reachable-via rx ? > WORD Access-list name > allow-default Allow default route to match when checking source > address > > > I have a spoofed packet with global src-addr input to the WAN interface > of a standalone CPE Router - the destination of this packet is the > global IPv6 address of a LAN interface. Strict uRPF check will check if > the src-addr is reachable by a path thru the input interface which is > the WAN interface. The WAN interface, which is also a routed port has > only a link-local address. So how can the global address have a path > thru the WAN interface that is assigned only a link-local address? see RFC3704. the uRPF check is done in the FIB. independent of addresses configured on the interfaces (apart from installed connected routes of course). I don't see much value in running uRPF on receive for the WAN interface. what isn't going to match the default route. you are only protecting yourself from receiving packets spoofed with a source from your own address space. as Antionio pointed out, doing it on the LAN side has value. > In general, if one even issues a ping to a global address and the ping > has to go out the WAN interface which only has a link-local address > configured, the ping will fail to head out because there is no valid > source address for destination. See a test from my IPv6 Cisco router > where I have assigned only a link-local address to the network interface > (FE80::205:FF:FEE0:74CE) that is supposed to send the ping out. that is also incorrect, and I can say that with some level of confidence since I wrote the IOS source address selection code in my previous life. IOS implements the weak host model, and will use an address from another interface if the outgoing interface doesn't have an address of sufficient scope. you need to have at least _one_ address configured on the box obviously. this is in any case host behaviour.you said: "...IPv6 routing and data forwarding breaks down if a routed interface of a router has only a link-local address." any other examples? > shark#ping 2001:420:3800:800:203:BAFF:FE11:B644 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:420:3800:800:203:BAFF:FE11:B644, > timeout is 2 seconds: > > % No valid source address for destination > Success rate is 0 percent (0/1) > shark# > shark#sh ipv6 int br > Ethernet0/0/0 [up/up] > unassigned > FastEthernet0/0/0 [up/up] > FE80::205:FF:FEE0:74CE /ot From owner-v6ops@ops.ietf.org Wed Jul 16 06:22:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6653D28C1AD for ; Wed, 16 Jul 2008 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUofD1MBsJXT for ; Wed, 16 Jul 2008 06:22:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80B8A3A6982 for ; Wed, 16 Jul 2008 06:22:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ6um-000Ndc-7W for v6ops-data@psg.com; Wed, 16 Jul 2008 13:19:28 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ6ui-000Ncr-7v for v6ops@ops.ietf.org; Wed, 16 Jul 2008 13:19:26 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 51AD7D0139; Wed, 16 Jul 2008 03:18:55 -1000 (HST) Date: Wed, 16 Jul 2008 03:18:55 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Ole Troan , "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 16 Jul 2008, Hemant Singh (shemant) wrote: > Even if the CPE Router has a default router out the WAN interface to the > SP router, RPF may support a knob where "Allow default route to match > when checking source address" is not allowed. One can configure a > router to disable checking the default route to match src-addr by RPF. Aren't we talking about a single-homed router? On a mass-market consumer router with one logical WAN interface connected to a service provider's edge, how likely would such a knob be used? Asymmetrical routing is proably not a significant factor. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Wed Jul 16 06:27:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D5E3A67F2 for ; Wed, 16 Jul 2008 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ3KaBNGOVyO for ; Wed, 16 Jul 2008 06:27:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D60B3A6846 for ; Wed, 16 Jul 2008 06:27:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ72I-000OXT-3g for v6ops-data@psg.com; Wed, 16 Jul 2008 13:27:14 +0000 Received: from [98.136.44.32] (helo=n54.bullet.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ72D-000OWR-5z for v6ops@ops.ietf.org; Wed, 16 Jul 2008 13:27:11 +0000 Received: from [216.252.122.218] by n54.bullet.mail.sp1.yahoo.com with NNFMP; 16 Jul 2008 13:27:05 -0000 Received: from [69.147.65.155] by t3.bullet.sp1.yahoo.com with NNFMP; 16 Jul 2008 13:27:05 -0000 Received: from [127.0.0.1] by omp403.mail.sp1.yahoo.com with NNFMP; 16 Jul 2008 13:27:05 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 305154.38495.bm@omp403.mail.sp1.yahoo.com Received: (qmail 79773 invoked by uid 60001); 16 Jul 2008 13:27:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=Ej4Xvj7w14fCdF5NCpHqxfkJ4SkpNs+41pR86DHbA4dJpZ/FWyZuF3axkte+0qgnlnbYdggEidXBi+g3MOz7cnHqeMd+vD2p5aOV1YpqTFQmM+OtsToJiZUse6C4rULpkLRR4+vepraV/QJsqFf38tzKVI0miQkO/zGcmIhNmJs=; Received: from [89.139.207.70] by web45501.mail.sp1.yahoo.com via HTTP; Wed, 16 Jul 2008 06:27:04 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Wed, 16 Jul 2008 06:27:04 -0700 (PDT) From: Gabi Nakibly Subject: Comments on draft-ietf-v6ops-tunnel-security-concerns-00.txt To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-566668314-1216214824=:79593" Message-ID: <939381.79593.qm@web45501.mail.sp1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0-566668314-1216214824=:79593 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0AI have some general comments concerning draft-ietf-v6ops-tunnel-se= curity-concerns-00.txt.=0A=A0=0A1) In the Introduction the draft=A0mentions= tunnels that go through NATs and it seems that=A0it is focused=A0solely=A0= on such tunnels. However, there are some security vulnerabilities discussed= throughout the draft (specifically in sections 2 and 3) that relate to tun= nels in general. I think the draft should be positioned to address tunnels = in general.=0A2)=A0What is=A0the relation of this draft to RFC4942 ("IPv6 t= ransition security considerations")? Will it update this RFC? There is some= considerable overlap between section 3 of the RFC and the draft. The=A0dra= ft=A0elaborates on issues which are already mentioned in=A0section 3=A0of t= he RFC and there are some points mentioned in the RFC which are not raised = in the draft. For example, using tunnels to make sure that the Hop Limit = =3D 255. Of course, there some issues in the draft which are not mentioned = in the RFC.=0A3) The major recommendation of the draft is in 3.1.3: "Tunnel= ing over UDP or TCP (including HTTP) to reach the Internet is=A0 not recomm= ended as a solution for managed networks.". Why is this recommendation rele= vant only to managed networks? It seems that in unmanaged environments (hom= e or SOHO) the use of such tunnels=A0will have similar effects.=0A4) How th= e above recommendation settles with the softwire group's recommendation to= =A0use=A0LT2P tunnels in the hub and spoke scenario (http://www.ietf.org/in= ternet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-09.txt)?=0A=A0=0AGabi= =0A=0A=0A --0-566668314-1216214824=:79593 Content-Type: text/html; charset=us-ascii
Hello,
I have some general comments concerning draft-ietf-v6ops-tunnel-security-concerns-00.txt.
 
1) In the Introduction the draft mentions tunnels that go through NATs and it seems that it is focused solely on such tunnels. However, there are some security vulnerabilities discussed throughout the draft (specifically in sections 2 and 3) that relate to tunnels in general. I think the draft should be positioned to address tunnels in general.
2) What is the relation of this draft to RFC4942 ("IPv6 transition security considerations")? Will it update this RFC? There is some considerable overlap between section 3 of the RFC and the draft. The draft elaborates on issues which are already mentioned in section 3 of the RFC and there are some points mentioned in the RFC which are not raised in the draft. For example, using tunnels to make sure that the Hop Limit = 255. Of course, there some issues in the draft which are not mentioned in the RFC.
3) The major recommendation of the draft is in 3.1.3: "Tunneling over UDP or TCP (including HTTP) to reach the Internet is  not recommended as a solution for managed networks.". Why is this recommendation relevant only to managed networks? It seems that in unmanaged environments (home or SOHO) the use of such tunnels will have similar effects.
4) How the above recommendation settles with the softwire group's recommendation to use LT2P tunnels in the hub and spoke scenario (http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-09.txt)?
 
Gabi

--0-566668314-1216214824=:79593-- From owner-v6ops@ops.ietf.org Wed Jul 16 07:15:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3993A681A for ; Wed, 16 Jul 2008 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSX-fvtoc2Z9 for ; Wed, 16 Jul 2008 07:15:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9ECD3A68B0 for ; Wed, 16 Jul 2008 07:15:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ7lf-0004Ex-HC for v6ops-data@psg.com; Wed, 16 Jul 2008 14:14:07 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ7lW-0004Dh-UY for v6ops@ops.ietf.org; Wed, 16 Jul 2008 14:14:05 +0000 X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14464614" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2008 14:13:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GEDvhq023490; Wed, 16 Jul 2008 10:13:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GEDvwP025140; Wed, 16 Jul 2008 14:13:57 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 10:13:57 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Wed, 16 Jul 2008 10:13:56 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjnRpi4nhZZQ/l4TtmN+rrCQt8kbQABY+BA References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Ole Troan" , "Stark, Barbara" , X-OriginalArrivalTime: 16 Jul 2008 14:13:57.0496 (UTC) FILETIME=[2FC4EF80:01C8E74E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2130; t=1216217637; x=1217081637; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=Q6TTmnPSD2/m1H1Vr0fC8xluLy/F5BQf5z7uiqj+Td8=; b=Uh5oR/+AQegTLVcjLlYJBxe/MepNHUMBciRejzuAfXwW0CinORPQ0i6Hpk Srq55GSYhtHQBt91NT7e3oOe1upxK+qKLml+SCCNU3J6Tj4Erld5oW4FRQa+ nPcnjiZERl; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 Antonio, Please see in line below. -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Wednesday, July 16, 2008 9:19 AM To: Hemant Singh (shemant) Cc: Ole Troan; Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Wed, 16 Jul 2008, Hemant Singh (shemant) wrote: > Even if the CPE Router has a default router out the WAN interface to=20 > the SP router, RPF may support a knob where "Allow default route to=20 > match when checking source address" is not allowed. One can configure > a router to disable checking the default route to match src-addr by RPF. Aren't we talking about a single-homed router?=20 On a mass-market consumer router with one logical WAN interface connected to a service provider's edge, how likely would such a knob be used? =20 Asymmetrical routing is proably not a significant factor. Folks may think the knob is less likely to be used. Asymmetrical routing may be likely for the CPE Router because besides the default router, as our draft says, RIPv6 may optionally run between the CPE Router and the SP aggregation router. You see, all folks in this discussion have said, RIPv6 is not needed. But when they said it's not needed they are talking about the upstream direction from the CPE Router to the SP. It's the downstream direction that is interesting. I already said yesterday, for the direction of RP to the CPE Router, how does the SP aggregation router know the routes to the PD's assigned to the CPE Router? In the March IETF, folks presented one solution (to v6ops) on how does the SP aggregation router learn routes to PD's in the downstream. IETF has still not standardized one solution for this problem nor am I sure if IETF would like to standardize such a solution. In the meantime, we are saying one may use RIPv6 to solve the problem. The other alternative is to have the aggregation router support DHCPv6 snooping for the IA_PD and then inject a route for the PD.=20 Hemant Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Wed Jul 16 07:39:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4C93A687D for ; Wed, 16 Jul 2008 07:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmJv2uC2pEPa for ; Wed, 16 Jul 2008 07:39:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA4153A681A for ; Wed, 16 Jul 2008 07:39:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ87T-0006s3-Em for v6ops-data@psg.com; Wed, 16 Jul 2008 14:36:39 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ87E-0006q5-1A for v6ops@ops.ietf.org; Wed, 16 Jul 2008 14:36:29 +0000 X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14484051" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2008 14:36:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GEaMIt003989; Wed, 16 Jul 2008 10:36:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6GEaM53028142; Wed, 16 Jul 2008 14:36:22 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 10:36:22 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Wed, 16 Jul 2008 10:36:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjnRpi4nhZZQ/l4TtmN+rrCQt8kbQABY+BAAAEx0PA= References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Antonio Querubin" Cc: "Ole Troan" , "Stark, Barbara" , X-OriginalArrivalTime: 16 Jul 2008 14:36:22.0827 (UTC) FILETIME=[51A627B0:01C8E751] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2704; t=1216218982; x=1217082982; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22Antonio=20Querubin=22=20; bh=mndTHj2udcpCjr7SdmLRPiUa8ZrY+2tjHfRWESPIO9U=; b=FzWbFWbYM7UTe0Zzx9WomDF0RkK7cdU0huRKCBfmfEHyo6RvGZSSeLHBwK fYktevWXpXOhkeGYJ/u1/wIj/D6ALgp4hERxCN+KMKTIa9eSYsQ/caGGD5bV UKaYVBGjAc; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sorry, I had two typos in the email below. Here are the fixed sentences for typos shown in quotes. [Asymmetrical routing may be likely for the CPE Router because besides the default "route", ...] and [for the direction of "SP" to the CPE Router] Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, July 16, 2008 10:14 AM To: Antonio Querubin Cc: Ole Troan; Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt =20 Antonio, Please see in line below. -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Wednesday, July 16, 2008 9:19 AM To: Hemant Singh (shemant) Cc: Ole Troan; Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Wed, 16 Jul 2008, Hemant Singh (shemant) wrote: > Even if the CPE Router has a default router out the WAN interface to=20 > the SP router, RPF may support a knob where "Allow default route to=20 > match when checking source address" is not allowed. One can configure > a router to disable checking the default route to match src-addr by RPF. Aren't we talking about a single-homed router?=20 On a mass-market consumer router with one logical WAN interface connected to a service provider's edge, how likely would such a knob be used? =20 Asymmetrical routing is proably not a significant factor. Folks may think the knob is less likely to be used. Asymmetrical routing may be likely for the CPE Router because besides the default router, as our draft says, RIPv6 may optionally run between the CPE Router and the SP aggregation router. You see, all folks in this discussion have said, RIPv6 is not needed. But when they said it's not needed they are talking about the upstream direction from the CPE Router to the SP. It's the downstream direction that is interesting. I already said yesterday, for the direction of RP to the CPE Router, how does the SP aggregation router know the routes to the PD's assigned to the CPE Router? In the March IETF, folks presented one solution (to v6ops) on how does the SP aggregation router learn routes to PD's in the downstream. IETF has still not standardized one solution for this problem nor am I sure if IETF would like to standardize such a solution. In the meantime, we are saying one may use RIPv6 to solve the problem. The other alternative is to have the aggregation router support DHCPv6 snooping for the IA_PD and then inject a route for the PD.=20 Hemant Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Wed Jul 16 11:07:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783F43A6990 for ; Wed, 16 Jul 2008 11:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zt5sg7hG1fm for ; Wed, 16 Jul 2008 11:07:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DAB03A697A for ; Wed, 16 Jul 2008 11:07:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJBLQ-0006Nc-1K for v6ops-data@psg.com; Wed, 16 Jul 2008 18:03:16 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJBLL-0006Lm-Li for v6ops@ops.ietf.org; Wed, 16 Jul 2008 18:03:14 +0000 X-IronPort-AV: E=Sophos;i="4.31,198,1215388800"; d="scan'208";a="87681031" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2008 18:03:11 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6GI3Au8026620; Wed, 16 Jul 2008 11:03:10 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6GI3AdY009645; Wed, 16 Jul 2008 18:03:10 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'marcelo bagnulo braun'" Cc: "'v6ops'" References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> <48776366.4040306@free.fr> <487B84D8.6000502@free.fr> Subject: RE: How to include APBP scenarios in the Coexistence RequirementI-D Date: Wed, 16 Jul 2008 11:03:10 -0700 Message-ID: <216601c8e76e$356ec5d0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <487B84D8.6000502@free.fr> Thread-Index: Acjl0zbIvOYhTpDYSWW8CzaF0Fyk7wBmUzjA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3256; t=1216231390; x=1217095390; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20How=20to=20include=20APBP=20scenarios=2 0in=20the=20Coexistence=20RequirementI-D |Sender:=20; bh=pnfblPhG3vqEf6JKmjKrwgfz68/NPGWO3tUrMFSWYZY=; b=SM3uJUA2Q86q6DDRzJ1WoPWPAQbfdUrbKiCvzOBYTJF7+RQ8ezt7PBD+MZ AbfsHffHjCX2AozkUAWLsHZYfINFU8h8nCZtr5h4HWVeyge+667VgSlVshfa qyM4Zg+G5+; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Following some privatly received comments of Dan Wing, the > standby phase hasn't be long, and the idea to possibly give up > APBP stands no longer ! > > I just posted draft-01, with I believe substantial simplifications > and improved applicability. > > Sorry for the one more change. Allow me to elaborate a bit on our offline discussion over the weekend. I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, dual-stack-lite, etc.) are quiet on a significant aspect of a requirement that is important: keeping existing games and existing applications working. I am thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to function properly over the Internet, and applications such as Microsoft Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job of explaining the specifics. A protocol which meets the requirements of APBP would allow UPnP IGD, NAT-PMP, and appropriate ALGs to be in the subscriber-side CPE box, and allow using APBP to the carrier-owned NAT64/NAT44 box to obtain a real, publicly-routable v4 transport address. That publicly-routable v45 transport address would then be used by the subscriber-side CPE in exactly the same way that today's subscriber-side CPE uses its own WAN transport address for the same functions. For UPnP IGD, the availability of APBP means a host that performs the UPnP getPublicIPAddress() API call would get a publicly-routable v4 transport address. Without APBP, a host performing that same function call would not get a v4 address at all. Here is some beautiful ASCII art diagrams of the difference between today's UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary) for tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: Today's UPnP IGD and NAT-PMP function at a high level: +-----------------+ |incoming UPnP IGD| |or NAT-PMP packet| +----+------------+ | V +-------------+ +-----------------------+ | need new |-----YES->| create NAT binding | |NAT binding? | |using NAT's WAN address| +----+--------+ +---------+-------------+ | | NO | | | V | +----+---------------+ | |respond to UPnP IGD |<------------+ |or NAT-PMP request | +----+---------------+ Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT (difference highlighted with "=" and capital letters): +-----------------+ |incoming UPnP IGD| |or NAT-PMP packet| +----+------------+ | V +-------------+ +=========================+ | need new |-----YES->| SEND "APBP" MESSAGE | |NAT binding? | | TOWARDS SP'S CARRIER NAT| +----+--------+ +=========+===============+ | | NO | | | V | +----+---------------+ | |respond to UPnP IGD |<------------+ |or NAT-PMP request | +----+---------------+ -d From owner-v6ops@ops.ietf.org Wed Jul 16 13:54:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695FC3A6986 for ; Wed, 16 Jul 2008 13:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKjJD0W7PUzX for ; Wed, 16 Jul 2008 13:54:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A3763A697C for ; Wed, 16 Jul 2008 13:54:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJDyW-0003DN-4d for v6ops-data@psg.com; Wed, 16 Jul 2008 20:51:48 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJDyK-0003Bs-3e for v6ops@ops.ietf.org; Wed, 16 Jul 2008 20:51:38 +0000 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8337356; Wed, 16 Jul 2008 16:51:07 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 16:51:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 20:50:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Microsoft-Entourage/12.11.0.080522 Content-class: urn:content-classes:message Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D Date: Wed, 16 Jul 2008 16:50:04 -0400 Message-ID: In-Reply-To: <216601c8e76e$356ec5d0$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to include APBP scenarios in the Coexistence RequirementI-D Thread-Index: Acjl0zbIvOYhTpDYSWW8CzaF0Fyk7wBmUzjAAAZAg9I= From: "Durand, Alain" To: "Dan Wing" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "marcelo bagnulo braun" Cc: "v6ops" X-OriginalArrivalTime: 16 Jul 2008 20:51:06.0993 (UTC) FILETIME=[AB419E10:01C8E785] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dan, Because there is only one level of NAT in dual-stack lite, couldn't this = be simplified by asking the dual-stack lite home gateway to forward the = UPnP message to the dual-stack lite carrier-grade NAT? - Alain. On 7/16/08 2:03 PM, "Dan Wing" wrote: >> Following some privatly received comments of Dan Wing, the >> standby phase hasn't be long, and the idea to possibly give up >> APBP stands no longer ! >>=20 >> I just posted draft-01, with I believe substantial simplifications >> and improved applicability. >>=20 >> Sorry for the one more change. >=20 > Allow me to elaborate a bit on our offline discussion over the = weekend. >=20 > I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > dual-stack-lite, etc.) are quiet on a significant aspect of a = requirement that > is important: keeping existing games and existing applications = working. I am > thinking of game boxes like Microsoft's Xbox that need UPnP IGD in = order to > function properly over the Internet, and applications such as = Microsoft > Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio = streaming > (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job = of > explaining the specifics. >=20 > A protocol which meets the requirements of APBP would allow UPnP IGD, = NAT-PMP, > and appropriate ALGs to be in the subscriber-side CPE box, and allow = using > APBP to the carrier-owned NAT64/NAT44 box to obtain a real, = publicly-routable > v4 transport address. That publicly-routable v45 transport address = would then > be used by the subscriber-side CPE in exactly the same way that = today's > subscriber-side CPE uses its own WAN transport address for the same = functions. > For UPnP IGD, the availability of APBP means a host that performs the = UPnP > getPublicIPAddress() API call would get a publicly-routable v4 = transport > address. Without APBP, a host performing that same function call = would not > get a v4 address at all. >=20 >=20 > Here is some beautiful ASCII art diagrams of the difference between = today's > UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and = necessary) for > tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: >=20 >=20 > Today's UPnP IGD and NAT-PMP function at a high level: >=20 > +-----------------+ > |incoming UPnP IGD| > |or NAT-PMP packet| > +----+------------+ > | > V > +-------------+ +-----------------------+ > | need new |-----YES->| create NAT binding | > |NAT binding? | |using NAT's WAN address| > +----+--------+ +---------+-------------+ > | | > NO | > | | > V | > +----+---------------+ | > |respond to UPnP IGD |<------------+ > |or NAT-PMP request | > +----+---------------+ >=20 >=20 > Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT > (difference highlighted with "=3D" and capital letters): >=20 >=20 > +-----------------+ > |incoming UPnP IGD| > |or NAT-PMP packet| > +----+------------+ > | > V > +-------------+ = +=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+ > | need new |-----YES->| SEND "APBP" MESSAGE | > |NAT binding? | | TOWARDS SP'S CARRIER NAT| > +----+--------+ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + > | | > NO | > | | > V | > +----+---------------+ | > |respond to UPnP IGD |<------------+ > |or NAT-PMP request | > +----+---------------+ >=20 > -d >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 14:22:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2BB3A69B0 for ; Wed, 16 Jul 2008 14:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s850SdNPu7Q for ; Wed, 16 Jul 2008 14:22:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C89A3A68AD for ; Wed, 16 Jul 2008 14:22:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEQQ-0006yY-RX for v6ops-data@psg.com; Wed, 16 Jul 2008 21:20:38 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEQK-0006xh-SW for v6ops@ops.ietf.org; Wed, 16 Jul 2008 21:20:36 +0000 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.57832781; Wed, 16 Jul 2008 17:19:45 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 17:19:51 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 21:19:28 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 17:19:25 -0400 Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D From: Alain Durand To: Alain Durand , Dan Wing , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , marcelo bagnulo braun CC: v6ops Message-ID: Thread-Topic: How to include APBP scenarios in the Coexistence RequirementI-D Thread-Index: Acjl0zbIvOYhTpDYSWW8CzaF0Fyk7wBmUzjAAAZAg9IAAQZpqg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Jul 2008 21:19:51.0067 (UTC) FILETIME=[AEE26EB0:01C8E789] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: But, of course, all this has to be balanced with the security (or lack thereof) of UPnP... - Alain. On 7/16/08 4:50 PM, "Alain Durand" wrote: > Dan, > > Because there is only one level of NAT in dual-stack lite, couldn't this be > simplified by asking the dual-stack lite home gateway to forward the UPnP > message to the dual-stack lite carrier-grade NAT? > > - Alain. > > > On 7/16/08 2:03 PM, "Dan Wing" wrote: > >>> Following some privatly received comments of Dan Wing, the >>> standby phase hasn't be long, and the idea to possibly give up >>> APBP stands no longer ! >>> >>> I just posted draft-01, with I believe substantial simplifications >>> and improved applicability. >>> >>> Sorry for the one more change. >> >> Allow me to elaborate a bit on our offline discussion over the weekend. >> >> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, >> dual-stack-lite, etc.) are quiet on a significant aspect of a requirement >> that >> is important: keeping existing games and existing applications working. I >> am >> thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to >> function properly over the Internet, and applications such as Microsoft >> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming >> (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job of >> explaining the specifics. >> >> A protocol which meets the requirements of APBP would allow UPnP IGD, >> NAT-PMP, >> and appropriate ALGs to be in the subscriber-side CPE box, and allow using >> APBP to the carrier-owned NAT64/NAT44 box to obtain a real, publicly-routable >> v4 transport address. That publicly-routable v45 transport address would >> then >> be used by the subscriber-side CPE in exactly the same way that today's >> subscriber-side CPE uses its own WAN transport address for the same >> functions. >> For UPnP IGD, the availability of APBP means a host that performs the UPnP >> getPublicIPAddress() API call would get a publicly-routable v4 transport >> address. Without APBP, a host performing that same function call would not >> get a v4 address at all. >> >> >> Here is some beautiful ASCII art diagrams of the difference between today's >> UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary) for >> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: >> >> >> Today's UPnP IGD and NAT-PMP function at a high level: >> >> +-----------------+ >> |incoming UPnP IGD| >> |or NAT-PMP packet| >> +----+------------+ >> | >> V >> +-------------+ +-----------------------+ >> | need new |-----YES->| create NAT binding | >> |NAT binding? | |using NAT's WAN address| >> +----+--------+ +---------+-------------+ >> | | >> NO | >> | | >> V | >> +----+---------------+ | >> |respond to UPnP IGD |<------------+ >> |or NAT-PMP request | >> +----+---------------+ >> >> >> Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT >> (difference highlighted with "=" and capital letters): >> >> >> +-----------------+ >> |incoming UPnP IGD| >> |or NAT-PMP packet| >> +----+------------+ >> | >> V >> +-------------+ +=========================+ >> | need new |-----YES->| SEND "APBP" MESSAGE | >> |NAT binding? | | TOWARDS SP'S CARRIER NAT| >> +----+--------+ +=========+===============+ >> | | >> NO | >> | | >> V | >> +----+---------------+ | >> |respond to UPnP IGD |<------------+ >> |or NAT-PMP request | >> +----+---------------+ >> >> -d >> >> > > > From owner-v6ops@ops.ietf.org Wed Jul 16 14:44:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01113A690E for ; Wed, 16 Jul 2008 14:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJKGM0ON1H+k for ; Wed, 16 Jul 2008 14:44:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C9F23A6862 for ; Wed, 16 Jul 2008 14:44:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEmi-0009hC-Gl for v6ops-data@psg.com; Wed, 16 Jul 2008 21:43:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEmY-0009gE-VA for v6ops@ops.ietf.org; Wed, 16 Jul 2008 21:43:38 +0000 X-IronPort-AV: E=Sophos;i="4.31,199,1215388800"; d="scan'208";a="53968425" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2008 21:32:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6GLWoPZ017532; Wed, 16 Jul 2008 14:32:50 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GLWn8m016841; Wed, 16 Jul 2008 21:32:50 GMT From: "Dan Wing" To: "'Durand, Alain'" , "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'marcelo bagnulo braun'" Cc: "'v6ops'" References: <216601c8e76e$356ec5d0$c2f0200a@cisco.com> Subject: RE: How to include APBP scenarios in the Coexistence RequirementI-D Date: Wed, 16 Jul 2008 14:32:49 -0700 Message-ID: <2ad401c8e78b$7f662490$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acjl0zbIvOYhTpDYSWW8CzaF0Fyk7wBmUzjAAAZAg9IAAR5vEA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4618; t=1216243970; x=1217107970; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20How=20to=20include=20APBP=20scenarios=2 0in=20the=20Coexistence=20RequirementI-D |Sender:=20; bh=JSQoa5hL6JxyOyP2Mxx2gz7LSeAIite/SX4iocOANOc=; b=L58t35aJ3NJVodxiyzLZqBNrsCStsGFX4xeBQ8HAc8KKEec+aMuuVhAPp9 FGK0T1Z+d40XkGiajwn/u9dweNyeDJk8h5KsGYMcYV1VnGAU3wF5vIHQNg1T YcykeqmOqYcF7VKEtnns7iUpItKuQU1/6ahxXIBlVPSF46oEx35PU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Durand, Alain [mailto:Alain_Durand@cable.comcast.com]=20 > Sent: Wednesday, July 16, 2008 1:50 PM > To: Dan Wing; R=E9mi Despr=E9s; marcelo bagnulo braun > Cc: v6ops > Subject: Re: How to include APBP scenarios in the Coexistence=20 > RequirementI-D >=20 > Dan, >=20 > Because there is only one level of NAT in dual-stack lite,=20 > couldn't this be > simplified by asking the dual-stack lite home gateway to=20 > forward the UPnP > message to the dual-stack lite carrier-grade NAT? Yes, UPnP IGD could be considered a candidate protocol to meet the needs of an address-port-borrowing-protocol. -d > - Alain. >=20 >=20 > On 7/16/08 2:03 PM, "Dan Wing" wrote: >=20 > >> Following some privatly received comments of Dan Wing, the > >> standby phase hasn't be long, and the idea to possibly give up > >> APBP stands no longer ! > >>=20 > >> I just posted draft-01, with I believe substantial=20 > simplifications > >> and improved applicability. > >>=20 > >> Sorry for the one more change. > >=20 > > Allow me to elaborate a bit on our offline discussion over=20 > the weekend. > >=20 > > I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > > dual-stack-lite, etc.) are quiet on a significant aspect of=20 > a requirement that > > is important: keeping existing games and existing=20 > applications working. I am > > thinking of game boxes like Microsoft's Xbox that need UPnP=20 > IGD in order to > > function properly over the Internet, and applications such=20 > as Microsoft > > Netmeeting (needs an H.323 ALG in the NAT), Quicktime and=20 > RealAudio streaming > > (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does=20 > a good job of > > explaining the specifics. > >=20 > > A protocol which meets the requirements of APBP would allow=20 > UPnP IGD, NAT-PMP, > > and appropriate ALGs to be in the subscriber-side CPE box,=20 > and allow using > > APBP to the carrier-owned NAT64/NAT44 box to obtain a real,=20 > publicly-routable > > v4 transport address. That publicly-routable v45 transport=20 > address would then > > be used by the subscriber-side CPE in exactly the same way=20 > that today's > > subscriber-side CPE uses its own WAN transport address for=20 > the same functions. > > For UPnP IGD, the availability of APBP means a host that=20 > performs the UPnP > > getPublicIPAddress() API call would get a publicly-routable=20 > v4 transport > > address. Without APBP, a host performing that same=20 > function call would not > > get a v4 address at all. > >=20 > >=20 > > Here is some beautiful ASCII art diagrams of the difference=20 > between today's > > UPnP IGD (and NAT-PMP) and what I am suggesting is useful=20 > (and necessary) for > > tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: > >=20 > >=20 > > Today's UPnP IGD and NAT-PMP function at a high level: > >=20 > > +-----------------+ > > |incoming UPnP IGD| > > |or NAT-PMP packet| > > +----+------------+ > > | > > V > > +-------------+ +-----------------------+ > > | need new |-----YES->| create NAT binding | > > |NAT binding? | |using NAT's WAN address| > > +----+--------+ +---------+-------------+ > > | | > > NO | > > | | > > V | > > +----+---------------+ | > > |respond to UPnP IGD |<------------+ > > |or NAT-PMP request | > > +----+---------------+ > >=20 > >=20 > > Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT > > (difference highlighted with "=3D" and capital letters): > >=20 > >=20 > > +-----------------+ > > |incoming UPnP IGD| > > |or NAT-PMP packet| > > +----+------------+ > > | > > V > > +-------------+ = +=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+ > > | need new |-----YES->| SEND "APBP" MESSAGE | > > |NAT binding? | | TOWARDS SP'S CARRIER NAT| > > +----+--------+ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + > > | | > > NO | > > | | > > V | > > +----+---------------+ | > > |respond to UPnP IGD |<------------+ > > |or NAT-PMP request | > > +----+---------------+ > >=20 > > -d > >=20 > >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 14:45:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCDE3A69BE for ; Wed, 16 Jul 2008 14:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H475i-gowg3 for ; Wed, 16 Jul 2008 14:45:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 261453A67AB for ; Wed, 16 Jul 2008 14:45:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEoo-0009xR-Hg for v6ops-data@psg.com; Wed, 16 Jul 2008 21:45:50 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJEok-0009wn-EB for v6ops@ops.ietf.org; Wed, 16 Jul 2008 21:45:48 +0000 X-IronPort-AV: E=Sophos;i="4.31,199,1215388800"; d="scan'208";a="127640900" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2008 21:45:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6GLjcI7027592; Wed, 16 Jul 2008 14:45:38 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6GLjb2S021425; Wed, 16 Jul 2008 21:45:38 GMT From: "Dan Wing" To: "'Alain Durand'" , "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'marcelo bagnulo braun'" Cc: "'v6ops'" References: Subject: RE: How to include APBP scenarios in the Coexistence RequirementI-D Date: Wed, 16 Jul 2008 14:45:38 -0700 Message-ID: <2b2101c8e78d$497a0e80$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acjl0zbIvOYhTpDYSWW8CzaF0Fyk7wBmUzjAAAZAg9IAAQZpqgAA4rTg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5025; t=1216244738; x=1217108738; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20How=20to=20include=20APBP=20scenarios=2 0in=20the=20Coexistence=20RequirementI-D |Sender:=20; bh=YEh1jVo0ymQvNCEJWyiPKCOXTExP6tc4apsBU8S6i8U=; b=hhejm5sor33c4yCWNYeZpbTR+8aEEKvpkTI+M1ttkm6QZEoDc2hgGa8em4 Ei3sOtI7iS/nJM0LnAG+DSg6wDiAIr3bS2e0Q0pcMkCnFP/1JHJBx0mVG98A tFNmB92AMD; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 > Sent: Wednesday, July 16, 2008 2:19 PM > To: Alain Durand; Dan Wing; R=E9mi Despr=E9s; marcelo bagnulo braun > Cc: v6ops > Subject: Re: How to include APBP scenarios in the Coexistence=20 > RequirementI-D >=20 > But, of course, all this has to be balanced with the security (or lack > thereof) of UPnP... A requirement of any APBP is that a subscriber could only open ports for their own IP address -- not their neighbor's IP address. -d > - Alain. >=20 >=20 > On 7/16/08 4:50 PM, "Alain Durand"=20 > wrote: >=20 > > Dan, > >=20 > > Because there is only one level of NAT in dual-stack lite,=20 > couldn't this be > > simplified by asking the dual-stack lite home gateway to=20 > forward the UPnP > > message to the dual-stack lite carrier-grade NAT? > >=20 > > - Alain. > >=20 > >=20 > > On 7/16/08 2:03 PM, "Dan Wing" wrote: > >=20 > >>> Following some privatly received comments of Dan Wing, the > >>> standby phase hasn't be long, and the idea to possibly give up > >>> APBP stands no longer ! > >>>=20 > >>> I just posted draft-01, with I believe substantial=20 > simplifications > >>> and improved applicability. > >>>=20 > >>> Sorry for the one more change. > >>=20 > >> Allow me to elaborate a bit on our offline discussion over=20 > the weekend. > >>=20 > >> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > >> dual-stack-lite, etc.) are quiet on a significant aspect=20 > of a requirement > >> that > >> is important: keeping existing games and existing=20 > applications working. I > >> am > >> thinking of game boxes like Microsoft's Xbox that need=20 > UPnP IGD in order to > >> function properly over the Internet, and applications such=20 > as Microsoft > >> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and=20 > RealAudio streaming > >> (RTSP), and so on. http://tools.ietf.org/html/rfc3027=20 > does a good job of > >> explaining the specifics. > >>=20 > >> A protocol which meets the requirements of APBP would=20 > allow UPnP IGD, > >> NAT-PMP, > >> and appropriate ALGs to be in the subscriber-side CPE box,=20 > and allow using > >> APBP to the carrier-owned NAT64/NAT44 box to obtain a=20 > real, publicly-routable > >> v4 transport address. That publicly-routable v45=20 > transport address would > >> then > >> be used by the subscriber-side CPE in exactly the same way=20 > that today's > >> subscriber-side CPE uses its own WAN transport address for the same > >> functions. > >> For UPnP IGD, the availability of APBP means a host that=20 > performs the UPnP > >> getPublicIPAddress() API call would get a=20 > publicly-routable v4 transport > >> address. Without APBP, a host performing that same=20 > function call would not > >> get a v4 address at all. > >>=20 > >>=20 > >> Here is some beautiful ASCII art diagrams of the=20 > difference between today's > >> UPnP IGD (and NAT-PMP) and what I am suggesting is useful=20 > (and necessary) for > >> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: > >>=20 > >>=20 > >> Today's UPnP IGD and NAT-PMP function at a high level: > >>=20 > >> +-----------------+ > >> |incoming UPnP IGD| > >> |or NAT-PMP packet| > >> +----+------------+ > >> | > >> V > >> +-------------+ +-----------------------+ > >> | need new |-----YES->| create NAT binding | > >> |NAT binding? | |using NAT's WAN address| > >> +----+--------+ +---------+-------------+ > >> | | > >> NO | > >> | | > >> V | > >> +----+---------------+ | > >> |respond to UPnP IGD |<------------+ > >> |or NAT-PMP request | > >> +----+---------------+ > >>=20 > >>=20 > >> Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT > >> (difference highlighted with "=3D" and capital letters): > >>=20 > >>=20 > >> +-----------------+ > >> |incoming UPnP IGD| > >> |or NAT-PMP packet| > >> +----+------------+ > >> | > >> V > >> +-------------+ = +=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+ > >> | need new |-----YES->| SEND "APBP" MESSAGE | > >> |NAT binding? | | TOWARDS SP'S CARRIER NAT| > >> +----+--------+ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + > >> | | > >> NO | > >> | | > >> V | > >> +----+---------------+ | > >> |respond to UPnP IGD |<------------+ > >> |or NAT-PMP request | > >> +----+---------------+ > >>=20 > >> -d > >>=20 > >>=20 > >=20 > >=20 > >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 15:59:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DCA3A6832 for ; Wed, 16 Jul 2008 15:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whZYG1ZaiZC6 for ; Wed, 16 Jul 2008 15:59:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 071103A6807 for ; Wed, 16 Jul 2008 15:59:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJFvI-000I3P-5K for v6ops-data@psg.com; Wed, 16 Jul 2008 22:56:36 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJFvD-000I2t-UJ for v6ops@ops.ietf.org; Wed, 16 Jul 2008 22:56:34 +0000 Received: (qmail 19700 invoked by uid 509); 16 Jul 2008 22:56:31 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.1/7724. spamassassin: 3.2.5. Clear:RC:1(211.28.128.246):. Processed in 0.087058 secs); 16 Jul 2008 22:56:31 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Wed, 16 Jul 2008 17:56:30 -0500 Cc: Dan Wing , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , marcelo bagnulo braun , v6ops Message-Id: <106836D5-7FCE-41E5-B7E2-855EE31AF8A2@thetiger.com> From: David Miles To: Alain Durand In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D Date: Thu, 17 Jul 2008 08:56:24 +1000 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I just want to add a consideration or two for UPnP and NAT-PMP operation in a an environment where many households will share a single IPv4 address. As I understand, UPnP does not have a mechanism to request a anonymous (or IGD/NAT-assigned port) whereas NAT-PMP does. In UPnP, the ExternalPort may request a wildcard mapping which indicates all unused ports should be listened to (DMZ operation), but provides no facility to request an external port be assigned and notify the UPnP client of its value. Consider a theoretical game supports any high-port, in UPnP the client must request a mapping and specify the external port. If the port-number can be any value it is reasonable to assume a random function should find a free port within a few AddPortMapping requests. NAT-PMP works differently, and does support the assignment of a high- numbered port of the NAT devices choosing (as it always responds to a mapping request with the Mapped External Port value). Without having firsthand experience I understand some applications, such as Xbox Live, request/require specific ports to be opened - something that is impractical when many households share the same IP address. Point being that each application would need to support a NAT- assigned (or at least randomise the request for an) external port. I realise that it is no different from having multiple clients in a single household but it may present an issue in some cases. Also, I am not sure it is a good idea to allow external ports to be < 1024 for port mappings (which invariably have a liftetime) because of the potential for impersonation or interception of traffic. Restricting port mappings to only high-ports may also impact some applications. All of these considerations leave me in two minds: do we go to the effort of inter-working UPnP/NAT-PMP with the invariable NAPT that must occur somewhere in the network accepting it will help some apps and not others; or, do we accept there are alternative methods for NAPT traversal and hole-punching that that do not require explicit signalling? If an application needs to be adapted to support either environment, perhaps the developers could include IPv6 transport and solve our problem. Does anyone have experience with UPnP and multiple devices/apps behind the same IGD, and the external port numbers they request? Regards, -David On 17/07/2008, at 7:19 AM, Alain Durand wrote: > But, of course, all this has to be balanced with the security (or lack > thereof) of UPnP... > > - Alain. > > > On 7/16/08 4:50 PM, "Alain Durand" > wrote: > >> Dan, >> >> Because there is only one level of NAT in dual-stack lite, couldn't >> this be >> simplified by asking the dual-stack lite home gateway to forward >> the UPnP >> message to the dual-stack lite carrier-grade NAT? >> >> - Alain. >> >> >> On 7/16/08 2:03 PM, "Dan Wing" wrote: >> >>>> Following some privatly received comments of Dan Wing, the >>>> standby phase hasn't be long, and the idea to possibly give up >>>> APBP stands no longer ! >>>> >>>> I just posted draft-01, with I believe substantial >>>> simplifications >>>> and improved applicability. >>>> >>>> Sorry for the one more change. >>> >>> Allow me to elaborate a bit on our offline discussion over the >>> weekend. >>> >>> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, >>> dual-stack-lite, etc.) are quiet on a significant aspect of a >>> requirement >>> that >>> is important: keeping existing games and existing applications >>> working. I >>> am >>> thinking of game boxes like Microsoft's Xbox that need UPnP IGD in >>> order to >>> function properly over the Internet, and applications such as >>> Microsoft >>> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and >>> RealAudio streaming >>> (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good >>> job of >>> explaining the specifics. >>> >>> A protocol which meets the requirements of APBP would allow UPnP >>> IGD, >>> NAT-PMP, >>> and appropriate ALGs to be in the subscriber-side CPE box, and >>> allow using >>> APBP to the carrier-owned NAT64/NAT44 box to obtain a real, >>> publicly-routable >>> v4 transport address. That publicly-routable v45 transport >>> address would >>> then >>> be used by the subscriber-side CPE in exactly the same way that >>> today's >>> subscriber-side CPE uses its own WAN transport address for the same >>> functions. >>> For UPnP IGD, the availability of APBP means a host that performs >>> the UPnP >>> getPublicIPAddress() API call would get a publicly-routable v4 >>> transport >>> address. Without APBP, a host performing that same function call >>> would not >>> get a v4 address at all. >>> >>> >>> Here is some beautiful ASCII art diagrams of the difference >>> between today's >>> UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and >>> necessary) for >>> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: >>> >>> >>> Today's UPnP IGD and NAT-PMP function at a high level: >>> >>> +-----------------+ >>> |incoming UPnP IGD| >>> |or NAT-PMP packet| >>> +----+------------+ >>> | >>> V >>> +-------------+ +-----------------------+ >>> | need new |-----YES->| create NAT binding | >>> |NAT binding? | |using NAT's WAN address| >>> +----+--------+ +---------+-------------+ >>> | | >>> NO | >>> | | >>> V | >>> +----+---------------+ | >>> |respond to UPnP IGD |<------------+ >>> |or NAT-PMP request | >>> +----+---------------+ >>> >>> >>> Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT >>> (difference highlighted with "=" and capital letters): >>> >>> >>> +-----------------+ >>> |incoming UPnP IGD| >>> |or NAT-PMP packet| >>> +----+------------+ >>> | >>> V >>> +-------------+ +=========================+ >>> | need new |-----YES->| SEND "APBP" MESSAGE | >>> |NAT binding? | | TOWARDS SP'S CARRIER NAT| >>> +----+--------+ +=========+===============+ >>> | | >>> NO | >>> | | >>> V | >>> +----+---------------+ | >>> |respond to UPnP IGD |<------------+ >>> |or NAT-PMP request | >>> +----+---------------+ >>> >>> -d >>> >>> >> >> >> > > > From owner-v6ops@ops.ietf.org Thu Jul 17 02:15:28 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027393A6B3F for ; Thu, 17 Jul 2008 02:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEguezS3E7lY for ; Thu, 17 Jul 2008 02:15:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 219963A6B3C for ; Thu, 17 Jul 2008 02:15:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJPVv-0005Ml-6A for v6ops-data@psg.com; Thu, 17 Jul 2008 09:11:03 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJPVi-0005KK-Aq for v6ops@ops.ietf.org; Thu, 17 Jul 2008 09:11:01 +0000 Received: (qmail 30959 invoked by uid 417); 17 Jul 2008 09:10:41 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 17 Jul 2008 09:10:41 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 17 Jul 2008 03:10:40 -0600 References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> <48776366.4040306@free.fr> <487B84D8.6000502@free.fr> <216601c8e76e$356ec5d0$c2f0200a@cisco.com> In-Reply-To: <216601c8e76e$356ec5d0$c2f0200a@cisco.com> From: EricLKlein@softhome.net To: "Dan Wing" Cc: "=?iso-8859-1?Q?'R=E9mi=20Despr=E9s'?=" , "'marcelo bagnulo braun'" , "'v6ops'" Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D Date: Thu, 17 Jul 2008 03:10:40 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [192.117.238.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dan Wing writes: >> Following some privatly received comments of Dan Wing, the >> standby phase hasn't be long, and the idea to possibly give up >> APBP stands no longer ! >> >> I just posted draft-01, with I believe substantial simplifications >> and improved applicability. >> >> Sorry for the one more change. > > Allow me to elaborate a bit on our offline discussion over the weekend. > > I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > dual-stack-lite, etc.) are quiet on a significant aspect of a requirement that > is important: keeping existing games and existing applications working. I am > thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to > function properly over the Internet, and applications such as Microsoft > Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming > (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job of > explaining the specifics. > As much as I hate discussions about NAT in context of IPv6, a good draft to look at is http://tools.ietf.org/html/draft-jennings-behave-nat6-00 From owner-v6ops@ops.ietf.org Thu Jul 17 02:46:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0B53A681B for ; Thu, 17 Jul 2008 02:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo-G+WQciBVa for ; Thu, 17 Jul 2008 02:46:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C17E3A6817 for ; Thu, 17 Jul 2008 02:46:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJQ34-0009Vt-9u for v6ops-data@psg.com; Thu, 17 Jul 2008 09:45:18 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJQ30-0009VK-11 for v6ops@ops.ietf.org; Thu, 17 Jul 2008 09:45:16 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 496813EA0C8; Thu, 17 Jul 2008 11:45:10 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id D8F583EA0F8; Thu, 17 Jul 2008 11:45:09 +0200 (CEST) Message-ID: <487F1483.5030403@free.fr> Date: Thu, 17 Jul 2008 11:44:35 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dan Wing CC: 'marcelo bagnulo braun' , 'v6ops' Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> <48776366.4040306@free.fr> <487B84D8.6000502@free.fr> <216601c8e76e$356ec5d0$c2f0200a@cisco.com> In-Reply-To: <216601c8e76e$356ec5d0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dan Wing - Le 7/16/08 8:03 PM : > I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > dual-stack-lite, etc.) are quiet on a significant aspect of a requirement that > is important: keeping existing games and existing applications working. I am > thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to > function properly over the Internet, and applications such as Microsoft > Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming > (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job of > explaining the specifics. Thanks, a very useful RFC. > Here is some beautiful ASCII art diagrams of the difference between today's > UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary) for > tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: In the new APBP draft (http://tools.ietf.org/html/draft-despres-v6ops-apbp-01), an APBP client obtains in one request a public IPv4 address and a range of ports to go with it. An APBP message to the APBP server is then not necessary for each UPnP... packet, and independent outgoing connections will have the same public IPv4 source adress, IMO an important progress. Here is a proposed revision of your ASCII art: +-----------------+ |incoming UPnP IGD| |or NAT-PMP packet| +----+------------+ | V +-------------+ +===============================+ | need new |-----YES->|If needed, Send an APBP Request| |NAT binding? | | Then create NAT binding | +----+--------+ |using the obtained IPv4 address| | | and a free port in its range | NO +===============================+ | | V | +----+---------------+ | |respond to UPnP IGD |<------------+ |or NAT-PMP request | +----+---------------+ Once an APBP client has obtained a range of ports with an address, it can operate as though it would have an exclusive v4 address, except that it has less than 64K ports to go with it, and no port in the < 1024 range. - Of course, this is still a significant restriction but, IMU, CGNs won't do better. - To be reachable on a well-known port, in a site that has an IPv6 prefix and no public IPv4 address, applications should better be reachable in IPv6. Regards. RD From owner-v6ops@ops.ietf.org Thu Jul 17 07:35:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339113A69EE for ; Thu, 17 Jul 2008 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdQecfYe2viC for ; Thu, 17 Jul 2008 07:35:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25C923A69BD for ; Thu, 17 Jul 2008 07:35:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUW2-000HyZ-OM for v6ops-data@psg.com; Thu, 17 Jul 2008 14:31:30 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUVs-000Hv1-JC for v6ops@ops.ietf.org; Thu, 17 Jul 2008 14:31:25 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id E10947A9462;Thu, 17 Jul 2008 16:31:11 +0200 (CEST) Message-ID: <487F57AF.8000600@it.uc3m.es> Date: Thu, 17 Jul 2008 16:31:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <484C9758.90904@gmail.com> In-Reply-To: <484C9758.90904@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-16.7165 TC:1F TRN:62 TV:5.5.1026(16036.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Brain, thanks for the comments, i am working on this see comemnts and a few questions below... Brian E Carpenter escribiĂ³: > Hi, > > A few comments: > > >> 2.1. Transition scenarios >> >> There are six obvious transition scenarios: >> > > I think we can avoid off-topic reactions by changing this > slightly: > > There are six obvious IP layer transition scenarios: > > done > and adding underneath something like > > Transition scenarios involving the use of upper layer proxies > have their place, but are out of scope for this document. > > done >> 2.1.3. Transition scenarios that require translation >> > > I think there's a point that should be made in this section: > > In practice, it is highly likely that addresses will be in short > supply in the IPv4-only domain, and therefore that address sharing > and port mapping will be required. These functions may or may not > be combined with the IPv6-IPv4 translation function. > > done >> 3.3. v4 addressing consideration >> > ... > >> ...The case where the v4-only node has a >> private v4 address and the NAT64 box has a public address seems also >> possible, but here it seems reasonable to assume that a NAT box will >> exist between the v4 only node and the NAT64 box. >> > > There is an alternative assumption which is that traditional NAT > (v4 to v4) is embedded in the NAT64 device. There is a difference, > because then the NAT64 is aware of the address and port mappings > (and that opens some possibilities, as SHANTI and MNAT-PT show). > > added that the nat44 can be colocated with the nat64 box >> 3.4. Name-space considerations >> >> One of the major choices that are faced when designing a NAT4 >> mechanism that enable communication initiated by the v4-only node >> towards a v6-only node. In this case, the v4 only node needs to >> identify the v6 only node and the problem is that there is no means >> to permanently map the v6 address space in the v4 address space. >> > > Well yes, that is unsolvable, so let's not try to solve it. > This returns to point about port mapping - if you want the NAT64 to > support incoming sessions, the number of sessions is limited by > (number of ports)*(number of IPv4 addresses). In DNS, the IPv6-only > servers will have to be represented by a shared A record for each > IPv4 address. That doesn't require a DNS ALG. But it does require > defined mappings for inbound ports. That's NAT 101, and the mapping > to IPv6 doesn't change it. > > right, not sure if you want me to do somehting about this in the document? >> o R2.2: Translation mechanim must support v4-initiated short-lived >> local handle (as defined in Section 3.1). (not clear if there is >> consensus for this) >> > > I think that if we're going to do this at all, it needs to be symmetrical, > so I hum for this. > > ok same question that i have done to Dan, do you think servers can be located in v6 land or only peers? (i.e. p2p applications with v4 and v6 peers) >> o R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4 >> private addresses and use a NAT.(The acceptance of R2.2.1 is >> subject to the acceptance of R2.2. >> > > As noted above, that does *not* imply a separate NAT; it could be combined > with the NAT64. > > cahnges nat by nat function, ok? thanks, marcelo > Brian > > > From owner-v6ops@ops.ietf.org Thu Jul 17 07:49:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D9F3A6A84 for ; Thu, 17 Jul 2008 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v619Av9GR1Dx for ; Thu, 17 Jul 2008 07:49:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBC543A6A7F for ; Thu, 17 Jul 2008 07:49:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUmc-000K4L-C5 for v6ops-data@psg.com; Thu, 17 Jul 2008 14:48:38 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUmW-000K3N-8K for v6ops@ops.ietf.org; Thu, 17 Jul 2008 14:48:35 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id 5DDA27BE492;Thu, 17 Jul 2008 16:48:29 +0200 (CEST) Message-ID: <487F5BBD.4020708@it.uc3m.es> Date: Thu, 17 Jul 2008 16:48:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Philip Matthews CC: v6ops Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <09E3E900-0058-4D5D-BC43-2B6CB244CE9E@magma.ca> In-Reply-To: <09E3E900-0058-4D5D-BC43-2B6CB244CE9E@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.6765 TC:1F TRN:75 TV:5.5.1026(16036.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Phillip, thanks for the review I am trying to work on your comments but i havne't been able to actually reflect any changes in the document so far... see below Philip Matthews escribió: > Some comments on this draft, from the perspective of someone familiar > with the various BEHAVE documents. > > * R6 lists TCP, UDP, ICMP, and TLS as protocols to be supported. I am > surprised that TLS is listed in addition to TCP, since full TCP > support would imply TLS. is this so? If yes, it seems that needs to be removed, should we? > I am also surprised that DTLS is not listed, if listing TLS is seen as > necessary. Any explanation for this? > > * R7 lists the BEHAVE requirement documents for TCP and UDP. Is there > some reason for not listing the BEHAVE requirement document for ICMP? > well, behave req for tcp and udp are included to make sure that ICE works do we need to comply with icmp reqs to make ice work? is there other reasons why we should include icmp reqs? > * R8 talks about fragmented packets. Is there some reason to include > this specifically, given that the BEHAVE requirements cover > fragmentation in some detail? do you think that we should simply refer to the behave document for this and remove this req? aren't the behave req v4 specific? i mean, do they apply to v6 fragments? > The BEHAVE requirements do not mention the 5 second stuff, but they > talk about out-of-order fragments which R8 does not mention. > the current version covers in order and out of order packets > * I6 and I7 talk about SCTP and DCCP support. Is it acceptable to > support these by transporting them over UDP? > don't know, do you think we need to be explicit about it? why? > * I8 talks about multicast. Should multicast support comply with the > BEHAVE requirement document for multicast? > don't know, what do you think? > * A (long) comment on R2. > There is a class of applications that work today through NAT44s. As a > general rule, these are applications that do not carry addresses > embedded inside protocol messages, and have communication initiated by > the host behind the NAT. Is this the same class of applications that > should be supported by the proposed translation mechanism? > well, i think it is a subset, cause we only require client server with v4 clients. p2p communications are considered in I4, cause they require host support > Code in a NAT that recognizes packets of a specific application > protocol and does special processing of that packet is known as an ALG > (Application Level Gateway). The BEHAVE group considers an FTP ALG to > be acceptable, because FTP was there before NATs, but other ALGs are > discouraged (= default off). Is this rule consistent with the proposed > transition mechanism? This rule is given in RFC 4787, which R7 says > the mechanism must comply with. > > If so, is R2 an attempt to formalize all this in different words? > i don't think so, as i mention above, it seems more restricitive than that Regards,marcelo > - Philip > > > > On Tue, 13-May-08, at 19:30 , 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 : IPv4/IPv6 Coexistence and Transition: >> Requirements for solutions >> Author(s) : M. Bagnulo, et al. >> Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt >> Pages : 17 >> Date : 2008-05-13 >> >> This note presents the problem statement, analysis and requirements >> for solutions to IPv4/IPv6 coexistence and eventual transition in a >> scenario in which dual stack operation is not the norm. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statement-req-00.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > From owner-v6ops@ops.ietf.org Thu Jul 17 07:49:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC963A6A99 for ; Thu, 17 Jul 2008 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35OFIOPBUyHI for ; Thu, 17 Jul 2008 07:49:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D38673A6A7F for ; Thu, 17 Jul 2008 07:49:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUmq-000K6S-Rf for v6ops-data@psg.com; Thu, 17 Jul 2008 14:48:52 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJUmk-000K5I-JV for v6ops@ops.ietf.org; Thu, 17 Jul 2008 14:48:50 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp02.uc3m.es (Postfix) with ESMTP id B8D7341F957;Thu, 17 Jul 2008 16:48:43 +0200 (CEST) Message-ID: <487F5BCB.1070209@it.uc3m.es> Date: Thu, 17 Jul 2008 16:48:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, =?ISO-8859-1?Q?R=E9mi_Despr=E9s?=, Jari Arkko , Philip Matthews Subject: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.1302 TC:1F TRN:58 TV:5.5.1026(16036.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I am trying to extract the actual proposed changes for the draft ------------------------------------------ - 1) Additional scenario needed? ------------------------------------------ It seems that there is the potential need for a new scenario. It is the case described by Dan and by Teemu about a dual stack host, located in a v6 network, and that needs to run a v4 only application. In order to do that, it needs to obtain a public IPv4 transport address and also discover a tunnel endpoint, so it can tunnel v4 packets in v6 till the tunnel endpoint and use the IPv4 transport address it has obtained to establish a communication with v4 land. So essentially this is tunnel scenario, but rather than being obtaining a full IPv4 address to use, the host only obtains a transport address (which is public) I understand that this is what Dan and Teemu are proposing, is that correct? So, if this is the case, how can we fit this into the document? As i see it, the document has two parts, clearly differentiated: A first part that covers an overview of the different aspects of transition and then a part that described the specific requirements of new translation mechanism I think that it makes sense to me to include a description of this case in the overview section. In order to do that, we need first to ackwoledge the exsitance of a new scenarion in section 2.1. Transition scenarios currently, it includes 6 scenarios: There are six obvious transition scenarios: o IPv4 system connecting to an IPv4 system across an IPv4 network, o An IPv6 system connecting to an IPv6 system across an IPv6 network, o an IPv4 system connecting to an IPv4 system across an IPv6 network, o an IPv6 system connecting to an IPv6 system across an IPv4 network, o an IPv4 system connecting to an IPv6 system, or o an IPv6 system connecting to an IPv4 system. I understand that we need to include one more: o a dual stack system connected to a IPv6 domain that is connecting to an IPv4 system. In addition, we need to include an additional text in section 2.1.2. Transition scenarios that do not require translation something along these lines: Another scenario that does not involves translation is the case where a dual stack node is connected to an IPv6-only domain and it is communicating with a IPv4-only node as depicted in Figure 2. ,-----. ,-----. ,' `. ,' `. / \ / \ / IPv6-only \ / IPv4-only \ / Domain +-----------+ Domain \ ; | Tunnel | : | | endpoint | | : +-----+ +-----------+ ; \ |Dual | / \ +----+ / \ |Stack| / \ |IPv4| / \ |Host | / \ |Host| / `.+-----+,' `. +----+,' '-----' '-----' In this case, the dual stack host needs to establish a IPv4 in IPv6 tunnel to the tunnel endpoint. In addition to that, the dual stack needs to obtain a IPv4 address that is valid in the IPv4-only domain. The simplest option is for the dual stack to obtain an IPv4 public address. However, this may not be possible due to the shortage of IPv4 public addresses. The other option is to use an IPv4 private address (and potentially in conjunction with IPv4 NAT). The other option is for the dual stack to obtain a public IPv4 transport address. In all the cases, the acquisition of the address can be performed dynamically. would this address your inputs? ---------------------------------------- -2) Scalability ---------------------------------------- Teemu proposed to include: 2.2. Requirements for the overall transition strategy 8. Transition architectures should be scalable for large number of hosts and high data speeds. 4.2. Important things that SHOULD be supported I9: Scalability The translation mechanism SHOULD support very large number of hosts and high data speeds with reasonable infrastructure requirements considering equipment available at the transition timeframe. I think this makes sense, and i have a hard time finding someone who don't agrees with this so i am planning to include them -------------------------------------------- -3) discovery --------------------------------------------- Teemu also porposed: 2.2. Requirements for the overall transition strategy 9. Availability of transition solutions on an access network should be quickly discoverable. 4.2. Important things that SHOULD be supported I10: Discovery The translation mechanism SHOULD be quickly discoverable, preferably in one RTT, to help moving hosts better assess capabilities of available access networks and to provide good user experience. I have a hard time understanding this one. I mean R1 states: R1: Changes in the hosts The translation mechanism MUST NOT require changes in the v4-only nodes to support the Basic requirements described in this section, unless explicitly stated in the particular requirement. The translation mechanism MAY require changes to v6-only nodes. So if we don't want changes in the host, how can a host have the discovery mechanisms? I mean, i think this assuming some other form of solution that is not based on translation. I am not doing anything about this at this point ------------------------------------------ -4) no translation ------------------------------------------ Teemu also porposed: 4.3. Important things that MAY be supported M1: No NATs or ALGs The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid need for ALGs. this clearly seems contradictory in a requirements fro translation (no translation) I understand that translation should be avoided and we already say this in the document i.e. that dual stack is preferred and then tunnel and finally if there is no other option translation. I don't think that this should go in the requirements section cause seems like and oxymoron to me ------------------------------------------ -5) MIP6 support ------------------------------------------ George and Jaru commented that I5: MIPv6 support should go away I am removing that ------------------------------------------ -6) Symbian ------------------------------------------ added symbian to the OS in market timing consdierations regards, marcelo From owner-v6ops@ops.ietf.org Thu Jul 17 08:05:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E853A686B for ; Thu, 17 Jul 2008 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.338 X-Spam-Level: ** X-Spam-Status: No, score=2.338 tagged_above=-999 required=5 tests=[AWL=-1.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jweGZvXa1n1 for ; Thu, 17 Jul 2008 08:05:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60CC23A6781 for ; Thu, 17 Jul 2008 08:05:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJV19-000MGP-Qm for v6ops-data@psg.com; Thu, 17 Jul 2008 15:03:39 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJV10-000MFJ-QJ for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:03:36 +0000 Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.57855991; Thu, 17 Jul 2008 11:03:09 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 11:03:10 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 15:02:21 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 11:02:19 -0400 Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D From: Alain Durand To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Dan Wing CC: marcelo bagnulo braun , v6ops Message-ID: Thread-Topic: How to include APBP scenarios in the Coexistence RequirementI-D Thread-Index: Acjn9cfsLUOyuoRHTambGl3DA2Gv4AAKFOwx In-Reply-To: <487F1483.5030403@free.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Jul 2008 15:03:10.0269 (UTC) FILETIME=[3A2C16D0:01C8E81E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: R=E9mi, I have some fundamental objections to the APBP proposal. What is does is replace the carrier grade nat (CGN) by a distributed system of home gateways that are allocated chunks of port numbers. The service provider still has to run the port mapping part of the CGN, the only advantage I see is to avoid back-hauling the data traffic to the CGN. You still have most if the issue with CGN, which are mainly customer apps cannot expect to run on their own, well know, port number. More importantly, you introduce a whole bunch of new issues. In random order: - You need to put filtering in place on the ISP access router to make sure the customer is only using the allocated port numbers. This list needs to b= e in sync with the port number allocation system. - The same access router now need to do port base routing to return the packets to the customer. This is not without cost. - Allocating chunks of port number is not the most efficient allocation algorithm. If a customers does nothing or just use one port number, you are wasting a lot of resources. - Timing out those port number is a bit of a mess, both the apps, the home gateway, the access router and the port allocation system need to be synced up. - All kind of security measure need to be put in place to prevent customers to hoard the port number space. In other words, the complexity you create by distributing the mapping mechanism seems high. It seem to me a better trade-off to centralize this i= n a CGN. Please note that an ISP does not need to run only one CGN and can distribute those as well close to its network edge, but no closer. Note: the route you are on seems to lead to IPv7 (ask ekr about it), where you augment the IPv4 addressing space with the port number space for routing. You might have seen the T-shirt 32+16 > 128. - Alain. On 7/17/08 5:44 AM, "R=E9mi Despr=E9s" wrote: > Dan Wing - Le 7/16/08 8:03 PM : >=20 >> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, >> dual-stack-lite, etc.) are quiet on a significant aspect of a requiremen= t >> that >> is important: keeping existing games and existing applications working.= I >> am >> thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order= to >> function properly over the Internet, and applications such as Microsoft >> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio stre= aming >> (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does a good job o= f >> explaining the specifics. >=20 > Thanks, a very useful RFC. >=20 >=20 >=20 >> Here is some beautiful ASCII art diagrams of the difference between toda= y's >> UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary= ) for >> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP: >=20 > In the new APBP draft > (http://tools.ietf.org/html/draft-despres-v6ops-apbp-01), an APBP client > obtains in one request a public IPv4 address and a range of ports to go > with it. > An APBP message to the APBP server is then not necessary for each > UPnP... packet, and independent outgoing connections will have the same > public IPv4 source adress, IMO an important progress. >=20 > Here is a proposed revision of your ASCII art: >=20 > +-----------------+ > |incoming UPnP IGD| > |or NAT-PMP packet| > +----+------------+ > | > V > +-------------+ +=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+ > | need new |-----YES->|If needed, Send an APBP Request| > |NAT binding? | | Then create NAT binding | > +----+--------+ |using the obtained IPv4 address| > | | and a free port in its range | > NO +=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+ > | | > V | > +----+---------------+ | > |respond to UPnP IGD |<------------+ > |or NAT-PMP request | > +----+---------------+ >=20 >=20 >=20 >=20 > Once an APBP client has obtained a range of ports with an address, it > can operate as though it would have an exclusive v4 address, except that > it has less than 64K ports to go with it, and no port in the < 1024 range= . > - Of course, this is still a significant restriction but, IMU, CGNs > won't do better. > - To be reachable on a well-known port, in a site that has an IPv6 > prefix and no public IPv4 address, applications should better be > reachable in IPv6. >=20 >=20 > Regards. >=20 > RD >=20 From owner-v6ops@ops.ietf.org Thu Jul 17 08:13:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1092A3A67E6 for ; Thu, 17 Jul 2008 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.206 X-Spam-Level: ** X-Spam-Status: No, score=2.206 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moCTJU1nk+AS for ; Thu, 17 Jul 2008 08:13:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38DB43A68C0 for ; Thu, 17 Jul 2008 08:13:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJV9m-000NY1-I1 for v6ops-data@psg.com; Thu, 17 Jul 2008 15:12:34 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJV9i-000NX9-2r for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:12:32 +0000 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.57856334; Thu, 17 Jul 2008 11:07:23 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 11:07:24 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 15:07:06 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 11:07:04 -0400 Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt From: Alain Durand To: marcelo bagnulo braun , 'IPv6 Operations' , Fred Baker , Dan Wing , , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Jari Arkko , Philip Matthews Message-ID: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjoHsV8mmk45FvATEuKag6wCV9niA== In-Reply-To: <487F5BCB.1070209@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jul 2008 15:07:24.0289 (UTC) FILETIME=[D1947710:01C8E81E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/17/08 10:48 AM, "marcelo bagnulo braun" wrote: > Hi, > > I am trying to extract the actual proposed changes for the draft > > ------------------------------------------ > - 1) Additional scenario needed? > ------------------------------------------ > > It seems that there is the potential need for a new scenario. > It is the case described by Dan and by Teemu about a dual stack host, > located in a v6 network, and that needs to run a v4 only application. In > order to do that, it needs to obtain a public IPv4 transport address and > also discover a tunnel endpoint, so it can tunnel v4 packets in v6 till > the tunnel endpoint and use the IPv4 transport address it has obtained > to establish a communication with v4 land. > > So essentially this is tunnel scenario, but rather than being obtaining > a full IPv4 address to use, the host only obtains a transport address > (which is public) > > I understand that this is what Dan and Teemu are proposing, is that correct? How is this different from the dual-stack lite mechanism? See draft-durand-dual-stack-lite-00.txt, section 3.2 Second question, if you have that, why is it not enough and why would you still need to do any IPv6 to IPv4 translation? - Alain. From owner-v6ops@ops.ietf.org Thu Jul 17 08:17:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DD03A68C0 for ; Thu, 17 Jul 2008 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLVuqfU368tq for ; Thu, 17 Jul 2008 08:17:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4DD13A68A8 for ; Thu, 17 Jul 2008 08:17:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVDw-000O6i-0e for v6ops-data@psg.com; Thu, 17 Jul 2008 15:16:52 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVDr-000O5M-A6 for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:16:50 +0000 X-IronPort-AV: E=Sophos;i="4.31,204,1215388800"; d="scan'208";a="87994384" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2008 15:15:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6HFFYED018775; Thu, 17 Jul 2008 08:15:34 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6HFFY9O013225; Thu, 17 Jul 2008 15:15:34 GMT From: "Dan Wing" To: Cc: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'marcelo bagnulo braun'" , "'v6ops'" References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485A9E8C.8080907@it.uc3m.es> <48776366.4040306@free.fr> <487B84D8.6000502@free.fr> <216601c8e76e$356ec5d0$c2f0200a@cisco.com> Subject: RE: How to include APBP scenarios in the Coexistence RequirementI-D Date: Thu, 17 Jul 2008 08:15:33 -0700 Message-ID: <2ff601c8e81f$f5cc0d40$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acjn7Q2C1W7GobpkQ7+hmrJ1mzU/BwAMtdOA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1721; t=1216307734; x=1217171734; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20How=20to=20include=20APBP=20scenarios=2 0in=20the=20Coexistence=20RequirementI-D |Sender:=20; bh=8LKCle+EoaCxx0op2KjgB9Ai4w4uMZq4NppRapDiIHs=; b=DvvBzIF7sXCBQ3qg/Def+9Nsjo+4wPOERqaYdzhNpi8Aj1b/Prt+SnFXCb gpc3n1TjlXW80/t3dxVTAn56vplD9F9rRsHGlPXPiH/bPQnfsSBdMJkyfF50 fqSN1ta+oZ; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: EricLKlein@softhome.net [mailto:EricLKlein@softhome.net]=20 > Sent: Thursday, July 17, 2008 2:11 AM > To: Dan Wing > Cc: 'R=E9mi Despr=E9s'; 'marcelo bagnulo braun'; 'v6ops' > Subject: Re: How to include APBP scenarios in the Coexistence=20 > RequirementI-D >=20 > Dan Wing writes:=20 >=20 > >> Following some privatly received comments of Dan Wing, the=20 > >> standby phase hasn't be long, and the idea to possibly give up=20 > >> APBP stands no longer !=20 > >>=20 > >> I just posted draft-01, with I believe substantial=20 > simplifications=20 > >> and improved applicability.=20 > >>=20 > >> Sorry for the one more change. > >=20 > > Allow me to elaborate a bit on our offline discussion over=20 > the weekend.=20 > >=20 > > I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI, > > dual-stack-lite, etc.) are quiet on a significant aspect of=20 > a requirement that > > is important: keeping existing games and existing=20 > applications working. I am > > thinking of game boxes like Microsoft's Xbox that need UPnP=20 > IGD in order to > > function properly over the Internet, and applications such=20 > as Microsoft > > Netmeeting (needs an H.323 ALG in the NAT), Quicktime and=20 > RealAudio streaming > > (RTSP), and so on. http://tools.ietf.org/html/rfc3027 does=20 > a good job of > > explaining the specifics.=20 > >=20 >=20 > As much as I hate discussions about NAT in context of IPv6, a=20 > good draft to=20 > look at is http://tools.ietf.org/html/draft-jennings-behave-nat6-00 I attempted to kick off a discussion of that draft on Behave. I would certainly like to see more discussion of it. -d From owner-v6ops@ops.ietf.org Thu Jul 17 08:30:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9B33A6A84 for ; Thu, 17 Jul 2008 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOW4Ezvw-LVQ for ; Thu, 17 Jul 2008 08:30:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 225853A695A for ; Thu, 17 Jul 2008 08:30:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVQI-0000ED-Un for v6ops-data@psg.com; Thu, 17 Jul 2008 15:29:38 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVQF-0000DL-0B for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:29:37 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp02.uc3m.es (Postfix) with ESMTP id 0AAE741F9AD;Thu, 17 Jul 2008 17:29:32 +0200 (CEST) Message-ID: <487F655B.2090004@it.uc3m.es> Date: Thu, 17 Jul 2008 17:29:31 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alain Durand CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.1432 TC:1F TRN:36 TV:5.5.1026(16036.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand escribió: > > On 7/17/08 10:48 AM, "marcelo bagnulo braun" wrote: > > >> Hi, >> >> I am trying to extract the actual proposed changes for the draft >> >> ------------------------------------------ >> - 1) Additional scenario needed? >> ------------------------------------------ >> >> It seems that there is the potential need for a new scenario. >> It is the case described by Dan and by Teemu about a dual stack host, >> located in a v6 network, and that needs to run a v4 only application. In >> order to do that, it needs to obtain a public IPv4 transport address and >> also discover a tunnel endpoint, so it can tunnel v4 packets in v6 till >> the tunnel endpoint and use the IPv4 transport address it has obtained >> to establish a communication with v4 land. >> >> So essentially this is tunnel scenario, but rather than being obtaining >> a full IPv4 address to use, the host only obtains a transport address >> (which is public) >> >> I understand that this is what Dan and Teemu are proposing, is that correct? >> > > > How is this different from the dual-stack lite mechanism? See > draft-durand-dual-stack-lite-00.txt, section 3.2 > > I don't know I am working on the requirement draft, not on solution space. So do you think we need to include this in the req draft or not? > Second question, if you have that, why is it not enough and why would you > still need to do any IPv6 to IPv4 translation? > > well, it seems that you will be having legacy IPv6 hosts (i.e. no new mechanisms) that are running IPv6 apps that want to communicate with v4 hosts that are running ipv4 apps and in that case, this doesn't seem to work regards, marcelo > - Alain. > > > > From owner-v6ops@ops.ietf.org Thu Jul 17 08:38:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CDE3A685E for ; Thu, 17 Jul 2008 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.165 X-Spam-Level: ** X-Spam-Status: No, score=2.165 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43wI-+uECJBL for ; Thu, 17 Jul 2008 08:38:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 481663A688C for ; Thu, 17 Jul 2008 08:38:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVXJ-0001IY-OQ for v6ops-data@psg.com; Thu, 17 Jul 2008 15:36:53 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVXE-0001Hm-U6 for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:36:51 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8402708; Thu, 17 Jul 2008 11:36:22 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 11:36:23 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 15:35:49 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 11:35:46 -0400 Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt From: Alain Durand To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Jari Arkko , Philip Matthews Message-ID: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjoIsfgDl0JOAVyU0+PdOHLRGEeFQ== In-Reply-To: <487F655B.2090004@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jul 2008 15:36:23.0746 (UTC) FILETIME=[DE608A20:01C8E822] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/17/08 11:29 AM, "marcelo bagnulo braun" wrote: >> How is this different from the dual-stack lite mechanism? See >> draft-durand-dual-stack-lite-00.txt, section 3.2 >> >> > I don't know > I am working on the requirement draft, not on solution space. > So do you think we need to include this in the req draft or not? Well, I'm not sure. If you are talking about the requirement for a NAT v6->v4, then I would say no, but add a pointer to my draft. >> Second question, if you have that, why is it not enough and why would you >> still need to do any IPv6 to IPv4 translation? >> >> > well, it seems that you will be having legacy IPv6 hosts (i.e. no new > mechanisms) that are running IPv6 apps that want to communicate with v4 > hosts that are running ipv4 apps and in that case, this doesn't seem to work The only thing that is required for dual-stack lite is a v4/v6 tunnel that is present on most implementation I know, so no new code is needed. And if this is still a problem, you can always use a router upstream to do the encap for you. - Alain. From owner-v6ops@ops.ietf.org Thu Jul 17 08:41:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FC43A67E6 for ; Thu, 17 Jul 2008 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPip+wb7Uixf for ; Thu, 17 Jul 2008 08:41:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1DFD3A685E for ; Thu, 17 Jul 2008 08:41:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVbE-0001xf-Sk for v6ops-data@psg.com; Thu, 17 Jul 2008 15:40:56 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVbB-0001wp-3T for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:40:55 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id F101148D8D9;Thu, 17 Jul 2008 17:40:49 +0200 (CEST) Message-ID: <487F6801.6030406@it.uc3m.es> Date: Thu, 17 Jul 2008 17:40:49 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alain Durand CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.0492 TC:1F TRN:33 TV:5.5.1026(16036.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand escribió: > > On 7/17/08 11:29 AM, "marcelo bagnulo braun" wrote: > > >>> How is this different from the dual-stack lite mechanism? See >>> draft-durand-dual-stack-lite-00.txt, section 3.2 >>> >>> >>> >> I don't know >> I am working on the requirement draft, not on solution space. >> So do you think we need to include this in the req draft or not? >> > > Well, I'm not sure. If you are talking about the requirement for a NAT > v6->v4, then I would say no, but add a pointer to my draft. > it is not only a translation requirement draft read the draft, find out and comment :-) > >>> Second question, if you have that, why is it not enough and why would you >>> still need to do any IPv6 to IPv4 translation? >>> >>> >>> >> well, it seems that you will be having legacy IPv6 hosts (i.e. no new >> mechanisms) that are running IPv6 apps that want to communicate with v4 >> hosts that are running ipv4 apps and in that case, this doesn't seem to work >> > > The only thing that is required for dual-stack lite is a v4/v6 tunnel that > is present on most implementation I know, so no new code is needed. > And if this is still a problem, you can always use a router upstream to do > the encap for you. > but you would need to have v4 on your hosts, right? the assumption for translation is that you have v6 only nodes on one side regards, marcelo > - Alain. > > > From owner-v6ops@ops.ietf.org Thu Jul 17 08:56:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF8E3A68DD for ; Thu, 17 Jul 2008 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC+sMlS+Llbj for ; Thu, 17 Jul 2008 08:56:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDFCC3A685E for ; Thu, 17 Jul 2008 08:56:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVp7-0003p1-L5 for v6ops-data@psg.com; Thu, 17 Jul 2008 15:55:17 +0000 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVp3-0003oF-Uo for v6ops@ops.ietf.org; Thu, 17 Jul 2008 15:55:15 +0000 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48250340; Thu, 17 Jul 2008 11:54:59 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 11:54:58 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 15:54:34 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 11:54:32 -0400 Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt From: Alain Durand To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Jari Arkko , Philip Matthews Message-ID: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjoJWcG/tv1VdTxB0Kl7g1nmz079Q== In-Reply-To: <487F6801.6030406@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jul 2008 15:54:58.0585 (UTC) FILETIME=[76DF7890:01C8E825] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/17/08 11:40 AM, "marcelo bagnulo braun" wrote: >>> well, it seems that you will be having legacy IPv6 hosts (i.e. no new >>> mechanisms) that are running IPv6 apps that want to communicate with v4 >>> hosts that are running ipv4 apps and in that case, this doesn't seem to work >>> >> >> The only thing that is required for dual-stack lite is a v4/v6 tunnel that >> is present on most implementation I know, so no new code is needed. >> And if this is still a problem, you can always use a router upstream to do >> the encap for you. >> > but you would need to have v4 on your hosts, right? No, you need a v4 stack, not a v4 address. That is the whole point of the dual-stack lite model. > the assumption for translation is that you have v6 only nodes on one side This is the part I'm challenging by making a distinction between v6-only, dual-stack provisioned (v4 & v6) and dual-stack lite, where the host is dual-stack capable but only provisioned with v6. - Alain. From owner-v6ops@ops.ietf.org Thu Jul 17 09:01:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937B73A689A for ; Thu, 17 Jul 2008 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fL1kHbFqKNN for ; Thu, 17 Jul 2008 09:01:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1F6C3A688C for ; Thu, 17 Jul 2008 09:01:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVuZ-0004UJ-HB for v6ops-data@psg.com; Thu, 17 Jul 2008 16:00:55 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJVuV-0004Tl-QJ for v6ops@ops.ietf.org; Thu, 17 Jul 2008 16:00:53 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id 92A4048D887;Thu, 17 Jul 2008 18:00:48 +0200 (CEST) Message-ID: <487F6CB0.9010005@it.uc3m.es> Date: Thu, 17 Jul 2008 18:00:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alain Durand CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.8452 TC:1F TRN:30 TV:5.5.1026(16036.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand escribió: > On 7/17/08 11:40 AM, "marcelo bagnulo braun" wrote: > > >>>> well, it seems that you will be having legacy IPv6 hosts (i.e. no new >>>> mechanisms) that are running IPv6 apps that want to communicate with v4 >>>> hosts that are running ipv4 apps and in that case, this doesn't seem to work >>>> >>>> >>> The only thing that is required for dual-stack lite is a v4/v6 tunnel that >>> is present on most implementation I know, so no new code is needed. >>> And if this is still a problem, you can always use a router upstream to do >>> the encap for you. >>> >>> >> but you would need to have v4 on your hosts, right? >> > > No, you need a v4 stack, not a v4 address. That is the whole point of the > dual-stack lite model. > i guess i will need to read the draft then cause i fail to understand how useful could a stack wihtout an IP address could be regards, marcelo > > >> the assumption for translation is that you have v6 only nodes on one side >> > > This is the part I'm challenging by making a distinction between v6-only, > dual-stack provisioned (v4 & v6) and dual-stack lite, where the host is > dual-stack capable but only provisioned with v6. > > - Alain. > > > From owner-v6ops@ops.ietf.org Thu Jul 17 09:08:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738683A6887 for ; Thu, 17 Jul 2008 09:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4oC4tPMnuG9 for ; Thu, 17 Jul 2008 09:08:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4323A69D6 for ; Thu, 17 Jul 2008 09:08:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJW12-0005Qs-SH for v6ops-data@psg.com; Thu, 17 Jul 2008 16:07:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJW0x-0005Q7-5s for v6ops@ops.ietf.org; Thu, 17 Jul 2008 16:07:34 +0000 X-IronPort-AV: E=Sophos;i="4.31,204,1215388800"; d="scan'208";a="88020039" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2008 16:07:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6HG7NMe029058; Thu, 17 Jul 2008 09:07:23 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6HG7LAs000989; Thu, 17 Jul 2008 16:07:22 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , "'IPv6 Operations'" , "'Fred Baker'" , , "'Brian E Carpenter'" , , "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Jari Arkko'" , "'Philip Matthews'" References: <487F5BCB.1070209@it.uc3m.es> Subject: RE: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Thu, 17 Jul 2008 09:07:21 -0700 Message-ID: <00ba01c8e827$32b15470$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <487F5BCB.1070209@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjoHD4ulcxjUm8ORAusT926oEhm1QABSi7g DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12487; t=1216310843; x=1217174843; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20changes=20to=20draft-ietf-v6ops-nat64-p b-statement-req-00.txt |Sender:=20; bh=uhnFpd/+xfoVwvSjn0BViIW0TaMbFLb39V1YKXw7qp0=; b=ndHUMjaiek0yHstxee0tsurkt/VMlTbIPUDzJ57eyqFjPu3OyVxZG2qSyF ZGWgdpKtOQbqDZGQUiYkxlGIASB4QPGcVdLtnoz1O9tfdmF5/pw69YHV3eZi vO+3VE9vlV; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Thursday, July 17, 2008 7:49 AM > To: 'IPv6 Operations'; Fred Baker; Dan Wing;=20 > teemu.savolainen@nokia.com; Brian E Carpenter;=20 > Alain_Durand@cable.comcast.com; R=E9mi Despr=E9s; Jari Arkko;=20 > Philip Matthews > Subject: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt >=20 > Hi, >=20 > I am trying to extract the actual proposed changes for the draft >=20 > ------------------------------------------ > - 1) Additional scenario needed? > ------------------------------------------ >=20 > It seems that there is the potential need for a new scenario. > It is the case described by Dan and by Teemu about a dual stack host,=20 > located in a v6 network, and that needs to run a v4 only=20 > application. In=20 > order to do that, it needs to obtain a public IPv4 transport=20 > address and=20 > also discover a tunnel endpoint, so it can tunnel v4 packets=20 > in v6 till=20 > the tunnel endpoint and use the IPv4 transport address it has=20 > obtained=20 > to establish a communication with v4 land. >=20 > So essentially this is tunnel scenario, but rather than being=20 > obtaining=20 > a full IPv4 address to use, the host only obtains a transport address=20 > (which is public) >=20 > I understand that this is what Dan and Teemu are proposing,=20 > is that correct? I don't have a proposal; I just want to see if folks are prepared to have subscribers lose existing v4 functionality for v4 hosts accessing the v4 Internet (ALGs, NAT-PMP, and UPnP). That is, I am trying to imagine a Behave or Softwire proposal that I would personally be willing to buy from my ISP, could recommend to my mother-in-law, and could recommend to my nephew. I don't have an XBox, so I don't personally care but I=20 am aware of how XBox does UPnP IGD. My Nephew has an XBox and uses BitTorrent a lot more than I do. If a BitTorrent client cannot get v4 mapped, it will be a 'leech' and have horrid=20 download speeds. (Yes, I know most=20 BitTorrent clients support v6, but I don't know how well- exercised that code is and I don't know how many v6-capable BitTorrent peers there are to upload to [so that download speeds are fast]). BitTorrent seems an a valuable use case to consider. The two biggest BitTorrent clients (uTorrent and Vuze=20 (Azureus)) support UPnP (and NAT-PMP). So including support for them to do UPnP -- somehow -- would allow them=20 to function well. We could also conciously decide to not bother, and for those subscribers that need incoming v4 connections or=20 need v4-aware ALGs, they will have to stick with a "real" v4 connection (like today). Other subscribers can use our transition scheme. I just worry that reduces the usefulnes of our transition scheme. The question is if leaving out UPnP IGD/NAT-PMP/v4 ALGs reduces the=20 usefulness 'too much'. > So, if this is the case, how can we fit this into the document? >=20 > As i see it, the document has two parts, clearly differentiated: > A first part that covers an overview of the different aspects of=20 > transition and then a part that described the specific=20 > requirements of=20 > new translation mechanism >=20 > I think that it makes sense to me to include a description of=20 > this case=20 > in the overview section. >=20 >=20 > In order to do that, we need first to ackwoledge the=20 > exsitance of a new=20 > scenarion in section >=20 > 2.1. Transition scenarios >=20 > currently, it includes 6 scenarios: >=20 > There are six obvious transition scenarios: >=20 > o IPv4 system connecting to an IPv4 system across an IPv4 network, > o An IPv6 system connecting to an IPv6 system across an IPv6 > network, > o an IPv4 system connecting to an IPv4 system across an IPv6 > network, > o an IPv6 system connecting to an IPv6 system across an IPv4 > network, > o an IPv4 system connecting to an IPv6 system, or >=20 >=20 > o an IPv6 system connecting to an IPv4 system. >=20 > I understand that we need to include one more: >=20 > o a dual stack system connected to a IPv6 domain that is=20 > connecting to an IPv4 system. >=20 >=20 > In addition, we need to include an additional text in section >=20 > 2.1.2. Transition scenarios that do not require translation >=20 > something along these lines: >=20 > Another scenario that does not involves translation is the case > where a dual stack node is connected to an IPv6-only domain > and it is communicating with a IPv4-only node as depicted in Figure 2. >=20 >=20 > ,-----. ,-----. > ,' `. ,' `. > / \ / \ > / IPv6-only \ / IPv4-only \ > / Domain +-----------+ Domain \ > ; | Tunnel | : > | | endpoint | | > : +-----+ +-----------+ ; > \ |Dual | / \ +----+ / > \ |Stack| / \ |IPv4| / > \ |Host | / \ |Host| / > `.+-----+,' `. +----+,' > '-----' '-----' >=20 >=20 >=20 >=20 >=20 > In this case, the dual stack host needs to establish a IPv4 in IPv6=20 > tunnel to the tunnel endpoint. In addition to that, the dual stack > needs to obtain a IPv4 address that is valid in the IPv4-only domain. > The simplest option is for the dual stack to obtain an IPv4 public > address. However, this may not be possible due to the shortage of > IPv4 public addresses. The other option is to use an IPv4=20 > private address > (and potentially in conjunction with IPv4 NAT). The other option > is for the dual stack to obtain a public IPv4 transport address. > In all the cases, the acquisition of the address can be=20 > performed dynamically. >=20 >=20 > would this address your inputs? Looks good to me. > ---------------------------------------- > -2) Scalability > ---------------------------------------- >=20 > Teemu proposed to include: >=20 > 2.2. Requirements for the overall transition strategy >=20 > 8. Transition architectures should be scalable for large number of > hosts and high data speeds. >=20 > 4.2. Important things that SHOULD be supported >=20 > I9: Scalability >=20 > The translation mechanism SHOULD support very large number of=20 > hosts and > high data speeds with reasonable infrastructure requirements=20 > considering > equipment available at the transition timeframe. >=20 > I think this makes sense, and i have a hard time finding=20 > someone who don't agrees with this > so i am planning > to include them I don't know how we would determine if we met the requirement, though. Most any of these could be implemented in the aggregation router (the first L3 hop away from the subscriber), consuming 1 MIPS per subscriber and any of these could be implemented in=20 a multi-million dollar server placed in Denver, Colorado (the=20 center of the US) also consuming 1 MIPS per subscriber. Which solution meets that requirement better? Or are they similar because they're both 1 MIPS per subscriber, and this is really a requirement around state? Or the need for layer 7 awareness in a protocol-sniffing ALG (which I agree does require more processing cycles than just NATing and forwarding packets). Or is this scalability question really about operational=20 expense and operational complexity (fewer boxes with less state=20 inside of them is better than many boxes with a lot of state=20 inside of them)? > -------------------------------------------- > -3) discovery > --------------------------------------------- >=20 > Teemu also porposed: >=20 > 2.2. Requirements for the overall transition strategy >=20 > 9. Availability of transition solutions on an access network=20 > should be > quickly discoverable. >=20 > 4.2. Important things that SHOULD be supported >=20 >=20 > I10: Discovery >=20 > The translation mechanism SHOULD be quickly discoverable,=20 > preferably in > one RTT, to help moving hosts better assess capabilities of available > access networks and to provide good user experience. >=20 > I have a hard time understanding this one. > I mean R1 states: >=20 > R1: Changes in the hosts >=20 > The translation mechanism MUST NOT require changes in the v4-only > nodes to support the Basic requirements described in this section, > unless explicitly stated in the particular requirement. The > translation mechanism MAY require changes to v6-only nodes. >=20 > So if we don't want changes in the host, how can a host have=20 > the discovery mechanisms? I mean,=20 > i think this assuming some other form of solution that is not=20 > based on translation. >=20 > I am not doing anything about this at this point Was Teemu perhaps considering a situation where a v6 box is doing the translation from a v4-host to the ISP's v6 network? After all, such a v6 box will look like a v6 host to the v6 network:=20 [v4 host] --- [v4/v6 Interworking] ----- [ ISP box ] --- v4 Internet [ CPE Device ] It would be useful for that v6 box to automatically sense whatever it needs to know from the ISP's network (for example, with IVI, it would need to know the IVI prefix). > ------------------------------------------ > -4) no translation > ------------------------------------------ >=20 > Teemu also porposed: >=20 >=20 > 4.3. Important things that MAY be supported >=20 > M1: No NATs or ALGs >=20 > The translation mechanism MAY avoid use of IPv4 NATs and thus=20 > also avoid > need for ALGs.=20 >=20 >=20 > this clearly seems contradictory in a requirements fro=20 > translation (no translation) >=20 > I understand that translation should be avoided and we=20 > already say this in the document > i.e. that dual stack is preferred and then tunnel and finally=20 > if there is no other option > translation. I don't think that this should go in the=20 > requirements section cause seems like > and oxymoron to me Somewhat related to this, I would like to consider one of my worries with ALGs: getting bugs fixed in a massive centralized box. My story: About a month ago, ftp.ietf.org changed its behavior that broke my FTP client (my FTP client's code was last modified in 1998). This had nothing to do with an ALG -- I use PASV and have my FTP ALG in my NAT turned off -- but rather just a change in behavior to a very long-established protocol. It is reasonable to expect that this happens elsewhere, not just with the IETF's FTP servers, and not just with FTP. =20 If an ISP has to receive trouble-tickets from users for the ISP's broken ALG ("it doesn't work with such-and- such FTP client", or "it doesn't work with such-and-such FTP server"), or has to receive trouble-tickets to add new application support to their NAT ("why don't you support H.323, I need it for NetMeeting and can't support my=20 business clients!"), it can be a long, drawn-out process between the vendor, the ISP, and the subscribers. One way to reduce this problem is to leave this function where it is today: at the subscriber premise. If the subscriber needs a bugfix, or needs to tweak something, or needs an ALG that is capable of helping them with their fancy new protocol XYZZY, they can get a NAT (or build a Linux NAT) that supports XYZZY -- without=20 involving the ISP. =20 This is one of my purposes for asking if people care about=20 ALGs, UPnP, and NAT-PMP -- and why APBP could keep this complexity to the subscriber edge (where it is now). > ------------------------------------------ > -5) MIP6 support > ------------------------------------------ >=20 > George and Jaru commented that I5: MIPv6 support > should go away > I am removing that >=20 > ------------------------------------------ > -6) Symbian=20 > ------------------------------------------ > added symbian to the OS in market timing=20 > consdierations >=20 > regards, marcelo Thanks! -d From owner-v6ops@ops.ietf.org Thu Jul 17 09:13:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13013A68DD for ; Thu, 17 Jul 2008 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJeY1eZtEBfZ for ; Thu, 17 Jul 2008 09:13:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC0F63A67E6 for ; Thu, 17 Jul 2008 09:13:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJW6D-0006HV-3l for v6ops-data@psg.com; Thu, 17 Jul 2008 16:12:57 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJW69-0006Gq-5Q for v6ops@ops.ietf.org; Thu, 17 Jul 2008 16:12:55 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 69FC43EA0CD; Thu, 17 Jul 2008 18:12:52 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id D7A983EA0D4; Thu, 17 Jul 2008 18:12:51 +0200 (CEST) Message-ID: <487F6F61.7050908@free.fr> Date: Thu, 17 Jul 2008 18:12:17 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alain Durand CC: Dan Wing , marcelo bagnulo braun , v6ops Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand - Le 7/17/08 5:02 PM : > The service provider still has to run the port mapping part of the CGN, the > only advantage I see is to avoid back-hauling the data traffic to the CGN. Actually, this may not be the case, depending on how far away a customer site finds its APBP servers. But there are other advantages, among which: - less processing in ISP devices (essentially encap-decap vs ALGs). - As pointed out by Dan, specific ALGs in CPE routers, that users are familiar with, remain in operation. > More importantly, you introduce a whole bunch of new issues. In random > order: > - You need to put filtering in place on the ISP access router to make sure > the customer is only using the allocated port numbers. This list needs to be > in sync with the port number allocation system. In the APBP server, yes, but NOT in the ISP access router. Testing that a number is in a given range is not difficult. It may even not be necessary if the CPE is manged by the ISP. > - The same access router now need to do port base routing to return the > packets to the customer. This is not without cost. NO (E2E packets are encapsulated between APBP clients and servers). > - Allocating chunks of port number is not the most efficient allocation > algorithm. If a customers does nothing or just use one port number, you are > wasting a lot of resources. Wasting SOME resource, yes indeed, but "a lot" is debatable. To take an example, if each residential customer receives 512 ports, then 126 customer sites can be supported per public IPv4 address. As noted in the draft, a sparing use of these 512 ports is possible: "In APBP clients, port management may be optimized so as to increase the number of transport connections that are possible with a given number of ports. In particular, port reuse based on endpoint dependent mappings may be envisaged for ports that are assigned to outgoing transport connections known not to need endpoint independent mapping (DNS, HTTP, SMTP, POP3, NNTP, Telnet, SNMP, etc.)." IMU, CGNs would also enforce a maximum number of connections per customer site to avoid DOS attacks. They would be able to overbook, right, but do you know with which factor (a factor of 1 keeps things simple). > - Timing out those port number is a bit of a mess, both the apps, the home > gateway, the access router and the port allocation system need to be synced > up. I don't see that. Once a customer site has received its lot, it keeps it until it rests with no active connection, and then releases its lot (or until, being turned off, it no longer sends its keep-alives). > - All kind of security measure need to be put in place to prevent customers > to hoard the port number space. IMU, it is sufficient to check in the APBP server that used ports are, for each customer site, in its assigned range. > In other words, the complexity you create by distributing the mapping > mechanism seems high. It seem to me a better trade-off to centralize this in > a CGN. Please note that an ISP does not need to run only one CGN and can > distribute those as well close to its network edge, but no closer. IMU, APBP servers and CGNs can be put at the same places, centralized or not, as traffic engineering preferences of ISPs tell. > Note: the route you are on seems to lead to IPv7 (ask ekr about it) I don't see this. But OK, I can ask ekr if you tell me how to do it. > you augment the IPv4 addressing space with the port number space for > routing. You might have seen the T-shirt 32+16 > 128. I was not aware to be that smart, but that seems nice a result :-). Cheers. RD From owner-v6ops@ops.ietf.org Thu Jul 17 09:55:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED1E3A6B21 for ; Thu, 17 Jul 2008 09:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.223 X-Spam-Level: ** X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKPWIDgpZbb8 for ; Thu, 17 Jul 2008 09:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 439063A68B4 for ; Thu, 17 Jul 2008 09:55:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJWjG-000C9p-Sq for v6ops-data@psg.com; Thu, 17 Jul 2008 16:53:18 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJWjD-000C9J-9F for v6ops@ops.ietf.org; Thu, 17 Jul 2008 16:53:17 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8415993; Thu, 17 Jul 2008 12:52:51 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 12:52:51 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 16:52:48 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 12:52:47 -0400 Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt From: Alain Durand To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , , Brian E Carpenter , =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Jari Arkko , Philip Matthews Message-ID: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjoLYo1L6fPVf4waE2qJvc1+3c+Qw== In-Reply-To: <487F6CB0.9010005@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jul 2008 16:52:51.0313 (UTC) FILETIME=[8CC7B610:01C8E82D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/17/08 12:00 PM, "marcelo bagnulo braun" wrote: >> No, you need a v4 stack, not a v4 address. That is the whole point of the >> dual-stack lite model. >> > i guess i will need to read the draft then cause i fail to understand > how useful could a stack wihtout an IP address could be When a dual-stack lite host (dual stack capable, v6-only provisioned) wants to send a v4 packet, it can simply put any v4 dummy address as source address before shipping the packet through the v6 tunnel to the CGN. Even 0.0.0.1 will work as it will be replaced later by the CGN. The mapping will be disambiguified by the tunnel ID (v6 src address). - Alain. From owner-v6ops@ops.ietf.org Thu Jul 17 10:55:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C6B3A6AE8 for ; Thu, 17 Jul 2008 10:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.781 X-Spam-Level: X-Spam-Status: No, score=-104.781 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D4Bvqml-i38 for ; Thu, 17 Jul 2008 10:55:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55AAB3A6809 for ; Thu, 17 Jul 2008 10:55:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJXer-000JPq-Tm for v6ops-data@psg.com; Thu, 17 Jul 2008 17:52:49 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJXem-000JOz-CX for v6ops@ops.ietf.org; Thu, 17 Jul 2008 17:52:47 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-203.messagelabs.com!1216317142!26812955!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 8994 invoked from network); 17 Jul 2008 17:52:23 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-13.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 17 Jul 2008 17:52:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6HHqfYn006605; Thu, 17 Jul 2008 13:52:42 -0400 Received: from 01GAF5142010625.AD.BLS.COM ([139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6HHpAbp002814; Thu, 17 Jul 2008 13:52:34 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jul 2008 13:46:31 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jul 2008 13:46:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 13:46:30 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 17 Jul 2008 17:46:31.0621 (UTC) FILETIME=[0C3BB750:01C8E835] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I've looked over RFC4241. I think it accurately describes what needs to happen in a generic PPPoE environment -- except the section "2.8. Connectivity Monitoring". We do not currently require CPE routers to respond to ICMP echo requests. It's even an option in some of our routers for customers to disable responses to unsolicited ICMP messages. And we still don't have something called a "loopback interface". I also don't think we intend to provide a /48 in this mass market environment. Probably the smallest prefix would be a /56. I haven't seen any ARIN policy relating to required echo support, especially for an end customer with a /56. But I'm starting to wonder if we may just be experiencing another terminology problem, with "loopback interface".=20 That is, I definitely agree that all CPE routers need to have a global address that can initiate and receive traffic to and from the Internet (over each logical WAN interface -- at the link layer or over PPP). I think this address can easily come from the prefix, and doesn't have to be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The CPE router must be able to act as a host device to the WAN. Clearly, there will be a link-local IP address on that WAN (link layer or PPP) interface. There may be a global IP address assigned by SLAAC or stateful DHCPv6. If there is, I think it would be useful to think about when the device might use or respond to messages to that global address, vs. global addresses it gives itself from the prefix. My preference would be to always use the prefix address for sending messages, by default (that is, unless configured to do otherwise). Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by default (unless configured otherwise). Unless the device doesn't get a prefix; then it will need to use the SLAAC/DHCPv6 address. I also think it's not a bad idea for the CPE router to keep the /64 for itself that equates to the prefix it's given followed by zeroes, to get to 64 bits (which is my attempt at trying to generically describe what I think RFC4241 section 2.8 is saying). I think it's fine for the CPE router to be able to respond to echo requests to that /64, if that function (responding to echo requests from the WAN) is enabled. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Tuesday, July 15, 2008 7:10 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Did you get a chance to look at our -02 draft and its reference to RFC4241? Please read RFC4241 to see what has NTT done in Japan to their ADSL IPv6 services. Thanks. Hemant=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Thu Jul 17 11:38:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1353A6A3B for ; Thu, 17 Jul 2008 11:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztv4zHEhxsye for ; Thu, 17 Jul 2008 11:38:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 055403A6847 for ; Thu, 17 Jul 2008 11:38:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJYJr-000PRA-SD for v6ops-data@psg.com; Thu, 17 Jul 2008 18:35:11 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJYJm-000PQV-OS for v6ops@ops.ietf.org; Thu, 17 Jul 2008 18:35:09 +0000 X-IronPort-AV: E=Sophos;i="4.31,204,1215388800"; d="scan'208";a="14598199" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2008 18:35:05 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6HIZ5jO013520; Thu, 17 Jul 2008 14:35:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6HIZ5kx027893; Thu, 17 Jul 2008 18:35:05 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 14:35:05 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 14:35:05 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWAACKnJ4A== References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 17 Jul 2008 18:35:05.0748 (UTC) FILETIME=[D5303540:01C8E83B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14740; t=1216319705; x=1217183705; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=20=22Anto nio=20Querubin=22=20; bh=6qcP6qc/5rf7dGGM+Uu763ujMp+B4xdwa12Dk7xzYW4=; b=gwKXEaxYJyt5u+gNE1fnUl1Bie3OpSHjesZ1ANWpW8Vy/0psO6eD16+Ta3 n9ct9b0VL6lfb+kWB4AtR+Ndu0WEmPUl5ExUxNjihT0dDSSB4dzI8Be66F/9 yBA2uQ4wEI; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, Let me make sure I understand you. Are you agreeing to that fact that the WAN interface should have a global IPv6 address assigned to it because this is different from what you asked for in the past which was to only assign a link-local address to the WAN interface. Also assume, for the sake of closure to the question, that there is no Loopback interface enabled on the CPE Router - after all, our draft says the Loopback interface is optional. Further, even I agree with you that it's not wise for a CPE Router to respond to pings. But I appreciate what NTT did in their deployment because how else can one monitor health of the device in the home? The device has to at least rate limit ICMP if the device responds to it. Section 2.8 of RFC4241 is also not clear when it says "The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet." What happens if the CPE received another ping req, say, 2 secs later. Will the CPE reply? If yes, then I can launch a ping attack on this CPE sending one pings per x secs and the CPE keeps replying. That is why I mentioned rate limiting. Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Thursday, July 17, 2008 1:47 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I've looked over RFC4241. I think it accurately describes what needs to happen in a generic PPPoE environment -- except the section "2.8. Connectivity Monitoring". We do not currently require CPE routers to respond to ICMP echo requests. It's even an option in some of our routers for customers to disable responses to unsolicited ICMP messages. And we still don't have something called a "loopback interface". I also don't think we intend to provide a /48 in this mass market environment. Probably the smallest prefix would be a /56. I haven't seen any ARIN policy relating to required echo support, especially for an end customer with a /56. But I'm starting to wonder if we may just be experiencing another terminology problem, with "loopback interface".=20 That is, I definitely agree that all CPE routers need to have a global address that can initiate and receive traffic to and from the Internet (over each logical WAN interface -- at the link layer or over PPP). I think this address can easily come from the prefix, and doesn't have to be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The CPE router must be able to act as a host device to the WAN. Clearly, there will be a link-local IP address on that WAN (link layer or PPP) interface. There may be a global IP address assigned by SLAAC or stateful DHCPv6. If there is, I think it would be useful to think about when the device might use or respond to messages to that global address, vs. global addresses it gives itself from the prefix. My preference would be to always use the prefix address for sending messages, by default (that is, unless configured to do otherwise). Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by default (unless configured otherwise). Unless the device doesn't get a prefix; then it will need to use the SLAAC/DHCPv6 address. I also think it's not a bad idea for the CPE router to keep the /64 for itself that equates to the prefix it's given followed by zeroes, to get to 64 bits (which is my attempt at trying to generically describe what I think RFC4241 section 2.8 is saying). I think it's fine for the CPE router to be able to respond to echo requests to that /64, if that function (responding to echo requests from the WAN) is enabled. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 7:10 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Did you get a chance to look at our -02 draft and its reference to RFC4241? Please read RFC4241 to see what has NTT done in Japan to their ADSL IPv6 services. Thanks. Hemant=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Thu Jul 17 14:15:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C62A3A67E6 for ; Thu, 17 Jul 2008 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.755 X-Spam-Level: X-Spam-Status: No, score=-104.755 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hBeUsjzTUGm for ; Thu, 17 Jul 2008 14:15:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B72933A677C for ; Thu, 17 Jul 2008 14:15:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJakm-000ITc-Vg for v6ops-data@psg.com; Thu, 17 Jul 2008 21:11:08 +0000 Received: from [216.82.245.115] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJakh-000ISs-Eh for v6ops@ops.ietf.org; Thu, 17 Jul 2008 21:11:06 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1216329060!24313151!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 14758 invoked from network); 17 Jul 2008 21:11:01 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-7.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 17 Jul 2008 21:11:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6HLB0er017726; Thu, 17 Jul 2008 17:11:00 -0400 Received: from 01GAF5142010622.AD.BLS.COM ([139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6HLAtpZ017591; Thu, 17 Jul 2008 17:10:55 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jul 2008 17:10:55 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Jul 2008 17:10:54 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 17:10:53 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWAACKnJ4AADGn8A References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Antonio Querubin" CC: X-OriginalArrivalTime: 17 Jul 2008 21:10:54.0930 (UTC) FILETIME=[99BC2B20:01C8E851] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'm sorry to have caused you to think that I didn't want a global IP address on the WAN interface! What I meant to express, was that I didn't think a global IP address needed to be provided via SLAAC or stateful DHCPv6, but that it could be taken from the prefix. The definition of "Numbered Model" is very specific to getting the global address via SLAAC or stateful DHCPv6, and not any other way. So either the "Numbered Model" should also allow the global address to come from the prefix (especially if none comes from SLAAC or stateful DHCPv6), or the "Unnumbered Model" needs to mention that the WAN interface gets a global address from the prefix. I'm fine either way. Yes, the WAN interface absolutely *must* have a global IP address that it uses for sending and receiving IP messages, as far as I'm concerned. The "health" of the connection can be determined in a variety of ways. PPP has messages for testing the PPP connection. I forget what the access network uses in IPv4. I know that inside the home we use ARP (for IPv4) to test whether the device is still there. There are also PHY and L2 layer tests to see if those layers are working. I can go ask the access network guys what we do for IP over Ethernet. In addition to these access network methods, our devices have a "heartbeat". They are expected to periodically "phone home" to the TR-069 server. For the health of the device (above and beyond whether the IP connection is up or down), we rely on TR-069.=20 FYI: Note that TR-069 is just some remote procedure calls and XML config parameters that run over (SOAP)/HTTPS/TCP/IP. Pretty basic. One big difference between TR-069 and SNMP is that TR-069 requires the CPE to initiate the connection (pull model). The XML config parameters are the analog of SNMP MIBs. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Thursday, July 17, 2008 2:35 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Let me make sure I understand you. Are you agreeing to that fact that the WAN interface should have a global IPv6 address assigned to it because this is different from what you asked for in the past which was to only assign a link-local address to the WAN interface. Also assume, for the sake of closure to the question, that there is no Loopback interface enabled on the CPE Router - after all, our draft says the Loopback interface is optional. Further, even I agree with you that it's not wise for a CPE Router to respond to pings. But I appreciate what NTT did in their deployment because how else can one monitor health of the device in the home? The device has to at least rate limit ICMP if the device responds to it. Section 2.8 of RFC4241 is also not clear when it says "The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet." What happens if the CPE received another ping req, say, 2 secs later. Will the CPE reply? If yes, then I can launch a ping attack on this CPE sending one pings per x secs and the CPE keeps replying. That is why I mentioned rate limiting. Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Thursday, July 17, 2008 1:47 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I've looked over RFC4241. I think it accurately describes what needs to happen in a generic PPPoE environment -- except the section "2.8. Connectivity Monitoring". We do not currently require CPE routers to respond to ICMP echo requests. It's even an option in some of our routers for customers to disable responses to unsolicited ICMP messages. And we still don't have something called a "loopback interface". I also don't think we intend to provide a /48 in this mass market environment. Probably the smallest prefix would be a /56. I haven't seen any ARIN policy relating to required echo support, especially for an end customer with a /56. But I'm starting to wonder if we may just be experiencing another terminology problem, with "loopback interface".=20 That is, I definitely agree that all CPE routers need to have a global address that can initiate and receive traffic to and from the Internet (over each logical WAN interface -- at the link layer or over PPP). I think this address can easily come from the prefix, and doesn't have to be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The CPE router must be able to act as a host device to the WAN. Clearly, there will be a link-local IP address on that WAN (link layer or PPP) interface. There may be a global IP address assigned by SLAAC or stateful DHCPv6. If there is, I think it would be useful to think about when the device might use or respond to messages to that global address, vs. global addresses it gives itself from the prefix. My preference would be to always use the prefix address for sending messages, by default (that is, unless configured to do otherwise). Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by default (unless configured otherwise). Unless the device doesn't get a prefix; then it will need to use the SLAAC/DHCPv6 address. I also think it's not a bad idea for the CPE router to keep the /64 for itself that equates to the prefix it's given followed by zeroes, to get to 64 bits (which is my attempt at trying to generically describe what I think RFC4241 section 2.8 is saying). I think it's fine for the CPE router to be able to respond to echo requests to that /64, if that function (responding to echo requests from the WAN) is enabled. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 7:10 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Did you get a chance to look at our -02 draft and its reference to RFC4241? Please read RFC4241 to see what has NTT done in Japan to their ADSL IPv6 services. Thanks. Hemant=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document. I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP running over either Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is integrated into the CPE router. For discussion purposes, in a general network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports. If they are physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider. When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider.=20 When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem. Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Thu Jul 17 14:44:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231F23A67F8 for ; Thu, 17 Jul 2008 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r+NjNopOosG for ; Thu, 17 Jul 2008 14:44:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C0BB3A67B6 for ; Thu, 17 Jul 2008 14:44:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbFt-000MUT-Sr for v6ops-data@psg.com; Thu, 17 Jul 2008 21:43:17 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbFo-000MTc-P9 for v6ops@ops.ietf.org; Thu, 17 Jul 2008 21:43:14 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6HLgmKa008350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 14:42:49 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6HLgmVm011273; Thu, 17 Jul 2008 14:42:48 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6HLgkIf011252; Thu, 17 Jul 2008 14:42:47 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 14:42:46 -0700 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 14:42:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104B83A1A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWAACKnJ4AAG3F4w References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 17 Jul 2008 21:42:46.0798 (UTC) FILETIME=[0D4C12E0:01C8E856] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 >Sent: Thursday, July 17, 2008 11:35 AM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Let me make sure I understand you. Are you agreeing to that fact that >the WAN interface should have a global IPv6 address assigned to it >because this is different from what you asked for in the past which was >to only assign a link-local address to the WAN interface. Also assume, >for the sake of closure to the question, that there is no Loopback >interface enabled on the CPE Router - after all, our draft says the >Loopback interface is optional. I don't understand this. If it is a router, it follows the weak end system model and it can source packets from addresses assigned to any of its interfaces, including virtual interfaces like a loopback. I do not see a requirement for assignment of a non-link-local IPv6 address on the WAN interface. Fred fred.l.templin@boeing.com >Further, even I agree with you that it's not wise for a CPE Router to >respond to pings. But I appreciate what NTT did in their deployment >because how else can one monitor health of the device in the home? The >device has to at least rate limit ICMP if the device responds to it. >Section 2.8 of RFC4241 is also not clear when it says "The CPE must >return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo >Request packet." What happens if the CPE received another ping=20 >req, say, >2 secs later. Will the CPE reply? If yes, then I can launch a ping >attack on this CPE sending one pings per x secs and the CPE keeps >replying. That is why I mentioned rate limiting. > >Hemant > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com]=20 >Sent: Thursday, July 17, 2008 1:47 PM >To: Hemant Singh (shemant); Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I've looked over RFC4241. I think it accurately describes what needs to >happen in a generic PPPoE environment -- except the section "2.8. >Connectivity Monitoring". We do not currently require CPE routers to >respond to ICMP echo requests. It's even an option in some of our >routers for customers to disable responses to unsolicited ICMP=20 >messages. >And we still don't have something called a "loopback interface". I also >don't think we intend to provide a /48 in this mass market environment. >Probably the smallest prefix would be a /56. I haven't seen any ARIN >policy relating to required echo support, especially for an=20 >end customer >with a /56. > >But I'm starting to wonder if we may just be experiencing another >terminology problem, with "loopback interface".=20 > >That is, I definitely agree that all CPE routers need to have a global >address that can initiate and receive traffic to and from the Internet >(over each logical WAN interface -- at the link layer or over PPP). I >think this address can easily come from the prefix, and doesn't have to >be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The >CPE router must be able to act as a host device to the WAN. > >Clearly, there will be a link-local IP address on that WAN (link layer >or PPP) interface. There may be a global IP address assigned=20 >by SLAAC or >stateful DHCPv6. If there is, I think it would be useful to think about >when the device might use or respond to messages to that=20 >global address, >vs. global addresses it gives itself from the prefix. My preference >would be to always use the prefix address for sending messages, by >default (that is, unless configured to do otherwise). Incoming traffic >to the SLAAC/DHCPv6 address might be blocked, by default (unless >configured otherwise). Unless the device doesn't get a prefix; then it >will need to use the SLAAC/DHCPv6 address. > >I also think it's not a bad idea for the CPE router to keep the /64 for >itself that equates to the prefix it's given followed by zeroes, to get >to 64 bits (which is my attempt at trying to generically=20 >describe what I >think RFC4241 section 2.8 is saying). I think it's fine for the CPE >router to be able to respond to echo requests to that /64, if that >function (responding to echo requests from the WAN) is enabled. >Barbara > >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >Sent: Tuesday, July 15, 2008 7:10 PM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Did you get a chance to look at our -02 draft and its reference to >RFC4241? Please read RFC4241 to see what has NTT done in Japan to their >ADSL IPv6 services. > >Thanks. > >Hemant=20 > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Tuesday, July 15, 2008 5:34 PM >To: Hemant Singh (shemant); Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I would prefer if no statements were made as to number of physical WAN >interfaces. We have some bonded DSL interfaces that have 2 physical >interfaces that are bonded together at either the ATM or=20 >Ethernet layer. >There are 2 physical WAN interfaces, but from the perspective of the IP >portion of the access network, there is only one "logical" WAN=20 >interface >on the router. > >I really would prefer to describe the behavior of a single link layer >(L2) interface, rather than make any mention of physical interfaces >(quantity, PHY, jack, or otherwise). I agree with your statement that >this document's functionality needs to be abstracted from the physical. >I really, really agree. >Barbara > >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >Sent: Tuesday, July 15, 2008 4:51 PM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Thanks for this email. For the purposes of description of behavior of a >CPE Router, all we are asking for is how many physical WAN interface >ports will the CPE Router have? We have recommended one. We could care >less about any other physical layer behavior. We are defining routing >behavior that sits abstracted from link or physical layers. Where a >layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP >address acquisition does not perform DAD.=20 > >Hemant > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Tuesday, July 15, 2008 4:17 PM >To: Antonio Querubin; Hemant Singh (shemant) >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I don't understand the relevance of mentioning PHY interfaces, PHY >modems, or pure Ethernet switches, in a document about IPv6 behavior of >CPE routers. A physical instantiation of a CPE router may=20 >indeed contain >a PHY modem and Ethernet switch, but I don't see why that's relevant or >needs to be called out in this document. > >I don't see any functionality described in this draft that=20 >changes based >on the link layer or below. Certainly not if the link layer is=20 >Ethernet. > >I know that there do exist WAN PHY interfaces that do not have the IP >running over either Ethernet link layer or PPP. Such IP=20 >interfaces will >either exhibit the same behavior as described in this document, or they >won't. If they do, that can be mentioned. If they don't, but have mass >market relevance, it can be described how they differ. The WAN=20 >interface >as an Ethernet link layer interface will cover all mass market retail >routers, and the vast majority of DSL modem/routers. I can't speak for >DOCSIS or UMTS, since I don't know those protocol stacks very well. If >they don't use Ethernet for their link layers, do they have some other >link layer that is similar to Ethernet? Is there any reason why that >link layer shouldn't be considered the "WAN interface"? >Barbara > >-----Original Message----- >From: Antonio Querubin [mailto:tony@lava.net] >Sent: Tuesday, July 15, 2008 2:00 PM >To: Hemant Singh (shemant) >Cc: Stark, Barbara; v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > >> Date: Tue, 15 Jul 2008 11:34:29 -0400 >> From: "Hemant Singh (shemant)" >> To: "Stark, Barbara" , v6ops@ops.ietf.org >> Cc: Antonio Querubin >> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >>=20 >> Barbara, >> >> Since Antonio also raised a point about IPv6 addresses=20 >assigned to the > >> WAN interface (and the number of WAN interface(s)), we are=20 >combining a > >> reply to both you and Antonio. >> >> Barbara, when you say, >> >> "We have considered the possibility of a separate IP address for our >> TR-069 management of the CPE routers that we supply, but would want >this >> to be a >> configurable option." >> >> could you please elaborate. Does this separate IPv6 address get >assigned >> to the WAN side of the CPE Router? If yes, if the WAN interface is >only >> assigned a link-local address, then what network interface=20 >on the WAN=20 >> side does this IPv6 address get assigned to? One choice we=20 >have is to=20 >> assign the IPv6 address to the Loopback interface facing the=20 >WAN side. >> Also, when reviewers ask for another network interface on the WAN >side, >> or another IPv6 address on the WAN side, could reviewers please=20 >> appreciate the fact that another WAN interface can mean two=20 >things for >a >> router. Either we have second physical WAN interface with a new=20 >> mac-address or we still have one WAN interface and the second WAN=20 >> interface is just a logical interface bound to the physical WAN=20 >> interface such that both the physical WAN interface and the logical=20 >> interface share a mac-address between them. Antonio and=20 >Barbara, which > >> one of these two interfaces are you talking about? Further,=20 >if one is=20 >> spawning logical interfaces on any router, once doesn't have to stop >at >> one extra interface. Go ahead and spawn more if one wants. > >Actually the discussion is confusing because the 'WAN'=20 >interface appears > >to mean different things depending on whether the layer 2 modem is >integrated into the CPE router. For discussion purposes, in a general >network configuration where all the components are separate=20 >you'll have: > > PCs > | > | > | >----- modem ----- switch ----- router/firewall ----- switch ----- PCs > 1 A 2 B 3 C 4 D 5 E > >Devices B and D are just plain ethernet switches. Although=20 >the focus of > >this document seems to be on device C, it's interfaces, and=20 >the customer > >devices (E) behind it, the CPE router being discussed potentially >encompasses functionality of devices A, B, C, and D. > >In the case where the modem is integrated, the interface that=20 >internally > >links the modem to the internal router device C may or may not be >accessible to the consumer via external physical ports. If they are >physically accessible, they need a different name than "WAN"=20 >if "WAN" is > >defined to be 1 above. > >If the modem is not integrated into your CPE device, then the "WAN"=20 >interface is just 2 and/or 3 above depending on whether=20 >additional "WAN" > >ports are provided by the vendor. > >However these multiple definitions of WAN interfaces are confusing, >hence my earlier suggestion of using different names for the >modem-router interface and the access provider interface. > >> Further, Antonio, when you say, >> >> "Additionally, for those vendors that wish to integrate the layer 2 >> (DSL/cable) modem as part of the CPE router (where the "WAN" >> encapsulation is not ethernet), perhaps a separately named interface=20 >> definition might be appropriate to avoid confusion with "WAN"." >> >> In such a case, the WAN interface is a logical interface=20 >that bridges=20 >> the CPE Router to the broadband modem. We clarified the WAN=20 >interface=20 >> definition as follows with new text >> >> WAN interface - a single physical network interface on the=20 >standalone=20 >> CPE Router that is used to connect the router to the access=20 >network of > >> the Service Provider. When the CPE Router is embedded in a=20 >device that > >> connects to the WAN, this interface is a logical network interface >that >> bridges the device to the CPE Router. Some devices which can have an=20 >> embedded CPE router are: a cable or DSL modem, or a cellular >telephone, >> etc. >> >> When we publish our next revision of the draft, we will include new >text >> for the WAN interface definition. > >How about this. If you want to tie the WAN interface to the internal >router: > >WAN interface - a network interface on the CPE Router that is used to >connect the router to the access network of the Service Provider. When >a CPE Router is embedded in a device that connects to the service >provider > >via a non-ethernet connection, this interface is the logical interface >that connects the internal router to the internal bridge. Some devices >which can have an embedded CPE router are: a cable or DSL modem, or a >cellular telephone, etc. > >SPA (service provider access) interface - a non-ethernet physical >network interface that is bridged to the WAN interface and directly >connects to the access network of the Service Provider. > >But if you want to keep the definition of WAN tightly coupled with the >physical external port then something like this might be more suitable: > >WAN interface - a network interface on the CPE Router that is used to >connect the router directly to the access network of the Service >Provider.=20 >When a CPE Router is embedded in a device that connects to the service >provider via a non-ethernet connection, this physical interface is >bridged to the router via an internal modem. Some devices which can >have an embedded CPE router are: a cable or DSL modem, or a cellular >telephone, etc. > >WANEA (WAN Ethernet Access) interface - an optional ethernet interface >that is bridged to the WAN interface and provides additional direct >access to the Service Provider network. > >You may want to call it something other than WANEA :) > >Antonio Querubin >whois: AQ7-ARIN > >***** > >The information transmitted is intended only for the person or=20 >entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. GA621 > > > >***** > >The information transmitted is intended only for the person or=20 >entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. GA622 > > > > From owner-v6ops@ops.ietf.org Thu Jul 17 14:47:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42813A67B6 for ; Thu, 17 Jul 2008 14:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl6wyhwwKNRU for ; Thu, 17 Jul 2008 14:47:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B24CD3A67DA for ; Thu, 17 Jul 2008 14:47:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbJh-000Mzv-1Z for v6ops-data@psg.com; Thu, 17 Jul 2008 21:47:13 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbJb-000MzN-IE for v6ops@ops.ietf.org; Thu, 17 Jul 2008 21:47:10 +0000 X-IronPort-AV: E=Sophos;i="4.31,205,1215388800"; d="scan'208";a="128142189" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2008 21:47:00 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6HLl0sk003720; Thu, 17 Jul 2008 14:47:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6HLkwt7008385; Thu, 17 Jul 2008 21:47:00 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 17:46:58 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 17:46:56 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWAACKnJ4AADGn8AAAL8c5A= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 17 Jul 2008 21:46:58.0777 (UTC) FILETIME=[A37D0490:01C8E856] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19613; t=1216331220; x=1217195220; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20; bh=kLFDBElnsTznFSiZy041hHoAP6OOOPjmIxSusJc4yDo=; b=Oo5jEWmHtRwcCkHkZv0ZUgVmAehLxo2snkuhzythdKLwyhEIKJpY1lmX7T EkYz5yxNt0KJ6VhCiVi08jGhyrbIiZczR+StVOyyBGxpIrQcOPDt86WKULV1 oUnW8gwcmn; Authentication-Results: sj-dkim-3; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara, No apologies needed! Thanks for the quick reply back. So now, you from = AT&T and Shin from NTT, Japan are on the same page wrt global IPv6 = address on the WAN interface. Shin has also asked for a global IPv6 = address as a must for the WAN interface. From the -00 version of our = draft we have been saying the WAN interface acquires a global address. = Further, Mikael on this thread has said he wants the WAN interface to = only acquire a link-local but the CPE Router spawn an Loopback interface = to which a global IPv6 address is assigned - we have already said in our = draft this Loopback interface is optional and your deployment can ignore = using it. I'd also like to point out that the configuration required by = Mikael is essentially the same as assigning a global IPv6 address to the = WAN interface. Yes, there was a reason why we didn't add text in the Numbered model to = say that the global IPv6 address for the WAN interface may be assigned = from the IA_PD. We wanted to be careful about it. Here is an example. = The IA_PD obtained by the CPE Router is a /56. The CPE Router = sub-delegates this prefix to a /64 for the LAN interface(s). So if a = na=EFve implementation picked a global address for the WAN from the /64, = then the WAN and the LAN are in the same IPv6 subnet - that's wrong = because the WAN and LAN interface(s) are physically different network = segments for the CPE Router and hence they must have different subnets = to route traffic between them. What one has to do is pick a global = address for the WAN interface from the /56 IA_PD. We can add new text to = the Numbered model to cover your suggestion. As for your other question in another email, no, I haven't seen anyone = settle on what prefix length to dole out in the IA_PD - meaning /56 or = /48 or what have you. That is why we have stayed away from specifying = any prefix length in our draft. Thanks for the mention of other "health" check mechanisms. At least when = the CPE Router is embedded in a cable or DSL modem, I am sure the two = broadband deployments have their own heartbeat between CMTS and cable = modem or DSLAM and the DSL modem. Personally I don't like an ICMPv6 = mechanism because it susceptible to attacks. Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Thursday, July 17, 2008 5:11 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I'm sorry to have caused you to think that I didn't want a global IP = address on the WAN interface! What I meant to express, was that I didn't = think a global IP address needed to be provided via SLAAC or stateful = DHCPv6, but that it could be taken from the prefix. The definition of = "Numbered Model" is very specific to getting the global address via = SLAAC or stateful DHCPv6, and not any other way. So either the "Numbered = Model" should also allow the global address to come from the prefix = (especially if none comes from SLAAC or stateful DHCPv6), or the = "Unnumbered Model" needs to mention that the WAN interface gets a global = address from the prefix. I'm fine either way. Yes, the WAN interface absolutely *must* have a global IP address that = it uses for sending and receiving IP messages, as far as I'm concerned. The "health" of the connection can be determined in a variety of ways. PPP has messages for testing the PPP connection. I forget what the = access network uses in IPv4. I know that inside the home we use ARP (for IPv4) to test whether the device is still there. There are also PHY and L2 layer tests to see if those layers are working. I can go ask the = access network guys what we do for IP over Ethernet. In addition to = these access network methods, our devices have a "heartbeat". They are = expected to periodically "phone home" to the TR-069 server. For the = health of the device (above and beyond whether the IP connection is up = or down), we rely on TR-069.=20 FYI: Note that TR-069 is just some remote procedure calls and XML config = parameters that run over (SOAP)/HTTPS/TCP/IP. Pretty basic. One big = difference between TR-069 and SNMP is that TR-069 requires the CPE to = initiate the connection (pull model). The XML config parameters are the = analog of SNMP MIBs. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Thursday, July 17, 2008 2:35 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Let me make sure I understand you. Are you agreeing to that fact that = the WAN interface should have a global IPv6 address assigned to it = because this is different from what you asked for in the past which was = to only assign a link-local address to the WAN interface. Also assume, = for the sake of closure to the question, that there is no Loopback = interface enabled on the CPE Router - after all, our draft says the = Loopback interface is optional. Further, even I agree with you that it's not wise for a CPE Router to = respond to pings. But I appreciate what NTT did in their deployment = because how else can one monitor health of the device in the home? The = device has to at least rate limit ICMP if the device responds to it. Section 2.8 of RFC4241 is also not clear when it says "The CPE must = return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo = Request packet." What happens if the CPE received another ping req, say, 2 secs later. Will the CPE reply? If yes, then I can launch a ping = attack on this CPE sending one pings per x secs and the CPE keeps = replying. That is why I mentioned rate limiting. Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Thursday, July 17, 2008 1:47 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I've looked over RFC4241. I think it accurately describes what needs to = happen in a generic PPPoE environment -- except the section "2.8. Connectivity Monitoring". We do not currently require CPE routers to = respond to ICMP echo requests. It's even an option in some of our = routers for customers to disable responses to unsolicited ICMP messages. And we still don't have something called a "loopback interface". I also = don't think we intend to provide a /48 in this mass market environment. Probably the smallest prefix would be a /56. I haven't seen any ARIN = policy relating to required echo support, especially for an end customer = with a /56. But I'm starting to wonder if we may just be experiencing another = terminology problem, with "loopback interface".=20 That is, I definitely agree that all CPE routers need to have a global = address that can initiate and receive traffic to and from the Internet = (over each logical WAN interface -- at the link layer or over PPP). I = think this address can easily come from the prefix, and doesn't have to = be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The = CPE router must be able to act as a host device to the WAN. Clearly, there will be a link-local IP address on that WAN (link layer = or PPP) interface. There may be a global IP address assigned by SLAAC or = stateful DHCPv6. If there is, I think it would be useful to think about = when the device might use or respond to messages to that global address, = vs. global addresses it gives itself from the prefix. My preference = would be to always use the prefix address for sending messages, by = default (that is, unless configured to do otherwise). Incoming traffic = to the SLAAC/DHCPv6 address might be blocked, by default (unless = configured otherwise). Unless the device doesn't get a prefix; then it = will need to use the SLAAC/DHCPv6 address. I also think it's not a bad idea for the CPE router to keep the /64 for = itself that equates to the prefix it's given followed by zeroes, to get = to 64 bits (which is my attempt at trying to generically describe what I = think RFC4241 section 2.8 is saying). I think it's fine for the CPE = router to be able to respond to echo requests to that /64, if that = function (responding to echo requests from the WAN) is enabled. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 7:10 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Did you get a chance to look at our -02 draft and its reference to = RFC4241? Please read RFC4241 to see what has NTT done in Japan to their = ADSL IPv6 services. Thanks. Hemant=20 -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 5:34 PM To: Hemant Singh (shemant); Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I would prefer if no statements were made as to number of physical WAN = interfaces. We have some bonded DSL interfaces that have 2 physical = interfaces that are bonded together at either the ATM or Ethernet layer. There are 2 physical WAN interfaces, but from the perspective of the IP = portion of the access network, there is only one "logical" WAN interface = on the router. I really would prefer to describe the behavior of a single link layer (L2) interface, rather than make any mention of physical interfaces = (quantity, PHY, jack, or otherwise). I agree with your statement that = this document's functionality needs to be abstracted from the physical. I really, really agree. Barbara -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, July 15, 2008 4:51 PM To: Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Barbara, Thanks for this email. For the purposes of description of behavior of a = CPE Router, all we are asking for is how many physical WAN interface = ports will the CPE Router have? We have recommended one. We could care = less about any other physical layer behavior. We are defining routing = behavior that sits abstracted from link or physical layers. Where a = layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP = address acquisition does not perform DAD.=20 Hemant -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, July 15, 2008 4:17 PM To: Antonio Querubin; Hemant Singh (shemant) Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I don't understand the relevance of mentioning PHY interfaces, PHY = modems, or pure Ethernet switches, in a document about IPv6 behavior of = CPE routers. A physical instantiation of a CPE router may indeed contain = a PHY modem and Ethernet switch, but I don't see why that's relevant or = needs to be called out in this document. I don't see any functionality described in this draft that changes based = on the link layer or below. Certainly not if the link layer is Ethernet. I know that there do exist WAN PHY interfaces that do not have the IP = running over either Ethernet link layer or PPP. Such IP interfaces will = either exhibit the same behavior as described in this document, or they = won't. If they do, that can be mentioned. If they don't, but have mass = market relevance, it can be described how they differ. The WAN interface = as an Ethernet link layer interface will cover all mass market retail = routers, and the vast majority of DSL modem/routers. I can't speak for = DOCSIS or UMTS, since I don't know those protocol stacks very well. If = they don't use Ethernet for their link layers, do they have some other = link layer that is similar to Ethernet? Is there any reason why that = link layer shouldn't be considered the "WAN interface"? Barbara -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Tuesday, July 15, 2008 2:00 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > Date: Tue, 15 Jul 2008 11:34:29 -0400 > From: "Hemant Singh (shemant)" > To: "Stark, Barbara" , v6ops@ops.ietf.org > Cc: Antonio Querubin > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Barbara, > > Since Antonio also raised a point about IPv6 addresses assigned to the > WAN interface (and the number of WAN interface(s)), we are combining a > reply to both you and Antonio. > > Barbara, when you say, > > "We have considered the possibility of a separate IP address for our > TR-069 management of the CPE routers that we supply, but would want this > to be a > configurable option." > > could you please elaborate. Does this separate IPv6 address get assigned > to the WAN side of the CPE Router? If yes, if the WAN interface is only > assigned a link-local address, then what network interface on the WAN=20 > side does this IPv6 address get assigned to? One choice we have is to=20 > assign the IPv6 address to the Loopback interface facing the WAN side. > Also, when reviewers ask for another network interface on the WAN side, > or another IPv6 address on the WAN side, could reviewers please=20 > appreciate the fact that another WAN interface can mean two things for a > router. Either we have second physical WAN interface with a new=20 > mac-address or we still have one WAN interface and the second WAN=20 > interface is just a logical interface bound to the physical WAN=20 > interface such that both the physical WAN interface and the logical=20 > interface share a mac-address between them. Antonio and Barbara, which > one of these two interfaces are you talking about? Further, if one is=20 > spawning logical interfaces on any router, once doesn't have to stop at > one extra interface. Go ahead and spawn more if one wants. Actually the discussion is confusing because the 'WAN' interface appears to mean different things depending on whether the layer 2 modem is = integrated into the CPE router. For discussion purposes, in a general = network configuration where all the components are separate you'll have: PCs | | | ----- modem ----- switch ----- router/firewall ----- switch ----- PCs 1 A 2 B 3 C 4 D 5 E Devices B and D are just plain ethernet switches. Although the focus of this document seems to be on device C, it's interfaces, and the customer devices (E) behind it, the CPE router being discussed potentially = encompasses functionality of devices A, B, C, and D. In the case where the modem is integrated, the interface that internally links the modem to the internal router device C may or may not be = accessible to the consumer via external physical ports. If they are = physically accessible, they need a different name than "WAN" if "WAN" is defined to be 1 above. If the modem is not integrated into your CPE device, then the "WAN"=20 interface is just 2 and/or 3 above depending on whether additional "WAN" ports are provided by the vendor. However these multiple definitions of WAN interfaces are confusing, = hence my earlier suggestion of using different names for the = modem-router interface and the access provider interface. > Further, Antonio, when you say, > > "Additionally, for those vendors that wish to integrate the layer 2 > (DSL/cable) modem as part of the CPE router (where the "WAN" > encapsulation is not ethernet), perhaps a separately named interface=20 > definition might be appropriate to avoid confusion with "WAN"." > > In such a case, the WAN interface is a logical interface that bridges=20 > the CPE Router to the broadband modem. We clarified the WAN interface=20 > definition as follows with new text > > WAN interface - a single physical network interface on the standalone=20 > CPE Router that is used to connect the router to the access network of > the Service Provider. When the CPE Router is embedded in a device that > connects to the WAN, this interface is a logical network interface that > bridges the device to the CPE Router. Some devices which can have an=20 > embedded CPE router are: a cable or DSL modem, or a cellular telephone, > etc. > > When we publish our next revision of the draft, we will include new text > for the WAN interface definition. How about this. If you want to tie the WAN interface to the internal router: WAN interface - a network interface on the CPE Router that is used to = connect the router to the access network of the Service Provider. When = a CPE Router is embedded in a device that connects to the service = provider via a non-ethernet connection, this interface is the logical interface = that connects the internal router to the internal bridge. Some devices = which can have an embedded CPE router are: a cable or DSL modem, or a = cellular telephone, etc. SPA (service provider access) interface - a non-ethernet physical = network interface that is bridged to the WAN interface and directly = connects to the access network of the Service Provider. But if you want to keep the definition of WAN tightly coupled with the = physical external port then something like this might be more suitable: WAN interface - a network interface on the CPE Router that is used to = connect the router directly to the access network of the Service = Provider.=20 When a CPE Router is embedded in a device that connects to the service = provider via a non-ethernet connection, this physical interface is = bridged to the router via an internal modem. Some devices which can = have an embedded CPE router are: a cable or DSL modem, or a cellular = telephone, etc. WANEA (WAN Ethernet Access) interface - an optional ethernet interface = that is bridged to the WAN interface and provides additional direct = access to the Service Provider network. You may want to call it something other than WANEA :) Antonio Querubin whois: AQ7-ARIN ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 From owner-v6ops@ops.ietf.org Thu Jul 17 14:52:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1283A689D for ; Thu, 17 Jul 2008 14:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92HlgNI+pdF4 for ; Thu, 17 Jul 2008 14:52:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47DDD3A6805 for ; Thu, 17 Jul 2008 14:52:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbOM-000NZJ-Jm for v6ops-data@psg.com; Thu, 17 Jul 2008 21:52:02 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbOG-000NYm-TV for v6ops@ops.ietf.org; Thu, 17 Jul 2008 21:51:59 +0000 X-IronPort-AV: E=Sophos;i="4.31,205,1215388800"; d="scan'208";a="14617468" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2008 21:51:53 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6HLpr8H009036; Thu, 17 Jul 2008 17:51:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6HLprZL014061; Thu, 17 Jul 2008 21:51:53 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 17:51:53 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 17:51:53 -0400 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104B83A1A@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjmpKWhonnM2P7CSgOYpI9mEbK03wABBWkgAARsxnAAAayNYAADrKhgAFHTyWAACKnJ4AAG3F4wAABafeA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <39C363776A4E8C4A94691D2BD9D1C9A104B83A1A@XCH-NW-7V2.nw.nos.boeing.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Stark, Barbara" , "Antonio Querubin" Cc: X-OriginalArrivalTime: 17 Jul 2008 21:51:53.0438 (UTC) FILETIME=[531EB7E0:01C8E857] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17067; t=1216331513; x=1217195513; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Templin,=20Fred=20L=22=20,=0A=20=20=20=20=20=20=20=20=22Stark,=20Barbara=22=20,=20=22Antonio=20Querubin=22=20; bh=wtR6Rn9aghUdAZeTi0fQF8XxTq5KdELYZh+m+UNS7q4=; b=R5ZQa5Q5rzuYVvHdXIdN30podOtj+DZqihy3oEpUmBD1M4FOwKZJASOJoQ iaB93wMg733KJ/FBUl7hK3rXy+b7lH0hkQ/M5Tn2YfYXmksuLgRmLoYpiHFn OgB9FPFVEX; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, I just replied to Barbara. Please read that email. What you are saying is what we and others also have been harking at. A router can send packets sourced from any of physical or virtual interfaces. I have told Shin from NTT and Barbara from AT&T that if they want a global IPv6 address on the WAN interface - fine. Then we have also told them they don't have to spawn the optional Loopback interface if they don't want to.=20 Then I told Mikael, that for his purpose, his WAN interface only acquire a link-local and the CPE Router spawn a Loopback interface that will be assigned a global IPv6 address. Then the CPE Router can source packets with the Loopback interface global address when the router needs to. Hemant=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Thursday, July 17, 2008 5:43 PM To: Hemant Singh (shemant); Stark, Barbara; Antonio Querubin Cc: v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt =20 >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >Sent: Thursday, July 17, 2008 11:35 AM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Let me make sure I understand you. Are you agreeing to that fact that=20 >the WAN interface should have a global IPv6 address assigned to it=20 >because this is different from what you asked for in the past which was >to only assign a link-local address to the WAN interface. Also assume,=20 >for the sake of closure to the question, that there is no Loopback=20 >interface enabled on the CPE Router - after all, our draft says the=20 >Loopback interface is optional. I don't understand this. If it is a router, it follows the weak end system model and it can source packets from addresses assigned to any of its interfaces, including virtual interfaces like a loopback. I do not see a requirement for assignment of a non-link-local IPv6 address on the WAN interface. Fred fred.l.templin@boeing.com >Further, even I agree with you that it's not wise for a CPE Router to=20 >respond to pings. But I appreciate what NTT did in their deployment=20 >because how else can one monitor health of the device in the home? The=20 >device has to at least rate limit ICMP if the device responds to it. >Section 2.8 of RFC4241 is also not clear when it says "The CPE must=20 >return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo=20 >Request packet." What happens if the CPE received another ping req,=20 >say, >2 secs later. Will the CPE reply? If yes, then I can launch a ping=20 >attack on this CPE sending one pings per x secs and the CPE keeps=20 >replying. That is why I mentioned rate limiting. > >Hemant > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Thursday, July 17, 2008 1:47 PM >To: Hemant Singh (shemant); Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I've looked over RFC4241. I think it accurately describes what needs to >happen in a generic PPPoE environment -- except the section "2.8. >Connectivity Monitoring". We do not currently require CPE routers to=20 >respond to ICMP echo requests. It's even an option in some of our=20 >routers for customers to disable responses to unsolicited ICMP=20 >messages. >And we still don't have something called a "loopback interface". I also >don't think we intend to provide a /48 in this mass market environment. >Probably the smallest prefix would be a /56. I haven't seen any ARIN=20 >policy relating to required echo support, especially for an end=20 >customer with a /56. > >But I'm starting to wonder if we may just be experiencing another=20 >terminology problem, with "loopback interface". > >That is, I definitely agree that all CPE routers need to have a global=20 >address that can initiate and receive traffic to and from the Internet=20 >(over each logical WAN interface -- at the link layer or over PPP). I=20 >think this address can easily come from the prefix, and doesn't have to >be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The >CPE router must be able to act as a host device to the WAN. > >Clearly, there will be a link-local IP address on that WAN (link layer=20 >or PPP) interface. There may be a global IP address assigned by SLAAC=20 >or stateful DHCPv6. If there is, I think it would be useful to think=20 >about when the device might use or respond to messages to that global=20 >address, vs. global addresses it gives itself from the prefix. My=20 >preference would be to always use the prefix address for sending=20 >messages, by default (that is, unless configured to do otherwise).=20 >Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by=20 >default (unless configured otherwise). Unless the device doesn't get a=20 >prefix; then it will need to use the SLAAC/DHCPv6 address. > >I also think it's not a bad idea for the CPE router to keep the /64 for >itself that equates to the prefix it's given followed by zeroes, to get >to 64 bits (which is my attempt at trying to generically describe what=20 >I think RFC4241 section 2.8 is saying). I think it's fine for the CPE=20 >router to be able to respond to echo requests to that /64, if that=20 >function (responding to echo requests from the WAN) is enabled. >Barbara > >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >Sent: Tuesday, July 15, 2008 7:10 PM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Did you get a chance to look at our -02 draft and its reference to=20 >RFC4241? Please read RFC4241 to see what has NTT done in Japan to their >ADSL IPv6 services. > >Thanks. > >Hemant > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Tuesday, July 15, 2008 5:34 PM >To: Hemant Singh (shemant); Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I would prefer if no statements were made as to number of physical WAN=20 >interfaces. We have some bonded DSL interfaces that have 2 physical=20 >interfaces that are bonded together at either the ATM or Ethernet=20 >layer. >There are 2 physical WAN interfaces, but from the perspective of the IP >portion of the access network, there is only one "logical" WAN=20 >interface on the router. > >I really would prefer to describe the behavior of a single link layer >(L2) interface, rather than make any mention of physical interfaces=20 >(quantity, PHY, jack, or otherwise). I agree with your statement that=20 >this document's functionality needs to be abstracted from the physical. >I really, really agree. >Barbara > >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com] >Sent: Tuesday, July 15, 2008 4:51 PM >To: Stark, Barbara; Antonio Querubin >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >Barbara, > >Thanks for this email. For the purposes of description of behavior of a >CPE Router, all we are asking for is how many physical WAN interface=20 >ports will the CPE Router have? We have recommended one. We could care=20 >less about any other physical layer behavior. We are defining routing=20 >behavior that sits abstracted from link or physical layers. Where a=20 >layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP=20 >address acquisition does not perform DAD. > >Hemant > >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Tuesday, July 15, 2008 4:17 PM >To: Antonio Querubin; Hemant Singh (shemant) >Cc: v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >I don't understand the relevance of mentioning PHY interfaces, PHY=20 >modems, or pure Ethernet switches, in a document about IPv6 behavior of >CPE routers. A physical instantiation of a CPE router may indeed=20 >contain a PHY modem and Ethernet switch, but I don't see why that's=20 >relevant or needs to be called out in this document. > >I don't see any functionality described in this draft that changes=20 >based on the link layer or below. Certainly not if the link layer is=20 >Ethernet. > >I know that there do exist WAN PHY interfaces that do not have the IP=20 >running over either Ethernet link layer or PPP. Such IP interfaces=20 >will either exhibit the same behavior as described in this document, or >they won't. If they do, that can be mentioned. If they don't, but have=20 >mass market relevance, it can be described how they differ. The WAN=20 >interface as an Ethernet link layer interface will cover all mass=20 >market retail routers, and the vast majority of DSL modem/routers. I=20 >can't speak for DOCSIS or UMTS, since I don't know those protocol=20 >stacks very well. If they don't use Ethernet for their link layers, do=20 >they have some other link layer that is similar to Ethernet? Is there=20 >any reason why that link layer shouldn't be considered the "WAN=20 >interface"? >Barbara > >-----Original Message----- >From: Antonio Querubin [mailto:tony@lava.net] >Sent: Tuesday, July 15, 2008 2:00 PM >To: Hemant Singh (shemant) >Cc: Stark, Barbara; v6ops@ops.ietf.org >Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > >On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote: > >> Date: Tue, 15 Jul 2008 11:34:29 -0400 >> From: "Hemant Singh (shemant)" >> To: "Stark, Barbara" , v6ops@ops.ietf.org >> Cc: Antonio Querubin >> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >>=20 >> Barbara, >> >> Since Antonio also raised a point about IPv6 addresses >assigned to the > >> WAN interface (and the number of WAN interface(s)), we are >combining a > >> reply to both you and Antonio. >> >> Barbara, when you say, >> >> "We have considered the possibility of a separate IP address for our >> TR-069 management of the CPE routers that we supply, but would want >this >> to be a >> configurable option." >> >> could you please elaborate. Does this separate IPv6 address get >assigned >> to the WAN side of the CPE Router? If yes, if the WAN interface is >only >> assigned a link-local address, then what network interface >on the WAN >> side does this IPv6 address get assigned to? One choice we >have is to >> assign the IPv6 address to the Loopback interface facing the >WAN side. >> Also, when reviewers ask for another network interface on the WAN >side, >> or another IPv6 address on the WAN side, could reviewers please=20 >> appreciate the fact that another WAN interface can mean two >things for >a >> router. Either we have second physical WAN interface with a new=20 >> mac-address or we still have one WAN interface and the second WAN=20 >> interface is just a logical interface bound to the physical WAN=20 >> interface such that both the physical WAN interface and the logical=20 >> interface share a mac-address between them. Antonio and >Barbara, which > >> one of these two interfaces are you talking about? Further, >if one is >> spawning logical interfaces on any router, once doesn't have to stop >at >> one extra interface. Go ahead and spawn more if one wants. > >Actually the discussion is confusing because the 'WAN'=20 >interface appears > >to mean different things depending on whether the layer 2 modem is=20 >integrated into the CPE router. For discussion purposes, in a general=20 >network configuration where all the components are separate you'll=20 >have: > > PCs > | > | > | >----- modem ----- switch ----- router/firewall ----- switch ----- PCs > 1 A 2 B 3 C 4 D 5 E > >Devices B and D are just plain ethernet switches. Although the focus=20 >of > >this document seems to be on device C, it's interfaces, and the=20 >customer > >devices (E) behind it, the CPE router being discussed potentially=20 >encompasses functionality of devices A, B, C, and D. > >In the case where the modem is integrated, the interface that=20 >internally > >links the modem to the internal router device C may or may not be=20 >accessible to the consumer via external physical ports. If they are=20 >physically accessible, they need a different name than "WAN" >if "WAN" is > >defined to be 1 above. > >If the modem is not integrated into your CPE device, then the "WAN"=20 >interface is just 2 and/or 3 above depending on whether additional=20 >"WAN" > >ports are provided by the vendor. > >However these multiple definitions of WAN interfaces are confusing,=20 >hence my earlier suggestion of using different names for the=20 >modem-router interface and the access provider interface. > >> Further, Antonio, when you say, >> >> "Additionally, for those vendors that wish to integrate the layer 2 >> (DSL/cable) modem as part of the CPE router (where the "WAN" >> encapsulation is not ethernet), perhaps a separately named interface=20 >> definition might be appropriate to avoid confusion with "WAN"." >> >> In such a case, the WAN interface is a logical interface >that bridges >> the CPE Router to the broadband modem. We clarified the WAN >interface >> definition as follows with new text >> >> WAN interface - a single physical network interface on the >standalone >> CPE Router that is used to connect the router to the access >network of > >> the Service Provider. When the CPE Router is embedded in a >device that > >> connects to the WAN, this interface is a logical network interface >that >> bridges the device to the CPE Router. Some devices which can have an=20 >> embedded CPE router are: a cable or DSL modem, or a cellular >telephone, >> etc. >> >> When we publish our next revision of the draft, we will include new >text >> for the WAN interface definition. > >How about this. If you want to tie the WAN interface to the internal >router: > >WAN interface - a network interface on the CPE Router that is used to=20 >connect the router to the access network of the Service Provider. When >a CPE Router is embedded in a device that connects to the service=20 >provider > >via a non-ethernet connection, this interface is the logical interface=20 >that connects the internal router to the internal bridge. Some devices >which can have an embedded CPE router are: a cable or DSL modem, or a=20 >cellular telephone, etc. > >SPA (service provider access) interface - a non-ethernet physical=20 >network interface that is bridged to the WAN interface and directly=20 >connects to the access network of the Service Provider. > >But if you want to keep the definition of WAN tightly coupled with the=20 >physical external port then something like this might be more suitable: > >WAN interface - a network interface on the CPE Router that is used to=20 >connect the router directly to the access network of the Service=20 >Provider. >When a CPE Router is embedded in a device that connects to the service=20 >provider via a non-ethernet connection, this physical interface is=20 >bridged to the router via an internal modem. Some devices which can=20 >have an embedded CPE router are: a cable or DSL modem, or a cellular=20 >telephone, etc. > >WANEA (WAN Ethernet Access) interface - an optional ethernet interface=20 >that is bridged to the WAN interface and provides additional direct=20 >access to the Service Provider network. > >You may want to call it something other than WANEA :) > >Antonio Querubin >whois: AQ7-ARIN > >***** > >The information transmitted is intended only for the person or entity=20 >to which it is addressed and may contain confidential, proprietary,=20 >and/or privileged material. Any review, retransmission, dissemination=20 >or other use of, or taking of any action in reliance upon this=20 >information by persons or entities other than the intended recipient is >prohibited. If you received this in error, please contact the sender=20 >and delete the material from all computers. GA621 > > > >***** > >The information transmitted is intended only for the person or entity=20 >to which it is addressed and may contain confidential, proprietary,=20 >and/or privileged material. Any review, retransmission, dissemination=20 >or other use of, or taking of any action in reliance upon this=20 >information by persons or entities other than the intended recipient is >prohibited. If you received this in error, please contact the sender=20 >and delete the material from all computers. GA622 > > > > From owner-v6ops@ops.ietf.org Thu Jul 17 15:31:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81313A692C for ; Thu, 17 Jul 2008 15:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.027 X-Spam-Level: * X-Spam-Status: No, score=1.027 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYavTRJyNm7V for ; Thu, 17 Jul 2008 15:31:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EE7628C104 for ; Thu, 17 Jul 2008 15:31:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbyu-0002Bz-Cq for v6ops-data@psg.com; Thu, 17 Jul 2008 22:29:48 +0000 Received: from [74.125.92.24] (helo=qw-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbyq-0002BF-QQ for v6ops@ops.ietf.org; Thu, 17 Jul 2008 22:29:46 +0000 Received: by qw-out-2122.google.com with SMTP id 8so88962qwh.65 for ; Thu, 17 Jul 2008 15:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ee4onvLJPhmlkSyKcEx3mYO6Ht+CoThfpXevjmRhcA8=; b=rzk1xgzKBXuLee9KAZl8CKP1+pvdyOcMxBMadXWT9EZszfMXrNV5qOR9rlHOUoWVfZ coCkQ2K6B5FZ2GOFA8gEkydndw3QHNXq05RHUsUHvmjolSdT1+QFEENPaRWzg38sZHzb gUouHxUjj9ROXNNw/H1WDNzYtEWbJpghPyN1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Y7+RM+fgn1oSY3zMef4yx/mXv6qHUlNlRpK+3j2ze+SIH61m/g4BTHfhc6zbzqut0p lZnF10wpYXRZ3Ooyw3nV8FoV33Idwcs5wWJbMxAM6JWGDdUQOelKZ3i73F/4/wgual0I 0cdajpBtckFXB+JBkILKER533gatb2D7UuM2o= Received: by 10.151.102.16 with SMTP id e16mr1193822ybm.80.1216333783077; Thu, 17 Jul 2008 15:29:43 -0700 (PDT) Received: by 10.151.26.7 with HTTP; Thu, 17 Jul 2008 15:29:42 -0700 (PDT) Message-ID: <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> Date: Fri, 18 Jul 2008 00:29:42 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Stark, Barbara" , "Antonio Querubin" , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> X-Google-Sender-Auth: fa3b28dfaa0e1d4a Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > No apologies needed! Thanks for the quick reply back. So now, you from A= T&T and Shin from NTT, Japan are on the same page wrt global IPv6 address o= n the WAN interface. Shin has also asked for a global IPv6 address as a mus= t for the WAN interface. From the -00 version of our draft we have been say= ing the WAN interface acquires a global address. Further, Mikael on this th= read has said he wants the WAN interface to only acquire a link-local but t= he CPE Router spawn an Loopback interface to which a global IPv6 address is= assigned - we have already said in our draft this Loopback interface is op= tional and your deployment can ignore using it. I'd also like to point out = that the configuration required by Mikael is essentially the same as assign= ing a global IPv6 address to the WAN interface. > > Yes, there was a reason why we didn't add text in the Numbered model to s= ay that the global IPv6 address for the WAN interface may be assigned from = the IA_PD. We wanted to be careful about it. Here is an example. The IA_PD= obtained by the CPE Router is a /56. The CPE Router sub-delegates this pre= fix to a /64 for the LAN interface(s). So if a na=EFve implementation picke= d a global address for the WAN from the /64, then the WAN and the LAN are i= n the same IPv6 subnet - that's wrong because the WAN and LAN interface(s) = are physically different network segments for the CPE Router and hence they= must have different subnets to route traffic between them. What one has to= do is pick a global address for the WAN interface from the /56 IA_PD. We c= an add new text to the Numbered model to cover your suggestion. > this model is not supported by RFC3633. /ot From owner-v6ops@ops.ietf.org Thu Jul 17 15:35:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A073A6993 for ; Thu, 17 Jul 2008 15:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.835 X-Spam-Level: X-Spam-Status: No, score=-4.835 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGBpGx9w3OgQ for ; Thu, 17 Jul 2008 15:35:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4AEE3A6768 for ; Thu, 17 Jul 2008 15:35:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJc4Z-0002lv-6k for v6ops-data@psg.com; Thu, 17 Jul 2008 22:35:39 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJc4V-0002lZ-EV for v6ops@ops.ietf.org; Thu, 17 Jul 2008 22:35:37 +0000 X-IronPort-AV: E=Sophos;i="4.31,205,1215388800"; d="scan'208";a="14636665" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2008 22:35:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6HMZYCt023199; Thu, 17 Jul 2008 18:35:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6HMZW4O028012; Thu, 17 Jul 2008 22:35:34 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 18:35:33 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 18:35:33 -0400 Message-ID: In-Reply-To: <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjoXLTmHMZdhyePQFq5Al8DfdroCgAAD5UA References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Stark, Barbara" , "Antonio Querubin" , , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 17 Jul 2008 22:35:33.0981 (UTC) FILETIME=[6D15D8D0:01C8E85D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2261; t=1216334134; x=1217198134; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=maT7UWVc8ufkN7sGFi+egO5JMM7yj/4csUeWHJ4QhyU=; b=YYgyhwrAvpzjRsJMR8USSIwnZLEqJycUwdjgB/Sgf6VosRQEWk/X7AiAKY /9Lef6fAvUP5jVOIDe1+tVUMQc8Dt6kccUWE6fdqqgeqO9uGeF76s3IEAFhK LeTaunOw+4; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: OK, then we'll hold off Barbara's suggestion to add anything to the = Numbered section. If DSL folks want to push their proposal in this area, = they can work with the authors of RFC3633. Thanks. Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf = Of Ole Troan Sent: Thursday, July 17, 2008 6:30 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > No apologies needed! Thanks for the quick reply back. So now, you = from AT&T and Shin from NTT, Japan are on the same page wrt global IPv6 = address on the WAN interface. Shin has also asked for a global IPv6 = address as a must for the WAN interface. From the -00 version of our = draft we have been saying the WAN interface acquires a global address. = Further, Mikael on this thread has said he wants the WAN interface to = only acquire a link-local but the CPE Router spawn an Loopback interface = to which a global IPv6 address is assigned - we have already said in our = draft this Loopback interface is optional and your deployment can ignore = using it. I'd also like to point out that the configuration required by = Mikael is essentially the same as assigning a global IPv6 address to the = WAN interface. > > Yes, there was a reason why we didn't add text in the Numbered model = to say that the global IPv6 address for the WAN interface may be = assigned from the IA_PD. We wanted to be careful about it. Here is an = example. The IA_PD obtained by the CPE Router is a /56. The CPE Router = sub-delegates this prefix to a /64 for the LAN interface(s). So if a = na=EFve implementation picked a global address for the WAN from the /64, = then the WAN and the LAN are in the same IPv6 subnet - that's wrong = because the WAN and LAN interface(s) are physically different network = segments for the CPE Router and hence they must have different subnets = to route traffic between them. What one has to do is pick a global = address for the WAN interface from the /56 IA_PD. We can add new text to = the Numbered model to cover your suggestion. > this model is not supported by RFC3633. /ot From owner-v6ops@ops.ietf.org Thu Jul 17 15:51:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9783A6831 for ; Thu, 17 Jul 2008 15:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKrZbO7syJr2 for ; Thu, 17 Jul 2008 15:51:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBDE03A67B6 for ; Thu, 17 Jul 2008 15:51:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcJ6-0004bE-2d for v6ops-data@psg.com; Thu, 17 Jul 2008 22:50:40 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcJ1-0004Yj-56 for v6ops@ops.ietf.org; Thu, 17 Jul 2008 22:50:37 +0000 X-IronPort-AV: E=Sophos;i="4.31,206,1215388800"; d="scan'208";a="14637791" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2008 22:50:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6HMoYkn030091; Thu, 17 Jul 2008 18:50:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6HMoXki007290; Thu, 17 Jul 2008 22:50:34 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 18:50:33 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 18:50:28 -0400 Message-ID: In-Reply-To: <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjoXLTmHMZdhyePQFq5Al8DfdroCgAArRYg References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Stark, Barbara" , "Antonio Querubin" , X-OriginalArrivalTime: 17 Jul 2008 22:50:33.0695 (UTC) FILETIME=[855B4EF0:01C8E85F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2201; t=1216335034; x=1217199034; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=bDIK11ngBfb0iAphrDQEYp3v863ONvOnrc9t2C194AA=; b=XXJs5HUZ2QIdPqQbUq+fLYo7S+mZjY+N5InkntBueoDcYiR/vr+uwnXyPf sygCexWP+rWEVZY0mtgpg9sdK7qe57lW/Xtt0oqq+MSP1aw17+7qbGC8Qtl1 m7ZRDSJox4; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ole, It does help us if you can point to text in RFC3633 that prohibits the = behavior that is being asked by some DSL folks. Thanks. Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf = Of Ole Troan Sent: Thursday, July 17, 2008 6:30 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > No apologies needed! Thanks for the quick reply back. So now, you = from AT&T and Shin from NTT, Japan are on the same page wrt global IPv6 = address on the WAN interface. Shin has also asked for a global IPv6 = address as a must for the WAN interface. From the -00 version of our = draft we have been saying the WAN interface acquires a global address. = Further, Mikael on this thread has said he wants the WAN interface to = only acquire a link-local but the CPE Router spawn an Loopback interface = to which a global IPv6 address is assigned - we have already said in our = draft this Loopback interface is optional and your deployment can ignore = using it. I'd also like to point out that the configuration required by = Mikael is essentially the same as assigning a global IPv6 address to the = WAN interface. > > Yes, there was a reason why we didn't add text in the Numbered model = to say that the global IPv6 address for the WAN interface may be = assigned from the IA_PD. We wanted to be careful about it. Here is an = example. The IA_PD obtained by the CPE Router is a /56. The CPE Router = sub-delegates this prefix to a /64 for the LAN interface(s). So if a = na=EFve implementation picked a global address for the WAN from the /64, = then the WAN and the LAN are in the same IPv6 subnet - that's wrong = because the WAN and LAN interface(s) are physically different network = segments for the CPE Router and hence they must have different subnets = to route traffic between them. What one has to do is pick a global = address for the WAN interface from the /56 IA_PD. We can add new text to = the Numbered model to cover your suggestion. > this model is not supported by RFC3633. /ot From owner-v6ops@ops.ietf.org Thu Jul 17 16:06:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE7A3A659B for ; Thu, 17 Jul 2008 16:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.577 X-Spam-Level: X-Spam-Status: No, score=0.577 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ9C4vlgFtjd for ; Thu, 17 Jul 2008 16:06:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E8673A6831 for ; Thu, 17 Jul 2008 16:06:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcXz-0006Mq-Ih for v6ops-data@psg.com; Thu, 17 Jul 2008 23:06:03 +0000 Received: from [74.125.92.25] (helo=qw-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcXw-0006M7-3c for v6ops@ops.ietf.org; Thu, 17 Jul 2008 23:06:01 +0000 Received: by qw-out-2122.google.com with SMTP id 8so95290qwh.65 for ; Thu, 17 Jul 2008 16:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=wbL9il+yBTJ+3e76mn4u3whlIAE3ht+d0jPQ5TgXQFQ=; b=aCOn/31B+UTTRTdWGFyS0VOY4k8J9pkkhMLyeppnRMHJib/4gOLgz45JOWAAav2cZc VSqEmlqILUAwczi0ciKAqkcsbq0yK6T0wJ/s71HXKhEZj7NvWHE2HKzCJTZFMBsQ1g3V c9iyZZJuccPWVtk4S6yUTjbhHM6Tbg+oJdasM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SxQN/FiXVwo1MYCFvbkT2syGijxLRbqSdLo2qWaG+Hruwe/Z9AH9n3KSMic8emBqgZ imSDhM288WKFDv0g6iuq5rk7XO/vWczlZcdSFhdG3rIpgbqZkFXangd6C/rixbBvhYGw IH1dFXwbfhJq3zdXqYgUKT9Vd74lcmVZ5n+jU= Received: by 10.150.145.20 with SMTP id s20mr1223433ybd.242.1216335959200; Thu, 17 Jul 2008 16:05:59 -0700 (PDT) Received: by 10.151.26.7 with HTTP; Thu, 17 Jul 2008 16:05:59 -0700 (PDT) Message-ID: <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> Date: Fri, 18 Jul 2008 01:05:59 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Stark, Barbara" , "Antonio Querubin" , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> X-Google-Sender-Auth: c27cab16f8e5aa05 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > It does help us if you can point to text in RFC3633 that prohibits the behavior that is being asked by some DSL folks. > section 12.1: Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. /ot From owner-v6ops@ops.ietf.org Thu Jul 17 16:10:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784A53A6831 for ; Thu, 17 Jul 2008 16:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.82 X-Spam-Level: X-Spam-Status: No, score=-4.82 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHOn4JqjoJ18 for ; Thu, 17 Jul 2008 16:10:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 108E03A67B6 for ; Thu, 17 Jul 2008 16:10:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcbl-0006sL-8g for v6ops-data@psg.com; Thu, 17 Jul 2008 23:09:57 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJcbe-0006rJ-Hi for v6ops@ops.ietf.org; Thu, 17 Jul 2008 23:09:54 +0000 X-IronPort-AV: E=Sophos;i="4.31,206,1215388800"; d="scan'208";a="14639046" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2008 23:09:45 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6HN9jjQ003144; Thu, 17 Jul 2008 19:09:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6HN9jDt013580; Thu, 17 Jul 2008 23:09:45 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 19:09:45 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Thu, 17 Jul 2008 19:09:44 -0400 Message-ID: In-Reply-To: <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjoYbNqzLVd/6JxTl+stUkof3dHJQAABtrQ References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Stark, Barbara" , "Antonio Querubin" , X-OriginalArrivalTime: 17 Jul 2008 23:09:45.0230 (UTC) FILETIME=[33B99AE0:01C8E862] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1302; t=1216336185; x=1217200185; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=F2yfe7ChCiKZ6ZmQY13VfJWHmbODxCRi6Ozr1zhhldI=; b=Lc7WUwgcJcHB6IP1nohb9IOTjEePmowa+2kVQwuiMu6T5phyWYskvG4MG8 0XYCziBci2i052Mt75qGqfGbUXBxlOI9ufKGYM08/UgQvrHOzA2h8encI8L2 UX2z36rEaz; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ole, Thanks very much! I kind of figured it would be like this since my example to Barbara said it would be wrong for a router to have two disparate segments to be configured with same subnet. Barbara and anyone else, you will have to get a global IPv6 address for the WAN interface via SLAAC or DHCPv6 and then obtain the IA_PD via DHCPv6 or stateless DHCPv6. Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Thursday, July 17, 2008 7:06 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Hemant, > It does help us if you can point to text in RFC3633 that prohibits the behavior that is being asked by some DSL folks. > section 12.1: Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. /ot From owner-v6ops@ops.ietf.org Thu Jul 17 21:20:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB0A3A6A87 for ; Thu, 17 Jul 2008 21:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kaKwb1luy61 for ; Thu, 17 Jul 2008 21:20:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E34F13A69A6 for ; Thu, 17 Jul 2008 21:20:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJhOS-000Hs7-DQ for v6ops-data@psg.com; Fri, 18 Jul 2008 04:16:32 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJhOO-000Hra-EY for v6ops@ops.ietf.org; Fri, 18 Jul 2008 04:16:30 +0000 Received: (qmail 27385 invoked by uid 509); 18 Jul 2008 04:16:26 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.1/7733. spamassassin: 3.2.5. Clear:RC:1(211.28.128.246):. Processed in 0.044368 secs); 18 Jul 2008 04:16:26 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Thu, 17 Jul 2008 23:16:25 -0500 Cc: v6ops WG Message-Id: <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> From: David Miles To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 18 Jul 2008 14:16:21 +1000 References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant and Wes, Some comments on draft-02: - The un-numbered model doesn't require a loopback interface - ULA addresses generation per RFC4193 may not be appropriate for CPE as it requires time of day and is a one-time algorithm. I think we may need to suggest a new random algorithm that is consistent with the one in RFC 4193 and does not require time of day. We should also point out that a ULA prefix should be consistent across reloads and there must be some method by which the user can regenerate or otherwise specify their desired ULA prefix. Finally ULA is a 48-bit prefix. - I think we should add a line that says traffic with a ULA source address should not be forwarded out the WAN interface, rather than noting you could use user-configured ACL. - Seeing you mention DAD on the WAN interface, you may also want to add joining the solicited-node MC group via MLD per RFC 4861/2. - Suggest you use RIPng terminology rather than RIPv6 - The IPv6 over PPP and softwire sections makes no mention of WAN interface address assignment other than IPv6CP (interface-ID). Should we support both numbered and unnumbered models on PPP links? - Section 7: IPv6 Data forwarding should reference the Default Routers List and the creation of the default route based on this. As you've covered off cascading routers we also need to consider how to route traffic to them (assuming they will in turn populate their default router list with the root CPE). This suggests the DHCPv6 server in the CPE must be able to trigger route updates based on active leases. I think we need a new section that describes CPE behaviour on reload/ WAN up, thoughts below: ----- 5.4 Prefix Delegation Rebinding Whenever the CPE WAN link changes state, addresses passed through DHCPv6 must be revalidated. Conditions that should trigger a Rebind include: - When the CPE reboots - When the CPE WAN interface transitions to an up state Prior to completing a Rebind, the CPE should continue to use addresses and lifetimes previously assigned to its LAN interface(s) that are derived from IA_PD Prefix options. These may be subsequently invalidated through the Rebind process. On reload, a routing CPE may not be able to validate any IA_PD Prefix option lifetimes. Certain parameters must be stored in persistent memory to avoid a situation where hosts in the LAN segments consider previously advertised prefixes valid that the CPE does not know of or that may not be permitted by the upstream ISP. These persistent parameters are: - DHCPv6 PD - IAID - Prefix Options - A register of subnets assigned to each interface with associated IAID, IA_PD Prefix option and AdvPrefixList. - Interface address assignments and lifetimes The CPE MUST NOT advertise any RA PIO for prefixes derived from IA_PD Prefix Options until the prefixes have been validated through a DHCP Rebind message exchange. Once the WAN interface initialises, the reloading CPE SHOULD issue a DHCPv6-PD Rebind message, including the stored IAID and Prefix Options in the message. The DHCP Reply message will indicate whether the prefixes are valid (the valid lifetime is > 0) or invalid (the valid lifetime is 0). If there is no reply within CNF_MAX_RD [RFC 3315] the CPE MUST initiate DHCPv6 Address Acquisition. It should continue to use addresses and lifetimes previously assigned to its LAN interface(s). For each invalid prefix, the CPE MUST transmit unsolicited RA to LAN segments that contain PIO with the invalid prefix and the lifetime set to zero to immediately invalidate these addresses from hosts on the LAN. The CPE MUST then initialise DHCPv6 Address Acquisition. For each valid prefix, the CPE MUST transmit unsolicited RA to LAN segments that contain PIO with the valid prefix and lifetimes set to the values is the DHCP Reply IA_PD Prefix option. ----- - I'd suggest text in the DHCPv6 Address Acquisition section that clarifies IA_PD prefix options received by the CPE are an explicit list of valid prefixes. All prefixes in the CPE AdvPrefixList that originated from previous IA_PD and that are not contained in the DHCP- PD Reply MUST be immediately expired. This ensures a host will not try an communicate through the ISP with a invalid source address. I'm not sure what we should do in the scenario where DHCPv6 Address Acquisitions fails (ie, we get a response but no IA_PD Options) but I would lean to doing nothing (ie, dont expire prefixes but do not send any PIO, let the lifetime age away) as we are not going to forward anyway. - Some comments on the Unnumbered model with suggested text: From: 5.3.2. Unnumbered Model When the CPE router is configured for Unnumbered model, after the WAN and Loopback interfaces have acquired a link-local address, the Loopback interface initiates SLAAC or stateful DHCPv6 to obtain IA_PD option and other configuration information. On receiving the DHCPv6 REPLY with IA_PD option, the CPE Router sub-delegates one global IPv6 address from the IA_PD option to the Loopback interface. At any instance in time of the CPE Router operation, the router does not forward any traffic between its WAN and LAN interface(s) if the router has not completed IPv6 provisioning process that involves the acquisition of a global IPv6 address by the WAN or loopback interface and the acquisition of a global or Unique Local Address (ULA) by the LAN interface(s). --- To: 5.3.2. Unnumbered Model In the unnumbered model the WAN interface will not acquire an interface address through SLAAC or DHCPv6. When the CPE router is configured for Unnumbered model and after interface initialisation, the WAN interface initiates DHCPv6 to obtain IA_PD option and other configuration information. 5.3.3. Both Models On receiving the DHCPv6 REPLY with a IA_PD option, the CPE Router assigns a /64 prefix from within the bounds of the IA_PD Prefix Option to all interfaces except the WAN interface. The interface addresses are constructed using the /64 prefix and using EUI-64 on each interface for the Interface-ID portion of the address. At any instance in time of the CPE Router operation, the router does not forward any traffic between its WAN and LAN interface(s) if the router has not completed IPv6 provisioning process that involves the acquisition or rebinding of addresses via DHCPv6-PD. Cheers, -David From owner-v6ops@ops.ietf.org Fri Jul 18 03:58:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827D23A694E for ; Fri, 18 Jul 2008 03:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrAZypTvDObt for ; Fri, 18 Jul 2008 03:58:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B7993A69C2 for ; Fri, 18 Jul 2008 03:58:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJnbX-000Jz4-KU for v6ops-data@psg.com; Fri, 18 Jul 2008 10:54:27 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJnbT-000Jym-Hc for v6ops@ops.ietf.org; Fri, 18 Jul 2008 10:54:25 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id A2D763EA0C6; Fri, 18 Jul 2008 12:54:22 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 991063EA0A8; Fri, 18 Jul 2008 12:54:21 +0200 (CEST) Message-ID: <4880763B.4000902@free.fr> Date: Fri, 18 Jul 2008 12:53:47 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> In-Reply-To: <487F5BCB.1070209@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun - Le 7/17/08 4:48 PM : > > 2.1. Transition scenarios > > currently, it includes 6 scenarios: > > There are six obvious transition scenarios: > > o IPv4 system connecting to an IPv4 system across an IPv4 network, > o An IPv6 system connecting to an IPv6 system across an IPv6 > network, > o an IPv4 system connecting to an IPv4 system across an IPv6 > network, > o an IPv6 system connecting to an IPv6 system across an IPv4 > network, > o an IPv4 system connecting to an IPv6 system, or > > > o an IPv6 system connecting to an IPv4 system. > > I understand that we need to include one more: > > o a dual stack system connected to a IPv6 domain that is connecting > to an IPv4 system. Approved. > In addition, we need to include an additional text in section > > 2.1.2. Transition scenarios that do not require translation > > something along these lines: > > Another scenario that does not involves translation is the case > where a dual stack node is connected to an IPv6-only domain > and it is communicating with a IPv4-only node as depicted in Figure 2. > > > ,-----. ,-----. > ,' `. ,' `. > / \ / \ > / IPv6-only \ / IPv4-only \ > / Domain +-----------+ Domain \ > ; | Tunnel | : > | | endpoint | | > : +-----+ +-----------+ ; > \ |Dual | / \ +----+ / > \ |Stack| / \ |IPv4| / > \ |Host | / \ |Host| / > `.+-----+,' `. +----+,' > '-----' '-----' > > > > > > In this case, the dual stack host needs to establish a IPv4 in IPv6 > tunnel to the tunnel endpoint. In addition to that, the dual stack > needs to obtain a IPv4 address that is valid in the IPv4-only domain. > The simplest option is for the dual stack to obtain an IPv4 public > address. However, this may not be possible due to the shortage of > IPv4 public addresses. The other option is to use an IPv4 private address > (and potentially in conjunction with IPv4 NAT). The other option > is for the dual stack to obtain a public IPv4 transport address. > In all the cases, the acquisition of the address can be performed > dynamically. After "... shortage of IPv4 public addresses." you could add: "The other option is to obtain an IPv4 public address with a limited range of usable ports." > > Teemu proposed to include: > > 2.2. Requirements for the overall transition strategy > > 8. Transition architectures should be scalable for large number of > hosts and high data speeds. > > 4.2. Important things that SHOULD be supported > > I9: Scalability > > The translation mechanism SHOULD support very large number of hosts and > high data speeds with reasonable infrastructure requirements considering > equipment available at the transition timeframe. > > I think this makes sense, and i have a hard time finding someone who > don't agrees with this > so i am planning > to include them > > -------------------------------------------- > -3) discovery > --------------------------------------------- > > Teemu also porposed: > > 2.2. Requirements for the overall transition strategy > > 9. Availability of transition solutions on an access network should be > quickly discoverable. > > 4.2. Important things that SHOULD be supported > > > I10: Discovery > > The translation mechanism SHOULD be quickly discoverable, preferably in > one RTT, to help moving hosts better assess capabilities of available > access networks and to provide good user experience. > > I have a hard time understanding this one. > I mean R1 states: > > R1: Changes in the hosts > > The translation mechanism MUST NOT require changes in the v4-only > nodes to support the Basic requirements described in this section, > unless explicitly stated in the particular requirement. The > translation mechanism MAY require changes to v6-only nodes. > > So if we don't want changes in the host, how can a host have the > discovery mechanisms? I mean, i think this assuming some other form of > solution that is not based on translation. > > I am not doing anything about this at this point Proposal (additions between "s): The translation mechanism SHOULD be quickly discoverable, preferably in one RTT, to help moving "dual stack" hosts "or router CPEs" better assess capabilities of available access networks and to provide good user experience. > ------------------------------------------ > -4) no translation > ------------------------------------------ > > Teemu also porposed: > > > 4.3. Important things that MAY be supported > > M1: No NATs or ALGs > > The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid > need for ALGs. > > this clearly seems contradictory in a requirements fro translation (no > translation) > > I understand that translation should be avoided and we already say this > in the document > i.e. that dual stack is preferred and then tunnel and finally if there > is no other option > translation. I don't think that this should go in the requirements > section cause seems like > and oxymoron to me Proposal: M1: No NATs or ALGs "between dual stack and IPv4 hosts" The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid the need for ALGs "(translation being then limited, for example, to encapsulation-decapsulation). Regards. Rémi From owner-v6ops@ops.ietf.org Fri Jul 18 05:02:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1553A6997 for ; Fri, 18 Jul 2008 05:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.733 X-Spam-Level: X-Spam-Status: No, score=-104.733 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4meINF9wTgAQ for ; Fri, 18 Jul 2008 05:02:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80EE33A68D5 for ; Fri, 18 Jul 2008 05:02:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJod4-0002KH-QT for v6ops-data@psg.com; Fri, 18 Jul 2008 12:00:06 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJod0-0002Jb-Vy for v6ops@ops.ietf.org; Fri, 18 Jul 2008 12:00:04 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1216382400!2464230!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 31734 invoked from network); 18 Jul 2008 12:00:00 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jul 2008 12:00:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6IBxxmc002305; Fri, 18 Jul 2008 07:59:59 -0400 Received: from 01GAF5142010623.AD.BLS.COM ([139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6IBxrqU002233; Fri, 18 Jul 2008 07:59:53 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jul 2008 07:59:53 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jul 2008 07:59:53 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Fri, 18 Jul 2008 07:59:51 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDEDA5@crexc41p> In-Reply-To: <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt thread-index: AcjoYbGOnJblw4EaSlSqQh28KrGztQAa9zDQ References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> From: "Stark, Barbara" To: "Ole Troan" , "Hemant Singh (shemant)" CC: "Antonio Querubin" , X-OriginalArrivalTime: 18 Jul 2008 11:59:53.0216 (UTC) FILETIME=[C9D4B800:01C8E8CD] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: What is the reason for this prohibition?=20 Barbara=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Thursday, July 17, 2008 7:06 PM To: Hemant Singh (shemant) Cc: Stark, Barbara; Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Hemant, > It does help us if you can point to text in RFC3633 that prohibits the behavior that is being asked by some DSL folks. > section 12.1: Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. /ot ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 From owner-v6ops@ops.ietf.org Fri Jul 18 05:35:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151AA3A69F6 for ; Fri, 18 Jul 2008 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6ObReCIUaJ2 for ; Fri, 18 Jul 2008 05:35:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C2E73A69F4 for ; Fri, 18 Jul 2008 05:35:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpAH-0006zh-5z for v6ops-data@psg.com; Fri, 18 Jul 2008 12:34:25 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpAD-0006zH-HX for v6ops@ops.ietf.org; Fri, 18 Jul 2008 12:34:23 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 81120198724; Fri, 18 Jul 2008 15:34:20 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3EFDE198711; Fri, 18 Jul 2008 15:34:20 +0300 (EEST) Message-ID: <48808DD3.2040004@piuha.net> Date: Fri, 18 Jul 2008 15:34:27 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> In-Reply-To: <487F5BCB.1070209@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Marcelo, I agree with your assessment of issues 3 through 5. Jari From owner-v6ops@ops.ietf.org Fri Jul 18 05:49:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7093A693E for ; Fri, 18 Jul 2008 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxyENupVOGLc for ; Fri, 18 Jul 2008 05:49:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F1D93A6893 for ; Fri, 18 Jul 2008 05:49:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpOl-0008uz-H6 for v6ops-data@psg.com; Fri, 18 Jul 2008 12:49:23 +0000 Received: from [64.233.166.180] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpOe-0008ra-D1 for v6ops@ops.ietf.org; Fri, 18 Jul 2008 12:49:18 +0000 Received: by py-out-1112.google.com with SMTP id d32so252607pye.19 for ; Fri, 18 Jul 2008 05:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=DCY4q5u+gXEx6pUzzix9+KRAWMr6tSUxy5N5xxZJb8I=; b=lVzVvy3+HoimWZeV7jwI5H4atzQACF9S4ZKpq4tus/EiHcnFckgozrqJY9ffFDqYkc dYJAu61VZX14655plPwjALMSQ6zqzqMv1SNZShkvJgN8OwVnuY42vb2WessicqBKvZXI k4+jIll8L3heCcWhpmUha3A12KLU6/SZuTBPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=gUKNQodwPuLMrL89b6l9UpxnDnqBHgS+sfFp3TDYEK6i0sYRH9gGFut56+Qk+y80iA CUXLVUDQ+lblyJ9C18/F+THY7jeReeWf5KqYIc0GTXxuDv9MsPstDL4K1bdqfGfk7JQE cGvH5hZusZRV7ytbkX6z/ozLbNqKQ631ctD2E= Received: by 10.141.170.10 with SMTP id x10mr45226rvo.140.1216385352659; Fri, 18 Jul 2008 05:49:12 -0700 (PDT) Received: by 10.141.203.3 with HTTP; Fri, 18 Jul 2008 05:49:12 -0700 (PDT) Message-ID: <2bbba3c10807180549q2ca0f178s33fcbf92d7724195@mail.gmail.com> Date: Fri, 18 Jul 2008 14:49:12 +0200 From: "Ole Troan" To: "Stark, Barbara" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Hemant Singh (shemant)" , "Antonio Querubin" , v6ops@ops.ietf.org In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDEDA5@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <7582BC68E4994F4ABF0BD4723975C3FA09DDEDA5@crexc41p> X-Google-Sender-Auth: 1dc75bf777da513a Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > What is the reason for this prohibition? let me see if I can recall the arguments at the time: - the model of prefix delegation in 3633 is strictly hierarchical and you delegate a prefix typically across an administrative boundary the upstream link (link between RR and DR) is managed by the DR - there are already two mechanisms for address assignment, PD is for prefix delegation not address assignment. if the delegated prefix was subnetted also on the upstream, would the RR send RA's for example? - the DR will consider the prefix off-link and not use ND for address resolution, while the RR thinks the prefix is on-link. what problem are you trying to solve? if you wish to avoid using a separate /64 for the upstream link, then there is a solution for that in the draft I believe. (no global address on the upstream link, use of a loopback interface with an address from the delegated prefix for management purposes). cheers, Ole >> It does help us if you can point to text in RFC3633 that prohibits the > behavior that is being asked by some DSL folks. >> > > section 12.1: > > Upon the receipt of a valid Reply message, for each IA_PD the > requesting router assigns a subnet from each of the delegated > prefixes to each of the links to which the associated interfaces are > attached, with the following exception: the requesting router MUST > NOT assign any delegated prefixes or subnets from the delegated > prefix(es) to the link through which it received the DHCP message > from the delegating router. > > /ot > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 > > > From owner-v6ops@ops.ietf.org Fri Jul 18 06:35:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D483A6AB4 for ; Fri, 18 Jul 2008 06:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.715 X-Spam-Level: X-Spam-Status: No, score=-104.715 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4ejXM9kXXC7 for ; Fri, 18 Jul 2008 06:35:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 636063A6A67 for ; Fri, 18 Jul 2008 06:35:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJq4g-000Fry-92 for v6ops-data@psg.com; Fri, 18 Jul 2008 13:32:42 +0000 Received: from [216.82.245.115] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJq4c-000Fr0-2y for v6ops@ops.ietf.org; Fri, 18 Jul 2008 13:32:40 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1216387955!19391661!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 22060 invoked from network); 18 Jul 2008 13:32:35 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-14.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jul 2008 13:32:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6IDWZK6013968; Fri, 18 Jul 2008 09:32:35 -0400 Received: from 01GAF5142010623.AD.BLS.COM ([139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6IDWUvb013827; Fri, 18 Jul 2008 09:32:30 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jul 2008 09:32:29 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Jul 2008 09:32:29 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Fri, 18 Jul 2008 09:32:28 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDEDF3@crexc41p> In-Reply-To: <2bbba3c10807180549q2ca0f178s33fcbf92d7724195@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: Acjo1LKXMJeQ++9ASjmkdg53d+eYIwAAWX6w References: <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <7582BC68E4994F4ABF0BD4723975C3FA09DDEDA5@crexc41p> <2bbba3c10807180549q2ca0f178s33fcbf92d7724195@mail.gmail.com> From: "Stark, Barbara" To: "Ole Troan" CC: "Hemant Singh (shemant)" , "Antonio Querubin" , X-OriginalArrivalTime: 18 Jul 2008 13:32:29.0072 (UTC) FILETIME=[B9611100:01C8E8DA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Yes, I was trying to avoid use of (and the access network having to know routing for) addresses in a different subnet. Before I drop this notion, let me describe a little better what I need a global address for: The device that physically includes the CPE router needs to be able to *initiate* traffic to global addresses on the upstream for the following purposes: 1. SIP client (SIP registration, SIP invite, etc.); SIP server cannot be assumed to be "known" to the access network -- it's just another destination on the Internet 2. various tests, including echo requests, traceroute, http file upload and download for throughput testing, to destinations on the Internet 3. TR-069 remote procedure calls (running over HTTPS/TCP/IP) for remote management; the TR-069 server cannot be assumed to be within some sort of "management domain" of the access network -- it should be thought of as just another destination on the Internet In addition, it needs to be able to *receive* incoming traffic: 1. responses to all of the above 2. SIP client receives SIP invites 3. HTTP server can be temporarily enabled (by the customer) to allow the help desk to troubleshoot by using the device's http UI (of course, using https); help desk is somewhere out on the Internet, and cannot be assumed to be able to come in through a controlled part of the access network. I don't think these functions are appropriate for something that's described as a "loopback interface for management purposes". But since I really don't understand what that loopback interface is, I'd appreciate others' opinions. Are there other options, or should I just give up and get a global address from SLAAC/stateful DHCPv6? Barbara -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Friday, July 18, 2008 8:49 AM To: Stark, Barbara Cc: Hemant Singh (shemant); Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > What is the reason for this prohibition? let me see if I can recall the arguments at the time: - the model of prefix delegation in 3633 is strictly hierarchical and you delegate a prefix typically across an administrative boundary the upstream link (link between RR and DR) is managed by the DR - there are already two mechanisms for address assignment, PD is for prefix delegation not address assignment. if the delegated prefix was subnetted also on the upstream, would the RR send RA's for example? - the DR will consider the prefix off-link and not use ND for address resolution, while the RR thinks the prefix is on-link. what problem are you trying to solve? if you wish to avoid using a separate /64 for the upstream link, then there is a solution for that in the draft I believe. (no global address on the upstream link, use of a loopback interface with an address from the delegated prefix for management purposes). cheers, Ole >> It does help us if you can point to text in RFC3633 that prohibits the > behavior that is being asked by some DSL folks. >> > > section 12.1: > > Upon the receipt of a valid Reply message, for each IA_PD the > requesting router assigns a subnet from each of the delegated > prefixes to each of the links to which the associated interfaces are > attached, with the following exception: the requesting router MUST > NOT assign any delegated prefixes or subnets from the delegated > prefix(es) to the link through which it received the DHCP message > from the delegating router. > > /ot > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 > > > From owner-v6ops@ops.ietf.org Fri Jul 18 09:01:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39333A6AEB for ; Fri, 18 Jul 2008 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgtDISb-iFv6 for ; Fri, 18 Jul 2008 09:01:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB8633A6A9D for ; Fri, 18 Jul 2008 09:01:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsKr-0008y9-Lv for v6ops-data@psg.com; Fri, 18 Jul 2008 15:57:33 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsKn-0008xa-5A for v6ops@ops.ietf.org; Fri, 18 Jul 2008 15:57:31 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id BA174D00C6; Fri, 18 Jul 2008 05:57:23 -1000 (HST) Date: Fri, 18 Jul 2008 05:57:23 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I wonder, for those who feel a loopback interface is important, is that because you want the CPE router to be pingable regardless of any PHY interface status? If that's so, since the document's focus is on router behaviour, perhaps it is this behaviour should be explicitly mentioned. Section 5, paragraph 1 states 'optional Loopback network interface, facing the Service Provider upstream, which initiates stateless DHCPv6'. A loopback interface doesn't really 'face' any direction. You might want to change the wording to something along the lines of 'optional Loopback network interface initiates a DHCPv6 request toward the upstream SP' Also I notice in the same paragraph, "recommend the CPE Router WAN interface acquire its global IPv6 address using stateful DHCPv6 for administrative control of the router". This makes it sound like DHCP is recommended for administrative control where I think you mean the global address is recommended for administrative control and provisioning of proxied services to the downstream devices. Why not just say "recommend the CPE Router acquire a global IPv6 address for administrative control ..." Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Jul 18 09:27:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEF53A6839 for ; Fri, 18 Jul 2008 09:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.24 X-Spam-Level: ** X-Spam-Status: No, score=2.24 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtIwQke-gxgG for ; Fri, 18 Jul 2008 09:27:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E4A63A6802 for ; Fri, 18 Jul 2008 09:27:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsnK-000D3K-7h for v6ops-data@psg.com; Fri, 18 Jul 2008 16:26:58 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsnE-000D2f-6W for v6ops@ops.ietf.org; Fri, 18 Jul 2008 16:26:55 +0000 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8531391; Fri, 18 Jul 2008 12:26:28 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 12:26:28 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Jul 2008 16:25:55 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 12:25:54 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , CC: "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAMK2xVk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2008 16:26:28.0742 (UTC) FILETIME=[07E84A60:01C8E8F3] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'm reading version -02. I have to first admit I have not read the -01 nor the other comments that came with it, so some of what I'm going to say may have been said previously. Here are my main comments on the draft: 1) Two WAN interface models. I think this is one too many. Especially is there is a variable that the customer has to configure to select which mode the router is on. I look at this as a potential source of calls to the tech support. Choosing between the 2 modes, I would favor the numbered one. The reason is that we still have customers who attach a single PC to their cable modem. Those device would be just as happy with a single DHCPv6 assigned address. 2) ULA Supporting both ULA & GUA at the same time is also a source of complexity and confusion. The key problem I see is with external referrals in multi-party communications where some of the hosts are inside, and some are outside. Mixing ULA & GUA can have complex consequences, and again generates service call. Also, if I read the text correctly, if the WAN interface gets configured first, no ULA are generated. Which leads to confusing situation depending on whether the customer turns its modem on before or after its CPE. I would rather like the text to recommend to only use ULA when nothing else is available and immediately renumber to GUA when those are acquired. 3) Cascading routers The text says that the CPE can either be a DHCPv6 server or a DHCPv6 relay. This needs to be clarified. From an operation perspective, I'd rather like that the ISP only provision the CPE, not the cascaded routers. With that in mind, I do not think that the DHCPv6 relay mode is realistic. 4) RIPv6 Running RIPv6 between routers within the home might be OK, although it all depends on how the distribution of the prefixes is done, maybe a combination of default route upstream plus a route downstream toward the delegated router will be enough. However, running RIPv6 between the CPE and the ISP is a whole different ball game. We are looking at other solutions (DHCPv6 message interception) for prefix route injection as route announcement coming from residential customers are hard to trust. 5) DHCPV6 on the LAN interfaces First: " The CPE Router may include a stateful DHCPv6 server to assign addresses to home devices connected via the LAN interface(s) of the CPE Router. However, we recommend that the CPE Router use SLAAC for home devices." I think this recommendation is too strong and basically says "don't run DHCPv6 stateful on the LAN". This is in conflict with the statement to run DHCPv6 stateful with PD for cascading routers. I'd like this text to adopt a more neutral tone wrt DHCPv6 stateful configuration. Another example: I found it was not spelled out if the CPE MUST implement stateless DHCPv6 or not. It is not spelled out either if the CPE SHOULD implement a DNS server and advertize itself as such in DHCPv6 messages or if the CPE SHOULD re-advertize the ISP DNS server address... There is also no mention about NTP or any other similar options. As such, I think this whole section need more work. 6) Softwire & dual-stack lite support. We are moving the dual-stack lite work to softwire. See draft-durand-dual-stack-lite-00.txt If this gets adopted, I'd like to see support for it required in this draft. The minimum requirement is to support IPv4 over IPv6 tunneling, with manual configuration of the tunnel endpoint. - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 09:33:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C703A6AF8 for ; Fri, 18 Jul 2008 09:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InNa9SgE3VFh for ; Fri, 18 Jul 2008 09:33:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8D733A68CC for ; Fri, 18 Jul 2008 09:33:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJst1-000Dmc-MX for v6ops-data@psg.com; Fri, 18 Jul 2008 16:32:51 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJssx-000Dld-TE for v6ops@ops.ietf.org; Fri, 18 Jul 2008 16:32:49 +0000 X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="67004910" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 18 Jul 2008 16:32:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6IGWXAl019654; Fri, 18 Jul 2008 09:32:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6IGWXYV013335; Fri, 18 Jul 2008 16:32:33 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 12:32:33 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Fri, 18 Jul 2008 12:32:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: Acjo7xG9uZE/F5gITC2YLqUznykcBQAAjN7g References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Stark, Barbara" , X-OriginalArrivalTime: 18 Jul 2008 16:32:33.0133 (UTC) FILETIME=[E119F1D0:01C8E8F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3502; t=1216398753; x=1217262753; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20; bh=0z8ch7mMKUU21zIsxYw+LVsVWvXMNpSsGNcTUfU6o0U=; b=c5HjUO9Kblovkcc9De+Dn9CYmbY9RFtFsRTcSHFmU23xxzQKl6PZ2HK8sn KdP2egyuX3KQ6IA2RVXz5cTzQVHj8LtHNjrIdybr2MkPNWfENhozfHlcaWv+ asEKZDdFB7us4soxQymZwCdGP/WqUoHxFljK6n/HZWQMzL21EuFNY=; Authentication-Results: sj-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Friday, July 18, 2008 11:57 AM To: Hemant Singh (shemant) Cc: Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt I wonder, for those who feel a loopback interface is important, is that because you want the CPE router to be pingable regardless of any PHY interface status? =20 =20 That is one reason senior (savvy) folks like Remi on this mailer gave. The other reason is equally critical. Some folks requested they only wanted to assign a link-local to their WAN interface and use a Loopback interface to assign a global IPv6 address to. Since the device is a router, spawning any virtual interface on the router is no big deal for us. We said fine. Then as Ole pointed out today, the Loopback interface is also a solution for folks like AT&T who want to assign a global address to the "WAN" interface from the IA_PD that was doled out by the SP. As Ole said, RFC3633 prevents a RR like the CPE Router to assign any address from the IA_PD to an interface that the DHCPv6 REPLY ingressed on. Any DHCPv6 REPLY has to get to the CPE Router via the physical WAN interface. The Loopback interface gets around this restriction of RFC3633. However, if AT&T doesn't like using a virtual interface like the Loopback interface, then I said they have cannot assign an global address to the WAN interface from the IA_PD the WAN interface gets doled out.=20 If that's so, since the document's focus is on router behaviour, perhaps it is this behaviour should be explicitly mentioned. Section 5, paragraph 1 states 'optional Loopback network interface, facing the Service Provider upstream, which initiates stateless DHCPv6'. A loopback interface doesn't really 'face' any direction. You might want to change the wording to something along the lines of 'optional Loopback network interface initiates a DHCPv6 request toward the upstream SP' I agree with you. My intent was to only mean that this interface initiates any address acquisition to the SP. Will take your suggestion. Also I notice in the same paragraph, "recommend the CPE Router WAN interface acquire its global IPv6 address using stateful DHCPv6 for administrative control of the router". This makes it sound like DHCP is recommended for administrative control where I think you mean the global address is recommended for administrative control and provisioning of proxied services to the downstream devices. Why not just say "recommend the CPE Router acquire a global IPv6 address for administrative control ..." Ah, no we don't mean what you suggested with your text. What we mean by administrative control is that if one uses DHCPv6 then the address acquisition by any downstream client is known to the Sap's provisioning servers like the DHCPv6 server and also a backend provisioning systems (BPS) that serves multiple DHCPv6 servers. If clients acquire IPv6 address using SLAAC, then only the SP router is aware of these clients - we will need some protocol to run between the SP aggregation router and the BPS to inform about clients. Cable IPv6 standards have prohibit a cable modem to initiate SLAAC and mandate that the cable modem initiate stateful DHCPv6 for address acquisition. This mandate is similar to the administrative control we are talking about. Hemant Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Jul 18 09:42:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31C03A6A6F for ; Fri, 18 Jul 2008 09:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVZAutPvEaht for ; Fri, 18 Jul 2008 09:42:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 544963A686A for ; Fri, 18 Jul 2008 09:42:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJt1w-000F9L-IA for v6ops-data@psg.com; Fri, 18 Jul 2008 16:42:04 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJt1p-000F85-R6 for v6ops@ops.ietf.org; Fri, 18 Jul 2008 16:42:02 +0000 X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="14705436" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2008 16:41:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IGfuX3022926; Fri, 18 Jul 2008 12:41:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IGfrkm011389; Fri, 18 Jul 2008 16:41:56 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 12:41:31 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 18 Jul 2008 12:40:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAMK2xVkAAGvS4A== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , Cc: "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 18 Jul 2008 16:41:31.0612 (UTC) FILETIME=[220F51C0:01C8E8F5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4355; t=1216399316; x=1217263316; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=20; bh=4qDvpP/SR0wtPUmJhoPZ6oU4KxHgAD1lsM3DxmPlbNQ=; b=B794FnA8/Y79pGVY27/0MhyGVSO8KHBrozlGprQLxBLXaSoGNBSB387Vp+ WU53a+bVL7g4lLUzVPaDBYY0If5unkzL9nprYJL7HVC1dGYrbAdTjgw46Dd7 WcszPlI3l4; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Thanks very much for the careful review. We are working closely with Mark Townsley at Cisco who told us about your draft and Ralph's SNAT. Mark has advised us that our CPE Router draft needs to track all softwire new work and any IPv4 address depletion solutions like yours. In our next version we will mention such tracking in our draft including mention of your draft.=20 I will reply to rest of your comments sometime later today or over the weekend. Regards. Hemant =20 -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Friday, July 18, 2008 12:26 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review I'm reading version -02. I have to first admit I have not read the -01 nor the other comments that came with it, so some of what I'm going to say may have been said previously. Here are my main comments on the draft: 1) Two WAN interface models. I think this is one too many. Especially is there is a variable that the customer has to configure to select which mode the router is on. I look at this as a potential source of calls to the tech support. Choosing between the 2 modes, I would favor the numbered one. The reason is that we still have customers who attach a single PC to their cable modem. Those device would be just as happy with a single DHCPv6 assigned address. 2) ULA Supporting both ULA & GUA at the same time is also a source of complexity and confusion. The key problem I see is with external referrals in multi-party communications where some of the hosts are inside, and some are outside. Mixing ULA & GUA can have complex consequences, and again generates service call. Also, if I read the text correctly, if the WAN interface gets configured first, no ULA are generated. Which leads to confusing situation depending on whether the customer turns its modem on before or after its CPE. I would rather like the text to recommend to only use ULA when nothing else is available and immediately renumber to GUA when those are acquired. 3) Cascading routers The text says that the CPE can either be a DHCPv6 server or a DHCPv6 relay. This needs to be clarified. From an operation perspective, I'd rather like that the ISP only provision the CPE, not the cascaded routers. With that in mind, I do not think that the DHCPv6 relay mode is realistic. 4) RIPv6 Running RIPv6 between routers within the home might be OK, although it all depends on how the distribution of the prefixes is done, maybe a combination of default route upstream plus a route downstream toward the delegated router will be enough. However, running RIPv6 between the CPE and the ISP is a whole different ball game. We are looking at other solutions (DHCPv6 message interception) for prefix route injection as route announcement coming from residential customers are hard to trust. 5) DHCPV6 on the LAN interfaces First: " The CPE Router may include a stateful DHCPv6 server to assign addresses to home devices connected via the LAN interface(s) of the CPE Router. However, we recommend that the CPE Router use SLAAC for home devices." I think this recommendation is too strong and basically says "don't run DHCPv6 stateful on the LAN". This is in conflict with the statement to run DHCPv6 stateful with PD for cascading routers. I'd like this text to adopt a more neutral tone wrt DHCPv6 stateful configuration. Another example: I found it was not spelled out if the CPE MUST implement stateless DHCPv6 or not. It is not spelled out either if the CPE SHOULD implement a DNS server and advertize itself as such in DHCPv6 messages or if the CPE SHOULD re-advertize the ISP DNS server address... There is also no mention about NTP or any other similar options. As such, I think this whole section need more work. 6) Softwire & dual-stack lite support. We are moving the dual-stack lite work to softwire. See draft-durand-dual-stack-lite-00.txt If this gets adopted, I'd like to see support for it required in this draft. The minimum requirement is to support IPv4 over IPv6 tunneling, with manual configuration of the tunnel endpoint. - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 12:26:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640C928C24E for ; Fri, 18 Jul 2008 12:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yF98W9BnAms for ; Fri, 18 Jul 2008 12:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C496028C253 for ; Fri, 18 Jul 2008 12:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvXO-000B28-8B for v6ops-data@psg.com; Fri, 18 Jul 2008 19:22:42 +0000 Received: from [128.18.84.113] (helo=mailgate-internal3.sri.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvXJ-000B1K-Q5 for v6ops@ops.ietf.org; Fri, 18 Jul 2008 19:22:39 +0000 Received: from smssmtp-internal1.sri.com (128.18.84.115) by mailgate-internal3.sri.com with SMTP; 18 Jul 2008 19:22:36 -0000 X-AuditID: 80125473-ac8f9bb000000a51-56-4880ed7ce7bb Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal1.sri.com (Symantec Mail Security) with ESMTP id A0BC01B2501 for ; Fri, 18 Jul 2008 12:22:36 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4700DF8V5MXETI@mail.sri.com> for v6ops@ops.ietf.org; Fri, 18 Jul 2008 12:22:36 -0700 (PDT) Date: Fri, 18 Jul 2008 15:22:34 -0400 From: Ed Jankiewicz Subject: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 To: IPv6 Operations Message-id: <4880ED7A.20007@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: in addition to some editorial comments I sent to Marcelo, I have a few substantive comments (some admittedly half-baked) and discussion points to raise on the draft. I'm assuming there will be discussion at IETF 72? 1. transition versus coexistence: recognizing that the period of coexistence is likely to be longer, I would rather see consistent use of the term coexistence rather than transition throughout the document, e.g. coexistence scenarios, coexistence tools, etc. 2. add a sentence in front of the Problem Statement to explicitly state this motivation, e.g. "Settled opinion on the transition from an IPv4-dominant network to an IPv6-dominant network was that the period of coexistence would be brief, and could be accommodated by dual-stack and tunneling. Operationally, we now expect..." 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF strongly prefers and recommends [dual stack] as the operational matters are simplest" begs for a citation. RFC 4213 says dual stack is the most straightforward but does not include language recommending or preferring this solution. Also the impetus of this draft is that dual stack solves only the simplest part of the problem, and becomes very problematic when IPv4 addresses really get scarce (approaching rather than reaching exhaustion). Some have already stated (Alain Durand I recall saying something like) "a plan that requires all new end-nodes to be dual-stack and to have global IPv4 addresses is a non-starter." Also an emphasis on dual stack creates a "must carry" situation where the core network continues to route IPv4 indefinitely. While we say in para 2.2 that turning off IPv4 will be a business decision, the ISP can't make that choice without alienating customers that rely on dual stack. I can still plug in a 50 year old rotary dial phone and expect the local telco (in the USA at least) to make it work, even though DTMF has been the dominant method for nearly that long. 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF recommends tunnels rather than dual NAT - that also would need a citation, unless this document is making the statement for the first time. Also, I believe if the two NATs know they are in a reflexive relationship, they can avoid at least some of the general NAT problems - i.e. they should not attempt to translate addresses in application data. 5. translation network architecture: this may be beyond scope, but it seems to me that in para 2.1.3 there could be several sub-scenarios depending on the location of the translator a. translator coupled to IPv6 end-nodes (IPv6 on the LAN side, IPv4 on the WAN side) b. translator coupled to IPv4 end-nodes (IPv4 on the LAN side, IPv6 on the WAN side) c. in-network translation gateway (most like NAT-PT) There are some commercial products in development that fit these sub-scenarios, and each has its own strengths and weaknesses. Pulling the translator into an IPv6-only or IPv4-only edge network (a or b) avoids some issues and those developers made the choice to restrict deployment architecture to simplify their job. The different deployment architectures also have impact on the addressing concerns (para 3.3) and namespace (para 3.4). 6. para 3.5 on market timing seems out of place as an implementation/deployment statement in a requirements draft 7. Requirement R3 would be better stated in the negative: Translation mechanism MUST NOT interfere with native connectivity...depending where the NAT64 is in the network it may be a pass-through, or it may not be involved at all in the native flow and thus do nothing but non-interference. 8. Requirement R4 is very broad. the essence of translating DNS in support of NAT64 is to map a query on one side to the equivalent query on the other, and do the same with the response. Of course that mapping of names and addresses is non-trivial. It might help to illustrate this mapping process as well as some of the bad behavior that must be avoided. 9. Requirement R5 seems to forbid any routing table update, but don't the addresses that the NAT64 is mapping have to be routable? 10. Requirement R6 lists a few protocols, but I'm sure others might be seen as highly desirable too. Are we avoiding ALG issues by not mentioning higher level protocols like FTP? 11. where does the interpretation in Requirement R7 that sees the IPv6 side being like the private side of an IPv4 NAT come from? the opposite could be reasonable too - i.e. if there is no NAT between the NAT64 and the v4-only nodes the v4-only nodes might be using private addresses, and the IPv6 side of the NAT64 is the public side. The way it is described in R7, the IPv6 addresses are like IPv4 private addresses, mapped to the global addresses on the public side. 12. Requirement R9 is a noble statement but hardly a "testable" requirement; at least we should cite RFC 4942 as guidance, and analyze some of the security issues that arise in the different scenarios and architectures discussed in the draft. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From owner-v6ops@ops.ietf.org Fri Jul 18 12:26:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194BD28C265 for ; Fri, 18 Jul 2008 12:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.829 X-Spam-Level: X-Spam-Status: No, score=-4.829 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5YLKQkYftGv for ; Fri, 18 Jul 2008 12:26:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74F5E28C253 for ; Fri, 18 Jul 2008 12:26:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvZh-000BKe-3H for v6ops-data@psg.com; Fri, 18 Jul 2008 19:25:05 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvZc-000BJ0-B8 for v6ops@ops.ietf.org; Fri, 18 Jul 2008 19:25:02 +0000 X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="14739331" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2008 19:24:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IJOIi2006669; Fri, 18 Jul 2008 15:24:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IJOH9i018859; Fri, 18 Jul 2008 19:24:17 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 15:24:17 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 18 Jul 2008 15:24:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAMK2xVkABDRd0A== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , Cc: "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 18 Jul 2008 19:24:17.0891 (UTC) FILETIME=[DF373B30:01C8E90B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8297; t=1216409058; x=1217273058; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=20; bh=FMK8zlXK9UEHQWxYr6LFxFde6TBXMC5iMUW0GfbWin4=; b=AOpMpyD6cqtOKyrflt9ceVXTov/jWxtkFGYvPAhDoQ6i6ev8kHykmQQQxR wKVnEWQI2DLu4Z7PCmT9dzIjd6ojTK3AQLFFOiCm+OaSTGRgh6s6wJkeHwkJ xWYLBPue8R; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Please see in line between and . After Wes and I have discussed your comments, we will update folks another time. I won't be able to talk to Wes before Thu next week. -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Friday, July 18, 2008 12:26 PM To: Hemant Singh (shemant); v6ops@ops.ietf.org Cc: Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review I'm reading version -02. I have to first admit I have not read the -01 nor the other comments that came with it, so some of what I'm going to say may have been said previously. Here are my main comments on the draft: 1) Two WAN interface models. I think this is one too many. Especially is there is a variable that the customer has to configure to select which mode the router is on. I look at this as a potential source of calls to the tech support. Even currently, a standalone Linksys like router needs to pick if DHCP or PPPOE is used for WAN connection. At least an old version that I have at home. The default with Linksys is DHCP. We can suggest one default like DHCP, but if a DSL user uses the CPE Router, they will have to provision the WAN port like it is done with Linksys today. Anyhow, the unnumbered model is something that a lot of DSL folks have asked for. We have got to keep it. We have tried to automate as much as we can like spawning a loopback interface with unnumbered model. If any further auto-detection is possible, we will suggest it to make the SP life simpler. Choosing between the 2 modes, I would favor the numbered one. The reason is that we still have customers who attach a single PC to their cable modem. Those device would be just as happy with a single DHCPv6 assigned address. 2) ULA Supporting both ULA & GUA at the same time is also a source of complexity and confusion. The key problem I see is with external referrals in multi-party communications where some of the hosts are inside, and some are outside. Mixing ULA & GUA can have complex consequences, and again generates service call. Sorry, I don't see the point yet. We have clearly shown in section 5.5.1 how both ULA and GUA will coexist including very simple source address selection (SAS) rules pointers in the section. Other folks haven't balked at this yet - feel free to jump in. Renumbering is an extra step. If you renumber ULA to expire and shoe-horn in the GUA, service will be disrupted for a little while. ULA's are also automatically generated, so the operator hasn't see any of it or any support calls. Also, if I read the text correctly, if the WAN interface gets configured first, no ULA are generated. Which leads to confusing situation depending on whether the customer turns its modem on before or after its CPE. You read the text correctly. This model is used when the SP controls the CPE Router or the CPE Router is embedded in a cable or DSL modem etc. Irrespective of when the modem turns on wrt to its CPE, when the WAN interface of the CPE Router get connection to the SP, the WAN interface init will take place. There is no need for ULA here. However, there is no reason why we cannot have the WAN init first model also follow the same idea as the LAN interface(s) init first. However, since our document says, the CPE Router may be embedded in a modem, we needed to keep this ULA out of the WAN init first model to be compliant with CableLabs (CL) eRouter CM standard. That standard mandates WAN inits first, then the LAN inits, then the LAN interface(s) are sub-delegated the IA_PD. If we add ULA to the WAN init first model, we won't be compliant with CL eRouter CM standard. If you want both WAN init first and LAN init first models to always assign UAL to the LAN interface(s), then CL has to adopt text from our draft to their eRouter CM standard. I would rather like the text to recommend to only use ULA when nothing else is available and immediately renumber to GUA when those are acquired. 3) Cascading routers The text says that the CPE can either be a DHCPv6 server or a DHCPv6 relay. This needs to be clarified. From an operation perspective, I'd rather like that the ISP only provision the CPE, not the cascaded routers. With that in mind, I do not think that the DHCPv6 relay mode is realistic. The text for this section is saying that a CPE Router vendor decides if the vendor implements a DHCPv6 server or a relay agent in their device to be able to support cascading of the CPE Router. SP is not going to provision anything here.=20 4) RIPv6 Running RIPv6 between routers within the home might be OK, although it all depends on how the distribution of the prefixes is done, maybe a combination of default route upstream plus a route downstream toward the delegated router will be enough. However, running RIPv6 between the CPE and the ISP is a whole different ball game. We are looking at other solutions (DHCPv6 message interception) for prefix route injection as route announcement coming from residential customers are hard to trust. Preaching to the choir here. I have already said in this draft's thread that I prefer the DHCPv6 message snooping. We just left the door open if anyone wanted to do anything with RIPv6. It's optional anyway for a vendor to support and the SP to decide to use it or not. 5) DHCPV6 on the LAN interfaces First: " The CPE Router may include a stateful DHCPv6 server to assign addresses to home devices connected via the LAN interface(s) of the CPE Router. However, we recommend that the CPE Router use SLAAC for home devices." I think this recommendation is too strong and basically says "don't run DHCPv6 stateful on the LAN". This is in conflict with the statement to run DHCPv6 stateful with PD for cascading routers. I'd like this text to adopt a more neutral tone wrt DHCPv6 stateful configuration. We can consider toning down the language. For the case when the CPE Router is embedded in a cable modem, we do not expect a cascading of router(s) behind the eRouter CM. That is why we have an "if" in the cascading section. It's left to the vendor to decide if they want to support a DHCPv6 server or not. Another example: I found it was not spelled out if the CPE MUST implement stateless DHCPv6 or not. It is not spelled out either if the CPE SHOULD implement a DNS server and advertize itself as such in DHCPv6 messages or if the CPE SHOULD re-advertize the ISP DNS server address... Section 5.5 says clearly that the DNS server IPv6 address obtained in DHCPv6 response messages is doled out to clients in the home. This is the text from section 5.5: "CPE Router can pass Domain Name Server(s) IPv6 address(es) to home devices.". In the long-term for our draft, we do need to add support for a DNS server on the CPE Router to advertise itself in DHCPv6 message as you say. In our next version we can add a new section placeholder for this item and the write the text when we get the time.=20 There is also no mention about NTP or any other similar options. We know about NTP but we didn't get time to do our homework on it to make sure if it's really needed. We do need to collect all options that are expected to be used in the home and add them when we compile the list. We will add a TBD to this section say such a list is pending.=20 As such, I think this whole section need more work. Some work is indeed needed. We will make sure the section has toned down language and also complete the TBD's mentioned above. 6) Softwire & dual-stack lite support. We are moving the dual-stack lite work to softwire. See draft-durand-dual-stack-lite-00.txt If this gets adopted, I'd like to see support for it required in this draft. The minimum requirement is to support IPv4 over IPv6 tunneling, with manual configuration of the tunnel endpoint. I already replied to this one. We will track this draft. After I finish reading it, I will send my feedback. Hemant - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 12:58:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C2D3A6B58 for ; Fri, 18 Jul 2008 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwwLCzbZWqQe for ; Fri, 18 Jul 2008 12:58:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB3123A6B48 for ; Fri, 18 Jul 2008 12:58:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJw4j-000Gmf-Hl for v6ops-data@psg.com; Fri, 18 Jul 2008 19:57:09 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJw4f-000Gm6-Cp for v6ops@ops.ietf.org; Fri, 18 Jul 2008 19:57:07 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 849A0ADADD; Fri, 18 Jul 2008 21:57:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 75E6AADADC; Fri, 18 Jul 2008 21:57:04 +0200 (CEST) Date: Fri, 18 Jul 2008 21:57:04 +0200 (CEST) From: Mikael Abrahamsson To: Alain Durand cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 18 Jul 2008, Alain Durand wrote: > I think this is one too many. Especially is there is a variable that the > customer has to configure to select which mode the router is on. I look at > this as a potential source of calls to the tech support. I'm ok with "globall routable WAN IPv6 address" being the default. My only request is that the "link-local only WAN" and "assign loopback address for management from DHCPv6 PD block"-model is a SHOULD requirement in the draft. > Choosing between the 2 modes, I would favor the numbered one. The reason is > that we still have customers who attach a single PC to their cable modem. > Those device would be just as happy with a single DHCPv6 assigned address. The service I have in mind would require the customer to have a router, otherwise they'll have to purchase a different service. Basically what I envision is that for single PC deployment we'd run tunneling (6to4) or equivalent, and "customer has a proper CPE router" would be native IPv6. Single PC is ok to have tunneled as there will be no multicast etc in that service. For routed multicast IPv6 you really really want to have a CPE router (at least that is my opinion). I am also looking at this in the 5-10 year future, where I think all customers want to have a routed CPE in their home and have multiple subnets. Not including "link-local WAN" in the model is too short-sighted for me, even though I can understand why people are hesitant about it in the short term. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 18 13:19:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41A628C27D for ; Fri, 18 Jul 2008 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZTHtdiPJ8SC for ; Fri, 18 Jul 2008 13:18:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 611F53A6A82 for ; Fri, 18 Jul 2008 13:18:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwP8-000Jpq-Qx for v6ops-data@psg.com; Fri, 18 Jul 2008 20:18:14 +0000 Received: from [128.18.84.114] (helo=mailgate-internal4.sri.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwP3-000JoA-Nq for v6ops@ops.ietf.org; Fri, 18 Jul 2008 20:18:12 +0000 Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 18 Jul 2008 20:18:09 -0000 X-AuditID: 80125474-a8a5fbb000000a7b-78-4880fa8162a6 Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id 4911C1B2501 for ; Fri, 18 Jul 2008 13:18:09 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4700FFQXQ8M5JV@mail.sri.com> for v6ops@ops.ietf.org; Fri, 18 Jul 2008 13:18:09 -0700 (PDT) Date: Fri, 18 Jul 2008 16:18:07 -0400 From: Ed Jankiewicz Subject: [Fwd: IPv4 and IPv6 Co-existence discussions in Dublin] To: IPv6 Operations Message-id: <4880FA7F.8020503@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In the unlikely event you didn't read this on another list... -------- Original Message -------- Subject: IPv4 and IPv6 Co-existence discussions in Dublin Date: Fri, 18 Jul 2008 18:30:05 +0200 From: Mark Townsley Reply-To: Internet Area To: softwires@ietf.org, ipv6@ietf.org, IETF DNSEXT WG Apologies for cross-posting, please reply only to int-area@ietf.org All, Recent discussions in the IETF indicate that the IPv4 and IPv6 co-existence solutions we have available will not be sufficient for all deployment scenarios which we expect to be necessary in the face of pressures due to upcoming IPv4 address space exhaustion (or "completion"). The INT, TSV and OPS ADs would like to discuss with the community the best way to proceed in chartering this work, with particular focus on solutions which seem both readily tractable and for which provide identifiable benefit. Specifically, two initial steps appear as potential work items: 1. The ability to employ an IPv6-only network infrastructure by, say a cable or DSL operator, and still be able to serve subscriber networks that run on IPv4. This scenario was described in the Vancouver IETF V6OPS meeting [4], and it could be helpful in large networks where private RFC1918 IPv4 space is not sufficient to address all devices without resorting to overlays or NAT of the private space itself. We believe that this is something that can be implemented through the use of tunneling of IPv4 over IPv6. If the subscribers are in turn given private IPv4 address space, the tunnels would be connected to an IPv4 NAT device that serves multiple subscribers, potentially requiring a device that serves a very large number of translations as well as tunnels. It is suggested that this is a work item that fits the SOFTWIRE WG, and the INT ADs will be sending off a recharter proposal for this WG to examine this particular problem space and develop a solution accordingly. 2. NAT-PT was deprecated for reasons described in RFC 4966. However, there are scenarios where some forms of translation may be necessary. In particular, the IAB noted in [1] that scenarios involving servers without public IPv4 addresses cannot be adequately handled with the existing mechanisms. Requirements on this issue have been discussed in V6OPS, and a problem statement document written [2]. One possible translation design with reduced scope from NAT-PT as defined in RFC 2766 has been discussed recently in the BEHAVE WG [3], but there are other possible designs as well [5]. In essence, these designs attempt to reduce the problems present in NAT-PT by various techniques, including limiting themselves to a simpler part of the overall problem, allowing some changes in IPv6 hosts, and generally being designed with a better knowledge of the issues in RFC 4966. We believe that, on balance, the benefits outweigh the costs on developing a standard method for translation of IPv4 and IPv6. This will likely have a smaller scope, at least in the short term, than the original NAT-PT though it will inevitably share some of the same limitations. We will discuss this design in two places at the upcoming meeting: BEHAVE and INTAREA (two separate places because we feel it necessary to involve both the IP experts and people with a history of building address translators). For the moment, general architectural discussion should happen on the int-area@ietf.org list. We would like to focus our discussions on whether the requirements scenario and architectural direction is sufficiently ready so that the work can be given to the protocol WGs. If the answer to these questions is yes, after the Dublin IETF the ADs will recharter the relevant working groups to do the work. V6OPS is already working on the requirements. We expect that the behave WG would be the primary solution discussion forum and produce the base translation specification. 6MAN and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts (including a DNS ALG, if needed). - INT, OPS, and TSV ADs [1] http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html [2] http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req [3] http://tools.ietf.org/id/draft-bagnulo-behave-nat64 [4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm [5] http://tools.ietf.org/id/draft-xli-behave-ivi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From owner-v6ops@ops.ietf.org Fri Jul 18 13:39:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E7928C229 for ; Fri, 18 Jul 2008 13:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.872 X-Spam-Level: ** X-Spam-Status: No, score=2.872 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE+ifXxrBERJ for ; Fri, 18 Jul 2008 13:39:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 568663A687F for ; Fri, 18 Jul 2008 13:39:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwi5-000MnF-FU for v6ops-data@psg.com; Fri, 18 Jul 2008 20:37:49 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwi1-000Mmc-SK for v6ops@ops.ietf.org; Fri, 18 Jul 2008 20:37:47 +0000 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8568502; Fri, 18 Jul 2008 16:37:14 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 16:37:14 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Jul 2008 20:36:40 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 16:36:38 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: Mikael Abrahamsson CC: "Hemant Singh (shemant)" , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpFfofOesHeTRTUkmQjoAW72AtEw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2008 20:37:14.0092 (UTC) FILETIME=[0FA282C0:01C8E916] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/18/08 3:57 PM, "Mikael Abrahamsson" wrote: > I am also looking at this in the 5-10 year future, where I think all > customers want to have a routed CPE in their home and have multiple > subnets. Not including "link-local WAN" in the model is too short-sighted > for me, even though I can understand why people are hesitant about it in > the short term. There is something I'm missing here: If you give an IPv6 address to the CPE (using stateful DHCPv6 or SLAAC) and then do a stateful DHCPv6-PD request from the CPE, what is missing? - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 13:50:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB71228C298 for ; Fri, 18 Jul 2008 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj-LVAJne6gS for ; Fri, 18 Jul 2008 13:50:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19CC728C292 for ; Fri, 18 Jul 2008 13:50:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwtz-000OUZ-Dt for v6ops-data@psg.com; Fri, 18 Jul 2008 20:50:07 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwtv-000OU4-NP for v6ops@ops.ietf.org; Fri, 18 Jul 2008 20:50:05 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1502AADADC; Fri, 18 Jul 2008 22:49:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A267ADAD9; Fri, 18 Jul 2008 22:49:58 +0200 (CEST) Date: Fri, 18 Jul 2008 22:49:57 +0200 (CEST) From: Mikael Abrahamsson To: Alain Durand cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 18 Jul 2008, Alain Durand wrote: > On 7/18/08 3:57 PM, "Mikael Abrahamsson" wrote: > >> I am also looking at this in the 5-10 year future, where I think all >> customers want to have a routed CPE in their home and have multiple >> subnets. Not including "link-local WAN" in the model is too short-sighted >> for me, even though I can understand why people are hesitant about it in >> the short term. > > There is something I'm missing here: If you give an IPv6 address to the CPE > (using stateful DHCPv6 or SLAAC) and then do a stateful DHCPv6-PD request > from the CPE, what is missing? I am not sure I understand the question, but I hope this is a clarification: I don't want to have a common IP network which is shared by the ISP device and the CPE device. Thus, no link network that is shared between ISP device and customer device (=link local). -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 18 13:55:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AAF3A6B78 for ; Fri, 18 Jul 2008 13:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.295 X-Spam-Level: ** X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja5qB-ECyA-D for ; Fri, 18 Jul 2008 13:55:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31EB13A6B76 for ; Fri, 18 Jul 2008 13:55:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwyp-000PTm-G2 for v6ops-data@psg.com; Fri, 18 Jul 2008 20:55:07 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwyl-000PSw-Gt for v6ops@ops.ietf.org; Fri, 18 Jul 2008 20:55:05 +0000 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.57927604; Fri, 18 Jul 2008 16:54:46 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 16:54:46 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Jul 2008 20:54:01 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 16:53:59 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: Mikael Abrahamsson CC: "Hemant Singh (shemant)" , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpGGabSeNZ5ChrMk6trWZs60zxSQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2008 20:54:46.0189 (UTC) FILETIME=[82BBC5D0:01C8E918] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/18/08 4:49 PM, "Mikael Abrahamsson" wrote: > I am not sure I understand the question, but I hope this is a > clarification: > > I don't want to have a common IP network which is shared by the ISP device > and the CPE device. Thus, no link network that is shared between ISP > device and customer device (=link local). Thank you for the clarification, I now understand better your goal, but what is the rationale for doing that? - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 14:36:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EEA3A680E for ; Fri, 18 Jul 2008 14:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsvX9+5dJMf4 for ; Fri, 18 Jul 2008 14:36:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88A073A6811 for ; Fri, 18 Jul 2008 14:36:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxbT-0005nC-2C for v6ops-data@psg.com; Fri, 18 Jul 2008 21:35:03 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxbN-0005mE-Sk for v6ops@ops.ietf.org; Fri, 18 Jul 2008 21:35:01 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 627C7ADADC; Fri, 18 Jul 2008 23:34:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 56B43ADAD9; Fri, 18 Jul 2008 23:34:56 +0200 (CEST) Date: Fri, 18 Jul 2008 23:34:56 +0200 (CEST) From: Mikael Abrahamsson To: Alain Durand cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 18 Jul 2008, Alain Durand wrote: > Thank you for the clarification, I now understand better your goal, but > what is the rationale for doing that? I stated this in the beginning of the discussion, but here goes again: I want to protect ISP equipment from outsid/Internet DDOS attacks. I foresee proliferation of basement/FTTC L3 switches (ASIC forwarding, small TCAM, small CPU) with ethernet/vdsl2 PHYs, and I want to be able to rate-limit traffic coming in from the internet to these devices (also my core). Therefore ISP equipment needs to be in separate IP space from customer equipment IP space. This also applies to SOHO market. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 18 14:54:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6388A3A684D for ; Fri, 18 Jul 2008 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDJH+s9md+2J for ; Fri, 18 Jul 2008 14:54:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 767C53A6811 for ; Fri, 18 Jul 2008 14:54:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxsZ-0008sz-1S for v6ops-data@psg.com; Fri, 18 Jul 2008 21:52:43 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxsV-0008sO-Cu for v6ops@ops.ietf.org; Fri, 18 Jul 2008 21:52:41 +0000 Received: by yx-out-2324.google.com with SMTP id 8so271484yxb.71 for ; Fri, 18 Jul 2008 14:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AR3810ZZZ6lAQF+/yod8bCLEPHFzwqTsZGTKrR4H6pM=; b=e8dcD7R5T6tHByRSOYZy7qbc+vav3qrdIQWCGl1ISHk3i/58tSHzWwpq7o5uvdAwfh QtPJjWeAAOZ23g13ie2ri9NKlYy20zWUv0XFVC7ua2tqK7xqXQKaSbbemIQVZZI1GS8z dJa/ZaDNnPiIvF/HRtu9JMG6G9Ucb+Nt5BXhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lJz3h/2EgHV7A0H5eqoP/KD6ukwVkNNaK45aIn9rRz6mW8BnohvRuvBZyLQpY0jGYu m00Ec/q5vTkFZgc+k4/2rX/xf+jVwyuvOMjlniZiD0Yaxhe+1S1VWmdq4bm36OzSrSas DW76b0xg6FZDaX3sUAKd+9SkFg4zFU7Sc8d2E= Received: by 10.151.143.3 with SMTP id v3mr632353ybn.244.1216417958217; Fri, 18 Jul 2008 14:52:38 -0700 (PDT) Received: by 10.151.26.7 with HTTP; Fri, 18 Jul 2008 14:52:38 -0700 (PDT) Message-ID: <2bbba3c10807181452h64ed2bfi460d1e0790f61f39@mail.gmail.com> Date: Fri, 18 Jul 2008 23:52:38 +0200 From: "Ole Troan" To: "Alain Durand" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 5a3d52abf2119ad6 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > 4) RIPv6 > > Running RIPv6 between routers within the home might be OK, although it all > depends on how the distribution of the prefixes is done, maybe a combination > of default route upstream plus a route downstream toward the delegated > router will be enough. > > However, running RIPv6 between the CPE and the ISP is a whole different ball > game. We are looking at other solutions (DHCPv6 message interception) for > prefix route injection as route announcement coming from residential > customers are hard to trust. quite. you can't run RIP in this scenario without solving the glaring security problem. http://tools.ietf.org/draft/draft-stenberg-v6ops-pd-route-maintenance/draft-stenberg-v6ops-pd-route-maintenance-00.txt for details. /ot From owner-v6ops@ops.ietf.org Fri Jul 18 15:20:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984BC3A693C for ; Fri, 18 Jul 2008 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.823 X-Spam-Level: X-Spam-Status: No, score=-4.823 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C6eozLUWA-Y for ; Fri, 18 Jul 2008 15:20:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DBE33A68CC for ; Fri, 18 Jul 2008 15:20:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyI6-000CRE-1k for v6ops-data@psg.com; Fri, 18 Jul 2008 22:19:06 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyI2-000CQp-6C for v6ops@ops.ietf.org; Fri, 18 Jul 2008 22:19:04 +0000 X-IronPort-AV: E=Sophos;i="4.31,212,1215388800"; d="scan'208";a="14737756" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2008 22:18:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IMIxrU013049; Fri, 18 Jul 2008 18:18:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IMIwcQ022429; Fri, 18 Jul 2008 22:18:58 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:18:58 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 18 Jul 2008 18:18:58 -0400 Message-ID: In-Reply-To: <2bbba3c10807181452h64ed2bfi460d1e0790f61f39@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpIKdtAx0PwNqZQ36ceHBHWdBhTAAA1OrQ References: <2bbba3c10807181452h64ed2bfi460d1e0790f61f39@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" , "Alain Durand" Cc: , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 18 Jul 2008 22:18:58.0822 (UTC) FILETIME=[46566260:01C8E924] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1304; t=1216419539; x=1217283539; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Ole=20Troan=22=20,=0A=20=20 =20=20=20=20=20=20=22Alain=20Durand=22=20; bh=V1ej9P2B6Gv59aAuF3W+lbgrl662KdVK3wFy2Ha6CLE=; b=H3P9QY+BKxu8OJI977ChSRNuaRR6YCYbd+8Y1/omJlPNQFzj3RkhC6kEIH dbc8FCa++fXw60T49yPiyjZsxhwSCcXdSUk0o0lQilN82SUXPP3wDfUBhoJr Rob8TasK6R; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Right. This was the 3rd solution we had alluded to in our emails but not pointed to it since we authors are leaning towards the dhcv6 snooping by the aggregation router.=20 Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Friday, July 18, 2008 5:53 PM To: Alain Durand Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review > 4) RIPv6 > > Running RIPv6 between routers within the home might be OK, although it > all depends on how the distribution of the prefixes is done, maybe a=20 > combination of default route upstream plus a route downstream toward=20 > the delegated router will be enough. > > However, running RIPv6 between the CPE and the ISP is a whole=20 > different ball game. We are looking at other solutions (DHCPv6 message > interception) for prefix route injection as route announcement coming=20 > from residential customers are hard to trust. quite. you can't run RIP in this scenario without solving the glaring security problem. http://tools.ietf.org/draft/draft-stenberg-v6ops-pd-route-maintenance/dr aft-stenberg-v6ops-pd-route-maintenance-00.txt for details. /ot From owner-v6ops@ops.ietf.org Fri Jul 18 15:45:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F3E3A68A6 for ; Fri, 18 Jul 2008 15:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.816 X-Spam-Level: X-Spam-Status: No, score=-4.816 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWzY0NknN-hS for ; Fri, 18 Jul 2008 15:45:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2ED983A68A8 for ; Fri, 18 Jul 2008 15:45:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyfr-000FzV-84 for v6ops-data@psg.com; Fri, 18 Jul 2008 22:43:39 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyfn-000Fyx-Fp for v6ops@ops.ietf.org; Fri, 18 Jul 2008 22:43:37 +0000 X-IronPort-AV: E=Sophos;i="4.31,212,1215388800"; d="scan'208";a="14755376" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2008 22:43:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6IMhYqY026641; Fri, 18 Jul 2008 18:43:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IMhYVm029811; Fri, 18 Jul 2008 22:43:34 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:43:34 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 18 Jul 2008 18:43:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAMK2xVkADNu6cA== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , Cc: "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 18 Jul 2008 22:43:34.0335 (UTC) FILETIME=[B5CFCCF0:01C8E927] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=379; t=1216421014; x=1217285014; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=20; bh=2TU1UOykDok2tHDRD7129r/3/Hs9JEB1BtnuhErSVKI=; b=Q/B40xeN6SoRkqpIGIwbO7/EEj/xkHjZRyDFKoq7gnKOc6iVPK1uoynLL3 oNTZSA3AqJJRT4k7BGw+rMMt9NOwuPR/WModb9k7Dvdg3Jx9G+9ywPDDKxer TsfwjkPX7z; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Draft dual-stack-lite looks alright to me. Good job. Since SNAT proposes using a softwire for the v4 in v6 tunnel, the CPE Router will add support for such a softwire. We already include a softwire for v6 in v4 tunnel in our -02 draft. Our draft will leave TBD for how does the CPE Router obtain dual-stack lite carrier-grade NAT device IPv6 address. Hemant From owner-v6ops@ops.ietf.org Fri Jul 18 17:17:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765B23A694C for ; Fri, 18 Jul 2008 17:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.303 X-Spam-Level: ** X-Spam-Status: No, score=2.303 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x77RYK-QLLIU for ; Fri, 18 Jul 2008 17:17:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08FDE3A680E for ; Fri, 18 Jul 2008 17:17:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK06E-0001fT-7k for v6ops-data@psg.com; Sat, 19 Jul 2008 00:14:58 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK069-0001et-Dr for v6ops@ops.ietf.org; Sat, 19 Jul 2008 00:14:55 +0000 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.57933608; Fri, 18 Jul 2008 20:14:33 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 20:14:33 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Sat, 19 Jul 2008 00:14:30 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 20:14:29 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , CC: "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAMK2xVkADNu6cAADgbw1 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Jul 2008 00:14:33.0217 (UTC) FILETIME=[6B8F1710:01C8E934] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/18/08 6:43 PM, "Hemant Singh (shemant)" wrote: > Alain, > > Draft dual-stack-lite looks alright to me. Good job. Thank you! > Since SNAT proposes using a softwire for the v4 in v6 tunnel, the CPE > Router will add support for such a softwire. We already include a > softwire for v6 in v4 tunnel in our -02 draft. Our draft will leave TBD > for how does the CPE Router obtain dual-stack lite carrier-grade NAT > device IPv6 address. 2 things. A) I'd like to use a simpler encap for dual-stack lite. No need for L2TP, just IPv4 in IPv6. B) About the tunnel end point discovery, you may simply say that the CPE must have the option to manually configure it and that a yet-to-be-defined DHCPv6 option might help. - Alain. From owner-v6ops@ops.ietf.org Fri Jul 18 19:04:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F3D3A684F for ; Fri, 18 Jul 2008 19:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnHDoSQoRUE8 for ; Fri, 18 Jul 2008 19:04:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 533D43A6826 for ; Fri, 18 Jul 2008 19:04:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK1kT-000Fem-46 for v6ops-data@psg.com; Sat, 19 Jul 2008 02:00:37 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK1kP-000FeR-7S for v6ops@ops.ietf.org; Sat, 19 Jul 2008 02:00:35 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id C31D8D00FA; Fri, 18 Jul 2008 16:00:27 -1000 (HST) Date: Fri, 18 Jul 2008 16:00:27 -1000 (HST) From: Antonio Querubin To: Mikael Abrahamsson cc: Alain Durand , "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 18 Jul 2008, Mikael Abrahamsson wrote: > Basically what I envision is that for single PC deployment we'd run tunneling > (6to4) or equivalent, and "customer has a proper CPE router" would be native > IPv6. Single PC is ok to have tunneled as there will be no multicast etc in > that service. For routed multicast IPv6 you really really want to have a CPE > router (at least that is my opinion). Why would a single PC be precluded from benefiting from multicast service if it's connection were tunneled? While there may not be a direct benefit to the end-user, the alternative means a content provider would have to plan to support more unicast clients. Even service providers benefit from reduced bandwidth in their core regardless of whether multicast customers at the edge are just single PCs. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Fri Jul 18 20:01:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A9D3A67D0 for ; Fri, 18 Jul 2008 20:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sejer2oeqfzt for ; Fri, 18 Jul 2008 20:01:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 585383A680E for ; Fri, 18 Jul 2008 20:01:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK2fT-000Ms3-2C for v6ops-data@psg.com; Sat, 19 Jul 2008 02:59:31 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK2fP-000MrM-2J for v6ops@ops.ietf.org; Sat, 19 Jul 2008 02:59:29 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 99DBCADADC; Sat, 19 Jul 2008 04:59:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8D0FFADAD9; Sat, 19 Jul 2008 04:59:25 +0200 (CEST) Date: Sat, 19 Jul 2008 04:59:25 +0200 (CEST) From: Mikael Abrahamsson To: Antonio Querubin cc: Alain Durand , "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 18 Jul 2008, Antonio Querubin wrote: > Why would a single PC be precluded from benefiting from multicast > service if it's connection were tunneled? While there may not be a > direct benefit to the end-user, the alternative means a content provider > would have to plan to support more unicast clients. Even service > providers benefit from reduced bandwidth in their core regardless of > whether multicast customers at the edge are just single PCs. If you want to deploy native IPv6 multicast in your network, that's your prerogative. I am not looking at limiting other peoples' choice, I just want ability to choose the functionality I feel is important for me (and for others in the end). Of course multicast over tunnels works, it's just that normally a tunnel is terminated fairly centrally in the network, and replicating 10-20 meg HDTV streams doesn't really scale in that topology. You want the replication to happen as close to the customer as possible (DSLAM, ethernet switch etc). I see TV as the main driver for multicast, and doing that over tunnels is just not feasable to me. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Jul 18 20:02:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A683A680E for ; Fri, 18 Jul 2008 20:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6a6OsCgUFbL for ; Fri, 18 Jul 2008 20:02:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D14DB3A67D0 for ; Fri, 18 Jul 2008 20:02:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK2hh-000N9s-Jv for v6ops-data@psg.com; Sat, 19 Jul 2008 03:01:49 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK2hd-000N9N-Vp for v6ops@ops.ietf.org; Sat, 19 Jul 2008 03:01:47 +0000 Received: by rv-out-0506.google.com with SMTP id b25so579183rvf.41 for ; Fri, 18 Jul 2008 20:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qN98NTgSWUoUBknBoAMkyOPo1dn6WrWQy7tz1IcildU=; b=HsXiujxr3me9crfQ1vA+pk2dS0bA+9D+rPNXykIY1V1T5slKp8jeBkpNkb4rVHc0GZ Bk0KYmq6OCVcI14uQY4/UYtTDD5VI2LoGQPvYvlo/wHvNeBv6RlB5k41TcgBzI0a+M/N o4UdBH//RGtAXYFNVvEnKtQ4uEbNCpFCx5tcw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=e19kDFCjZdo5iVSwDJRTqgfw15Sb/EdVA+/hLt7C/3Z6BumvC2ab6tAVyqByWcon9M b6/ZrzlLEFZQgEUls+Z+bMb2HG0GPl0jnldBb/7H/7pGaDyJl82USVF7aoN7AHMrZL5y SpipiW0uPKHYSX70rMdkH7kPD0ifvrm+v0DhU= Received: by 10.142.90.13 with SMTP id n13mr304375wfb.75.1216436505822; Fri, 18 Jul 2008 20:01:45 -0700 (PDT) Received: from ?10.1.1.4? ( [118.93.26.50]) by mx.google.com with ESMTPS id 9sm3286403wfc.6.2008.07.18.20.01.43 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 20:01:44 -0700 (PDT) Message-ID: <48815915.1020201@gmail.com> Date: Sat, 19 Jul 2008 15:01:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun CC: IPv6 Operations Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <484C9758.90904@gmail.com> <487F57AF.8000600@it.uc3m.es> In-Reply-To: <487F57AF.8000600@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-18 02:31, marcelo bagnulo braun wrote: ... > > same question that i have done to Dan, do you think servers can be > located in v6 land or only peers? (i.e. p2p applications with v4 and v6 > peers) Ideally both. If we place any restrictions they will cause a problem in 5, 10 or 15 years time. > >>> o R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4 >>> private addresses and use a NAT.(The acceptance of R2.2.1 is >>> subject to the acceptance of R2.2. >>> >> >> As noted above, that does *not* imply a separate NAT; it could be >> combined >> with the NAT64. >> >> > cahnges nat by nat function, ok? Yes, we'd better not over-design in the requirements stage. Brian From owner-v6ops@ops.ietf.org Fri Jul 18 20:28:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5453A6885 for ; Fri, 18 Jul 2008 20:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0BNEfZIe2JA for ; Fri, 18 Jul 2008 20:28:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67F8A3A680E for ; Fri, 18 Jul 2008 20:28:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK366-0000Pc-1i for v6ops-data@psg.com; Sat, 19 Jul 2008 03:27:02 +0000 Received: from [209.85.200.175] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK362-0000PA-8E for v6ops@ops.ietf.org; Sat, 19 Jul 2008 03:27:00 +0000 Received: by wf-out-1314.google.com with SMTP id 26so353580wfd.32 for ; Fri, 18 Jul 2008 20:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0e4HmckcsI/y6ay7P6Yx08YW5kOMGUtOQ612nuD6gN4=; b=TbZ5vrWEHuPGiXHA7tEG3BlWCuJkp4vFVbd6Bkwh20iWhUPNW2emj4+rnrN1FUlK24 c6qTD4t6tdq8zFCT8mtsK/1WPhFHfNDkfafz4z3Ggdo+qQlYaDbGzXxjI9/DkiqbMtFV Q1MFpmmzaesjdrzYvQxv9SfYMiTkdhaZa3fms= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=wXLY7OAIXlhZ6MUnAb6n3SWlbRGaEic+HOLorqBEoorzoe4fyv6jugzUgOX3YAz09V ubmKmiz2XkR/adb6qfOKTCa1T5uterrobx3sgIdzHAB0dNqbVdHhiOBAyMFvis48TQv6 Xjrhq4+fgYTxRO0+1p30CoNoKVPMfn2UARayM= Received: by 10.143.37.20 with SMTP id p20mr302577wfj.236.1216438017988; Fri, 18 Jul 2008 20:26:57 -0700 (PDT) Received: from ?10.1.1.4? ( [118.93.26.50]) by mx.google.com with ESMTPS id 28sm3323245wfg.15.2008.07.18.20.26.55 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 20:26:57 -0700 (PDT) Message-ID: <48815EFD.5090308@gmail.com> Date: Sat, 19 Jul 2008 15:26:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ed Jankiewicz CC: IPv6 Operations Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 References: <4880ED7A.20007@sri.com> In-Reply-To: <4880ED7A.20007@sri.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ed, On 2008-07-19 07:22, Ed Jankiewicz wrote: > in addition to some editorial comments I sent to Marcelo, I have a few > substantive comments (some admittedly half-baked) and discussion points > to raise on the draft. I'm assuming there will be discussion at IETF 72? > > 1. transition versus coexistence: recognizing that the period of > coexistence is likely to be longer, I would rather see consistent use of > the term coexistence rather than transition throughout the document, > e.g. coexistence scenarios, coexistence tools, etc. Yes. As some of us having been saying for *many* years, in my case, since RFC 1671. > > 2. add a sentence in front of the Problem Statement to explicitly state > this motivation, e.g. "Settled opinion on the transition from an > IPv4-dominant network to an IPv6-dominant network was that the period of > coexistence would be brief, and could be accommodated by dual-stack and > tunneling. I deny that. I personally have always expected many years of coexistence, and I don't know where this "settled opinion" was to be found. > Operationally, we now expect..." > > 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF > strongly prefers and recommends [dual stack] as the operational matters > are simplest" begs for a citation. RFC 4213 says dual stack is the most > straightforward but does not include language recommending or preferring > this solution. That doesn't belong in that document. You're possibly correct that no IETF document formally states the strong preference for dual stack as the coexistence mechanism, but it's the implicit assumption throughout pretty much everything NGTRANS and V6OPS have done. I don't think we should rewrite history, and dual stack is still the best way we know (for reasons stated in RFC 1671, which of course has absolutely no authority whatever). > Also the impetus of this draft is that dual stack solves > only the simplest part of the problem, and becomes very problematic when > IPv4 addresses really get scarce (approaching rather than reaching > exhaustion). Some have already stated (Alain Durand I recall saying > something like) "a plan that requires all new end-nodes to be dual-stack > and to have global IPv4 addresses is a non-starter." Correct, but that argues for more v4/v4 NAT, not against dual stack. > Also an emphasis > on dual stack creates a "must carry" situation where the core network > continues to route IPv4 indefinitely. While we say in para 2.2 that > turning off IPv4 will be a business decision, the ISP can't make that > choice without alienating customers that rely on dual stack. I can > still plug in a 50 year old rotary dial phone and expect the local telco > (in the USA at least) to make it work, even though DTMF has been the > dominant method for nearly that long. Bingo. I'm sure ISPs will still be routing IPv4 for 15 years; not so clear about 50. > > 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF > recommends tunnels rather than dual NAT - that also would need a > citation, unless this document is making the statement for the first > time. Also, I believe if the two NATs know they are in a reflexive > relationship, they can avoid at least some of the general NAT problems - > i.e. they should not attempt to translate addresses in application data. If you mean by "reflexive" that the NAT mapping is reversed before delivery, sure, that's invisible to the upper layer and is isomorphic with a tunnel. But do such devices exist? The IETF definitely recommends avoiding irreversible NAT when possible, and therefore the statement that tunnels are preferred is definitely true. Brian From owner-v6ops@ops.ietf.org Fri Jul 18 20:43:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CEC3A6822 for ; Fri, 18 Jul 2008 20:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCk0U5w6iQgC for ; Fri, 18 Jul 2008 20:43:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2DD13A684F for ; Fri, 18 Jul 2008 20:43:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3L7-0002XS-NC for v6ops-data@psg.com; Sat, 19 Jul 2008 03:42:33 +0000 Received: from [209.85.200.169] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3L3-0002XA-UF for v6ops@ops.ietf.org; Sat, 19 Jul 2008 03:42:31 +0000 Received: by wf-out-1314.google.com with SMTP id 26so356030wfd.32 for ; Fri, 18 Jul 2008 20:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uN27Fm/AypkoOWO2pv32Usg2lhYFmfLLzPg4gJsYb4M=; b=mbrpYlO2ohejX1ja4Wn9QSNw8ZZDOIHMqMa/Fo/NIzj1a13rD+LUiWSTW51i6Whc+1 aeJLaMmb5DW3tqLX9y+mJFRBeAoVRZU/P4l7g6+uDmOqS49+H/YoS25P9QuZ/ageNM0c 1DRhJ1B6exfnmxLVhsz4t2NVVfgFPWglq1t6E= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=COCvYGx/TgD9190WYZJw7EurFa7pZ+HCy0j2uwpo+Vm9qOXduRcsai9Nvybpm67RVs OtK5UggcyYadWzJJ48CV1812OzIVNPjPm/ILIYtkWNrpcv0acEn7TboMLBnRlmWyYp6z DYNEGHJpyJ/pqu0SKrrn8+AmNF2ojRcxuFxRU= Received: by 10.142.222.21 with SMTP id u21mr305082wfg.318.1216438949084; Fri, 18 Jul 2008 20:42:29 -0700 (PDT) Received: from ?10.1.1.4? ( [118.93.26.50]) by mx.google.com with ESMTPS id 30sm3037017wfa.10.2008.07.18.20.42.25 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 20:42:28 -0700 (PDT) Message-ID: <4881629F.60703@gmail.com> Date: Sat, 19 Jul 2008 15:42:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alain Durand CC: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-19 04:25, Alain Durand wrote: ... > 2) ULA > > Supporting both ULA & GUA at the same time is also a source of complexity > and confusion. The key problem I see is with external referrals in > multi-party communications where some of the hosts are inside, and some are > outside. Mixing ULA & GUA can have complex consequences, and again generates > service call. > > Also, if I read the text correctly, if the WAN interface gets configured > first, no ULA are generated. Which leads to confusing situation depending on > whether the customer turns its modem on before or after its CPE. > > I would rather like the text to recommend to only use ULA when nothing else > is available and immediately renumber to GUA when those are acquired. IMHO that is only acceptable if there MUST be a configurable option to support a ULA (generated once per factory-reset) in parallel with a GUA, if that's what the user wants. I think that is needed for scenarios where people want addresses for devices that are guaranteed never to reply to external packets. Brian From owner-v6ops@ops.ietf.org Fri Jul 18 20:57:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92773A68CD for ; Fri, 18 Jul 2008 20:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF9Y1BISbJSW for ; Fri, 18 Jul 2008 20:57:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C919A3A684F for ; Fri, 18 Jul 2008 20:57:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3Yu-0004N2-I3 for v6ops-data@psg.com; Sat, 19 Jul 2008 03:56:48 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3Yq-0004Mj-RX for v6ops@ops.ietf.org; Sat, 19 Jul 2008 03:56:46 +0000 Received: (qmail 18642 invoked by uid 509); 19 Jul 2008 03:56:44 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.3/7743. spamassassin: 3.2.5. Clear:RC:1(211.28.128.246):. Processed in 0.043111 secs); 19 Jul 2008 03:56:44 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Fri, 18 Jul 2008 22:56:43 -0500 Cc: Alain Durand , "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Message-Id: <06219B60-AB50-4E91-AF8A-747E728C3EB8@thetiger.com> From: David Miles To: Mikael Abrahamsson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Sat, 19 Jul 2008 13:56:38 +1000 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I might add a view on this too: - Having a global prefix on the WAN interface means a customer is represented by exactly two different IPv6 prefixes (in addition to their /32 in IPv4) from disparate address space. I am mindful ISP routers must perform accounting, rate-limiting/QoS, anti-spoofing and ACL on all these addresses. An extra prefix per subscriber is going to consume additional resources at a time we are already trying to support two prefixes (an IPv4 and IPv6 prefix). - Increased complexity in the ISP router for IP sessions. For example, a DHCPv6-PD uses a rebind message to reconfirm the prefix (state machine 1) whereas an IA_NA of the WAN interface uses a Confirm message (state machine 2). Two different messages, two different state machines, and more places things could go wrong. - It requires the DR/BNG/CMTS to advertise the WAN shared prefix in its RA for on-link determination. As RA go to all subscribers (in a common VLAN) you have a P2P consideration where subscribers will initiate ND (on multipoint interfaces) for one-another on their WAN interface. The router must now perform ND proxy for the shared prefix. - An advantage of the unnumbered model is that we may not need to configure the ISP router with any link information in advance. With a numbered model one would normally have to create an IP interface on the ISP router and configure RA PIO for the WAN prefix. The disadvantages I see are: - Operational troubleshooting. If the WAN interface did respond to ICMP echo requests you can test the subscriber state from any Internet host. - Traceroutes. If the WAN interface was link-local, a traceroute would indicate the loopback or LAN interface on the CPE as opposed to the WAN interface. - If a loopback interface is used, one may need to devote an entire / 64 to it - the alternative is to use an always-up LAN interface (ie bridge0 interface). -David On 19/07/2008, at 7:34 AM, Mikael Abrahamsson wrote: > On Fri, 18 Jul 2008, Alain Durand wrote: > >> Thank you for the clarification, I now understand better your goal, >> but what is the rationale for doing that? > > I stated this in the beginning of the discussion, but here goes again: > > I want to protect ISP equipment from outsid/Internet DDOS attacks. I > foresee proliferation of basement/FTTC L3 switches (ASIC forwarding, > small TCAM, small CPU) with ethernet/vdsl2 PHYs, and I want to be > able to rate-limit traffic coming in from the internet to these > devices (also my core). > > Therefore ISP equipment needs to be in separate IP space from > customer equipment IP space. This also applies to SOHO market. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > From owner-v6ops@ops.ietf.org Fri Jul 18 21:01:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C153A68CD for ; Fri, 18 Jul 2008 21:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.305 X-Spam-Level: ** X-Spam-Status: No, score=2.305 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w68ns-Ah3RCp for ; Fri, 18 Jul 2008 21:01:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81E703A67B1 for ; Fri, 18 Jul 2008 21:01:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3d3-0004oU-2Z for v6ops-data@psg.com; Sat, 19 Jul 2008 04:01:05 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3cz-0004oA-Fu for v6ops@ops.ietf.org; Sat, 19 Jul 2008 04:01:03 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8590957; Sat, 19 Jul 2008 00:00:27 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jul 2008 00:00:27 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Sat, 19 Jul 2008 03:53:22 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 23:53:20 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: Brian E Carpenter CC: "Hemant Singh (shemant)" , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpUX2gLik3YsKjQ6ms+cph8Bxp+QAAX4Yq In-Reply-To: <4881629F.60703@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Jul 2008 04:00:27.0331 (UTC) FILETIME=[FA70C130:01C8E953] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/18/08 11:42 PM, "Brian E Carpenter" wrote: >> I would rather like the text to recommend to only use ULA when nothing else >> is available and immediately renumber to GUA when those are acquired. > > IMHO that is only acceptable if there MUST be a configurable option > to support a ULA (generated once per factory-reset) in parallel with > a GUA, if that's what the user wants. I think that is needed for scenarios > where people want addresses for devices that are guaranteed never > to reply to external packets. I'd agree to this if, by default, parallel ULA support is off. - Alain. From owner-v6ops@ops.ietf.org Sat Jul 19 07:34:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBE73A68E5 for ; Sat, 19 Jul 2008 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu7+eBu4uj7o for ; Sat, 19 Jul 2008 07:34:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A5E93A6881 for ; Sat, 19 Jul 2008 07:34:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDSX-000Eup-KG for v6ops-data@psg.com; Sat, 19 Jul 2008 14:30:53 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDSR-000Eu6-LK for v6ops@ops.ietf.org; Sat, 19 Jul 2008 14:30:50 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id 311237C8197;Sat, 19 Jul 2008 16:30:44 +0200 (CEST) Message-ID: <4881FA93.7090109@it.uc3m.es> Date: Sat, 19 Jul 2008 16:30:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dan Wing CC: 'IPv6 Operations' , 'Fred Baker' , teemu.savolainen@nokia.com, 'Brian E Carpenter' , Alain_Durand@cable.comcast.com, =?ISO-8859-1?Q?=27R=E9mi_Despr=E9s=27?=, 'Jari Arkko' , 'Philip Matthews' Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <00ba01c8e827$32b15470$c2f0200a@cisco.com> In-Reply-To: <00ba01c8e827$32b15470$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.4482 TC:1F TRN:93 TV:5.5.1026(16040.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Dan, Dan Wing escribió: > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Thursday, July 17, 2008 7:49 AM >> To: 'IPv6 Operations'; Fred Baker; Dan Wing; >> teemu.savolainen@nokia.com; Brian E Carpenter; >> Alain_Durand@cable.comcast.com; Rémi Després; Jari Arkko; >> Philip Matthews >> Subject: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt >> >> Hi, >> >> I am trying to extract the actual proposed changes for the draft >> >> ------------------------------------------ >> - 1) Additional scenario needed? >> ------------------------------------------ >> >> It seems that there is the potential need for a new scenario. >> It is the case described by Dan and by Teemu about a dual stack host, >> located in a v6 network, and that needs to run a v4 only >> application. In >> order to do that, it needs to obtain a public IPv4 transport >> address and >> also discover a tunnel endpoint, so it can tunnel v4 packets >> in v6 till >> the tunnel endpoint and use the IPv4 transport address it has >> obtained >> to establish a communication with v4 land. >> >> So essentially this is tunnel scenario, but rather than being >> obtaining >> a full IPv4 address to use, the host only obtains a transport address >> (which is public) >> >> I understand that this is what Dan and Teemu are proposing, >> is that correct? >> > > I don't have a proposal; I just want to see if folks are prepared > to have subscribers lose existing v4 functionality for v4 hosts > accessing the v4 Internet (ALGs, NAT-PMP, and UPnP). > > That is, I am trying to imagine a Behave or Softwire proposal > this is the only thing from your perspective that somehow confuses me I think that there are several different problems and different scenarios and that these should be addressed with potential different tools I mean, it is the same for the IPv4 case, one thing is a NAT box, which solves some problem and a different thing is IPnP protocol that addresses other issues. Of course they complement each other or one is build on top of the other, but they were conceived differently So, so far, the goal is to identify different useful scenarios and then try to find requirements for those and then solutions We had initially identified two sceanrios, one the v4 - v6- v4 case and another one that was the IPv6 only host communicating to the IPv4 only only host Now, there is another scenario, which is the IPv4 only app running on an IPv6 only node that needs to communicate to the v4 peers. To me what makes sense is to find solutions for these different problems I guess that what i am trying to ask you (in a very convoluted way) is whether you think we should mix all these scenarios and address them all toghether or do you think that hiving different scenarions, with different tools and then figuring out potential synergies (i.e. my understanding of the current approach) makes sense If you think this makes sense, then we should include the 3 scenarios in this draft BTW, One may also think that this draft is kind of weird, in the sense that it identifies the 3 scenarios mentioned above and then only defines the requirements for one of them, i.e. the one requiring translation. From a document perspective, we can do 3 things, i guess. Either we keep it as it is, even if it may seems somehow strange. Or we split in two documents, one as the overview of the scenarios and another one with the requirements for translation, (and eventually having two more documents with requirements for the other scenarios, or we add to this document the requiremetns for the other scenarios) I personally preffer the first or the second one, since i would like to wrap up the transalion requireemtns asap. > that I would personally be willing to buy from my ISP, could > recommend to my mother-in-law, and could recommend to my > nephew. I don't have an XBox, so I don't personally care but I > am aware of how XBox does UPnP IGD. My Nephew has an XBox and > uses BitTorrent a lot more than I do. If a BitTorrent client > cannot get v4 mapped, it will be a 'leech' and have horrid > download speeds. (Yes, I know most > BitTorrent clients support v6, but I don't know how well- > exercised that code is and I don't know how many v6-capable > BitTorrent peers there are to upload to [so that download > speeds are fast]). BitTorrent seems an a valuable use > case to consider. > > The two biggest BitTorrent clients (uTorrent and Vuze > (Azureus)) support UPnP (and NAT-PMP). So including > support for them to do UPnP -- somehow -- would allow them > to function well. > > > We could also conciously decide to not bother, and for > those subscribers that need incoming v4 connections or > need v4-aware ALGs, they will have to stick with a "real" > v4 connection (like today). Other subscribers can use > our transition scheme. I just worry that reduces the > usefulnes of our transition scheme. The question is if > leaving out UPnP IGD/NAT-PMP/v4 ALGs reduces the > usefulness 'too much'. > > >> So, if this is the case, how can we fit this into the document? >> >> As i see it, the document has two parts, clearly differentiated: >> A first part that covers an overview of the different aspects of >> transition and then a part that described the specific >> requirements of >> new translation mechanism >> >> I think that it makes sense to me to include a description of >> this case >> in the overview section. >> >> >> In order to do that, we need first to ackwoledge the >> exsitance of a new >> scenarion in section >> >> 2.1. Transition scenarios >> >> currently, it includes 6 scenarios: >> >> There are six obvious transition scenarios: >> >> o IPv4 system connecting to an IPv4 system across an IPv4 network, >> o An IPv6 system connecting to an IPv6 system across an IPv6 >> network, >> o an IPv4 system connecting to an IPv4 system across an IPv6 >> network, >> o an IPv6 system connecting to an IPv6 system across an IPv4 >> network, >> o an IPv4 system connecting to an IPv6 system, or >> >> >> o an IPv6 system connecting to an IPv4 system. >> >> I understand that we need to include one more: >> >> o a dual stack system connected to a IPv6 domain that is >> connecting to an IPv4 system. >> >> >> In addition, we need to include an additional text in section >> >> 2.1.2. Transition scenarios that do not require translation >> >> something along these lines: >> >> Another scenario that does not involves translation is the case >> where a dual stack node is connected to an IPv6-only domain >> and it is communicating with a IPv4-only node as depicted in Figure 2. >> >> >> ,-----. ,-----. >> ,' `. ,' `. >> / \ / \ >> / IPv6-only \ / IPv4-only \ >> / Domain +-----------+ Domain \ >> ; | Tunnel | : >> | | endpoint | | >> : +-----+ +-----------+ ; >> \ |Dual | / \ +----+ / >> \ |Stack| / \ |IPv4| / >> \ |Host | / \ |Host| / >> `.+-----+,' `. +----+,' >> '-----' '-----' >> >> >> >> >> >> In this case, the dual stack host needs to establish a IPv4 in IPv6 >> tunnel to the tunnel endpoint. In addition to that, the dual stack >> needs to obtain a IPv4 address that is valid in the IPv4-only domain. >> The simplest option is for the dual stack to obtain an IPv4 public >> address. However, this may not be possible due to the shortage of >> IPv4 public addresses. The other option is to use an IPv4 >> private address >> (and potentially in conjunction with IPv4 NAT). The other option >> is for the dual stack to obtain a public IPv4 transport address. >> In all the cases, the acquisition of the address can be >> performed dynamically. >> >> >> would this address your inputs? >> > > Looks good to me. > > ok, i will add this >> ---------------------------------------- >> -2) Scalability >> ---------------------------------------- >> >> Teemu proposed to include: >> >> 2.2. Requirements for the overall transition strategy >> >> 8. Transition architectures should be scalable for large number of >> hosts and high data speeds. >> >> 4.2. Important things that SHOULD be supported >> >> I9: Scalability >> >> The translation mechanism SHOULD support very large number of >> hosts and >> high data speeds with reasonable infrastructure requirements >> considering >> equipment available at the transition timeframe. >> >> I think this makes sense, and i have a hard time finding >> someone who don't agrees with this >> so i am planning >> to include them >> > > I don't know how we would determine if we met the requirement, > though. :-) right (it is like the usual incremental deployment requriement , it means completely different things to different people) Well, i think Yakov defined scalability as the growth in the resources needed is lees than linear with the number of users, or something in this lines So, in this case, we could try to apply this definition here, but i am not sure we want to go that far? > Most any of these could be implemented in the aggregation > router (the first L3 hop away from the subscriber), consuming > 1 MIPS per subscriber and any of these could be implemented in > a multi-million dollar server placed in Denver, Colorado (the > center of the US) also consuming 1 MIPS per subscriber. Which > solution meets that requirement better? Or are they similar > because they're both 1 MIPS per subscriber, and this is really > a requirement around state? Or the need for layer 7 awareness > in a protocol-sniffing ALG (which I agree does require more > processing cycles than just NATing and forwarding packets). > > Or is this scalability question really about operational > expense and operational complexity (fewer boxes with less state > inside of them is better than many boxes with a lot of state > inside of them)? > > imho, people usually tries to take scalabilty anytime they look into a solution, so it is alsways present. Inlcuding it simply makes it explicit. For instance, in the last example you mention, when a solution requires more state, it ususally is more complex and people will preffer the other solution (even if we include this req or not) I am perfeclty ok leaving this out, but as i say, i think it is common sense that people will have this in mind OTOH, it is true that may not be so straight forward its application in the different scenarios. >> -------------------------------------------- >> -3) discovery >> --------------------------------------------- >> >> Teemu also porposed: >> >> 2.2. Requirements for the overall transition strategy >> >> 9. Availability of transition solutions on an access network >> should be >> quickly discoverable. >> >> 4.2. Important things that SHOULD be supported >> >> >> I10: Discovery >> >> The translation mechanism SHOULD be quickly discoverable, >> preferably in >> one RTT, to help moving hosts better assess capabilities of available >> access networks and to provide good user experience. >> >> I have a hard time understanding this one. >> I mean R1 states: >> >> R1: Changes in the hosts >> >> The translation mechanism MUST NOT require changes in the v4-only >> nodes to support the Basic requirements described in this section, >> unless explicitly stated in the particular requirement. The >> translation mechanism MAY require changes to v6-only nodes. >> >> So if we don't want changes in the host, how can a host have >> the discovery mechanisms? I mean, >> i think this assuming some other form of solution that is not >> based on translation. >> >> I am not doing anything about this at this point >> > > Was Teemu perhaps considering a situation where a v6 box is > doing the translation from a v4-host to the ISP's v6 network? > After all, such a v6 box will look like a v6 host to the > v6 network: > > [v4 host] --- [v4/v6 Interworking] ----- [ ISP box ] --- v4 Internet > [ CPE Device ] > > It would be useful for that v6 box to automatically sense whatever > it needs to know from the ISP's network (for example, with IVI, > it would need to know the IVI prefix). > > but this is not the translation scenario, but a tunnel scenario, right? So we are not defining requiremetns for this sceanrio (at least not in the current document) If we decide we should define requirements for these, i am for including this, but for the requrieemtns for trasnaltion, i think this doesn't apply and should not be included, agree? > >> ------------------------------------------ >> -4) no translation >> ------------------------------------------ >> >> Teemu also porposed: >> >> >> 4.3. Important things that MAY be supported >> >> M1: No NATs or ALGs >> >> The translation mechanism MAY avoid use of IPv4 NATs and thus >> also avoid >> need for ALGs. >> >> >> this clearly seems contradictory in a requirements fro >> translation (no translation) >> >> I understand that translation should be avoided and we >> already say this in the document >> i.e. that dual stack is preferred and then tunnel and finally >> if there is no other option >> translation. I don't think that this should go in the >> requirements section cause seems like >> and oxymoron to me >> > > > Somewhat related to this, I would like to consider one of > my worries with ALGs: getting bugs fixed in a massive > centralized box. > > My story: About a month > ago, ftp.ietf.org changed its behavior that broke my FTP > client (my FTP client's code was last modified in 1998). > This had nothing to do with an ALG -- I use PASV and > have my FTP ALG in my NAT turned off -- but rather just > a change in behavior to a very long-established protocol. > It is reasonable to expect that this happens elsewhere, > not just with the IETF's FTP servers, and not just with > FTP. > > If an ISP has to receive trouble-tickets from users > for the ISP's broken ALG ("it doesn't work with such-and- > such FTP client", or "it doesn't work with such-and-such > FTP server"), or has to receive trouble-tickets to add new > application support to their NAT ("why don't you support > H.323, I need it for NetMeeting and can't support my > business clients!"), it can be a long, drawn-out process > between the vendor, the ISP, and the subscribers. > > One way to reduce this problem is to leave this function > where it is today: at the subscriber premise. If the > subscriber needs a bugfix, or needs to tweak something, > or needs an ALG that is capable of helping them with > their fancy new protocol XYZZY, they can get a NAT (or > build a Linux NAT) that supports XYZZY -- without > involving the ISP. > > This is one of my purposes for asking if people care about > ALGs, UPnP, and NAT-PMP -- and why APBP could keep this > complexity to the subscriber edge (where it is now). > > I think i understnad your point, not sure i can transalte it into a requirement for the translation case.... Do you think that we should split the requirement one for CPEs NATs and another one for carrier grade nats and allow ALGs in CPE nats and avoid them in carrier grade nats? would that make sense to you? regards, marcelo > >> ------------------------------------------ >> -5) MIP6 support >> ------------------------------------------ >> >> George and Jaru commented that I5: MIPv6 support >> should go away >> I am removing that >> >> ------------------------------------------ >> -6) Symbian >> ------------------------------------------ >> added symbian to the OS in market timing >> consdierations >> >> regards, marcelo >> > > > Thanks! > -d > > > From owner-v6ops@ops.ietf.org Sat Jul 19 07:39:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3743A6969 for ; Sat, 19 Jul 2008 07:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWeY3Oa8X2CJ for ; Sat, 19 Jul 2008 07:38:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 487FE3A68E5 for ; Sat, 19 Jul 2008 07:38:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDa7-000GB5-MW for v6ops-data@psg.com; Sat, 19 Jul 2008 14:38:43 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDa3-000GAP-BU for v6ops@ops.ietf.org; Sat, 19 Jul 2008 14:38:41 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id BD34949019B;Sat, 19 Jul 2008 16:38:36 +0200 (CEST) Message-ID: <4881FC6C.2030109@it.uc3m.es> Date: Sat, 19 Jul 2008 16:38:36 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <4880763B.4000902@free.fr> In-Reply-To: <4880763B.4000902@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.5445 TC:1F TRN:58 TV:5.5.1026(16040.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Després escribió: > marcelo bagnulo braun - Le 7/17/08 4:48 PM : > >> >> 2.1. Transition scenarios >> >> currently, it includes 6 scenarios: >> >> There are six obvious transition scenarios: >> >> o IPv4 system connecting to an IPv4 system across an IPv4 network, >> o An IPv6 system connecting to an IPv6 system across an IPv6 >> network, >> o an IPv4 system connecting to an IPv4 system across an IPv6 >> network, >> o an IPv6 system connecting to an IPv6 system across an IPv4 >> network, >> o an IPv4 system connecting to an IPv6 system, or >> >> >> o an IPv6 system connecting to an IPv4 system. >> >> I understand that we need to include one more: >> >> o a dual stack system connected to a IPv6 domain that is >> connecting to an IPv4 system. > > Approved. > gee, thanks for approving it >> In addition, we need to include an additional text in section >> >> 2.1.2. Transition scenarios that do not require translation >> >> something along these lines: >> >> Another scenario that does not involves translation is the case >> where a dual stack node is connected to an IPv6-only domain >> and it is communicating with a IPv4-only node as depicted in Figure 2. >> >> >> ,-----. ,-----. >> ,' `. ,' `. >> / \ / \ >> / IPv6-only \ / IPv4-only \ >> / Domain +-----------+ Domain \ >> ; | Tunnel | : >> | | endpoint | | >> : +-----+ +-----------+ ; >> \ |Dual | / \ +----+ / >> \ |Stack| / \ |IPv4| / >> \ |Host | / \ |Host| / >> `.+-----+,' `. +----+,' >> '-----' '-----' >> >> >> >> >> >> In this case, the dual stack host needs to establish a IPv4 in IPv6 >> tunnel to the tunnel endpoint. In addition to that, the dual stack >> needs to obtain a IPv4 address that is valid in the IPv4-only domain. >> The simplest option is for the dual stack to obtain an IPv4 public >> address. However, this may not be possible due to the shortage of >> IPv4 public addresses. The other option is to use an IPv4 private >> address >> (and potentially in conjunction with IPv4 NAT). The other option >> is for the dual stack to obtain a public IPv4 transport address. >> In all the cases, the acquisition of the address can be performed >> dynamically. > > After "... shortage of IPv4 public addresses." you could add: > "The other option is to obtain an IPv4 public address with a limited > range of usable ports." > this is already implicity in the IPv4 transport address part > >> >> Teemu proposed to include: >> >> 2.2. Requirements for the overall transition strategy >> >> 8. Transition architectures should be scalable for large number of >> hosts and high data speeds. >> >> 4.2. Important things that SHOULD be supported >> >> I9: Scalability >> >> The translation mechanism SHOULD support very large number of hosts and >> high data speeds with reasonable infrastructure requirements considering >> equipment available at the transition timeframe. >> >> I think this makes sense, and i have a hard time finding someone who >> don't agrees with this >> so i am planning >> to include them >> >> -------------------------------------------- >> -3) discovery >> --------------------------------------------- >> >> Teemu also porposed: >> >> 2.2. Requirements for the overall transition strategy >> >> 9. Availability of transition solutions on an access network should be >> quickly discoverable. >> >> 4.2. Important things that SHOULD be supported >> >> >> I10: Discovery >> >> The translation mechanism SHOULD be quickly discoverable, preferably in >> one RTT, to help moving hosts better assess capabilities of available >> access networks and to provide good user experience. >> >> I have a hard time understanding this one. >> I mean R1 states: >> >> R1: Changes in the hosts >> >> The translation mechanism MUST NOT require changes in the v4-only >> nodes to support the Basic requirements described in this section, >> unless explicitly stated in the particular requirement. The >> translation mechanism MAY require changes to v6-only nodes. >> >> So if we don't want changes in the host, how can a host have the >> discovery mechanisms? I mean, i think this assuming some other form >> of solution that is not based on translation. >> >> I am not doing anything about this at this point > > > Proposal (additions between "s): > The translation mechanism SHOULD be quickly discoverable, preferably > in one RTT, to help moving "dual stack" hosts "or router CPEs" better > assess capabilities of available access networks and to provide good > user experience. > > again, this doesn't apply to the translation case, but the second tunnel case that we are now including, so this should be included in wherever we decide to make a list fo the requirements for these other scenarios >> ------------------------------------------ >> -4) no translation >> ------------------------------------------ >> >> Teemu also porposed: >> >> >> 4.3. Important things that MAY be supported >> >> M1: No NATs or ALGs >> The translation mechanism MAY avoid use of IPv4 NATs and thus also avoid >> need for ALGs. >> >> this clearly seems contradictory in a requirements fro translation >> (no translation) >> >> I understand that translation should be avoided and we already say >> this in the document >> i.e. that dual stack is preferred and then tunnel and finally if >> there is no other option >> translation. I don't think that this should go in the requirements >> section cause seems like >> and oxymoron to me > > Proposal: > > M1: No NATs or ALGs "between dual stack and IPv4 hosts" > > The translation mechanism MAY avoid use of IPv4 NATs and thus also > avoid the need for ALGs "(translation being then limited, for example, > to encapsulation-decapsulation). > again, this doesn't belong to the translation case but to the other tunnel case regards, marcelo > > > Regards. > > Rémi > From owner-v6ops@ops.ietf.org Sat Jul 19 07:45:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D527B3A6979 for ; Sat, 19 Jul 2008 07:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWaN16Q3DN52 for ; Sat, 19 Jul 2008 07:45:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E87423A69A3 for ; Sat, 19 Jul 2008 07:45:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDgS-000HFK-Kr for v6ops-data@psg.com; Sat, 19 Jul 2008 14:45:16 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKDgO-000HA2-8i for v6ops@ops.ietf.org; Sat, 19 Jul 2008 14:45:14 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id A097D490189;Sat, 19 Jul 2008 16:45:09 +0200 (CEST) Message-ID: <4881FDF5.3040204@it.uc3m.es> Date: Sat, 19 Jul 2008 16:45:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <20080513233001.301873A6854@core3.amsl.com> <484C9758.90904@gmail.com> <487F57AF.8000600@it.uc3m.es> <48815915.1020201@gmail.com> In-Reply-To: <48815915.1020201@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-17.4225 TC:1F TRN:29 TV:5.5.1026(16040.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian E Carpenter escribiĂ³: > On 2008-07-18 02:31, marcelo bagnulo braun wrote: > ... > >> same question that i have done to Dan, do you think servers can be >> located in v6 land or only peers? (i.e. p2p applications with v4 and v6 >> peers) >> > > Ideally both. If we place any restrictions they will cause a problem > in 5, 10 or 15 years time. > this seems to be a clear case of no consensus, i am afraid, and i am not sure what to do about this i will raise the question in the meeting and try to figure this one out there > >>>> o R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4 >>>> private addresses and use a NAT.(The acceptance of R2.2.1 is >>>> subject to the acceptance of R2.2. >>>> >>>> >>> As noted above, that does *not* imply a separate NAT; it could be >>> combined >>> with the NAT64. >>> >>> >>> >> cahnges nat by nat function, ok? >> > > Yes, we'd better not over-design in the requirements stage. > > will do regards, marcelo > Brian > > > From owner-v6ops@ops.ietf.org Sat Jul 19 08:31:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983B23A691A for ; Sat, 19 Jul 2008 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2yRMzZA9QT0 for ; Sat, 19 Jul 2008 08:31:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E09A3A680D for ; Sat, 19 Jul 2008 08:31:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKEO8-000OKm-RA for v6ops-data@psg.com; Sat, 19 Jul 2008 15:30:24 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKEO4-000OK1-C3 for v6ops@ops.ietf.org; Sat, 19 Jul 2008 15:30:22 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id 0024A7C8C62;Sat, 19 Jul 2008 17:30:16 +0200 (CEST) Message-ID: <48820888.8070901@it.uc3m.es> Date: Sat, 19 Jul 2008 17:30:16 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alain Durand CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.6371 TC:1F TRN:33 TV:5.5.1026(16042.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand escribió: > > On 7/17/08 12:00 PM, "marcelo bagnulo braun" wrote: > > >>> No, you need a v4 stack, not a v4 address. That is the whole point of the >>> dual-stack lite model. >>> >>> >> i guess i will need to read the draft then cause i fail to understand >> how useful could a stack wihtout an IP address could be >> > > When a dual-stack lite host (dual stack capable, v6-only provisioned) wants > to send a v4 packet, it can simply put any v4 dummy address as source > address before shipping the packet through the v6 tunnel to the CGN. Even > 0.0.0.1 will work as it will be replaced later by the CGN. The mapping will > be disambiguified by the tunnel ID (v6 src address). > i see clever, indeed I have read the draft (at least parts of it) You state that: o Dual-stack lite does not require any hack to the DNS. In other words, there is no need to synthesize fake AAAA records to represent IPv4 addresses. This make DNSsec works more reliably. o Because of the DNS ALG hack, NAT-PT places restriction on the topology, in most cases requiring that all exiting traffic go through a single point of contention. Because there is no DNS ALG with dual-stack lite and because each dual-stack lite device can be directed independently to a different dual-stack lite NAT, the dual-stack lite architecture can scale better. While this was true for nat-pt and to some degree for nat64, if we adopt Dave's suggestion of using the v4 mapped prefixes, this all go away i think cause there is no relationship whatdoever between the dns64 and the nat64 As long as you recieve a AAAA RR from somehwere, the nat64 can be placed in a completely different part of the topology and the actual data packets do not need to use the same path than the DNS query/repsonse did So, i think this is no longer true Regards, marcelo > - Alain. > > > > > From owner-v6ops@ops.ietf.org Sat Jul 19 11:00:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33073A6969 for ; Sat, 19 Jul 2008 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_61=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP9lVplO7mNb for ; Sat, 19 Jul 2008 11:00:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 691733A68E5 for ; Sat, 19 Jul 2008 11:00:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKGfu-000KZy-OB for v6ops-data@psg.com; Sat, 19 Jul 2008 17:56:54 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKGfq-000KZC-2T for v6ops@ops.ietf.org; Sat, 19 Jul 2008 17:56:52 +0000 Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp02.uc3m.es (Postfix) with ESMTP id A926241F572;Sat, 19 Jul 2008 19:56:45 +0200 (CEST) Message-ID: <48822ADD.4010409@it.uc3m.es> Date: Sat, 19 Jul 2008 19:56:45 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ed Jankiewicz CC: IPv6 Operations Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 References: <4880ED7A.20007@sri.com> In-Reply-To: <4880ED7A.20007@sri.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.1715 TC:1F TRN:93 TV:5.5.1026(16042.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Ed, thanks for the feedback some comments in line... Ed Jankiewicz escribió: > in addition to some editorial comments I sent to Marcelo, I have a few > substantive comments (some admittedly half-baked) and discussion > points to raise on the draft. I'm assuming there will be discussion > at IETF 72? > > 1. transition versus coexistence: recognizing that the period of > coexistence is likely to be longer, I would rather see consistent use > of the term coexistence rather than transition throughout the > document, e.g. coexistence scenarios, coexistence tools, etc. > right, i will make this change, if nobody opposes > 2. add a sentence in front of the Problem Statement to explicitly > state this motivation, e.g. "Settled opinion on the transition from > an IPv4-dominant network to an IPv6-dominant network was that the > period of coexistence would be brief, and could be accommodated by > dual-stack and tunneling. Operationally, we now expect..." > I don't think this was an assumption... at least for a long period now... > 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF > strongly prefers and recommends [dual stack] as the operational > matters are simplest" begs for a citation. RFC 4213 says dual stack > is the most straightforward but does not include language recommending > or preferring this solution. Also the impetus of this draft is that > dual stack solves only the simplest part of the problem, and becomes > very problematic when IPv4 addresses really get scarce (approaching > rather than reaching exhaustion). Some have already stated (Alain > Durand I recall saying something like) "a plan that requires all new > end-nodes to be dual-stack and to have global IPv4 addresses is a > non-starter." Also an emphasis on dual stack creates a "must carry" > situation where the core network continues to route IPv4 > indefinitely. While we say in para 2.2 that turning off IPv4 will be > a business decision, the ISP can't make that choice without alienating > customers that rely on dual stack. I can still plug in a 50 year old > rotary dial phone and expect the local telco (in the USA at least) to > make it work, even though DTMF has been the dominant method for nearly > that long. > i understand that this was what the document was reccomending Best option, native connectivity i.e. talk to v4 hosts using native v4 and talke to v6 hosts using native v6, hence dual stack Second best option, tunnel. this keeps packet unchanged Third option, translation do you think this is the wrong reccomendation to make? > 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF > recommends tunnels rather than dual NAT - that also would need a > citation, unless this document is making the statement for the first > time. Also, I believe if the two NATs know they are in a reflexive > relationship, they can avoid at least some of the general NAT problems > - i.e. they should not attempt to translate addresses in application > data. > > 5. translation network architecture: this may be beyond scope, but > it seems to me that in para 2.1.3 there could be several sub-scenarios > depending on the location of the translator > a. translator coupled to IPv6 end-nodes (IPv6 on the LAN side, > IPv4 on the WAN side) > b. translator coupled to IPv4 end-nodes (IPv4 on the LAN side, > IPv6 on the WAN side) > c. in-network translation gateway (most like NAT-PT) > There are some commercial products in development that fit these > sub-scenarios, and each has its own strengths and weaknesses. Pulling > the translator into an IPv6-only or IPv4-only edge network (a or b) > avoids some issues and those developers made the choice to restrict > deployment architecture to simplify their job. The different > deployment architectures also have impact on the addressing concerns > (para 3.3) and namespace (para 3.4). > i don't understand the scenarios you mention above I mean, for me a would be mostly nat64 and b would be mostly nat46 and c is the sum of both I am now considering having two different sets of requirements, one for nat64 and another for nat46, would that make sense to you? > 6. para 3.5 on market timing seems out of place as an > implementation/deployment statement in a requirements draft > don't know, you want to remove it? seems a pretty reasonable statement to me... > 7. Requirement R3 would be better stated in the negative: > Translation mechanism MUST NOT interfere with native > connectivity...depending where the NAT64 is in the network it may be a > pass-through, or it may not be involved at all in the native flow and > thus do nothing but non-interference. > right, so why is this not expressed in the current form? > 8. Requirement R4 is very broad. the essence of translating DNS in > support of NAT64 is to map a query on one side to the equivalent query > on the other, and do the same with the response. Of course that > mapping of names and addresses is non-trivial. It might help to > illustrate this mapping process as well as some of the bad behavior > that must be avoided. > so any suggestion how to rephrase it? > 9. Requirement R5 seems to forbid any routing table update, but don't > the addresses that the NAT64 is mapping have to be routable? > no, i don't think it is what it means, I think the goal here is to preclude mechanisms that would for instance map each v4 prefix into a different v6 prefix and that for some reason cannot be aggregated. If such a mechanism would exist, then we would importing all the v4 routing table into v6, which would be a bad idea. But certainly the v6 addresses that are used to map v4 addresses need to be routable. I mean, think about the deprecated natpt, it does not requires additional global routing table entries, right? > 10. Requirement R6 lists a few protocols, but I'm sure others might > be seen as highly desirable too. Are we avoiding ALG issues by not > mentioning higher level protocols like FTP? > No, the idea here was to mention the very basci protocols and go into the application level protocols. Do you think we should try to list all the application level protocols thta should be supported? that seems difficult to me > 11. where does the interpretation in Requirement R7 that sees the > IPv6 side being like the private side of an IPv4 NAT come from? This only applies to behave requirements I think this is the most stringent way of seeing this. I mean, take a look in endpoint independence. this makes sense if the v4 is the public address. If the v6 is the public address, then we are likely to easily satisfy this and we are likely to require more that just endpoint indepdence, but we are requiring a stable one to one association, between the v4 address and the v6 addres,s cause we can provide tha cause we have enough v6 addresses. So, all these requireemtns that are means to express difficult tradeoffs make sense when the v4 side is the public address. If the v6 is the publci address, we are likely to have much more stringent requirements than those > the opposite could be reasonable too - i.e. if there is no NAT > between the NAT64 and the v4-only nodes the v4-only nodes might be > using private addresses, and the IPv6 side of the NAT64 is the public > side. The way it is described in R7, the IPv6 addresses are like IPv4 > private addresses, mapped to the global addresses on the public side. > > 12. Requirement R9 is a noble statement but hardly a "testable" > requirement; at least we should cite RFC 4942 as guidance, and analyze > some of the security issues that arise in the different scenarios and > architectures discussed in the draft. > > i am not sure what you would like to see here... could you provide some more explicit guidance? Regards, marcelo > > From owner-v6ops@ops.ietf.org Sun Jul 20 03:00:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048C93A681B for ; Sun, 20 Jul 2008 03:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdeAQ+94srMo for ; Sun, 20 Jul 2008 03:00:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6E0E3A67B3 for ; Sun, 20 Jul 2008 03:00:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKVeS-000OCG-7Q for v6ops-data@psg.com; Sun, 20 Jul 2008 09:56:24 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKVeN-000OBL-2d for v6ops@ops.ietf.org; Sun, 20 Jul 2008 09:56:21 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6K9tokV047815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 11:55:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Message-Id: From: Iljitsch van Beijnum To: "" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Sun, 20 Jul 2008 11:55:55 +0200 References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 18 jun 2008, at 8:32, wrote: >> In a previous modified-nat-pt draft I wrote about the v4-v6-v4 >> case where IPv4 clients sit behind a CPE or layer in the stack >> that translates their IPv4 packets into IPv6 packets using SIIT (= >> stateless) and then the resulting IPv6 packets flow through the same >> NAT64 translators that IPv6 hosts that want to talk to the >> IPv4 world also use. >> Expect to see a new or updated draft on this topic before Dublin. > I'm looking forward to it. Unfortunately, other work came up so I didn't have time for this before the deadline... This is text from an expired draft: http://www.muada.com/drafts/draft-van-beijnum-modified-nat-pt-02.txt 5. IPv4-IPv6-IPv4 operation It would be optimistic to expect that all hosts implement IPv6 and the mechanisms outlined above within a limited timeframe. As such, it is useful to support both hosts that don't implement the changes set forth in this document, and even hosts that don't implement IPv6 at all. In these cases, a gateway device may be employed that manages a block of private IPv4 address space using DHCP and translates these to IPv6 addresses. The local device performs SIIT between the resulting IPv4 and IPv6 address pairs but not IPv4 NAT. Since the remote translator that translates from IPv6 to public IPv4 requires a unique IPv6 address in order to demultiplex, the local gateway MUST use a dedicated IPv6 address for each local IPv4 address. Any [RFC1918] address may be used locally as long as the requirements are met that only a single local IPv4 address maps to an IPv6 address, and that the addresses are equivalent for the purposes of computing checksums. A way to conform to these requirements is to construct the IPv6 address from the IPv4 address as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 64-bit subnet prefix |F0|ID|CHKSM| IPv4 addr | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Bit 70 in the address MUST be set to 0 to indicate a non globally unique address. The ID bits can contain a value that allows different gateways to live on the same subnet. In the absence of any administrative settings or the detection of duplicate addresses, this could be the lower 8 bits of the gateway's MAC address. The CHKSM bits are chosen such that they compensate for the differences in the checksum generated over the IPv4 pseudo-header and the checksum generated over the IPv6 pseudo-header. This means that this value is the one's complement of the one's complement addition of the 16-bit words from the top 96 bits of the address of remote modified NAT-PT translator and all the 16-bit words from the top 80 bits of IPv6 address that is being constructed. The local gateway SHOULD also perform IPv6 routing or otherwise allow IPv6 connectivity so that hosts that do support IPv6, but not MNAT-PT, have the ability to communicate directly over IPv6 in addition to being able to use translated IPv4 connectivity. There are two open issues: how do IPv4 hosts using different local gateways but the same modified NAT-PT translator communicate, and how do NAT traversal protocols such as uPnP, NAT-PMP and others work. > We should have a solution available that > includes client side changes Hm, client side modifications for 4-6-4 operation doesn't seem very useful... From owner-v6ops@ops.ietf.org Sun Jul 20 04:45:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ECD28C0E5 for ; Sun, 20 Jul 2008 04:45:50 -0700 (PDT) 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.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPgzbAyhTkuf for ; Sun, 20 Jul 2008 04:45:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0F5528C0CF for ; Sun, 20 Jul 2008 04:45:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXKQ-000DJs-Fe for v6ops-data@psg.com; Sun, 20 Jul 2008 11:43:50 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXKJ-000DJ1-Ir for v6ops@ops.ietf.org; Sun, 20 Jul 2008 11:43:48 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KBhOfp049202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 13:43:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Ralph Droms , IPv6 Operations Message-Id: <85BD4CB9-FB88-453B-82A3-9EA468DD055F@muada.com> From: Iljitsch van Beijnum To: David Conrad In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Sun, 20 Jul 2008 13:43:28 +0200 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3 jul 2008, at 22:45, David Conrad wrote: >> there won't be any motivation for NAT. > Provider independence. Cheaper gasoline prices are also a motivation for NAT. It of course helps if the tool you use actually achieves the intended purpose. If we make that a requirement both our examples are out. From owner-v6ops@ops.ietf.org Sun Jul 20 04:56:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688F23A69DA for ; Sun, 20 Jul 2008 04:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTLxS5gID1Sh for ; Sun, 20 Jul 2008 04:56:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 778403A6969 for ; Sun, 20 Jul 2008 04:56:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXWl-000F6f-O2 for v6ops-data@psg.com; Sun, 20 Jul 2008 11:56:35 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXWh-000F6H-N3 for v6ops@ops.ietf.org; Sun, 20 Jul 2008 11:56:33 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KBuE8T049378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 13:56:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Mikael Abrahamsson , v6ops@ops.ietf.org Message-Id: <698C1AD6-A49A-41EE-9B44-6E2149E8FB13@muada.com> From: Iljitsch van Beijnum To: EricLKlein@softhome.net In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Sun, 20 Jul 2008 13:56:19 +0200 References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 4 jul 2008, at 12:51, EricLKlein@softhome.net wrote: >> Yes, I realise this, but I want my native IPv6 service offering to >> require a "router" class device, even if it means that this >> "router" only forwards traffic logically between the WAN link-local >> interface and it's internal loopback address (DHCPv6-PD assigned >> space). > Then I suspect you will be greatly disappointed as I do not see most > of the devices that will be using IPv6 in the future fitting into > this category. Cellular devices outnumber PCs today, and unless you > plan to stretch the definition of CPE Router to include the ones at > cell sites then you will find that more devices are not behind a CPE > router than those that are. Look at the past 5 year trend to mobile > internet (Cellular, WiMAX, etc.), RFIDs, Automotive and traffic > systems, etc. These devices do not see a device that would fit into > this document even though they eventually are served by a router. The problem is that for hosts that connect to the IPv6 internet over ethernet or wifi, we have a widely implemented attachment model: router advertisements for a default gateway and on-link prefixes, router advertisements for address configuration, optionally DHCPv6 for address configuration and/or other config, and hopefully in the future router advertisements for DNS configuration. Except for the DNS stuff this works well. The problem is that the service that comes out of the wall usually doesn't provide this. Now we could tell the ISPs to add a box to provide all of this, but it turns out that ISPs like it when they can buy boxes with well-defined functionality from different vendors. That's why we're trying to standardize all of this. All these other systems that you mention use other attachment models, which are standardized elsewhere. (Inside or outside of the IETF.) From owner-v6ops@ops.ietf.org Sun Jul 20 05:01:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E80A3A696D for ; Sun, 20 Jul 2008 05:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boGAJfdOKVKX for ; Sun, 20 Jul 2008 05:01:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A2443A67D7 for ; Sun, 20 Jul 2008 05:01:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXav-000FiA-QC for v6ops-data@psg.com; Sun, 20 Jul 2008 12:00:53 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXar-000Fhb-GV for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:00:51 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KC0Zxm049444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:00:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: ericlklein@softhome.net, IPv6 Operations Message-Id: <65A6E4E5-D3E4-4104-8F72-BCAC6354ACA3@muada.com> From: Iljitsch van Beijnum To: David Conrad In-Reply-To: <8DF03C59-15BE-4707-9607-6121A0706875@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Sun, 20 Jul 2008 14:00:40 +0200 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> <8DF03C59-15BE-4707-9607-6121A0706875@virtualized.org> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 4 jul 2008, at 17:37, David Conrad wrote: > Because renumbering IPv6 prefixes will not be transparent, there > will be a market for NATv6. This is such nonsense. I wish you would stop spewing it. NAT gives you stable internal addresses, which may be useful for some stuff, but it won't help you much when you need to renumber because the problem there is the addresses that external entities see. From owner-v6ops@ops.ietf.org Sun Jul 20 05:06:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5914C3A696D for ; Sun, 20 Jul 2008 05:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXArkzbsmAEc for ; Sun, 20 Jul 2008 05:06:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C2503A6921 for ; Sun, 20 Jul 2008 05:06:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXg5-000Gdt-Oq for v6ops-data@psg.com; Sun, 20 Jul 2008 12:06:13 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXg1-000GbG-Oa for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:06:11 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KC5eAW049497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:05:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: , , , , Message-Id: <23D3F073-7E0B-4A7B-A78C-55574A4E6562@muada.com> From: Iljitsch van Beijnum To: "" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: new draft on IPv6 CPE router available for review Date: Sun, 20 Jul 2008 14:05:46 +0200 References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 4 jul 2008, at 15:06, wrote: > I'm not sure if the GGSN even configures itself global address from > the > prefixes it gives to subscribers (does router have to configure an > address for itself from the prefixes it sends out in RAs?). I was > unable > to verify this right now. No, that requirement went the way of the dodos in IPv6. Does this system give the subscriber more than just one /64? If not, the phone needs to be a bridge and the service provider will see more individual addresses. From owner-v6ops@ops.ietf.org Sun Jul 20 05:15:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B686C3A69DA for ; Sun, 20 Jul 2008 05:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQudk90l4Caz for ; Sun, 20 Jul 2008 05:15:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7F043A6783 for ; Sun, 20 Jul 2008 05:15:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXp4-000IFl-Ae for v6ops-data@psg.com; Sun, 20 Jul 2008 12:15:30 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXoy-000IEl-Sc for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:15:27 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KCF86x049649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:15:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Message-Id: From: Iljitsch van Beijnum To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 14:15:13 +0200 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 8 jul 2008, at 20:19, Stark, Barbara wrote: > 1. Based on what I'm hearing from the access network side of my > company, > I'm expecting for retail CPE routers (in the US) to continue to need > to > support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet > and > IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable > option that defaults to IP/Ethernet. I would expect that to be the > default with IPv6, as well. Wouldn't it be better if this could be provisioned automatically? > 2. The document seems to suggest that "numbered" vs. "unnumbered" > model > is a configuration option (section 5.3.2). I think the CPE router > needs > to be able to automatically detect what the access network is giving > it. > It should be pretty apparent if the access network is giving it a > global > IP address or not. Agree. > 3. I disagree with the behavior suggested for "unnumbered" model. I > don't think a CPE router should automatically open up a maintenance > loopback interface just because it doesn't get a global IP address. Also agree. > As a default, we believe > that the global address that the CPE router selects for its LAN > interface is sufficient for all WAN-side Internet communication, > including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests > from the router when my WAN is having problems]. "Real" routers don't answer pings for addresses on interfaces that are down. So if there's nothing connected to the ethernet, you wouldn't be able to ping. Of course we can specify the opposite behavior. > By the way, when I hear about IPv6 and loopback interface in the same > sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I > associate > loopback network interfaces with SNMP. In the router world it's normal to have loopback interfaces with global addresses in order to have an address that can be used for management, but also for stuff like BGP. From owner-v6ops@ops.ietf.org Sun Jul 20 05:25:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CB33A6A7B for ; Sun, 20 Jul 2008 05:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1i2WUyNrKWJ for ; Sun, 20 Jul 2008 05:25:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3987D3A6A47 for ; Sun, 20 Jul 2008 05:25:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXyW-000JsE-Q7 for v6ops-data@psg.com; Sun, 20 Jul 2008 12:25:16 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKXyS-000Jmz-Mm for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:25:14 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KCOetT049770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:24:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Ole Troan" , "Stark, Barbara" , , "Antonio Querubin" Message-Id: <9226DD8A-E33C-4B95-8A85-530A5918F4B4@muada.com> From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 14:24:45 +0200 References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 16 jul 2008, at 1:54, Hemant Singh (shemant) wrote: > RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, > due to security concerns, the router should drop the incoming > packet. If > the WAN interface of the CPE Router does not have a global IPV6 > address, > how is RPF going to work? If you run unicast RPF (uRPF, RPF itself is for multicast) on the ISP router then this whill work regardless of the interface the CPE uses to source packets because all the address space delegated to the user is obviously routed towards the CPE so it will pass the uRPF check. > RPF needs global IPv6 addresses. Link local addresses can't be forwarded by routers anyway, so uRPF and link locals are orthogonal. Where is the packet with a link local source address supposed to go to? From owner-v6ops@ops.ietf.org Sun Jul 20 05:29:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91A928C0E5 for ; Sun, 20 Jul 2008 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLMCAxY2X7cR for ; Sun, 20 Jul 2008 05:29:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F17B73A6A77 for ; Sun, 20 Jul 2008 05:29:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKY2H-000KSt-AI for v6ops-data@psg.com; Sun, 20 Jul 2008 12:29:09 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKY2D-000KSE-Hu for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:29:07 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KCSjit049831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:28:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Stark, Barbara" , "Antonio Querubin" , Message-Id: <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 14:28:50 +0200 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 17 jul 2008, at 20:35, Hemant Singh (shemant) wrote: > Further, even I agree with you that it's not wise for a CPE Router to > respond to pings. It's a router so it must generate numerous other ICMP packets in response to certain incoming packets. So not responding to pings doesn't buy you anything. From owner-v6ops@ops.ietf.org Sun Jul 20 05:47:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E863A6921 for ; Sun, 20 Jul 2008 05:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7DFsdi132j0 for ; Sun, 20 Jul 2008 05:47:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B4383A68E7 for ; Sun, 20 Jul 2008 05:47:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKYId-000NAY-TY for v6ops-data@psg.com; Sun, 20 Jul 2008 12:46:03 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKYIZ-000N9u-S0 for v6ops@ops.ietf.org; Sun, 20 Jul 2008 12:46:02 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KCjKgG050074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 14:45:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Hemant Singh (shemant)" , "Antonio Querubin" , Message-Id: From: Iljitsch van Beijnum To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 14:45:25 +0200 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: (Sorry about the large number of messages...) On 17 jul 2008, at 23:10, Stark, Barbara wrote: > Yes, the WAN interface absolutely *must* have a global IP address that > it uses for sending and receiving IP messages, as far as I'm > concerned. Huh? Didn't you say the exact opposite earlier? There three questions: 1. Should the CPE have a global address that it can use to send outgoing packets on the WAN interface 2. Should it be an option for the ISP to not provide address configuration over the WAN link (obviously they must do DHCPv6 PD) 3. If both 1 and 2, then what? Options: 3a: use a loopback interface and take a subnet from the PD prefix (even if it's only a /128, but that still makes a /64 unusable for anything else) 3b: use an address from a LAN interface (issue with usability of this address if LAN interface is down) 3c: take a subnet from the PD prefix (even if it's only a /128) and use it on the WAN interface Note that 1 MUST be answered with YES if there is the possibility that a LAN interface has a smaller MTU than the WAN interface in order to get PMTUD to work, and SHOULD be yes for the purpose of other ICMPv6 messages. 3b and 3c have the issue that they eat up address space, so if the ISP only provides a /64 you're in trouble. 3c also has the issue that it doesn't make much sense because the ISP doesn't know the address is on- link. 3b seems to make sense. From owner-v6ops@ops.ietf.org Sun Jul 20 06:47:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F1E3A6902 for ; Sun, 20 Jul 2008 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.81 X-Spam-Level: X-Spam-Status: No, score=-4.81 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuKyVcNruwlv for ; Sun, 20 Jul 2008 06:47:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 284133A68CE for ; Sun, 20 Jul 2008 06:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZEh-0009Gn-Qd for v6ops-data@psg.com; Sun, 20 Jul 2008 13:46:03 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZEe-0009GI-0U for v6ops@ops.ietf.org; Sun, 20 Jul 2008 13:46:02 +0000 X-IronPort-AV: E=Sophos;i="4.31,218,1215388800"; d="scan'208";a="14809024" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2008 13:45:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6KDjwUX010370; Sun, 20 Jul 2008 09:45:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6KDjwBq011920; Sun, 20 Jul 2008 13:45:58 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 09:45:58 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 09:45:57 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjqYomQPrka8B0OT4KwvFZKMp9hLgAC5WSQ References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" , "Stark, Barbara" Cc: X-OriginalArrivalTime: 20 Jul 2008 13:45:58.0864 (UTC) FILETIME=[F0E10500:01C8EA6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=718; t=1216561558; x=1217425558; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20,=0A=20=20=20=20=20=20=20=20=22Stark,=20Barbara=22=20; bh=NsoCAxfD3tuu9JsaP29iN9aSUoka64j9X0Yve5OSRIc=; b=rJLHYTb5dKMxaUWlr7OnoyVE/q0mBuTfGoQ8LLED2zRKz2bAK8TGXh39y3 JCZcG2MWbbMIvxg0MxJVF1vjRK0K5bP+5Mf8hH0mg0/Y3HKLECQI8EI+tTtg 1roKlNRrKC; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > 3. I disagree with the behavior suggested for "unnumbered" model. I > don't think a CPE router should automatically open up a maintenance > loopback interface just because it doesn't get a global IP address. Also agree.=20 =20 Not quite. The unnumbered model is clearly saying the WAN interface only acquires on a link-local address. But the WAN interface of the CPE Router has got to have a global IPv6 address. So what choice does the CPE Router have but to automatically spawn a Loopback interface that will get assigned a global IPv6 address (using SLAAC, DHCPv6, or one address from the IA_PD when the Loopback interface uses, say, stateless DHCPv6 to acquire an IA_PD). Hemant From owner-v6ops@ops.ietf.org Sun Jul 20 06:52:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48323A6902 for ; Sun, 20 Jul 2008 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.804 X-Spam-Level: X-Spam-Status: No, score=-4.804 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFg5wg60YClM for ; Sun, 20 Jul 2008 06:52:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2C823A682F for ; Sun, 20 Jul 2008 06:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZJt-000A4T-R3 for v6ops-data@psg.com; Sun, 20 Jul 2008 13:51:25 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZJq-000A41-0H for v6ops@ops.ietf.org; Sun, 20 Jul 2008 13:51:24 +0000 X-IronPort-AV: E=Sophos;i="4.31,218,1215388800"; d="scan'208";a="14825451" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2008 13:51:21 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6KDpK5E011262; Sun, 20 Jul 2008 09:51:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6KDpL5k012444; Sun, 20 Jul 2008 13:51:21 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 09:51:20 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 09:51:20 -0400 Message-ID: In-Reply-To: <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjqZDDsYs+V+8v1QG6gu33CwRzzRAACuf1A References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "Stark, Barbara" , "Antonio Querubin" , X-OriginalArrivalTime: 20 Jul 2008 13:51:20.0892 (UTC) FILETIME=[B0D297C0:01C8EA6F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=998; t=1216561881; x=1217425881; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20; bh=+23565VLBHpnHpFP6u0Je35+t6cEVTOl2QegJbklFx4=; b=ESAfDGe2lshvylMLqLnuW7To0jLb7mLW8B4Lbp/3dfQHHEt4uYrqk5aJyv o3nd+S8o1NJur2vswzQG95so0kebN6+YgEuBacWldHXccrChM+PRfFn6LUDu NO6h/j7kWG; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The draft clearly says what ICMPv6 errors are returned by the CPE Router, so it's not like the CPE Router is not responding to any ICMPv6 request. Existing IPv4 routers do have a ping disable feature where the router is configured to not respond to pings. I also said on this thread that if the CPE Router does respond to pings, the CPE Router needs to rate limit incoming ping reqs. Hemant=20 -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Sunday, July 20, 2008 8:29 AM To: Hemant Singh (shemant) Cc: Stark, Barbara; Antonio Querubin; v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On 17 jul 2008, at 20:35, Hemant Singh (shemant) wrote: > Further, even I agree with you that it's not wise for a CPE Router to=20 > respond to pings. It's a router so it must generate numerous other ICMP packets in response to certain incoming packets. So not responding to pings doesn't buy you anything. From owner-v6ops@ops.ietf.org Sun Jul 20 07:45:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BB93A69C8 for ; Sun, 20 Jul 2008 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctIn6frl0JZb for ; Sun, 20 Jul 2008 07:45:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26D633A6939 for ; Sun, 20 Jul 2008 07:45:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKa8b-000JFt-RJ for v6ops-data@psg.com; Sun, 20 Jul 2008 14:43:49 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKa8X-000JFK-J4 for v6ops@ops.ietf.org; Sun, 20 Jul 2008 14:43:47 +0000 X-IronPort-AV: E=Sophos;i="4.31,218,1215388800"; d="scan'208";a="14826723" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2008 14:43:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6KEhijG002975; Sun, 20 Jul 2008 10:43:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6KEhiO6023400; Sun, 20 Jul 2008 14:43:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 10:43:44 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 10:43:31 -0400 Message-ID: In-Reply-To: <9226DD8A-E33C-4B95-8A85-530A5918F4B4@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjqY6u681p+65BHSNSez4PTFeYV3gAEl7bg References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> <9226DD8A-E33C-4B95-8A85-530A5918F4B4@muada.com> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "Ole Troan" , "Stark, Barbara" , , "Antonio Querubin" X-OriginalArrivalTime: 20 Jul 2008 14:43:44.0459 (UTC) FILETIME=[0288D9B0:01C8EA77] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1893; t=1216565024; x=1217429024; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20; bh=fmGbopYgNgO3+Lb9J6SwRCb2ciRLv/bmwq8niuC5NFQ=; b=Oyb8a5g0yAq3iimmOdEzww+lEhHzs5qoLolqvD9+fHbn2Db5Eq84Zm19p1 3iTYkLXoAx7ycEYmzjXIGm06NlhSUX+S2cGbbUld0MiRuYSQZgl7hgWae8m+ LVSaapqbs1; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Please see the complete uRPF thread that we discussed on this mailer - they were emails between July 15 - 16th, 2008. Here is one piece of text snipped from my email on the subject of uRPF on July 16th. I wasn't talking about any packet with src-addr as link-local. "I have a spoofed packet with global src-addr input to the WAN interface of a standalone CPE Router - the destination of this packet is the global IPv6 address of a LAN interface. Strict uRPF check will check if the src-addr is reachable by a path thru the input interface which is the WAN interface. The WAN interface, which is also a routed port has only a link-local address. So how can the global address have a path thru the WAN interface that is assigned only a link-local address?" Hemant=20 -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Sunday, July 20, 2008 8:25 AM To: Hemant Singh (shemant) Cc: Ole Troan; Stark, Barbara; v6ops@ops.ietf.org; Antonio Querubin Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On 16 jul 2008, at 1:54, Hemant Singh (shemant) wrote: > RPF (Reverse Path Forwarding) will fail and if RPF fails for a router, > due to security concerns, the router should drop the incoming packet.=20 > If the WAN interface of the CPE Router does not have a global IPV6=20 > address, how is RPF going to work? If you run unicast RPF (uRPF, RPF itself is for multicast) on the ISP router then this whill work regardless of the interface the CPE uses to source packets because all the address space delegated to the user is obviously routed towards the CPE so it will pass the uRPF check. > RPF needs global IPv6 addresses. Link local addresses can't be forwarded by routers anyway, so uRPF and link locals are orthogonal. Where is the packet with a link local source address supposed to go to? From owner-v6ops@ops.ietf.org Sun Jul 20 09:06:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553693A6886 for ; Sun, 20 Jul 2008 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi6RJX33FyUz for ; Sun, 20 Jul 2008 09:06:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D75783A6896 for ; Sun, 20 Jul 2008 09:06:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbNi-0007WY-Qi for v6ops-data@psg.com; Sun, 20 Jul 2008 16:03:30 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbNe-0007Vi-MK for v6ops@ops.ietf.org; Sun, 20 Jul 2008 16:03:28 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14812521" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2008 16:03:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6KG3N8Z018341; Sun, 20 Jul 2008 12:03:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6KG3NFB003505; Sun, 20 Jul 2008 16:03:23 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 12:03:23 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Sun, 20 Jul 2008 12:03:01 -0400 Message-ID: In-Reply-To: <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjojRzMcym/0QQDQiGoqY7rIKtsBAArr17Q References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> From: "Hemant Singh (shemant)" To: "David Miles" Cc: "v6ops WG" X-OriginalArrivalTime: 20 Jul 2008 16:03:23.0019 (UTC) FILETIME=[22C73DB0:01C8EA82] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4392; t=1216569803; x=1217433803; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22David=20Miles=22=20; bh=DOQI49fQXpeuo6fWW+R/XKRnylhD6U7YBairgjFJPp0=; b=q/2S1sVngcvXwPcXLPSD2nl4fsH4LMtK5HfyyXJzeCd4xgYyhzHl5OZXKx FnxbftRpNibi3tyCqakz1beCG6jG8dX7PISM76h7RmMpjXOC7zHfqNGApRRE T++4pi8RQj; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David, Please see in line between and .=20 -----Original Message----- From: David Miles [mailto:davidm@thetiger.com]=20 Sent: Friday, July 18, 2008 12:16 AM To: Hemant Singh (shemant) Cc: v6ops WG Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Hemant and Wes, Some comments on draft-02: - The un-numbered model doesn't require a loopback interface It does. You may be behind checking your emails on this thread. Please read ample evidence given for this one.=20 - ULA addresses generation per RFC4193 may not be appropriate for CPE as it requires time of day and is a one-time algorithm. I think we may need to suggest a new random algorithm that is consistent with the one in RFC 4193 and does not require time of day. We should also point out that a ULA prefix should be consistent across reloads and there must be some method by which the user can regenerate or otherwise specify their desired ULA prefix. Finally ULA is a 48-bit prefix. Hmm, ULA is restricted to one home, so what are the odds of ULA clashing for one single home/SOHO premise since number of devices in the home may be 256 or even 500 or so. The only way my ULA is visible to my neighbor's home is if the CPE Router includes a WLAN. But two different homes have different wireless SSID, so even then if the ULA clashes with my neighbor's, it's not a clash. I do grant folks that fact that both myself and my neighbor may be lazy people and we both use the default SSID shipped with the WLAN of the CPE Router. But anyhow, how many clients exists in the home that the algorithm in RFC4193 is not good. For 100 connections, RFC4193 has this probability of collision. 100 4.54*10^-09 - I think we should add a line that says traffic with a ULA source address should not be forwarded out the WAN interface, rather than noting you could use user-configured ACL. All Internet RFC's mention filtering of ULA traffic at the edge. In that vein our use of ACL is appropriate. Anyhow, this is a minor point we can look into later. - Seeing you mention DAD on the WAN interface, you may also want to add joining the solicited-node MC group via MLD per RFC 4861/2. Disagree with the idea. We mention DAD in the draft only because for some links like PPP, the draft needs to point out that DAD will not be invoked for unicast addresses. Your suggestion is one detail too many. - Suggest you use RIPng terminology rather than RIPv6 Agreed. Thanks. - The IPv6 over PPP and softwire sections makes no mention of WAN interface address assignment other than IPv6CP (interface-ID). Should we support both numbered and unnumbered models on PPP links? Yes. PPP links also get their link-local address as per RFC5070. Then just like other networks that don't use PPP, even PPP link will use SLAAC or DHCPv6 to acquire a global IPv6 address. I have also said, we need to update the Unnumbered section to also include assigning the Loopback interface a global IPv6 address from the IA_PD obtained by the Loopback interface. I can add such text to the PPP section.=20 - Section 7: IPv6 Data forwarding should reference the Default Routers List and the creation of the default route based on this. No. We will define our router in terms of our own conceptual variables for routing. Default Routers List is a ND conceptual variable. =20 =20 As you've covered off cascading routers we also need to consider how to route traffic to them (assuming they will in turn populate their default router list with the root CPE). This suggests the DHCPv6 server in the CPE must be able to trigger route updates based on active leases. Once we say that RIPng may be used in the home, that is enough for routing information to flow from home's downstream routers to the next upstream router in the cascade. We will consider adding text to the Cascading section to say RIPng may be used in the home. The DHCPv6 server suggestion is so that the IA_PD can be sub-delegated downstream in the cascade, not for route updates! I have snipped out the rest of your email because I will reply to the snipped lot in another email. I wanted to get this reply out first. Hemant From owner-v6ops@ops.ietf.org Sun Jul 20 11:33:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9183A6A03 for ; Sun, 20 Jul 2008 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHr9vkJPNlCf for ; Sun, 20 Jul 2008 11:33:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED1E53A6998 for ; Sun, 20 Jul 2008 11:33:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdfr-0007mt-65 for v6ops-data@psg.com; Sun, 20 Jul 2008 18:30:23 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdfm-0007kq-QK for v6ops@ops.ietf.org; Sun, 20 Jul 2008 18:30:21 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id 3D80AD005F; Sun, 20 Jul 2008 08:30:10 -1000 (HST) Date: Sun, 20 Jul 2008 08:30:10 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Iljitsch van Beijnum , "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > router is configured to not respond to pings. I also said on this > thread that if the CPE Router does respond to pings, the CPE Router > needs to rate limit incoming ping reqs. You mean responses? The rate limiting should be optional. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Sun Jul 20 11:34:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACC23A6A7A for ; Sun, 20 Jul 2008 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.79 X-Spam-Level: X-Spam-Status: No, score=-4.79 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si+6BzMobXeI for ; Sun, 20 Jul 2008 11:34:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 166793A6A75 for ; Sun, 20 Jul 2008 11:34:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdk1-0008PN-Vr for v6ops-data@psg.com; Sun, 20 Jul 2008 18:34:41 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdjx-0008Oh-GP for v6ops@ops.ietf.org; Sun, 20 Jul 2008 18:34:39 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14832891" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2008 18:34:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6KIYYhD014249; Sun, 20 Jul 2008 14:34:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6KIYY8J019856; Sun, 20 Jul 2008 18:34:34 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 14:34:33 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 14:34:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: Acjqlq5DYHFRf7doSAWVgMgq74oSjAAABB8g References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Iljitsch van Beijnum" , "Stark, Barbara" , X-OriginalArrivalTime: 20 Jul 2008 18:34:33.0897 (UTC) FILETIME=[41716190:01C8EA97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=985; t=1216578874; x=1217442874; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=TMZwDoUYKcdq70WpXhVKw5glaiSC34+OX//UHddxlds=; b=P3APVeYMNT6QumiRK3wZLAZG7ESwjmqFLZxfzbZVP4j/xV+Vj7VfTwHUZF 6rit2Q8M9FlHZKNOpoBzvTfOYRHmWWBH4T5RlHxiL3RftLUJAnyD/a4xhovN eihNECQ8hu; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: No, I meant incoming ping reqs to the CPE Router's WAN interface. We have seen home networks getting attacked with pings from the WAN in cable deployments. As one may note, we don't discuss any throttling of ping reqs or responses into/from the CPE Router. We are going to think about it and see what do mention about throttling for the CPE Router. Hemant=20 -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Sunday, July 20, 2008 2:30 PM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; Stark, Barbara; v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > router is configured to not respond to pings. I also said on this=20 > thread that if the CPE Router does respond to pings, the CPE Router=20 > needs to rate limit incoming ping reqs. You mean responses? The rate limiting should be optional. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Sun Jul 20 11:54:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8003A6A75 for ; Sun, 20 Jul 2008 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UreKlW72hcU for ; Sun, 20 Jul 2008 11:54:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40E983A6A74 for ; Sun, 20 Jul 2008 11:54:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKe2G-000BrP-G9 for v6ops-data@psg.com; Sun, 20 Jul 2008 18:53:32 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKe2B-000Bqf-GG for v6ops@ops.ietf.org; Sun, 20 Jul 2008 18:53:30 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id BF4EAD005F; Sun, 20 Jul 2008 08:53:26 -1000 (HST) Date: Sun, 20 Jul 2008 08:53:26 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Iljitsch van Beijnum , Ole Troan , "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE79B@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE855@crexc41p> <2bbba3c10807151556k50e0acb8gc931dcf649f7034f@mail.gmail.com> <2bbba3c10807151612k22d2a546i2d4af02593170866@mail.gmail.com> <9226DD8A-E33C-4B95-8A85-530A5918F4B4@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > they were emails between July 15 - 16th, 2008. Here is one piece of > text snipped from my email on the subject of uRPF on July 16th. I > wasn't talking about any packet with src-addr as link-local. > > "I have a spoofed packet with global src-addr input to the WAN interface > of a standalone CPE Router - the destination of this packet is the > global IPv6 address of a LAN interface. Strict uRPF check will check if > the src-addr is reachable by a path thru the input interface which is > the WAN interface. The WAN interface, which is also a routed port has > only a link-local address. So how can the global address have a path > thru the WAN interface that is assigned only a link-local address?" The default route has to go somewhere. Regardless of whether the single WAN interface acts like a point-to-point link or is multi-access, it's still the one ingress point from SP to the customer. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Sun Jul 20 12:02:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE4B3A6A83 for ; Sun, 20 Jul 2008 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVPCK51g9ND3 for ; Sun, 20 Jul 2008 12:02:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A70263A6A03 for ; Sun, 20 Jul 2008 12:02:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeB8-000Diw-9I for v6ops-data@psg.com; Sun, 20 Jul 2008 19:02:42 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeB3-000DeK-Rr for v6ops@ops.ietf.org; Sun, 20 Jul 2008 19:02:39 +0000 Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTPS id EE4CDD008E; Sun, 20 Jul 2008 09:02:36 -1000 (HST) Date: Sun, 20 Jul 2008 09:02:36 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Iljitsch van Beijnum , "Stark, Barbara" , v6ops@ops.ietf.org Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <9AD383FA-37AC-46F9-AC63-A9385FEDD48E@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > No, I meant incoming ping reqs to the CPE Router's WAN interface. We ^^^^^^^^ > have seen home networks getting attacked with pings from the WAN in > cable deployments. As one may note, we don't discuss any throttling of > ping reqs or responses into/from the CPE Router. We are going to think > about it and see what do mention about throttling for the CPE Router. I'm confused. How does one rate-limit incoming requests on the WAN side when that's not under the control of the device? You can only rate-limit what you originate or forward, regardless of whether it's destination is internal or external. whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Sun Jul 20 12:40:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E041F3A6903 for ; Sun, 20 Jul 2008 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCAvsc5+0hvZ for ; Sun, 20 Jul 2008 12:40:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D20AA3A67DF for ; Sun, 20 Jul 2008 12:40:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKek6-000KQU-7d for v6ops-data@psg.com; Sun, 20 Jul 2008 19:38:50 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKek1-000KPY-Gu for v6ops@ops.ietf.org; Sun, 20 Jul 2008 19:38:48 +0000 Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6KJcTM5055896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2008 21:38:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: IPv6 Operations Message-Id: <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 21:38:34 +0200 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: >> 3. I disagree with the behavior suggested for "unnumbered" model. I >> don't think a CPE router should automatically open up a maintenance >> loopback interface just because it doesn't get a global IP address. > Would you PLEASE use normal quoting techniques? Reading email costs enough time as it is without everyone doing stuff in their own particular way so automation and habits don't work. > Not quite. The unnumbered model is clearly saying the WAN interface > only acquires on a link-local address. But the WAN interface of the > CPE > Router has got to have a global IPv6 address. You are being extremely imprecise. That is one of the reasons your draft is in such bad shape. The INTERFACE doesn't need a global address, but the ROUTER does. > So what choice does the > CPE Router have but to automatically spawn a Loopback interface that > will get assigned a global IPv6 address When you need to create a packet, use a source address from another interface that you have, i.e. a LAN interface. I believe this is explained in the base IPv6 specs. Or ask within your company about the behavior of "ipv6 unnumbered ..." > (using SLAAC, Creating addresses using stateless autoconfig on an interface different than the one where the RAs were received is very wrong. > DHCPv6 Using DHCPv6 address configuration on a router makes no sense in my opinion. > stateless DHCPv6 to acquire an IA_PD). I don't think prefix delegation is possible in the stateless version of DHCPv6. On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > The draft clearly says what ICMPv6 errors are returned by the CPE > Router, so it's not like the CPE Router is not responding to any > ICMPv6 > request. Good. > Existing IPv4 routers do have a ping disable feature where the > router is configured to not respond to pings. You are again using imprecise terminology. What you mean is IPv4 CPEs with NAT functionality. That has little to do with routing. For IPv6, CPEs do have to be real routers and conform to normal router behavior unless we specify exceptions. It is of course allowed to not return echo replies. However, since the router MUST generate other ICMPv6 messages under other circumstances, not replying to pings doesn't make the router invisible so there is little point in not returning ping replies. > I also said on this > thread that if the CPE Router does respond to pings, the CPE Router > needs to rate limit incoming ping reqs. You say that you want to rate limit INCOMING pings. (Which is useless anyway because the LAN bandwidth is much higher than the WAN bandwdith.) If you want to do this, it makes no sense to tie that to whether or not ping replies are sent. For the router itself this is a non-issue because the IPv6 specs mandate that ICMPv6 messages are rate limited anyway. On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > Please see the complete uRPF thread that we discussed on this mailer - > they were emails between July 15 - 16th, 2008. I read it earlier today. It didn't make much sense to me. But now it occurs to me that you actually want to run uRPF on the CPE itself. I don't see how that's useful. What you want to do is filter out outgoing packets on the WAN interface if they don't have a source address that is either in the prefix delegated by the ISP or have the router's own WAN address as a source address. From owner-v6ops@ops.ietf.org Sun Jul 20 15:57:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D563A6A84 for ; Sun, 20 Jul 2008 15:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9trjl4NTYVQK for ; Sun, 20 Jul 2008 15:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C46F3A6A78 for ; Sun, 20 Jul 2008 15:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKhn6-000PuZ-EI for v6ops-data@psg.com; Sun, 20 Jul 2008 22:54:08 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKhn0-000Pu3-NX for v6ops@ops.ietf.org; Sun, 20 Jul 2008 22:54:06 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14840585" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2008 22:53:58 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6KMrwcV016653; Sun, 20 Jul 2008 18:53:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6KMrw8R000922; Sun, 20 Jul 2008 22:53:58 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 18:53:58 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Sun, 20 Jul 2008 18:53:57 -0400 Message-ID: In-Reply-To: <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjojRzMcym/0QQDQiGoqY7rIKtsBAB/9TLw References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> From: "Hemant Singh (shemant)" To: "David Miles" Cc: "v6ops WG" X-OriginalArrivalTime: 20 Jul 2008 22:53:58.0520 (UTC) FILETIME=[7EAE5F80:01C8EABB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8515; t=1216594438; x=1217458438; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22David=20Miles=22=20; bh=2NpGsWmq4yVMy/BNi1EsLnZmNMdkkKJrQcAnaziqMqg=; b=K1JsYbtg0EyawpLaFP903Zzu17RBLqcY/XwmVysWAi2KwiGRoch/3ravLw 5uSQu3SfuRBdNg7NjK+cUjM49vU+JANE5YBAkPJ9gjiNcJKGD6QBnuUGKJGj BktccRR4a4; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David, Here is my response to the rest of your email. Please see in line below between and .=20 -----Original Message----- From: David Miles [mailto:davidm@thetiger.com]=20 Sent: Friday, July 18, 2008 12:16 AM To: Hemant Singh (shemant) Cc: v6ops WG Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Hemant and Wes, Some comments on draft-02: ------- snip --------------------------- I think we need a new section that describes CPE behaviour on reload/ WAN up, thoughts below: WAN up is already described in the document in various sections. A reload section may make sense to add to the document. If I and Wes are convinced, we'll add such a TBD to a "TBD list" for the document that we maintain. For all of our sanities, I will publish this TBD list every Friday so that everyone is aware what is TBD. We clearly have ignored some people's comments and requests because they didn't make sense to us. Folks are welcome to contact us if they still want their request to be kept in our TBD list with give proper justification. =20 ----- 5.4 Prefix Delegation Rebinding Whenever the CPE WAN link changes state, addresses passed through DHCPv6 must be revalidated. Conditions that should trigger a Rebind include: - When the CPE reboots - When the CPE WAN interface transitions to an up state Prior to completing a Rebind, the CPE should continue to use addresses and lifetimes previously assigned to its LAN interface(s) that are derived from IA_PD Prefix options. These may be subsequently invalidated through the Rebind process. On reload, a routing CPE may not be able to validate any IA_PD Prefix option lifetimes. Certain parameters must be stored in persistent memory to avoid a situation where hosts in the LAN segments consider previously advertised prefixes valid that the CPE does not know of or that may not be permitted by the upstream ISP. These persistent parameters are: - DHCPv6 PD - IAID - Prefix Options - A register of subnets assigned to each interface with associated IAID, IA_PD Prefix option and AdvPrefixList. - Interface address assignments and lifetimes The CPE MUST NOT advertise any RA PIO for prefixes derived from IA_PD Prefix Options until the prefixes have been validated through a DHCP Rebind message exchange. Once the WAN interface initialises, the reloading CPE SHOULD issue a DHCPv6-PD Rebind message, including the stored IAID and Prefix Options in the message. The DHCP Reply message will indicate whether the prefixes are valid (the valid lifetime is > 0) or invalid (the valid lifetime is 0). If there is no reply within CNF_MAX_RD [RFC 3315] the CPE MUST initiate DHCPv6 Address Acquisition. It should continue to use addresses and lifetimes previously assigned to its LAN interface(s). For each invalid prefix, the CPE MUST transmit unsolicited RA to LAN segments that contain PIO with the invalid prefix and the lifetime set to zero to immediately invalidate these addresses from hosts on the LAN. The CPE MUST then initialise DHCPv6 Address Acquisition. For each valid prefix, the CPE MUST transmit unsolicited RA to LAN segments that contain PIO with the valid prefix and lifetimes set to the values is the DHCP Reply IA_PD Prefix option. ----- - I'd suggest text in the DHCPv6 Address Acquisition section that clarifies IA_PD prefix options received by the CPE are an explicit list of valid prefixes. All prefixes in the CPE AdvPrefixList that originated from previous IA_PD and that are not contained in the DHCP- PD Reply MUST be immediately expired.=20 Most of your text above is already mentioned in RFC3633 that is a RFC referenced in our document. Like text from section 12.1 of RFC3633 describes some of your text above. Further, we have added this text to the end of 2nd paragraph of section 5.5 in our -02 version document (shown in square brackets below): [If the IA_PD changes, the CPE Router must reconfigure the LAN interface(s) with new IPv6 addresses derived from the new IA_PD and then also renumber the IPv6 ND RA configuration on the LAN interface(s).]. We will add a few more sentences at an appropriate place in our draft that address your concerns above. This ensures a host will not try an communicate through the ISP with a invalid source address. I'm not sure what we should do in the scenario where DHCPv6 Address Acquisitions fails (ie, we get a response but no IA_PD Options) but I would lean to doing nothing (ie, dont expire prefixes but do not send any PIO, let the lifetime age away) as we are not going to forward anyway. After section 5.3.2, we have a paragraph in the draft that says the router will not forward any traffic for the case you describe above. That text is as follows (shown between square brackets):=20 [At any instance in time of the CPE Router operation, the router does not forward any traffic between its WAN and LAN interface(s) if the router has not completed IPv6 provisioning process that involves the acquisition of a global IPv6 address by the WAN or Loopback interface and the acquisition of a global or Unique Local Address (ULA) [RFC4193] by the LAN interface(s).].=20 Then in section 5.4 of our draft we say (show in square brackets below): [When the CPE Router processes a DHCPv6 response from the server, if the response message (e.g. ADVERTISE or REPLY) received does not include an IA_PD option, or Reconfigure Accept option, then the CPE Router has failed DHCPv6 address acquisition.]. I don't see why you had to mention your case when we have already covered the case in the draft? - Some comments on the Unnumbered model with suggested text: From: 5.3.2. Unnumbered Model When the CPE router is configured for Unnumbered model, after the WAN and Loopback interfaces have acquired a link-local address, the Loopback interface initiates SLAAC or stateful DHCPv6 to obtain IA_PD option and other configuration information. On receiving the DHCPv6 REPLY with IA_PD option, the CPE Router sub-delegates one global IPv6 address from the IA_PD option to the Loopback interface. At any instance in time of the CPE Router operation, the router does not forward any traffic between its WAN and LAN interface(s) if the router has not completed IPv6 provisioning process that involves the acquisition of a global IPv6 address by the WAN or loopback interface and the acquisition of a global or Unique Local Address (ULA) by the LAN interface(s). --- To: 5.3.2. Unnumbered Model In the unnumbered model the WAN interface will not acquire an interface address through SLAAC or DHCPv6. When the CPE router is configured for Unnumbered model and after interface initialisation, the WAN interface initiates DHCPv6 to obtain IA_PD option and other configuration information. No. We don't want to prohibit the Loopback interface or any virtual interface on the router from acquiring a global IPv6 address using SLAAC or DHCPv6. As I said in an earlier emails, we will add a third option to the Unnumbered model where the third model will assign a global IPv6 address to the Loopback interface from the IA_PD acquired by the Loopback interface. We can also say that this third option is a preferred option for some SP deployments or any other way that DSL folks would like us to word the requirement. 5.3.3. Both Models On receiving the DHCPv6 REPLY with a IA_PD option, the CPE Router assigns a /64 prefix from within the bounds of the IA_PD Prefix Option to all interfaces except the WAN interface. The interface addresses are constructed using the /64 prefix and using EUI-64 on each interface for the Interface-ID portion of the address. At any instance in time of the CPE Router operation, the router does not forward any traffic between its WAN and LAN interface(s) if the router has not completed IPv6 provisioning process that involves the acquisition or rebinding of addresses via DHCPv6-PD. The paragraph at the end of section 5.3.2 does apply to both models. Your suggestion for putting this under a new sub-section makes perfect sense - thanks! What the text of the common sub-section is not agreeable to me. After we have added our third option to the Unnumbered section, we will run any new text for the "Both Models" by you take it from there. Hemant Cheers, -David From owner-v6ops@ops.ietf.org Sun Jul 20 16:21:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF33C28C0F7 for ; Sun, 20 Jul 2008 16:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIO831OgwVi7 for ; Sun, 20 Jul 2008 16:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA8C728C0FA for ; Sun, 20 Jul 2008 16:21:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKiCR-0004rE-NT for v6ops-data@psg.com; Sun, 20 Jul 2008 23:20:19 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKiCN-0004qY-TX for v6ops@ops.ietf.org; Sun, 20 Jul 2008 23:20:17 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14825183" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2008 23:20:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6KNKELw008136; Sun, 20 Jul 2008 19:20:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6KNKEbH029585; Sun, 20 Jul 2008 23:20:14 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 19:20:14 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Sun, 20 Jul 2008 19:20:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjojRzMcym/0QQDQiGoqY7rIKtsBAB/9TLwAAxHpiA= References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "David Miles" Cc: "v6ops WG" X-OriginalArrivalTime: 20 Jul 2008 23:20:14.0480 (UTC) FILETIME=[2A06C900:01C8EABF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2476; t=1216596014; x=1217460014; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22David=20Miles=22=20; bh=Q4gX27ZV4Oy6Ofm9m1M9YnFpV9AzX3nndd53Oj+B67k=; b=IIozvQXRd5xZfesK1zCp7V470Etu0w+L0R2KAnx02OmDsX7pqCmsop9swE De35qKXQT5gSctZQ/nqMU0b0QLUSBSYm4/WT+hJwWFmav4oSFN7ySTuHGv/q CU1um6zR/e; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, Here is a list of TBD items on our draft from the -02 version that includes our responses till now. As I said earlier, till it continues to make sense, I will publish such a list every Friday (if the list has changed) till all the requirements in the draft have gestated.=20 1. Reference RFC4605 in the mcast section because our proposal is similar to RFC4605. Need to give an example to Remi to show explicitly how mcast works in the CPE Router. The example is not planned to be added to the draft.=20 2. Add IP addr assignment of global IPv6 addr from IA_PD to the Unnumbered model (5.3.2) section. Also change some text in section 5 for IA_PD and this global address assignment. 3. Change text for Loopback interface that says "facing the WAN" - done. 4. Add to softwire section to track SNAT and dual-lite drafts and each draft's gross requirements including the fact that dual-lite supports v4 in v6 encap and not softwire. 5. Any auto-detection, if possible, for DHCP vs. PPPOE for WAN. 6. Add placeholder for local proxy DNS server to draft to -03 version and then complete this section in a later version. 7. Section 5.5 needs to add NTP option and any other options to pass to hosts in the home. 8. For IA_PD addr to be assigned to Loopback, should we suggest assigning prefix::1 to the WAN interface? 9. Tone down language for LAN hosts doing SLAAC vs. DHCPv6? 10. Add text to PPP section to mention that such links will also acquire global IPv6 address using SLAAC or DHCPv6 or from IA_PD even though the section 5.3 of the draft already mentions the same fact. This TBD makes the PPP section more clear. 11. Section 6, "Cascading of Routers behind the CPE Router" will add text to say RIPng may be used in the home for routing across a cascaded router set in the home. We have already changed the document to use RIPng and not RIPv6. No other mention of routing for the home is necessary and out of scope of our document. 12. May make sense to add a Reload section to the draft. Need to get back to the mailer on this one. 13. Fold in some text from RFC3633 for verifying of IA_PD prefix across CPE Router reload, or WAN interface bounce. 14. Make a new sub-section called "Both Models" and move text from end of section 5.3.2 to this new sub-section. Text may change for the new sub-section to align with the new version of the draft. Hemant From owner-v6ops@ops.ietf.org Sun Jul 20 17:49:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BF13A6AAC for ; Sun, 20 Jul 2008 17:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4tBq9qIdYdW for ; Sun, 20 Jul 2008 17:49:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44FF43A6A8C for ; Sun, 20 Jul 2008 17:49:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjYX-000KBY-95 for v6ops-data@psg.com; Mon, 21 Jul 2008 00:47:13 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjYT-000KBB-5i for v6ops@ops.ietf.org; Mon, 21 Jul 2008 00:47:11 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14827298" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 00:47:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6L0l76w005723; Sun, 20 Jul 2008 20:47:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6L0l7uo017252; Mon, 21 Jul 2008 00:47:07 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 20:47:07 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Sun, 20 Jul 2008 20:47:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpUX2gLik3YsKjQ6ms+cph8Bxp+QAAX4YqAF23ajA= References: <4881629F.60703@gmail.com> From: "Hemant Singh (shemant)" To: "Alain Durand" , "Brian E Carpenter" Cc: , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 00:47:07.0746 (UTC) FILETIME=[4D600C20:01C8EACB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2517; t=1216601227; x=1217465227; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Brian=20E=20Carpenter=22=2 0; bh=zqmsNp7xr0ZFYgi5n9mENfSJEcCg6kt845ELydSXwpA=; b=GklRfztIT4VXZ4nTS1OeeQ4G8Epim+qtSATC7sdVpKKzx2r+7b9Q2ZKtbB Rv7P8Z3D2nfCt0/GtRloW3NEVIYeMfIqOsC4h9WAIQgI9c4hX1lFdIMF4PIR VWiggsuypB; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Please go back to this draft's emails and see how Wes, I, and Remi discussed the ULA case and a MUST requirement. Your idea below is not valid because you have not considered the case of a standalone CPE Router that is purchased from retail. The user will power on the CPE Router at home and the LAN interface(s) of the router will be up first - the user hasn't connected the WAN port yet to the broadband network. The user needs some IPv6 address to configure the CPE Router via the web. That is why the ULA will be used. We have also said in our draft that manual configuration is out of scope of our draft - therefore we are not worried about details like how does the user get to know the ULA prior to logging on to the CPE Router over the web using this ULA. If need be, we can also work on such details but there is no dispensing with ULA. I too like Brian's suggestion of once per factory-reset and further I prefer a well-known ULA address publishes apriori in the CPE Router manuals for the user to use that address to configure the CPE Router. After configuration, any other ULA may be generated and the router reset to use the new ULA and associated ULA prefix(es). Only for the case when the CPE Router is embedded in a broadband device like a modem and thus managed by the SP, the ULA's will not be spawned as this is a WAN init first before LAN init model of our draft. See my other comments about WAN init first model also complying with CableLab docsis 3.0 standards.=20 Hemant =20 -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Friday, July 18, 2008 11:53 PM To: Brian E Carpenter Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review On 7/18/08 11:42 PM, "Brian E Carpenter" wrote: >> I would rather like the text to recommend to only use ULA when=20 >> nothing else is available and immediately renumber to GUA when those are acquired. >=20 > IMHO that is only acceptable if there MUST be a configurable option to > support a ULA (generated once per factory-reset) in parallel with a=20 > GUA, if that's what the user wants. I think that is needed for=20 > scenarios where people want addresses for devices that are guaranteed=20 > never to reply to external packets. I'd agree to this if, by default, parallel ULA support is off. - Alain. From owner-v6ops@ops.ietf.org Sun Jul 20 18:43:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86CA3A6AD4 for ; Sun, 20 Jul 2008 18:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.766 X-Spam-Level: X-Spam-Status: No, score=-4.766 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HMED-cE62lf for ; Sun, 20 Jul 2008 18:43:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E17103A6AD3 for ; Sun, 20 Jul 2008 18:43:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKkPV-0004Pq-EJ for v6ops-data@psg.com; Mon, 21 Jul 2008 01:41:57 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKkPP-0004Oz-SK for v6ops@ops.ietf.org; Mon, 21 Jul 2008 01:41:53 +0000 X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="14828835" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 01:41:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6L1foL6001578; Sun, 20 Jul 2008 21:41:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6L1foHE025799; Mon, 21 Jul 2008 01:41:50 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 21:41:50 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 21:41:29 -0400 Message-ID: In-Reply-To: <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjqoDuU1Vz10piuRdWh6pMxrn6GxwALIlJA References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 01:41:50.0568 (UTC) FILETIME=[F216EE80:01C8EAD2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7128; t=1216604510; x=1217468510; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20; bh=ZoXjiJh738EkjSgA7edfr2bvFcJjfiGT2eqKtQgBqpg=; b=W02cz+e9vZDAv7BD2hCAkEF2TbbRu6X7Y1AjMLYVnuqGvDt3Sjw/6TjMLz oBwGhdAtWWLciBOEoeEKeNQhaDpG3hN7ZmeIlGCH+9ZRZJNg8FPQ2nRr6ztC 3KVP/wb1Jg; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We are NOT adding any uRPF check feature to the CPE Router WAN on LAN interface(s) nor any ping throttle feature for ping reqs or responses. These are just topics being discussed. uRPF was only given as an example to say why CPE Router cannot work with just a link-local on the WAN interface. We want to focus first on getting a complete set of requirements from DSL folks and then see what does the draft shape out to be. In our -00 version of the draft, the draft was complete for cable deployment because cable has completed docsis 3.0 standards for IPv6 as of two years back and also an embedded CPE Router cable modem standard completed in May 2007. =20 We have clearly said to this mailer early on, that till we get a common consensus between DSL providers like AT&T, NTT, DSLForum folks like David Miles, and a Mikael A., nothing in this draft is concrete. Of course, I and Wes gave our cable recommendation to the DSL guys in -00 version but they didn't like it. Our cable recommendation in the -00 version has nothing to do with IA_PD and stateless DHCPv6, or a Loopback interface, or a WAN interface with only a link-local address. During the course of -01 and -02 versions we were attempting to fold in requirements from DSL and that has caused some problems in the draft. The DSL requirements from NTT, AT&T, and a Mikael have been varied. You guessed correctly. The Loopback interface cannot ask for IA_PD using stateless DHCPv6 if the Loopback interface hasn't acquired a global IPv6 address. The RFC for stateless DHCPv6 in RFC3736 clearly says the following in the Abstract section. [A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration.]. So the Loopback solution for DSL guys in our -02 version doesn't look good even though Mikael A., and David Miles suggested this path to us. As you can see we are still analyzing the solution and questioning requirements. The Loopback interface would need to acquire a global IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC doesn't support getting IA_PD). Also during stateful DHCPv6, the IA_PD is doled out to the interface and the interface also gets an IA_NA. Since the interface already got a global address in the IA_NA, then what's the point of assigning the interface an IPv6 address out of the IA_PD? So will one release the IA_NA, and then configure an address on the interface from the IA_PD? I don't like such machinations. Clearly, the DSL requirements are not flushed out yet for us. Also, you can keep arguing about router vs. interface and who's correct or not. If the CPE Router needs a global address, the next question folks will ask is what interface on the CPE Router does the global address gets assigned to? We are describing such details. Also, the virtual Loopback interface is in the same link-local domain as the WAN interface. Therefore any RA sent to the WAN interface has to be also seen by the Loopback interface (CPE Router internals have to take care of this). So then it is legal for the Loopback to use the RA seen by the WAN interface and the proceed to get a global IPv6 address for the Loopback address using SLAAC or DHCPv6.=20 Hemant =20 -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Sunday, July 20, 2008 3:39 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: >> 3. I disagree with the behavior suggested for "unnumbered" model. I=20 >> don't think a CPE router should automatically open up a maintenance=20 >> loopback interface just because it doesn't get a global IP address. > Would you PLEASE use normal quoting techniques? Reading email costs enough time as it is without everyone doing stuff in their own particular way so automation and habits don't work. > Not quite. The unnumbered model is clearly saying the WAN interface=20 > only acquires on a link-local address. But the WAN interface of the=20 > CPE Router has got to have a global IPv6 address. You are being extremely imprecise. That is one of the reasons your draft is in such bad shape. The INTERFACE doesn't need a global address, but the ROUTER does. > So what choice does the > CPE Router have but to automatically spawn a Loopback interface that=20 > will get assigned a global IPv6 address When you need to create a packet, use a source address from another interface that you have, i.e. a LAN interface. I believe this is explained in the base IPv6 specs. Or ask within your company about the behavior of "ipv6 unnumbered ..." > (using SLAAC, Creating addresses using stateless autoconfig on an interface different than the one where the RAs were received is very wrong. > DHCPv6 Using DHCPv6 address configuration on a router makes no sense in my opinion. > stateless DHCPv6 to acquire an IA_PD). I don't think prefix delegation is possible in the stateless version of DHCPv6. On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > The draft clearly says what ICMPv6 errors are returned by the CPE=20 > Router, so it's not like the CPE Router is not responding to any > ICMPv6 > request. Good. > Existing IPv4 routers do have a ping disable feature where the router=20 > is configured to not respond to pings. You are again using imprecise terminology. What you mean is IPv4 CPEs with NAT functionality. That has little to do with routing. For IPv6, CPEs do have to be real routers and conform to normal router behavior unless we specify exceptions. It is of course allowed to not return echo replies. However, since the router MUST generate other ICMPv6 messages under other circumstances, not replying to pings doesn't make the router invisible so there is little point in not returning ping replies. > I also said on this > thread that if the CPE Router does respond to pings, the CPE Router=20 > needs to rate limit incoming ping reqs. You say that you want to rate limit INCOMING pings. (Which is useless anyway because the LAN bandwidth is much higher than the WAN bandwdith.) If you want to do this, it makes no sense to tie that to whether or not ping replies are sent. For the router itself this is a non-issue because the IPv6 specs mandate that ICMPv6 messages are rate limited anyway. On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > Please see the complete uRPF thread that we discussed on this mailer - > they were emails between July 15 - 16th, 2008. I read it earlier today. It didn't make much sense to me. But now it occurs to me that you actually want to run uRPF on the CPE itself. I don't see how that's useful. What you want to do is filter out outgoing packets on the WAN interface if they don't have a source address that is either in the prefix delegated by the ISP or have the router's own WAN address as a source address. From owner-v6ops@ops.ietf.org Sun Jul 20 19:03:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014B03A685A for ; Sun, 20 Jul 2008 19:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.762 X-Spam-Level: X-Spam-Status: No, score=-4.762 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8ihYV29X48L for ; Sun, 20 Jul 2008 19:03:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C9813A6837 for ; Sun, 20 Jul 2008 19:03:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKkhm-0007gB-9l for v6ops-data@psg.com; Mon, 21 Jul 2008 02:00:50 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKkhh-0007fj-6c for v6ops@ops.ietf.org; Mon, 21 Jul 2008 02:00:47 +0000 X-IronPort-AV: E=Sophos;i="4.31,220,1215388800"; d="scan'208";a="14829456" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 02:00:43 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6L20h4R005754; Sun, 20 Jul 2008 22:00:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6L20hp2028291; Mon, 21 Jul 2008 02:00:43 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jul 2008 22:00:43 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Sun, 20 Jul 2008 22:00:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjqoDuU1Vz10piuRdWh6pMxrn6GxwALIlJAAAG36iA= References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Iljitsch van Beijnum" Cc: "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 02:00:43.0768 (UTC) FILETIME=[95878780:01C8EAD5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8332; t=1216605643; x=1217469643; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22Iljitsch=20van=20Beijnum=22 =20; bh=E0rREe8AYbly609MiGjYi62SU3+HaPnAKvRE9WtyJtQ=; b=ruYgZ4WPQxlw5168xfC52btz9/i/8mmHg1f6+z+5WvbyCCTSypN2kalBTe o++wghhwat4DBZoKBGVDfoC7AyTT1ACYp9RAjhmDqwZvnGu+hMnRh1y01RK1 WFloFggDAi; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For Iljitsch van Beijnum related to his question on whether IA_PD could be asked of by stateless DHCPv6: Sorry one correction for this statement in the email below.=20 "The Loopback interface would need to acquire a global IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC doesn't support getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)." The Loopback interface may acquire the global IPv6 address using SLAAC and not necessarily DHCPv6. Then since the Loopback interface does have a global address, then I believe it is permissible for stateless DHCPv6 to get IA_PD by specifying the IA_PD option in the ORO? We need to check if RFC3633 explicitly prohibits asking for IA_PD by stateless DHCPv6? Ole, what say you - thanks? Anyhow, the problem still remains that we expire the SLAAC address and then reassign an address from IA_PD. Same old ugliness. Hemant =20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Sunday, July 20, 2008 9:41 PM To: Iljitsch van Beijnum Cc: IPv6 Operations Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt We are NOT adding any uRPF check feature to the CPE Router WAN on LAN interface(s) nor any ping throttle feature for ping reqs or responses. These are just topics being discussed. uRPF was only given as an example to say why CPE Router cannot work with just a link-local on the WAN interface. We want to focus first on getting a complete set of requirements from DSL folks and then see what does the draft shape out to be. In our -00 version of the draft, the draft was complete for cable deployment because cable has completed docsis 3.0 standards for IPv6 as of two years back and also an embedded CPE Router cable modem standard completed in May 2007. =20 We have clearly said to this mailer early on, that till we get a common consensus between DSL providers like AT&T, NTT, DSLForum folks like David Miles, and a Mikael A., nothing in this draft is concrete. Of course, I and Wes gave our cable recommendation to the DSL guys in -00 version but they didn't like it. Our cable recommendation in the -00 version has nothing to do with IA_PD and stateless DHCPv6, or a Loopback interface, or a WAN interface with only a link-local address. During the course of -01 and -02 versions we were attempting to fold in requirements from DSL and that has caused some problems in the draft. The DSL requirements from NTT, AT&T, and a Mikael have been varied. You guessed correctly. The Loopback interface cannot ask for IA_PD using stateless DHCPv6 if the Loopback interface hasn't acquired a global IPv6 address. The RFC for stateless DHCPv6 in RFC3736 clearly says the following in the Abstract section. [A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration.]. So the Loopback solution for DSL guys in our -02 version doesn't look good even though Mikael A., and David Miles suggested this path to us. As you can see we are still analyzing the solution and questioning requirements. The Loopback interface would need to acquire a global IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC doesn't support getting IA_PD). Also during stateful DHCPv6, the IA_PD is doled out to the interface and the interface also gets an IA_NA. Since the interface already got a global address in the IA_NA, then what's the point of assigning the interface an IPv6 address out of the IA_PD? So will one release the IA_NA, and then configure an address on the interface from the IA_PD? I don't like such machinations. Clearly, the DSL requirements are not flushed out yet for us. Also, you can keep arguing about router vs. interface and who's correct or not. If the CPE Router needs a global address, the next question folks will ask is what interface on the CPE Router does the global address gets assigned to? We are describing such details. Also, the virtual Loopback interface is in the same link-local domain as the WAN interface. Therefore any RA sent to the WAN interface has to be also seen by the Loopback interface (CPE Router internals have to take care of this). So then it is legal for the Loopback to use the RA seen by the WAN interface and the proceed to get a global IPv6 address for the Loopback address using SLAAC or DHCPv6.=20 Hemant =20 -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Sunday, July 20, 2008 3:39 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: >> 3. I disagree with the behavior suggested for "unnumbered" model. I=20 >> don't think a CPE router should automatically open up a maintenance=20 >> loopback interface just because it doesn't get a global IP address. > Would you PLEASE use normal quoting techniques? Reading email costs enough time as it is without everyone doing stuff in their own particular way so automation and habits don't work. > Not quite. The unnumbered model is clearly saying the WAN interface=20 > only acquires on a link-local address. But the WAN interface of the=20 > CPE Router has got to have a global IPv6 address. You are being extremely imprecise. That is one of the reasons your draft is in such bad shape. The INTERFACE doesn't need a global address, but the ROUTER does. > So what choice does the > CPE Router have but to automatically spawn a Loopback interface that=20 > will get assigned a global IPv6 address When you need to create a packet, use a source address from another interface that you have, i.e. a LAN interface. I believe this is explained in the base IPv6 specs. Or ask within your company about the behavior of "ipv6 unnumbered ..." > (using SLAAC, Creating addresses using stateless autoconfig on an interface different than the one where the RAs were received is very wrong. > DHCPv6 Using DHCPv6 address configuration on a router makes no sense in my opinion. > stateless DHCPv6 to acquire an IA_PD). I don't think prefix delegation is possible in the stateless version of DHCPv6. On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > The draft clearly says what ICMPv6 errors are returned by the CPE=20 > Router, so it's not like the CPE Router is not responding to any > ICMPv6 > request. Good. > Existing IPv4 routers do have a ping disable feature where the router=20 > is configured to not respond to pings. You are again using imprecise terminology. What you mean is IPv4 CPEs with NAT functionality. That has little to do with routing. For IPv6, CPEs do have to be real routers and conform to normal router behavior unless we specify exceptions. It is of course allowed to not return echo replies. However, since the router MUST generate other ICMPv6 messages under other circumstances, not replying to pings doesn't make the router invisible so there is little point in not returning ping replies. > I also said on this > thread that if the CPE Router does respond to pings, the CPE Router=20 > needs to rate limit incoming ping reqs. You say that you want to rate limit INCOMING pings. (Which is useless anyway because the LAN bandwidth is much higher than the WAN bandwdith.) If you want to do this, it makes no sense to tie that to whether or not ping replies are sent. For the router itself this is a non-issue because the IPv6 specs mandate that ICMPv6 messages are rate limited anyway. On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > Please see the complete uRPF thread that we discussed on this mailer - > they were emails between July 15 - 16th, 2008. I read it earlier today. It didn't make much sense to me. But now it occurs to me that you actually want to run uRPF on the CPE itself. I don't see how that's useful. What you want to do is filter out outgoing packets on the WAN interface if they don't have a source address that is either in the prefix delegated by the ISP or have the router's own WAN address as a source address. From owner-v6ops@ops.ietf.org Sun Jul 20 23:31:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0708E3A69E9 for ; Sun, 20 Jul 2008 23:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VQXgteQwj0y for ; Sun, 20 Jul 2008 23:31:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A12A13A68C0 for ; Sun, 20 Jul 2008 23:31:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKorv-0002Fh-L7 for v6ops-data@psg.com; Mon, 21 Jul 2008 06:27:35 +0000 Received: from [192.100.122.235] (helo=mgw-fb01.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKorq-0002FO-Kw for v6ops@ops.ietf.org; Mon, 21 Jul 2008 06:27:33 +0000 Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6L67BOC020749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Jul 2008 09:07:12 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6L63Eo0030772; Mon, 21 Jul 2008 09:03:24 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 09:03:22 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 09:03:21 +0300 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Mon, 21 Jul 2008 09:03:18 +0300 Message-ID: In-Reply-To: <487F5BCB.1070209@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjoHD8FgJHXgd84Svy+7S99pXU/sgCiGr7g References: <487F5BCB.1070209@it.uc3m.es> From: "teemu.savolainen@nokia.com" To: , , , , , , , , X-OriginalArrivalTime: 21 Jul 2008 06:03:21.0636 (UTC) FILETIME=[7AB1E640:01C8EAF7] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi,=20 >From: ext marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 >Sent: 17 July, 2008 17:49 >So essentially this is tunnel scenario, but rather than being=20 >obtaining a full IPv4 address to use, the host only obtains a=20 >transport address (which is public) The solution can be tunneling, but also also double translation = (4->6->4) as described at least in NATv4v6v4 and MNAT-PT drafts. >There are six obvious transition scenarios: > > o IPv4 system connecting to an IPv4 system across an IPv4 network, > o An IPv6 system connecting to an IPv6 system across an IPv6 > network, > o an IPv4 system connecting to an IPv4 system across an IPv6 > network, > o an IPv6 system connecting to an IPv6 system across an IPv4 > network, > o an IPv4 system connecting to an IPv6 system, or > > > o an IPv6 system connecting to an IPv4 system. > >I understand that we need to include one more: > > o a dual stack system connected to a IPv6 domain that is=20 >connecting to an IPv4 system. Well yes, but then again isn't that essentially the same as having two = of those six obvious scenarios simultaneously at play (v6 connecting to = v6 across v6, and v4 connecting to v4 across v6).=20 >From those six, other scenarios could be build as well, such as = dual-stack connected to IPv4 domain that is connecting to IPv6 system, = or dual-stack connected to dual-stack domain contacting to dual-stack = systems (as already described in chapter 2.1.1). Could it be put this way:"A network can have a combination of the = obvious transition scenarios simultaneously in play. An example of such = a scenario is an IPv4/IPv6 dual-stack system connecting to an IPv4 = system across an IPv6 network."?=20 >In this case, the dual stack host needs to establish a IPv4 in IPv6=20 >tunnel to the tunnel endpoint. In addition to that, the dual stack >needs to obtain a IPv4 address that is valid in the IPv4-only domain. >The simplest option is for the dual stack to obtain an IPv4 public >address. However, this may not be possible due to the shortage of >IPv4 public addresses. The other option is to use an IPv4=20 >private address >(and potentially in conjunction with IPv4 NAT). The other option >is for the dual stack to obtain a public IPv4 transport address. >In all the cases, the acquisition of the address can be=20 >performed dynamically. > > >would this address your inputs? Yes. Though there might be other options as well: shared IPv4 address, = dual-stack lite (if I got it right)? Nevertheless, all are essentially = IPv4 in IPv6 tunnel. Maybe the requirement document should be more vague = about how to actually get the IPv4 address from tunnel endpoint (and = which kind, or none)? One related question: what happened to discussions of doing IPv4->IPv6 = translation on the host and then IPv6->IPv4 on the translation gateway? >---------------------------------------- >-2) Scalability >---------------------------------------- > >Teemu proposed to include: > >2.2. Requirements for the overall transition strategy > >8. Transition architectures should be scalable for large number of >hosts and high data speeds. > >4.2. Important things that SHOULD be supported > >I9: Scalability > >The translation mechanism SHOULD support very large number of hosts and >high data speeds with reasonable infrastructure requirements=20 >considering >equipment available at the transition timeframe. > >I think this makes sense, and i have a hard time finding=20 >someone who don't agrees with this >so i am planning to include them I agree that this is not easily measurable, but I proposed this as for = me it seems that various solutions around have different requirements = for states, cycles, complexities, and it would be good if the solution = proposals would have some considerations written down. E.g. = tunneling-based solution that uses IPsec would have different = requirements for tunnel endpoint than non-IPsec solution. >I10: Discovery > >The translation mechanism SHOULD be quickly discoverable, preferably in >one RTT, to help moving hosts better assess capabilities of available >access networks and to provide good user experience. > >I have a hard time understanding this one. >I mean R1 states: > > R1: Changes in the hosts > > The translation mechanism MUST NOT require changes in the v4-only > nodes to support the Basic requirements described in this section, > unless explicitly stated in the particular requirement. The > translation mechanism MAY require changes to v6-only nodes. > >So if we don't want changes in the host, how can a host have=20 >the discovery mechanisms? I mean,=20 >i think this assuming some other form of solution that is not=20 >based on translation. Well v4-only nodes must remain unchanged and I agree that it is = desirable that changes for v6-nodes would not be needed, but I would not = rule out solutions that does require v6-node changes if so doing provide = (clearly) better functionality than the solutions that do not involve = v6-nodes changes. Couldn't an operator be running two kinds of = solutions: one that helps transition of those unchangeble IPv6-nodes = that are out there already, and improved one that provides better = transition for modified nodes?=20 Furthermore, if multiple solutions are standardized, how a v6-node = attaching to a network knows what solutions are being available there = (unless of course all standardized solutions are invisible to v6-nodes)? >------------------------------------------ >-4) no translation >------------------------------------------ > >this clearly seems contradictory in a requirements fro=20 >translation (no translation) True, it was my confusion (with general requirements I am thinking about = transition commented on wrong place).=20 >------------------------------------------ >-6) Symbian=20 >------------------------------------------ >added symbian to the OS in market timing=20 >consdierations Thank you. Best regards, Teemu From owner-v6ops@ops.ietf.org Mon Jul 21 00:49:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2613A67F8 for ; Mon, 21 Jul 2008 00:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZvoCwuDPZ9P for ; Mon, 21 Jul 2008 00:48:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40E263A6838 for ; Mon, 21 Jul 2008 00:48:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKq6E-000Epc-Hs for v6ops-data@psg.com; Mon, 21 Jul 2008 07:46:26 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKq68-000EpD-J3 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 07:46:23 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 23CE1D00A3; Sun, 20 Jul 2008 21:46:11 -1000 (HST) Date: Sun, 20 Jul 2008 21:46:01 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Alain Durand , Brian E Carpenter , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: <4881629F.60703@gmail.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > Only for the case when the CPE Router is embedded in a broadband device > like a modem and thus managed by the SP, the ULA's will not be spawned > as this is a WAN init first before LAN init model of our draft. See my There are some false assumptions there - unless you are making these required conditions. Combination with a modem does not imply the device is managed by the SP, nor can you assume the WAN connection is actually useable at power-up. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 01:59:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8E23A68B3 for ; Mon, 21 Jul 2008 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyoAosZJgNwY for ; Mon, 21 Jul 2008 01:59:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 468433A688C for ; Mon, 21 Jul 2008 01:59:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrCj-000092-M0 for v6ops-data@psg.com; Mon, 21 Jul 2008 08:57:13 +0000 Received: from [192.100.122.235] (helo=mgw-fb01.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrCf-00008X-95 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 08:57:11 +0000 Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6L8HQoX032435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Jul 2008 11:17:26 +0300 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6L8DfTQ010025; Mon, 21 Jul 2008 11:14:00 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 11:13:48 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 11:13:44 +0300 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 Subject: RE: new draft on IPv6 CPE router available for review Date: Mon, 21 Jul 2008 11:13:40 +0300 Message-ID: In-Reply-To: <23D3F073-7E0B-4A7B-A78C-55574A4E6562@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft on IPv6 CPE router available for review Thread-Index: AcjqYQU6BphDIr32Qx+tdAXgNYmPOgAo9qZQ References: <20080703.050938.104080059.miyakawa@nttv6.jp> <20080704.011411.193726649.miyakawa@nttv6.jp> <23D3F073-7E0B-4A7B-A78C-55574A4E6562@muada.com> From: "teemu.savolainen@nokia.com" To: Cc: , , , , X-OriginalArrivalTime: 21 Jul 2008 08:13:44.0391 (UTC) FILETIME=[B16B9570:01C8EB09] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> I'm not sure if the GGSN even configures itself global address from=20 >> the prefixes it gives to subscribers (does router have to=20 >configure an=20 >> address for itself from the prefixes it sends out in RAs?). I was=20 >> unable to verify this right now. > >No, that requirement went the way of the dodos in IPv6. > >Does this system give the subscriber more than just one /64?=20 >If not, the phone needs to be a bridge and the service=20 >provider will see more individual addresses. Currently just one /64 per bearer. However, a network provider may configure phones to use simultaneously more than one bearer (called PDP contexts or EPS bearers as per 3GPP Release-8). A network provider can choose to configure separate bearers to be used for Internet and Intranet accesses. E.g. browser application may be configured to use bearer that provides only Internet connectivity, while email application may be configured to use bearer that can be used only to access Intranet. There are discussions ongoing about making it possible for phones to get more prefixes with DHCPv6 PD. As far as I see, future cellular system could work like this: - allocate single /64 per bearer (as now) - phone uses SLAAC to configure an address for itself from this prefix (as now) - phone checks (or is preconfigured with required information) whether the recently attached network supports DHCPv6 PD -> if YES - phone gets more prefixes with DHCPv6 PD, and starts to advertise them to LAN -> if NO - phone engages ND Proxy This also gives implementation priority for phones that wish to share the single "WAN" bearer with other devices: ND proxy support is a must, while DHCPv6 PD is a should as it is not guaranteed to be available in all networks the phone may connect to. This approach has the benefit of using just single bearer between phone and cellular network, which saves network's resources (when compared to multiple parallel bearers). Alternative implementation is to have multiple bearers (=3Dmultiple WAN connections), e.g. one bearer for phone's internal applications, and different bearer for LAN use. In this approach network allocates one /64 for the phone's own use, and another /64 for the LAN's use (which can be implemented as a standard dial-up modem like functionality, or as a bridging solution). The multiple bearer solution works however only in certain cellular environments, as there is also a case where a phone is providing IP connectivity to Bluetooth Personal Area Network: when connected to cellular network, the phone may have one or more bearers with DHCPv6 PD or not, but if the phone happens to connect to WLAN hot-spot, it has not other option than to share the WLAN connection between the internal applications and the Bluetooth PAN network. Best regards, Teemu From owner-v6ops@ops.ietf.org Mon Jul 21 02:21:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3393A6804 for ; Mon, 21 Jul 2008 02:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeAUvoecOq4f for ; Mon, 21 Jul 2008 02:21:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 298633A6767 for ; Mon, 21 Jul 2008 02:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrZ7-0003sD-1F for v6ops-data@psg.com; Mon, 21 Jul 2008 09:20:21 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrZ2-0003rp-Vq for v6ops@ops.ietf.org; Mon, 21 Jul 2008 09:20:19 +0000 Received: from dummyhost25.it.uc3m.es (dummyhost19.it.uc3m.es [163.117.139.225])by smtp01.uc3m.es (Postfix) with ESMTP id 3E0E57CB323;Mon, 21 Jul 2008 11:20:05 +0200 (CEST) Message-ID: <488454C4.1070009@it.uc3m.es> Date: Mon, 21 Jul 2008 11:20:04 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <4880763B.4000902@free.fr> <4881FC6C.2030109@it.uc3m.es> <488450F7.8010304@free.fr> In-Reply-To: <488450F7.8010304@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.5225 TC:1F TRN:36 TV:5.5.1026(16044.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Després escribió: > marcelo bagnulo braun - Le 7/19/08 4:38 PM : >> Rémi Després escribió: > >>>> >>>> ,-----. ,-----. >>>> ,' `. ,' `. >>>> / \ / \ >>>> / IPv6-only \ / IPv4-only \ >>>> / Domain +-----------+ Domain \ >>>> ; | Tunnel | : >>>> | | endpoint | | >>>> : +-----+ +-----------+ ; >>>> \ |Dual | / \ +----+ / >>>> \ |Stack| / \ |IPv4| / >>>> \ |Host | / \ |Host| / >>>> `.+-----+,' `. +----+,' >>>> '-----' '-----' >>>> >>>> >>>> >>>> >>>> >>>> In this case, the dual stack host needs to establish a IPv4 in IPv6 >>>> tunnel to the tunnel endpoint. In addition to that, the dual stack >>>> needs to obtain a IPv4 address that is valid in the IPv4-only domain. >>>> The simplest option is for the dual stack to obtain an IPv4 public >>>> address. However, this may not be possible due to the shortage of >>>> IPv4 public addresses. The other option is to use an IPv4 private >>>> address >>>> (and potentially in conjunction with IPv4 NAT). The other option >>>> is for the dual stack to obtain a public IPv4 transport address. >>>> In all the cases, the acquisition of the address can be performed >>>> dynamically. >>> >>> After "... shortage of IPv4 public addresses." you could add: >>> "The other option is to obtain an IPv4 public address with a limited >>> range of usable ports." >>> >> this is already implicity in the IPv4 transport address part > > Not quite: a Transport address cannot IMU be considered equivalent to > an address plus A RANGE of ports. > > (This additional alternative is part of draft-despres-v6ops-apbp-01.) > > New proposal to actually cover the point: after "transport address", > add "or a public IPv4 address plus a limited range of ports". > > >> Teemu proposed to include: >>> >>> Proposal (additions between "s): >>> The translation mechanism SHOULD be quickly discoverable, preferably >>> in one RTT, to help moving "dual stack" hosts "or router CPEs" >>> better assess capabilities of available access networks and to >>> provide good user experience. >>> >>> >> again, this doesn't apply to the translation case, but the second >> tunnel case that we are now including, > >> so this should be included in wherever we decide to make a list fo >> the requirements for these other scenarios > > Is there a reference to see how this tunnel case is introduced? yes, i have included the text that i have mentioned above, describing this scenario > > > Regards. > > Rémi > > > > From owner-v6ops@ops.ietf.org Mon Jul 21 02:22:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE103A688D for ; Mon, 21 Jul 2008 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueZ43yYTvuZT for ; Mon, 21 Jul 2008 02:22:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDD5B3A6804 for ; Mon, 21 Jul 2008 02:22:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrbY-0004Jk-7m for v6ops-data@psg.com; Mon, 21 Jul 2008 09:22:52 +0000 Received: from [212.27.60.43] (helo=postfix2-g20.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrbU-0004JG-62 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 09:22:50 +0000 Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by postfix2-g20.free.fr (Postfix) with ESMTP id 024E5283F01D for ; Mon, 21 Jul 2008 09:04:41 +0200 (CEST) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 3960A3EA0AB; Mon, 21 Jul 2008 11:04:28 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 102423EA0B9; Mon, 21 Jul 2008 11:04:26 +0200 (CEST) Message-ID: <488450F7.8010304@free.fr> Date: Mon, 21 Jul 2008 11:03:51 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: 'IPv6 Operations' , Fred Baker , Dan Wing , teemu.savolainen@nokia.com, Brian E Carpenter , Alain_Durand@cable.comcast.com, Jari Arkko , Philip Matthews Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <4880763B.4000902@free.fr> <4881FC6C.2030109@it.uc3m.es> In-Reply-To: <4881FC6C.2030109@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun - Le 7/19/08 4:38 PM : > Rémi Després escribió: >>> >>> ,-----. ,-----. >>> ,' `. ,' `. >>> / \ / \ >>> / IPv6-only \ / IPv4-only \ >>> / Domain +-----------+ Domain \ >>> ; | Tunnel | : >>> | | endpoint | | >>> : +-----+ +-----------+ ; >>> \ |Dual | / \ +----+ / >>> \ |Stack| / \ |IPv4| / >>> \ |Host | / \ |Host| / >>> `.+-----+,' `. +----+,' >>> '-----' '-----' >>> >>> >>> >>> >>> >>> In this case, the dual stack host needs to establish a IPv4 in IPv6 >>> tunnel to the tunnel endpoint. In addition to that, the dual stack >>> needs to obtain a IPv4 address that is valid in the IPv4-only domain. >>> The simplest option is for the dual stack to obtain an IPv4 public >>> address. However, this may not be possible due to the shortage of >>> IPv4 public addresses. The other option is to use an IPv4 private >>> address >>> (and potentially in conjunction with IPv4 NAT). The other option >>> is for the dual stack to obtain a public IPv4 transport address. >>> In all the cases, the acquisition of the address can be performed >>> dynamically. >> >> After "... shortage of IPv4 public addresses." you could add: >> "The other option is to obtain an IPv4 public address with a limited >> range of usable ports." >> > this is already implicity in the IPv4 transport address part Not quite: a Transport address cannot IMU be considered equivalent to an address plus A RANGE of ports. (This additional alternative is part of draft-despres-v6ops-apbp-01.) New proposal to actually cover the point: after "transport address", add "or a public IPv4 address plus a limited range of ports". > Teemu proposed to include: >> >> Proposal (additions between "s): >> The translation mechanism SHOULD be quickly discoverable, preferably >> in one RTT, to help moving "dual stack" hosts "or router CPEs" better >> assess capabilities of available access networks and to provide good >> user experience. >> >> > again, this doesn't apply to the translation case, but the second tunnel > case that we are now including, > so this should be included in wherever we decide to make a list fo the > requirements for these other scenarios Is there a reference to see how this tunnel case is introduced? Regards. Rémi From owner-v6ops@ops.ietf.org Mon Jul 21 02:48:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCDD3A68C4 for ; Mon, 21 Jul 2008 02:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcbuq8ZVAbJx for ; Mon, 21 Jul 2008 02:48:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33A363A68DC for ; Mon, 21 Jul 2008 02:48:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKryI-0008LX-AR for v6ops-data@psg.com; Mon, 21 Jul 2008 09:46:22 +0000 Received: from [69.147.75.103] (helo=web62511.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKry5-0008FU-Kb for v6ops@ops.ietf.org; Mon, 21 Jul 2008 09:46:11 +0000 Received: (qmail 73528 invoked by uid 60001); 21 Jul 2008 09:46:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=wL4FWmwTo4rT+VSU0UHMDp7S3zVTwrdg9UX8nv7c1yiHrUrSO0+aRZXwDe//Ov+6HjVm9RFaQhHSZAAOvYr9M1ACVv6SxjDZWXDWEWAdvi42jcoEfh/r/MgChTmEkF5A9/ZZR6oNmwRdhowMob8Gc69+w9LKDgseRFlQuwzPya4=; Received: from [193.49.124.107] by web62511.mail.re1.yahoo.com via HTTP; Mon, 21 Jul 2008 02:46:04 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 21 Jul 2008 02:46:04 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt To: "Hemant Singh \(shemant\)" Cc: IPv6 Operations , Iljitsch van Beijnum In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <311359.73224.qm@web62511.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: You say "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface." I don't understand your architecture. bridge? no bridge? Can you make a diagram of the WAN side ? Francois-Xavier --- On Sun, 7/20/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > To: "Iljitsch van Beijnum" > Cc: "IPv6 Operations" > Date: Sunday, July 20, 2008, 9:41 PM > We are NOT adding any uRPF check feature to the CPE Router > WAN on LAN > interface(s) nor any ping throttle feature for ping reqs or > responses. > These are just topics being discussed. uRPF was only given > as an > example to say why CPE Router cannot work with just a > link-local on the > WAN interface. > > We want to focus first on getting a complete set of > requirements from > DSL folks and then see what does the draft shape out to be. > In our -00 > version of the draft, the draft was complete for cable > deployment > because cable has completed docsis 3.0 standards for IPv6 > as of two > years back and also an embedded CPE Router cable modem > standard > completed in May 2007. > > > We have clearly said to this mailer early on, that till we > get a common > consensus between DSL providers like AT&T, NTT, > DSLForum folks like > David Miles, and a Mikael A., nothing in this draft is > concrete. Of > course, I and Wes gave our cable recommendation to the DSL > guys in -00 > version but they didn't like it. Our cable > recommendation in the -00 > version has nothing to do with IA_PD and stateless DHCPv6, > or a Loopback > interface, or a WAN interface with only a link-local > address. > > During the course of -01 and -02 versions we were > attempting to fold in > requirements from DSL and that has caused some problems in > the draft. > The DSL requirements from NTT, AT&T, and a Mikael have > been varied. You > guessed correctly. The Loopback interface cannot ask for > IA_PD using > stateless DHCPv6 if the Loopback interface hasn't > acquired a global IPv6 > address. The RFC for stateless DHCPv6 in RFC3736 clearly > says the > following in the Abstract section. > > [A node that uses stateless DHCP must have obtained its > IPv6 addresses > through some other mechanism, typically stateless address > autoconfiguration.]. > > So the Loopback solution for DSL guys in our -02 version > doesn't look > good even though Mikael A., and David Miles suggested this > path to us. > As you can see we are still analyzing the solution and > questioning > requirements. The Loopback interface would need to acquire > a global > IPv6 address first using stateful DHCPv6 (a MUST, because > SLAAC doesn't > support getting IA_PD). Also during stateful DHCPv6, the > IA_PD is doled > out to the interface and the interface also gets an IA_NA. > Since the > interface already got a global address in the IA_NA, then > what's the > point of assigning the interface an IPv6 address out of the > IA_PD? So > will one release the IA_NA, and then configure an address > on the > interface from the IA_PD? I don't like such > machinations. Clearly, the > DSL requirements are not flushed out yet for us. > > Also, you can keep arguing about router vs. interface and > who's correct > or not. If the CPE Router needs a global address, the next > question > folks will ask is what interface on the CPE Router does the > global > address gets assigned to? We are describing such details. > > Also, the virtual Loopback interface is in the same > link-local domain as > the WAN interface. Therefore any RA sent to the WAN > interface has to be > also seen by the Loopback interface (CPE Router internals > have to take > care of this). So then it is legal for the Loopback to use > the RA seen > by the WAN interface and the proceed to get a global IPv6 > address for > the Loopback address using SLAAC or DHCPv6. > > Hemant > > > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, July 20, 2008 3:39 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: Comments on > draft-wbeebee-ipv6-cpe-router-01.txt > > On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: > > >> 3. I disagree with the behavior suggested for > "unnumbered" model. I > >> don't think a CPE router should automatically > open up a maintenance > >> loopback interface just because it doesn't get > a global IP address. > > > > > Would you PLEASE use normal quoting techniques? Reading > email costs > enough time as it is without everyone doing stuff in their > own > particular way so automation and habits don't work. > > > Not quite. The unnumbered model is clearly saying the > WAN interface > > only acquires on a link-local address. But the WAN > interface of the > > CPE Router has got to have a global IPv6 address. > > You are being extremely imprecise. That is one of the > reasons your draft > is in such bad shape. > > The INTERFACE doesn't need a global address, but the > ROUTER does. > > > So what choice does the > > CPE Router have but to automatically spawn a Loopback > interface that > > will get assigned a global IPv6 address > > When you need to create a packet, use a source address from > another > interface that you have, i.e. a LAN interface. I believe > this is > explained in the base IPv6 specs. Or ask within your > company about the > behavior of "ipv6 unnumbered ..." > > > (using SLAAC, > > Creating addresses using stateless autoconfig on an > interface different > than the one where the RAs were received is very wrong. > > > DHCPv6 > > Using DHCPv6 address configuration on a router makes no > sense in my > opinion. > > > stateless DHCPv6 to acquire an IA_PD). > > I don't think prefix delegation is possible in the > stateless version of > DHCPv6. > > On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > > > The draft clearly says what ICMPv6 errors are returned > by the CPE > > Router, so it's not like the CPE Router is not > responding to any > > ICMPv6 > > request. > > Good. > > > Existing IPv4 routers do have a ping disable feature > where the router > > is configured to not respond to pings. > > You are again using imprecise terminology. What you mean is > IPv4 CPEs > with NAT functionality. That has little to do with routing. > For IPv6, > CPEs do have to be real routers and conform to normal > router behavior > unless we specify exceptions. > > It is of course allowed to not return echo replies. > > However, since the router MUST generate other ICMPv6 > messages under > other circumstances, not replying to pings doesn't make > the router > invisible so there is little point in not returning ping > replies. > > > I also said on this > > thread that if the CPE Router does respond to pings, > the CPE Router > > needs to rate limit incoming ping reqs. > > You say that you want to rate limit INCOMING pings. (Which > is useless > anyway because the LAN bandwidth is much higher than the > WAN > bandwdith.) If you want to do this, it makes no sense to > tie that to > whether or not ping replies are sent. For the router itself > this is a > non-issue because the IPv6 specs mandate that ICMPv6 > messages are rate > limited anyway. > > On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > > > Please see the complete uRPF thread that we discussed > on this mailer - > > > they were emails between July 15 - 16th, 2008. > > I read it earlier today. It didn't make much sense to > me. But now it > occurs to me that you actually want to run uRPF on the CPE > itself. I > don't see how that's useful. What you want to do is > filter out outgoing > packets on the WAN interface if they don't have a > source address that is > either in the prefix delegated by the ISP or have the > router's own WAN > address as a source address. From owner-v6ops@ops.ietf.org Mon Jul 21 03:37:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D329C3A6939 for ; Mon, 21 Jul 2008 03:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJzKhApymsPz for ; Mon, 21 Jul 2008 03:37:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAE0E3A6943 for ; Mon, 21 Jul 2008 03:37:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKsjD-000GO3-81 for v6ops-data@psg.com; Mon, 21 Jul 2008 10:34:51 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKsj4-000GNB-3Z for v6ops@ops.ietf.org; Mon, 21 Jul 2008 10:34:44 +0000 X-IronPort-AV: E=Sophos;i="4.31,222,1215388800"; d="scan'208";a="14913025" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2008 10:34:31 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LAYVX5003477; Mon, 21 Jul 2008 12:34:31 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LAYVGk016594; Mon, 21 Jul 2008 10:34:31 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 12:34:30 +0200 Received: from [192.168.1.104] ([10.61.97.220]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 12:34:29 +0200 Cc: Ralph Droms , "Iljitsch van Beijnum" , "IPv6 Operations" Message-Id: <053A4248-3125-4006-8FC1-BC6A5BCC5CE5@cisco.com> From: Ralph Droms To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 06:34:28 -0400 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 10:34:30.0415 (UTC) FILETIME=[5BA491F0:01C8EB1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9452; t=1216636471; x=1217500471; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20; bh=QVVj2DIyc12hBrs8H3GCCxBVv82p/dGx41F1S6X66r4=; b=OeaN5MNuPKems95qXivQCeiMOOxvZ1SxyqpjGxvYcrCY+nKaaHo7IXX8hL CV9fb+zGjw6+4+nbuWfR0rxuj0ZbKDu0rLgoWazEfIHwFYO9PZUEdc+yHOX3 7PAfz1R0rh; Authentication-Results: ams-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Assigning a prefix through DHCPv6 is equivalent to assigning an address, which is inherently stateful. Sections 11 and 12 of RFC 3633 specifies that IA_PD options are carried in Solicit, Advertise, Request and Reply messages (as part of the initial RR<->DR message exchange). I note that RFC 3633 does not explicitly disallow the inclusion of an IA_PD in an Information-Request message (as used in "stateless" DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the text in RFC 3633 that describes the prefix delegation mechanism is, I think, unambiguous in its description of how the IA_PD is used. - Ralph On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) wrote: > For Iljitsch van Beijnum related to his question on whether IA_PD > could > be asked of by stateless DHCPv6: > > Sorry one correction for this statement in the email below. > > "The Loopback interface would need to acquire a global IPv6 address > first using stateful DHCPv6 (a MUST, because SLAAC doesn't support > getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)." > > The Loopback interface may acquire the global IPv6 address using SLAAC > and not necessarily DHCPv6. Then since the Loopback interface does > have > a global address, then I believe it is permissible for stateless > DHCPv6 > to get IA_PD by specifying the IA_PD option in the ORO? We need to > check if RFC3633 explicitly prohibits asking for IA_PD by stateless > DHCPv6? Ole, what say you - thanks? > > Anyhow, the problem still remains that we expire the SLAAC address and > then reassign an address from IA_PD. Same old ugliness. > > Hemant > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Hemant Singh (shemant) > Sent: Sunday, July 20, 2008 9:41 PM > To: Iljitsch van Beijnum > Cc: IPv6 Operations > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > We are NOT adding any uRPF check feature to the CPE Router WAN on LAN > interface(s) nor any ping throttle feature for ping reqs or responses. > These are just topics being discussed. uRPF was only given as an > example to say why CPE Router cannot work with just a link-local on > the > WAN interface. > > We want to focus first on getting a complete set of requirements from > DSL folks and then see what does the draft shape out to be. In our > -00 > version of the draft, the draft was complete for cable deployment > because cable has completed docsis 3.0 standards for IPv6 as of two > years back and also an embedded CPE Router cable modem standard > completed in May 2007. > > > We have clearly said to this mailer early on, that till we get a > common > consensus between DSL providers like AT&T, NTT, DSLForum folks like > David Miles, and a Mikael A., nothing in this draft is concrete. Of > course, I and Wes gave our cable recommendation to the DSL guys in -00 > version but they didn't like it. Our cable recommendation in the -00 > version has nothing to do with IA_PD and stateless DHCPv6, or a > Loopback > interface, or a WAN interface with only a link-local address. > > During the course of -01 and -02 versions we were attempting to fold > in > requirements from DSL and that has caused some problems in the draft. > The DSL requirements from NTT, AT&T, and a Mikael have been varied. > You > guessed correctly. The Loopback interface cannot ask for IA_PD using > stateless DHCPv6 if the Loopback interface hasn't acquired a global > IPv6 > address. The RFC for stateless DHCPv6 in RFC3736 clearly says the > following in the Abstract section. > > [A node that uses stateless DHCP must have obtained its IPv6 addresses > through some other mechanism, typically stateless address > autoconfiguration.]. > > So the Loopback solution for DSL guys in our -02 version doesn't look > good even though Mikael A., and David Miles suggested this path to us. > As you can see we are still analyzing the solution and questioning > requirements. The Loopback interface would need to acquire a global > IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC > doesn't > support getting IA_PD). Also during stateful DHCPv6, the IA_PD is > doled > out to the interface and the interface also gets an IA_NA. Since the > interface already got a global address in the IA_NA, then what's the > point of assigning the interface an IPv6 address out of the IA_PD? So > will one release the IA_NA, and then configure an address on the > interface from the IA_PD? I don't like such machinations. Clearly, > the > DSL requirements are not flushed out yet for us. > > Also, you can keep arguing about router vs. interface and who's > correct > or not. If the CPE Router needs a global address, the next question > folks will ask is what interface on the CPE Router does the global > address gets assigned to? We are describing such details. > > Also, the virtual Loopback interface is in the same link-local > domain as > the WAN interface. Therefore any RA sent to the WAN interface has > to be > also seen by the Loopback interface (CPE Router internals have to take > care of this). So then it is legal for the Loopback to use the RA > seen > by the WAN interface and the proceed to get a global IPv6 address for > the Loopback address using SLAAC or DHCPv6. > > Hemant > > > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, July 20, 2008 3:39 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: > >>> 3. I disagree with the behavior suggested for "unnumbered" model. I >>> don't think a CPE router should automatically open up a maintenance >>> loopback interface just because it doesn't get a global IP address. > >> > > Would you PLEASE use normal quoting techniques? Reading email costs > enough time as it is without everyone doing stuff in their own > particular way so automation and habits don't work. > >> Not quite. The unnumbered model is clearly saying the WAN interface >> only acquires on a link-local address. But the WAN interface of the >> CPE Router has got to have a global IPv6 address. > > You are being extremely imprecise. That is one of the reasons your > draft > is in such bad shape. > > The INTERFACE doesn't need a global address, but the ROUTER does. > >> So what choice does the >> CPE Router have but to automatically spawn a Loopback interface that >> will get assigned a global IPv6 address > > When you need to create a packet, use a source address from another > interface that you have, i.e. a LAN interface. I believe this is > explained in the base IPv6 specs. Or ask within your company about the > behavior of "ipv6 unnumbered ..." > >> (using SLAAC, > > Creating addresses using stateless autoconfig on an interface > different > than the one where the RAs were received is very wrong. > >> DHCPv6 > > Using DHCPv6 address configuration on a router makes no sense in my > opinion. > >> stateless DHCPv6 to acquire an IA_PD). > > I don't think prefix delegation is possible in the stateless version > of > DHCPv6. > > On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > >> The draft clearly says what ICMPv6 errors are returned by the CPE >> Router, so it's not like the CPE Router is not responding to any >> ICMPv6 >> request. > > Good. > >> Existing IPv4 routers do have a ping disable feature where the router >> is configured to not respond to pings. > > You are again using imprecise terminology. What you mean is IPv4 CPEs > with NAT functionality. That has little to do with routing. For IPv6, > CPEs do have to be real routers and conform to normal router behavior > unless we specify exceptions. > > It is of course allowed to not return echo replies. > > However, since the router MUST generate other ICMPv6 messages under > other circumstances, not replying to pings doesn't make the router > invisible so there is little point in not returning ping replies. > >> I also said on this >> thread that if the CPE Router does respond to pings, the CPE Router >> needs to rate limit incoming ping reqs. > > You say that you want to rate limit INCOMING pings. (Which is useless > anyway because the LAN bandwidth is much higher than the WAN > bandwdith.) If you want to do this, it makes no sense to tie that to > whether or not ping replies are sent. For the router itself this is a > non-issue because the IPv6 specs mandate that ICMPv6 messages are rate > limited anyway. > > On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > >> Please see the complete uRPF thread that we discussed on this >> mailer - > >> they were emails between July 15 - 16th, 2008. > > I read it earlier today. It didn't make much sense to me. But now it > occurs to me that you actually want to run uRPF on the CPE itself. I > don't see how that's useful. What you want to do is filter out > outgoing > packets on the WAN interface if they don't have a source address > that is > either in the prefix delegated by the ISP or have the router's own WAN > address as a source address. > > > From owner-v6ops@ops.ietf.org Mon Jul 21 03:51:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85223A6934 for ; Mon, 21 Jul 2008 03:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIm6VdPuS+-2 for ; Mon, 21 Jul 2008 03:51:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D16A93A6810 for ; Mon, 21 Jul 2008 03:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKsyC-000Isv-V7 for v6ops-data@psg.com; Mon, 21 Jul 2008 10:50:20 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKsy8-000IsO-1x for v6ops@ops.ietf.org; Mon, 21 Jul 2008 10:50:18 +0000 X-IronPort-AV: E=Sophos;i="4.31,222,1215388800"; d="scan'208";a="129412717" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2008 10:49:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LAnrBE006092; Mon, 21 Jul 2008 03:49:53 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LAnqgC008529; Mon, 21 Jul 2008 10:49:52 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 06:49:51 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 06:49:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrBe+anni4+5D5QxGhhk2tyfs7CwAGCy1g References: <4881629F.60703@gmail.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Alain Durand" , "Brian E Carpenter" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 10:49:51.0940 (UTC) FILETIME=[80EA2040:01C8EB1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1652; t=1216637393; x=1217501393; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20; bh=okciMIa/UCfdtKNsq3mHM9ra701O73Mfoe6U/DKEr3Q=; b=uxYdKajI89iPeTPFPoR1anvwZvapR81Sb/OCo4/HQvDBZGBXrHoLR9hcQa V8F5mFF2MSjUszNoZsWDNVcS3YaU7Ola2WS+2vfKqvSwVZdA/GFwrjr0B4fE cUFDMD3F/B; Authentication-Results: sj-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: No. See my earlier email to you that said when the CPE Router is embedded in, say, a cable modem, then the WAN interface of the CPE Router becomes an internal logical interface (as opposed to a physically available port in a standalone CPE Router). The logical interface bridges to the cable modem. The cable modem is definitely managed by the ISP and it is this modem's software that can automatically configure the LAN interface(s) of the CPE Router. Cable standards have specified this automatic configuration by the modem. The CPE Router when embedded in a cable modem has to comply to Cable standards.=20 When the WAN interface is internal to the modem there is no question of useable or not. The interface is not even visible to the user. Hemant -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Monday, July 21, 2008 3:46 AM To: Hemant Singh (shemant) Cc: Alain Durand; Brian E Carpenter; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote: > Only for the case when the CPE Router is embedded in a broadband=20 > device like a modem and thus managed by the SP, the ULA's will not be=20 > spawned as this is a WAN init first before LAN init model of our=20 > draft. See my There are some false assumptions there - unless you are making these required conditions. Combination with a modem does not imply the device is managed by the SP, nor can you assume the WAN connection is actually useable at power-up. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 03:54:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADA23A694D for ; Mon, 21 Jul 2008 03:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCscCSRS-Tl5 for ; Mon, 21 Jul 2008 03:54:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EB9F3A6952 for ; Mon, 21 Jul 2008 03:54:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKt2A-000JY2-E2 for v6ops-data@psg.com; Mon, 21 Jul 2008 10:54:26 +0000 Received: from [74.125.46.31] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKt26-000JXh-Es for v6ops@ops.ietf.org; Mon, 21 Jul 2008 10:54:24 +0000 Received: by yw-out-2324.google.com with SMTP id 9so631303ywe.71 for ; Mon, 21 Jul 2008 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xCAm2guRAgakzzCjOB9XRFnLJeH9umjrqZErHCvgMN8=; b=Xy+j2OHMQXh0t+PE9ysGfvapshuBZxA6BlzY4Ime6o/b1L2Kw/IZAItHNZB06+S/hS Rd9fX809NdJVtqPZ7/vwKOjiSX90YdSbB9bxhKBrM9Q81rvz9r87AmZtyViwzazAAjls MjWfZjMRtmRaxpANwXyM5ETEWiHZFfQpjHvoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=HmPapyJZn0wTNFYxu8Z5qZ3iGwja5GPHhN35p1UR3vlUv7YWai2Z2w/FKgR6j2ELuw MAtQ8ZzZt+/KisgMTLF2m50Suq185NWNfGfOCGUXda+Kh22xRWsf4oyh2Cbi1WnROi6w 2+7K4aRTnDxH721uI5UY906z58jLpBk4D5l4M= Received: by 10.151.112.1 with SMTP id p1mr3645732ybm.52.1216637659726; Mon, 21 Jul 2008 03:54:19 -0700 (PDT) Received: by 10.151.26.7 with HTTP; Mon, 21 Jul 2008 03:54:19 -0700 (PDT) Message-ID: <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> Date: Mon, 21 Jul 2008 12:54:19 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Iljitsch van Beijnum" , "IPv6 Operations" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> X-Google-Sender-Auth: 9d232747f066b098 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, > For Iljitsch van Beijnum related to his question on whether IA_PD could > be asked of by stateless DHCPv6: > > Sorry one correction for this statement in the email below. > > "The Loopback interface would need to acquire a global IPv6 address > first using stateful DHCPv6 (a MUST, because SLAAC doesn't support > getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)." > > The Loopback interface may acquire the global IPv6 address using SLAAC > and not necessarily DHCPv6. Then since the Loopback interface does have > a global address, then I believe it is permissible for stateless DHCPv6 > to get IA_PD by specifying the IA_PD option in the ORO? We need to > check if RFC3633 explicitly prohibits asking for IA_PD by stateless > DHCPv6? Ole, what say you - thanks? no, you cannot use stateless DHCP for prefix delegation. I don't understand where you are going with this draft. this is all over the map. several people on this mailing list has tried to correct your misconceptions, but we don't seem to be getting through... e.g: - false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP IA/PD protocols - false: you need a global address on the WAN interface for uRPF - false: loopback interface is required. (it's only purpose is to have a stable always up management interface). > Anyhow, the problem still remains that we expire the SLAAC address and > then reassign an address from IA_PD. Same old ugliness. huh? don't understand this. I would not support this draft to become a working group document. /ot From owner-v6ops@ops.ietf.org Mon Jul 21 03:57:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DCE3A694D for ; Mon, 21 Jul 2008 03:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMrm7uUT3wzL for ; Mon, 21 Jul 2008 03:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F10F3A6941 for ; Mon, 21 Jul 2008 03:57:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKt54-000JxE-DV for v6ops-data@psg.com; Mon, 21 Jul 2008 10:57:26 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKt4y-000Jwn-Vy for v6ops@ops.ietf.org; Mon, 21 Jul 2008 10:57:23 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14855076" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 10:56:43 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LAuh6U005775; Mon, 21 Jul 2008 06:56:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LAuhI8020624; Mon, 21 Jul 2008 10:56:43 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 06:56:42 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 06:56:42 -0400 Message-ID: In-Reply-To: <053A4248-3125-4006-8FC1-BC6A5BCC5CE5@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjrHVz4OO2DyPQrS5m4VySH+6iioAAAiekw References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <053A4248-3125-4006-8FC1-BC6A5BCC5CE5@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" Cc: "Iljitsch van Beijnum" , "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 10:56:42.0893 (UTC) FILETIME=[75DC93D0:01C8EB20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10235; t=1216637803; x=1217501803; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20; bh=06ssQcg6mOnvE9ONq0SnH0htNbb54Z4nNYSwUVQeP3g=; b=IGDXj2jQoXDO0c8uJS88pmvwuM0bhe/X4p9tOFLqQ48Ty5G8RG0CzvsM7U iC4enzWMdNjXrdW/3ReYl8jp4Ke3GWcTYdhe2QRPQJfuqPK0qok3YGNk2bSD 33UPiE+ziB; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ralph, Thanks for the quick reply. I too noticed the text related to Solicit in RFC3633 but that can be misinterpreted to be merely an example because even a 2-way Rapid Commit DHCPv6 could be used with IA_PD. Since we don't see a clear MUST NOT from RFC3633 or RFC3736, one may say IA_PD is fine to use with stateless DHCPv6 as far as the interface has acquired a global address. =20 Hemant -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Monday, July 21, 2008 6:34 AM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Assigning a prefix through DHCPv6 is equivalent to assigning an address, which is inherently stateful. Sections 11 and 12 of RFC 3633 specifies that IA_PD options are carried in Solicit, Advertise, Request and Reply messages (as part of the initial RR<->DR message exchange). I note that RFC 3633 does not explicitly disallow the inclusion of an IA_PD in an Information-Request message (as used in "stateless" =20 DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the text in RFC 3633 that describes the prefix delegation mechanism is, I think, unambiguous in its description of how the IA_PD is used. - Ralph On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) wrote: > For Iljitsch van Beijnum related to his question on whether IA_PD=20 > could be asked of by stateless DHCPv6: > > Sorry one correction for this statement in the email below. > > "The Loopback interface would need to acquire a global IPv6 address=20 > first using stateful DHCPv6 (a MUST, because SLAAC doesn't support=20 > getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)." > > The Loopback interface may acquire the global IPv6 address using SLAAC > and not necessarily DHCPv6. Then since the Loopback interface does=20 > have a global address, then I believe it is permissible for stateless > DHCPv6 > to get IA_PD by specifying the IA_PD option in the ORO? We need to=20 > check if RFC3633 explicitly prohibits asking for IA_PD by stateless=20 > DHCPv6? Ole, what say you - thanks? > > Anyhow, the problem still remains that we expire the SLAAC address and > then reassign an address from IA_PD. Same old ugliness. > > Hemant > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Hemant Singh (shemant) > Sent: Sunday, July 20, 2008 9:41 PM > To: Iljitsch van Beijnum > Cc: IPv6 Operations > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > We are NOT adding any uRPF check feature to the CPE Router WAN on LAN > interface(s) nor any ping throttle feature for ping reqs or responses. > These are just topics being discussed. uRPF was only given as an=20 > example to say why CPE Router cannot work with just a link-local on=20 > the WAN interface. > > We want to focus first on getting a complete set of requirements from=20 > DSL folks and then see what does the draft shape out to be. In our=20 > -00 version of the draft, the draft was complete for cable deployment=20 > because cable has completed docsis 3.0 standards for IPv6 as of two=20 > years back and also an embedded CPE Router cable modem standard=20 > completed in May 2007. > > > We have clearly said to this mailer early on, that till we get a=20 > common consensus between DSL providers like AT&T, NTT, DSLForum folks=20 > like David Miles, and a Mikael A., nothing in this draft is concrete. > Of course, I and Wes gave our cable recommendation to the DSL guys in=20 > -00 version but they didn't like it. Our cable recommendation in the=20 > -00 version has nothing to do with IA_PD and stateless DHCPv6, or a=20 > Loopback interface, or a WAN interface with only a link-local address. > > During the course of -01 and -02 versions we were attempting to fold=20 > in requirements from DSL and that has caused some problems in the=20 > draft. > The DSL requirements from NTT, AT&T, and a Mikael have been varied. =20 > You > guessed correctly. The Loopback interface cannot ask for IA_PD using=20 > stateless DHCPv6 if the Loopback interface hasn't acquired a global > IPv6 > address. The RFC for stateless DHCPv6 in RFC3736 clearly says the=20 > following in the Abstract section. > > [A node that uses stateless DHCP must have obtained its IPv6 addresses > through some other mechanism, typically stateless address=20 > autoconfiguration.]. > > So the Loopback solution for DSL guys in our -02 version doesn't look=20 > good even though Mikael A., and David Miles suggested this path to us. > As you can see we are still analyzing the solution and questioning=20 > requirements. The Loopback interface would need to acquire a global > IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC=20 > doesn't support getting IA_PD). Also during stateful DHCPv6, the=20 > IA_PD is doled out to the interface and the interface also gets an=20 > IA_NA. Since the interface already got a global address in the IA_NA, > then what's the point of assigning the interface an IPv6 address out=20 > of the IA_PD? So will one release the IA_NA, and then configure an=20 > address on the interface from the IA_PD? I don't like such=20 > machinations. Clearly, the DSL requirements are not flushed out yet=20 > for us. > > Also, you can keep arguing about router vs. interface and who's=20 > correct or not. If the CPE Router needs a global address, the next=20 > question folks will ask is what interface on the CPE Router does the=20 > global address gets assigned to? We are describing such details. > > Also, the virtual Loopback interface is in the same link-local domain=20 > as the WAN interface. Therefore any RA sent to the WAN interface has=20 > to be also seen by the Loopback interface (CPE Router internals have=20 > to take care of this). So then it is legal for the Loopback to use=20 > the RA seen by the WAN interface and the proceed to get a global IPv6=20 > address for the Loopback address using SLAAC or DHCPv6. > > Hemant > > > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, July 20, 2008 3:39 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: > >>> 3. I disagree with the behavior suggested for "unnumbered" model. I=20 >>> don't think a CPE router should automatically open up a maintenance=20 >>> loopback interface just because it doesn't get a global IP address. > >> > > Would you PLEASE use normal quoting techniques? Reading email costs=20 > enough time as it is without everyone doing stuff in their own=20 > particular way so automation and habits don't work. > >> Not quite. The unnumbered model is clearly saying the WAN interface=20 >> only acquires on a link-local address. But the WAN interface of the=20 >> CPE Router has got to have a global IPv6 address. > > You are being extremely imprecise. That is one of the reasons your=20 > draft is in such bad shape. > > The INTERFACE doesn't need a global address, but the ROUTER does. > >> So what choice does the >> CPE Router have but to automatically spawn a Loopback interface that=20 >> will get assigned a global IPv6 address > > When you need to create a packet, use a source address from another=20 > interface that you have, i.e. a LAN interface. I believe this is=20 > explained in the base IPv6 specs. Or ask within your company about the > behavior of "ipv6 unnumbered ..." > >> (using SLAAC, > > Creating addresses using stateless autoconfig on an interface=20 > different than the one where the RAs were received is very wrong. > >> DHCPv6 > > Using DHCPv6 address configuration on a router makes no sense in my=20 > opinion. > >> stateless DHCPv6 to acquire an IA_PD). > > I don't think prefix delegation is possible in the stateless version=20 > of DHCPv6. > > On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: > >> The draft clearly says what ICMPv6 errors are returned by the CPE=20 >> Router, so it's not like the CPE Router is not responding to any >> ICMPv6 >> request. > > Good. > >> Existing IPv4 routers do have a ping disable feature where the router >> is configured to not respond to pings. > > You are again using imprecise terminology. What you mean is IPv4 CPEs=20 > with NAT functionality. That has little to do with routing. For IPv6,=20 > CPEs do have to be real routers and conform to normal router behavior=20 > unless we specify exceptions. > > It is of course allowed to not return echo replies. > > However, since the router MUST generate other ICMPv6 messages under=20 > other circumstances, not replying to pings doesn't make the router=20 > invisible so there is little point in not returning ping replies. > >> I also said on this >> thread that if the CPE Router does respond to pings, the CPE Router=20 >> needs to rate limit incoming ping reqs. > > You say that you want to rate limit INCOMING pings. (Which is useless=20 > anyway because the LAN bandwidth is much higher than the WAN > bandwdith.) If you want to do this, it makes no sense to tie that to=20 > whether or not ping replies are sent. For the router itself this is a=20 > non-issue because the IPv6 specs mandate that ICMPv6 messages are rate > limited anyway. > > On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: > >> Please see the complete uRPF thread that we discussed on this mailer=20 >> - > >> they were emails between July 15 - 16th, 2008. > > I read it earlier today. It didn't make much sense to me. But now it=20 > occurs to me that you actually want to run uRPF on the CPE itself. I=20 > don't see how that's useful. What you want to do is filter out=20 > outgoing packets on the WAN interface if they don't have a source=20 > address that is either in the prefix delegated by the ISP or have the=20 > router's own WAN address as a source address. > > > From owner-v6ops@ops.ietf.org Mon Jul 21 04:16:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB0F3A69ED for ; Mon, 21 Jul 2008 04:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVJi4DlyZed1 for ; Mon, 21 Jul 2008 04:16:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 304CF3A67B2 for ; Mon, 21 Jul 2008 04:16:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtMh-000N97-9p for v6ops-data@psg.com; Mon, 21 Jul 2008 11:15:39 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtMc-000N8X-Gx for v6ops@ops.ietf.org; Mon, 21 Jul 2008 11:15:37 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14918334" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2008 11:15:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LBFKst019201; Mon, 21 Jul 2008 13:15:20 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LBFJTE001056; Mon, 21 Jul 2008 11:15:19 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 13:15:19 +0200 Received: from [192.168.1.104] ([10.61.97.220]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 13:15:18 +0200 Cc: Ralph Droms , "Iljitsch van Beijnum" , "IPv6 Operations" Message-Id: <8EBDD23D-D64B-4DF4-A265-BDC34B841300@cisco.com> From: Ralph Droms To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 07:15:15 -0400 References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <053A4248-3125-4006-8FC1-BC6A5BCC5CE5@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 11:15:19.0118 (UTC) FILETIME=[0F2EFEE0:01C8EB23] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11170; t=1216638920; x=1217502920; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20; bh=TKLM1h5H2NNg8ytnDFvuV+w4LwvjuYKIrgCFxIgN+bQ=; b=qUig7XMDmQ0b7sBbrPU3ahAVJclfZopbyZ+pPu2RPx10ikzRYKs77kRqYz teE34QN9qT48UVpQ0RhwxLV2xg6l/2XXrgh00wF/rFWlDePC9SpaU99/ZqXq KTVp/ARld1; Authentication-Results: ams-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The rapid commit mechanism also uses Solicit and Reply in a two message Solicit/Reply message exchange that is still requires per- client state maintenance on the part of the server. Use of rapid commit for prefix delegation is unrelated to the use of "stateless" DHCPv6 for prefix delegation. While I agree that there is no explicit exclusion of the use of an IA_PD in an Information-Request message (as used in "stateless" DHCPv6) or the inclusion of the IA_PD code in an ORO, there has never been any confusion in the past about the implementation of prefix delegation. We could write an errata for RFC 3633 if there is consensus that such an update would be useful. - Ralph On Jul 21, 2008, at Jul 21, 2008,6:56 AM, Hemant Singh (shemant) wrote: > Ralph, > > Thanks for the quick reply. I too noticed the text related to Solicit > in RFC3633 but that can be misinterpreted to be merely an example > because even a 2-way Rapid Commit DHCPv6 could be used with IA_PD. > Since we don't see a clear MUST NOT from RFC3633 or RFC3736, one may > say > IA_PD is fine to use with stateless DHCPv6 as far as the interface has > acquired a global address. > > Hemant > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 6:34 AM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations > Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > Assigning a prefix through DHCPv6 is equivalent to assigning an > address, > which is inherently stateful. > > Sections 11 and 12 of RFC 3633 specifies that IA_PD options are > carried > in Solicit, Advertise, Request and Reply messages (as part of the > initial RR<->DR message exchange). > > I note that RFC 3633 does not explicitly disallow the inclusion of an > IA_PD in an Information-Request message (as used in "stateless" > DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the > text > in RFC 3633 that describes the prefix delegation mechanism is, I > think, > unambiguous in its description of how the IA_PD is used. > > - Ralph > > On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) > wrote: > >> For Iljitsch van Beijnum related to his question on whether IA_PD >> could be asked of by stateless DHCPv6: >> >> Sorry one correction for this statement in the email below. >> >> "The Loopback interface would need to acquire a global IPv6 address >> first using stateful DHCPv6 (a MUST, because SLAAC doesn't support >> getting IA_PD).(a MUST, because SLAAC doesn't support getting >> IA_PD)." >> >> The Loopback interface may acquire the global IPv6 address using >> SLAAC > >> and not necessarily DHCPv6. Then since the Loopback interface does >> have a global address, then I believe it is permissible for stateless >> DHCPv6 >> to get IA_PD by specifying the IA_PD option in the ORO? We need to >> check if RFC3633 explicitly prohibits asking for IA_PD by stateless >> DHCPv6? Ole, what say you - thanks? >> >> Anyhow, the problem still remains that we expire the SLAAC address >> and > >> then reassign an address from IA_PD. Same old ugliness. >> >> Hemant >> >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Hemant Singh (shemant) >> Sent: Sunday, July 20, 2008 9:41 PM >> To: Iljitsch van Beijnum >> Cc: IPv6 Operations >> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >> >> We are NOT adding any uRPF check feature to the CPE Router WAN on LAN >> interface(s) nor any ping throttle feature for ping reqs or >> responses. >> These are just topics being discussed. uRPF was only given as an >> example to say why CPE Router cannot work with just a link-local on >> the WAN interface. >> >> We want to focus first on getting a complete set of requirements from >> DSL folks and then see what does the draft shape out to be. In our >> -00 version of the draft, the draft was complete for cable deployment >> because cable has completed docsis 3.0 standards for IPv6 as of two >> years back and also an embedded CPE Router cable modem standard >> completed in May 2007. >> >> >> We have clearly said to this mailer early on, that till we get a >> common consensus between DSL providers like AT&T, NTT, DSLForum folks >> like David Miles, and a Mikael A., nothing in this draft is concrete. > >> Of course, I and Wes gave our cable recommendation to the DSL guys in >> -00 version but they didn't like it. Our cable recommendation in the >> -00 version has nothing to do with IA_PD and stateless DHCPv6, or a >> Loopback interface, or a WAN interface with only a link-local >> address. >> >> During the course of -01 and -02 versions we were attempting to fold >> in requirements from DSL and that has caused some problems in the >> draft. >> The DSL requirements from NTT, AT&T, and a Mikael have been varied. >> You >> guessed correctly. The Loopback interface cannot ask for IA_PD using >> stateless DHCPv6 if the Loopback interface hasn't acquired a global >> IPv6 >> address. The RFC for stateless DHCPv6 in RFC3736 clearly says the >> following in the Abstract section. >> >> [A node that uses stateless DHCP must have obtained its IPv6 >> addresses > >> through some other mechanism, typically stateless address >> autoconfiguration.]. >> >> So the Loopback solution for DSL guys in our -02 version doesn't look >> good even though Mikael A., and David Miles suggested this path to >> us. >> As you can see we are still analyzing the solution and questioning >> requirements. The Loopback interface would need to acquire a global >> IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC >> doesn't support getting IA_PD). Also during stateful DHCPv6, the >> IA_PD is doled out to the interface and the interface also gets an >> IA_NA. Since the interface already got a global address in the >> IA_NA, > >> then what's the point of assigning the interface an IPv6 address out >> of the IA_PD? So will one release the IA_NA, and then configure an >> address on the interface from the IA_PD? I don't like such >> machinations. Clearly, the DSL requirements are not flushed out yet >> for us. >> >> Also, you can keep arguing about router vs. interface and who's >> correct or not. If the CPE Router needs a global address, the next >> question folks will ask is what interface on the CPE Router does the >> global address gets assigned to? We are describing such details. >> >> Also, the virtual Loopback interface is in the same link-local domain >> as the WAN interface. Therefore any RA sent to the WAN interface has >> to be also seen by the Loopback interface (CPE Router internals have >> to take care of this). So then it is legal for the Loopback to use >> the RA seen by the WAN interface and the proceed to get a global IPv6 >> address for the Loopback address using SLAAC or DHCPv6. >> >> Hemant >> >> >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Sunday, July 20, 2008 3:39 PM >> To: Hemant Singh (shemant) >> Cc: IPv6 Operations >> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >> >> On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: >> >>>> 3. I disagree with the behavior suggested for "unnumbered" model. I >>>> don't think a CPE router should automatically open up a maintenance >>>> loopback interface just because it doesn't get a global IP address. >> >>> >> >> Would you PLEASE use normal quoting techniques? Reading email costs >> enough time as it is without everyone doing stuff in their own >> particular way so automation and habits don't work. >> >>> Not quite. The unnumbered model is clearly saying the WAN interface >>> only acquires on a link-local address. But the WAN interface of the >>> CPE Router has got to have a global IPv6 address. >> >> You are being extremely imprecise. That is one of the reasons your >> draft is in such bad shape. >> >> The INTERFACE doesn't need a global address, but the ROUTER does. >> >>> So what choice does the >>> CPE Router have but to automatically spawn a Loopback interface that >>> will get assigned a global IPv6 address >> >> When you need to create a packet, use a source address from another >> interface that you have, i.e. a LAN interface. I believe this is >> explained in the base IPv6 specs. Or ask within your company about >> the > >> behavior of "ipv6 unnumbered ..." >> >>> (using SLAAC, >> >> Creating addresses using stateless autoconfig on an interface >> different than the one where the RAs were received is very wrong. >> >>> DHCPv6 >> >> Using DHCPv6 address configuration on a router makes no sense in my >> opinion. >> >>> stateless DHCPv6 to acquire an IA_PD). >> >> I don't think prefix delegation is possible in the stateless version >> of DHCPv6. >> >> On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: >> >>> The draft clearly says what ICMPv6 errors are returned by the CPE >>> Router, so it's not like the CPE Router is not responding to any >>> ICMPv6 >>> request. >> >> Good. >> >>> Existing IPv4 routers do have a ping disable feature where the >>> router > >>> is configured to not respond to pings. >> >> You are again using imprecise terminology. What you mean is IPv4 CPEs >> with NAT functionality. That has little to do with routing. For IPv6, >> CPEs do have to be real routers and conform to normal router behavior >> unless we specify exceptions. >> >> It is of course allowed to not return echo replies. >> >> However, since the router MUST generate other ICMPv6 messages under >> other circumstances, not replying to pings doesn't make the router >> invisible so there is little point in not returning ping replies. >> >>> I also said on this >>> thread that if the CPE Router does respond to pings, the CPE Router >>> needs to rate limit incoming ping reqs. >> >> You say that you want to rate limit INCOMING pings. (Which is useless >> anyway because the LAN bandwidth is much higher than the WAN >> bandwdith.) If you want to do this, it makes no sense to tie that to >> whether or not ping replies are sent. For the router itself this is a >> non-issue because the IPv6 specs mandate that ICMPv6 messages are >> rate > >> limited anyway. >> >> On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: >> >>> Please see the complete uRPF thread that we discussed on this mailer >>> - >> >>> they were emails between July 15 - 16th, 2008. >> >> I read it earlier today. It didn't make much sense to me. But now it >> occurs to me that you actually want to run uRPF on the CPE itself. I >> don't see how that's useful. What you want to do is filter out >> outgoing packets on the WAN interface if they don't have a source >> address that is either in the prefix delegated by the ISP or have the >> router's own WAN address as a source address. >> >> >> > From owner-v6ops@ops.ietf.org Mon Jul 21 04:26:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF243A69CC for ; Mon, 21 Jul 2008 04:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPVum8ucsXaT for ; Mon, 21 Jul 2008 04:26:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE97C3A698E for ; Mon, 21 Jul 2008 04:26:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtWz-000P5x-Lk for v6ops-data@psg.com; Mon, 21 Jul 2008 11:26:17 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtWv-000P5Y-1R for v6ops@ops.ietf.org; Mon, 21 Jul 2008 11:26:15 +0000 Received: from dummyhost25.it.uc3m.es (unknown [163.117.139.225])by smtp03.uc3m.es (Postfix) with ESMTP id 3889649075F;Mon, 21 Jul 2008 13:22:45 +0200 (CEST) Message-ID: <48847184.9020906@it.uc3m.es> Date: Mon, 21 Jul 2008 13:22:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: teemu.savolainen@nokia.com CC: v6ops@ops.ietf.org, fred@cisco.com, dwing@cisco.com, brian.e.carpenter@gmail.com, Alain_Durand@cable.comcast.com, remi.despres@free.fr, jari.arkko@piuha.net, philip_matthews@magma.ca Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.0222 TC:1F TRN:74 TV:5.5.1026(16044.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: teemu.savolainen@nokia.com escribió: > Hi, > > >> From: ext marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: 17 July, 2008 17:49 >> > > >> So essentially this is tunnel scenario, but rather than being >> obtaining a full IPv4 address to use, the host only obtains a >> transport address (which is public) >> > > The solution can be tunneling, but also also double translation (4->6->4) as described at least in NATv4v6v4 and MNAT-PT drafts. > but we are not reccomending that, right? i mean this document is supposed to be a reccomednation, and the point is that is not what we reccomend afaiu > >> There are six obvious transition scenarios: >> >> o IPv4 system connecting to an IPv4 system across an IPv4 network, >> o An IPv6 system connecting to an IPv6 system across an IPv6 >> network, >> o an IPv4 system connecting to an IPv4 system across an IPv6 >> network, >> o an IPv6 system connecting to an IPv6 system across an IPv4 >> network, >> o an IPv4 system connecting to an IPv6 system, or >> >> >> o an IPv6 system connecting to an IPv4 system. >> >> I understand that we need to include one more: >> >> o a dual stack system connected to a IPv6 domain that is >> connecting to an IPv4 system. >> > > Well yes, but then again isn't that essentially the same as having two of those six obvious scenarios simultaneously at play (v6 connecting to v6 across v6, and v4 connecting to v4 across v6). > > >From those six, other scenarios could be build as well, such as dual-stack connected to IPv4 domain that is connecting to IPv6 system, or dual-stack connected to dual-stack domain contacting to dual-stack systems (as already described in chapter 2.1.1). > > Could it be put this way:"A network can have a combination of the obvious transition scenarios simultaneously in play. An example of such a scenario is an IPv4/IPv6 dual-stack system connecting to an IPv4 system across an IPv6 network."? > that is why it says simple sceanrios :-) i mean, i certainly see we can come up with very complex scenarions with a combination of all this. the question is whether we think these are so relevant to be explicitly mentioned. I think the rpevious ones are the basic ones and the others can be elaborated from these > >> In this case, the dual stack host needs to establish a IPv4 in IPv6 >> tunnel to the tunnel endpoint. In addition to that, the dual stack >> needs to obtain a IPv4 address that is valid in the IPv4-only domain. >> The simplest option is for the dual stack to obtain an IPv4 public >> address. However, this may not be possible due to the shortage of >> IPv4 public addresses. The other option is to use an IPv4 >> private address >> (and potentially in conjunction with IPv4 NAT). The other option >> is for the dual stack to obtain a public IPv4 transport address. >> In all the cases, the acquisition of the address can be >> performed dynamically. >> >> >> would this address your inputs? >> > > Yes. Though there might be other options as well: shared IPv4 address, this is what i meant by getting a v4 transport address, right, they share the v4 address and demux based on prtos > dual-stack lite dual stack lite is the tunneling mechanisms > (if I got it right)? Nevertheless, all are essentially IPv4 in IPv6 tunnel. Maybe the requirement document should be more vague about how to actually get the IPv4 address from tunnel endpoint (and which kind, or none)? > right i can try to add a sentence on this > One related question: what happened to discussions of doing IPv4->IPv6 translation on the host and then IPv6->IPv4 on the translation gateway? > > not sure what you mean >> ---------------------------------------- >> -2) Scalability >> ---------------------------------------- >> >> Teemu proposed to include: >> >> 2.2. Requirements for the overall transition strategy >> >> 8. Transition architectures should be scalable for large number of >> hosts and high data speeds. >> >> 4.2. Important things that SHOULD be supported >> >> I9: Scalability >> >> The translation mechanism SHOULD support very large number of hosts and >> high data speeds with reasonable infrastructure requirements >> considering >> equipment available at the transition timeframe. >> >> I think this makes sense, and i have a hard time finding >> someone who don't agrees with this >> so i am planning to include them >> > > I agree that this is not easily measurable, but I proposed this as for me it seems that various solutions around have different requirements for states, cycles, complexities, and it would be good if the solution proposals would have some considerations written down. E.g. tunneling-based solution that uses IPsec would have different requirements for tunnel endpoint than non-IPsec solution. > > right i have kept this one in any case >> I10: Discovery >> >> The translation mechanism SHOULD be quickly discoverable, preferably in >> one RTT, to help moving hosts better assess capabilities of available >> access networks and to provide good user experience. >> >> I have a hard time understanding this one. >> I mean R1 states: >> >> R1: Changes in the hosts >> >> The translation mechanism MUST NOT require changes in the v4-only >> nodes to support the Basic requirements described in this section, >> unless explicitly stated in the particular requirement. The >> translation mechanism MAY require changes to v6-only nodes. >> >> So if we don't want changes in the host, how can a host have >> the discovery mechanisms? I mean, >> i think this assuming some other form of solution that is not >> based on translation. >> > > Well v4-only nodes must remain unchanged and I agree that it is desirable that changes for v6-nodes would not be needed, but I would not rule out solutions that does require v6-node changes if so doing provide (clearly) better functionality than the solutions that do not involve v6-nodes changes. Couldn't an operator be running two kinds of solutions: one that helps transition of those unchangeble IPv6-nodes that are out there already, and improved one that provides better transition for modified nodes? > > Furthermore, if multiple solutions are standardized, how a v6-node attaching to a network knows what solutions are being available there (unless of course all standardized solutions are invisible to v6-nodes)? > > ok, so we can say that we need to be discoverable for v6 nodes if they require updating regards, marcelo >> ------------------------------------------ >> -4) no translation >> ------------------------------------------ >> >> this clearly seems contradictory in a requirements fro >> translation (no translation) >> > > True, it was my confusion (with general requirements I am thinking about transition commented on wrong place). > > >> ------------------------------------------ >> -6) Symbian >> ------------------------------------------ >> added symbian to the OS in market timing >> consdierations >> > > Thank you. > > Best regards, > > Teemu > > From owner-v6ops@ops.ietf.org Mon Jul 21 04:32:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F1E3A6A1F for ; Mon, 21 Jul 2008 04:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eudc-dpBsEH4 for ; Mon, 21 Jul 2008 04:32:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C4F03A68FD for ; Mon, 21 Jul 2008 04:32:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtch-000PzD-Ff for v6ops-data@psg.com; Mon, 21 Jul 2008 11:32:11 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtcc-000Pya-KD for v6ops@ops.ietf.org; Mon, 21 Jul 2008 11:32:09 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14857604" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 11:31:59 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LBVxpA018407; Mon, 21 Jul 2008 07:31:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LBVxBG004032; Mon, 21 Jul 2008 11:31:59 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 07:31:59 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 07:31:58 -0400 Message-ID: In-Reply-To: <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjrICgh6sjgkADvTsi000V00CMNpgAAQHLw References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Iljitsch van Beijnum" , "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 11:31:59.0442 (UTC) FILETIME=[636C5320:01C8EB25] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3522; t=1216639919; x=1217503919; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=AjiHWHLbcGJ7NEimU/JL6PtzQc5nUPqFZ/uX0lIDDdQ=; b=IvORr3XzjrRZooTuNnVVV3Hv/qcO5T0rhX35dQTpBlh29dPB5ZKnINdjMs mXXI4HRrXRPOcFa4ZH6cOcSy9utexSNyBMSVjqKse/jY9PoByFqw3lGsQdea UuUoy4rXkq; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We are not even concerned about the draft being a WG work item. We have not even completed requirements for the device. =20 > no, you cannot use stateless DHCP for prefix delegation. Also, if you say IA_PD is forbidden by stateless DHCPv6, please point to a MUST NOT text in any RFC. > e.g: > - false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP IA/PD protocols The Loopback interface doesn't face the downstream or the upstream. You and I both know RFC3633 has no explicit text that prohibits stateless DHCPv6 asking for IA_PD as I showed how (using the ORO once an interface has acquired a global IPv6 address).=20 > - false: you need a global address on the WAN interface for uRPF If you don't see the obvious problem with uRPF with just a link-local address on the WAN interface, I suggest you go do a test and get back to us. > - false: loopback interface is required. (it's only purpose is to have a stable always up management interface). DSL folks have asked to support the WAN interface acquiring a link-local address. So it is the Loopback interface that acquires a global IPv6 address to source packets to the WAN. If the Loopback interface is not spawned, then since the LAN interface has global IPv6 address, one could say, use the LAN interface global address to source packets to the WAN. But the CPE Router will not even function if the WAN interface has only link-local and the LAN interface has a global IPv6 address - see section 4 of=20 http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt Hemant=20 -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, July 21, 2008 6:54 AM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Hemant, > For Iljitsch van Beijnum related to his question on whether IA_PD=20 > could be asked of by stateless DHCPv6: > > Sorry one correction for this statement in the email below. > > "The Loopback interface would need to acquire a global IPv6 address=20 > first using stateful DHCPv6 (a MUST, because SLAAC doesn't support=20 > getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)." > > The Loopback interface may acquire the global IPv6 address using SLAAC > and not necessarily DHCPv6. Then since the Loopback interface does=20 > have a global address, then I believe it is permissible for stateless=20 > DHCPv6 to get IA_PD by specifying the IA_PD option in the ORO? We=20 > need to check if RFC3633 explicitly prohibits asking for IA_PD by=20 > stateless DHCPv6? Ole, what say you - thanks? no, you cannot use stateless DHCP for prefix delegation. I don't understand where you are going with this draft. this is all over the map. several people on this mailing list has tried to correct your misconceptions, but we don't seem to be getting through... e.g: - false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP IA/PD protocols - false: you need a global address on the WAN interface for uRPF - false: loopback interface is required. (it's only purpose is to have a stable always up management interface). > Anyhow, the problem still remains that we expire the SLAAC address and > then reassign an address from IA_PD. Same old ugliness. huh? don't understand this. I would not support this draft to become a working group document. /ot From owner-v6ops@ops.ietf.org Mon Jul 21 04:39:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517F33A6A0A for ; Mon, 21 Jul 2008 04:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.238 X-Spam-Level: X-Spam-Status: No, score=-4.238 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM0jTqplPcA9 for ; Mon, 21 Jul 2008 04:39:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D7653A698E for ; Mon, 21 Jul 2008 04:39:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKti3-0000xi-7S for v6ops-data@psg.com; Mon, 21 Jul 2008 11:37:43 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKthy-0000xB-2X for v6ops@ops.ietf.org; Mon, 21 Jul 2008 11:37:40 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="129428019" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2008 11:37:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m6LBbUmw015161; Mon, 21 Jul 2008 04:37:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LBbTRX014705; Mon, 21 Jul 2008 11:37:30 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 07:37:29 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 07:37:16 -0400 Message-ID: In-Reply-To: <8EBDD23D-D64B-4DF4-A265-BDC34B841300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjrIxCA8OUjTHjvQDGHH84uogvZHwAABkuQ References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <053A4248-3125-4006-8FC1-BC6A5BCC5CE5@cisco.com> <8EBDD23D-D64B-4DF4-A265-BDC34B841300@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" Cc: "Iljitsch van Beijnum" , "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 11:37:29.0769 (UTC) FILETIME=[28503990:01C8EB26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11837; t=1216640250; x=1217504250; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20; bh=JwF9cXy1LIo4kiRRLuXfcxg+4AnyLJyXUVgKwzI7l6s=; b=y9jkVeZheS8sRUqMKPlI0tdpSUEl454ykwJDbDC1gn1IO7kAgW73q711+a W5qQIVdQp2xgJ5xggA2iBl3yDpZU6TnH+NZBJWRb/M5x4Rf+Th5MC3oUqTdL kfU7z0+7JS; Authentication-Results: sj-dkim-8; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I think errata for RFC3633 makes sense because there is a means in stateless DHCPv6 via which the stateless client can ask for IA_PD and no explicit text in RFC3633 to forbid it. This mailer has a few folks asking stateless DHCPv6 to obtain IA_PD. Folks will use any tool available to them. That is why I say, we should shut the door on this with an errata. Thanks. Hemant -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Monday, July 21, 2008 7:15 AM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt The rapid commit mechanism also uses Solicit and Reply in a two message Solicit/Reply message exchange that is still requires per- client state maintenance on the part of the server. Use of rapid commit for prefix delegation is unrelated to the use of "stateless" =20 DHCPv6 for prefix delegation. While I agree that there is no explicit exclusion of the use of an IA_PD in an Information-Request message (as used in "stateless" =20 DHCPv6) or the inclusion of the IA_PD code in an ORO, there has never been any confusion in the past about the implementation of prefix delegation. We could write an errata for RFC 3633 if there is consensus that such an update would be useful. - Ralph On Jul 21, 2008, at Jul 21, 2008,6:56 AM, Hemant Singh (shemant) wrote: > Ralph, > > Thanks for the quick reply. I too noticed the text related to Solicit > in RFC3633 but that can be misinterpreted to be merely an example > because even a 2-way Rapid Commit DHCPv6 could be used with IA_PD. > Since we don't see a clear MUST NOT from RFC3633 or RFC3736, one may =20 > say > IA_PD is fine to use with stateless DHCPv6 as far as the interface has > acquired a global address. > > Hemant > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 6:34 AM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations > Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > > Assigning a prefix through DHCPv6 is equivalent to assigning an =20 > address, > which is inherently stateful. > > Sections 11 and 12 of RFC 3633 specifies that IA_PD options are =20 > carried > in Solicit, Advertise, Request and Reply messages (as part of the > initial RR<->DR message exchange). > > I note that RFC 3633 does not explicitly disallow the inclusion of an > IA_PD in an Information-Request message (as used in "stateless" > DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the =20 > text > in RFC 3633 that describes the prefix delegation mechanism is, I =20 > think, > unambiguous in its description of how the IA_PD is used. > > - Ralph > > On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) =20 > wrote: > >> For Iljitsch van Beijnum related to his question on whether IA_PD >> could be asked of by stateless DHCPv6: >> >> Sorry one correction for this statement in the email below. >> >> "The Loopback interface would need to acquire a global IPv6 address >> first using stateful DHCPv6 (a MUST, because SLAAC doesn't support >> getting IA_PD).(a MUST, because SLAAC doesn't support getting =20 >> IA_PD)." >> >> The Loopback interface may acquire the global IPv6 address using =20 >> SLAAC > >> and not necessarily DHCPv6. Then since the Loopback interface does >> have a global address, then I believe it is permissible for stateless >> DHCPv6 >> to get IA_PD by specifying the IA_PD option in the ORO? We need to >> check if RFC3633 explicitly prohibits asking for IA_PD by stateless >> DHCPv6? Ole, what say you - thanks? >> >> Anyhow, the problem still remains that we expire the SLAAC address =20 >> and > >> then reassign an address from IA_PD. Same old ugliness. >> >> Hemant >> >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Hemant Singh (shemant) >> Sent: Sunday, July 20, 2008 9:41 PM >> To: Iljitsch van Beijnum >> Cc: IPv6 Operations >> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >> >> We are NOT adding any uRPF check feature to the CPE Router WAN on LAN >> interface(s) nor any ping throttle feature for ping reqs or =20 >> responses. >> These are just topics being discussed. uRPF was only given as an >> example to say why CPE Router cannot work with just a link-local on >> the WAN interface. >> >> We want to focus first on getting a complete set of requirements from >> DSL folks and then see what does the draft shape out to be. In our >> -00 version of the draft, the draft was complete for cable deployment >> because cable has completed docsis 3.0 standards for IPv6 as of two >> years back and also an embedded CPE Router cable modem standard >> completed in May 2007. >> >> >> We have clearly said to this mailer early on, that till we get a >> common consensus between DSL providers like AT&T, NTT, DSLForum folks >> like David Miles, and a Mikael A., nothing in this draft is concrete. > >> Of course, I and Wes gave our cable recommendation to the DSL guys in >> -00 version but they didn't like it. Our cable recommendation in the >> -00 version has nothing to do with IA_PD and stateless DHCPv6, or a >> Loopback interface, or a WAN interface with only a link-local =20 >> address. >> >> During the course of -01 and -02 versions we were attempting to fold >> in requirements from DSL and that has caused some problems in the >> draft. >> The DSL requirements from NTT, AT&T, and a Mikael have been varied. >> You >> guessed correctly. The Loopback interface cannot ask for IA_PD using >> stateless DHCPv6 if the Loopback interface hasn't acquired a global >> IPv6 >> address. The RFC for stateless DHCPv6 in RFC3736 clearly says the >> following in the Abstract section. >> >> [A node that uses stateless DHCP must have obtained its IPv6 =20 >> addresses > >> through some other mechanism, typically stateless address >> autoconfiguration.]. >> >> So the Loopback solution for DSL guys in our -02 version doesn't look >> good even though Mikael A., and David Miles suggested this path to =20 >> us. >> As you can see we are still analyzing the solution and questioning >> requirements. The Loopback interface would need to acquire a global >> IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC >> doesn't support getting IA_PD). Also during stateful DHCPv6, the >> IA_PD is doled out to the interface and the interface also gets an >> IA_NA. Since the interface already got a global address in the =20 >> IA_NA, > >> then what's the point of assigning the interface an IPv6 address out >> of the IA_PD? So will one release the IA_NA, and then configure an >> address on the interface from the IA_PD? I don't like such >> machinations. Clearly, the DSL requirements are not flushed out yet >> for us. >> >> Also, you can keep arguing about router vs. interface and who's >> correct or not. If the CPE Router needs a global address, the next >> question folks will ask is what interface on the CPE Router does the >> global address gets assigned to? We are describing such details. >> >> Also, the virtual Loopback interface is in the same link-local domain >> as the WAN interface. Therefore any RA sent to the WAN interface has >> to be also seen by the Loopback interface (CPE Router internals have >> to take care of this). So then it is legal for the Loopback to use >> the RA seen by the WAN interface and the proceed to get a global IPv6 >> address for the Loopback address using SLAAC or DHCPv6. >> >> Hemant >> >> >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Sunday, July 20, 2008 3:39 PM >> To: Hemant Singh (shemant) >> Cc: IPv6 Operations >> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt >> >> On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: >> >>>> 3. I disagree with the behavior suggested for "unnumbered" model. I >>>> don't think a CPE router should automatically open up a maintenance >>>> loopback interface just because it doesn't get a global IP address. >> >>> >> >> Would you PLEASE use normal quoting techniques? Reading email costs >> enough time as it is without everyone doing stuff in their own >> particular way so automation and habits don't work. >> >>> Not quite. The unnumbered model is clearly saying the WAN interface >>> only acquires on a link-local address. But the WAN interface of the >>> CPE Router has got to have a global IPv6 address. >> >> You are being extremely imprecise. That is one of the reasons your >> draft is in such bad shape. >> >> The INTERFACE doesn't need a global address, but the ROUTER does. >> >>> So what choice does the >>> CPE Router have but to automatically spawn a Loopback interface that >>> will get assigned a global IPv6 address >> >> When you need to create a packet, use a source address from another >> interface that you have, i.e. a LAN interface. I believe this is >> explained in the base IPv6 specs. Or ask within your company about =20 >> the > >> behavior of "ipv6 unnumbered ..." >> >>> (using SLAAC, >> >> Creating addresses using stateless autoconfig on an interface >> different than the one where the RAs were received is very wrong. >> >>> DHCPv6 >> >> Using DHCPv6 address configuration on a router makes no sense in my >> opinion. >> >>> stateless DHCPv6 to acquire an IA_PD). >> >> I don't think prefix delegation is possible in the stateless version >> of DHCPv6. >> >> On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote: >> >>> The draft clearly says what ICMPv6 errors are returned by the CPE >>> Router, so it's not like the CPE Router is not responding to any >>> ICMPv6 >>> request. >> >> Good. >> >>> Existing IPv4 routers do have a ping disable feature where the =20 >>> router > >>> is configured to not respond to pings. >> >> You are again using imprecise terminology. What you mean is IPv4 CPEs >> with NAT functionality. That has little to do with routing. For IPv6, >> CPEs do have to be real routers and conform to normal router behavior >> unless we specify exceptions. >> >> It is of course allowed to not return echo replies. >> >> However, since the router MUST generate other ICMPv6 messages under >> other circumstances, not replying to pings doesn't make the router >> invisible so there is little point in not returning ping replies. >> >>> I also said on this >>> thread that if the CPE Router does respond to pings, the CPE Router >>> needs to rate limit incoming ping reqs. >> >> You say that you want to rate limit INCOMING pings. (Which is useless >> anyway because the LAN bandwidth is much higher than the WAN >> bandwdith.) If you want to do this, it makes no sense to tie that to >> whether or not ping replies are sent. For the router itself this is a >> non-issue because the IPv6 specs mandate that ICMPv6 messages are =20 >> rate > >> limited anyway. >> >> On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote: >> >>> Please see the complete uRPF thread that we discussed on this mailer >>> - >> >>> they were emails between July 15 - 16th, 2008. >> >> I read it earlier today. It didn't make much sense to me. But now it >> occurs to me that you actually want to run uRPF on the CPE itself. I >> don't see how that's useful. What you want to do is filter out >> outgoing packets on the WAN interface if they don't have a source >> address that is either in the prefix delegated by the ISP or have the >> router's own WAN address as a source address. >> >> >> > From owner-v6ops@ops.ietf.org Mon Jul 21 05:58:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C1F3A698E for ; Mon, 21 Jul 2008 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.329 X-Spam-Level: X-Spam-Status: No, score=-99.329 tagged_above=-999 required=5 tests=[AWL=2.670, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT0C8lOvac9q for ; Mon, 21 Jul 2008 05:58:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DD173A6941 for ; Mon, 21 Jul 2008 05:58:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKuvL-000FcB-Nd for v6ops-data@psg.com; Mon, 21 Jul 2008 12:55:31 +0000 Received: from [2001:268:30f:fffc::3] (helo=uranus.bugest.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKuvH-000Fbe-PJ for v6ops@ops.ietf.org; Mon, 21 Jul 2008 12:55:29 +0000 Received: from [192.168.3.3] (softbank219001131059.bbtec.net [219.1.131.59]) by uranus.bugest.net (Postfix) with ESMTPA id 3CCFFE65FB2; Mon, 21 Jul 2008 21:55:26 +0900 (JST) Message-Id: <535DB34F-D7C6-402A-9678-B67E85024E8E@inetcore.com> From: Ruri Hiromi To: ipv6@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: draft-ietf-6man-addr-select-sol-01.txt related 2 documents Date: Mon, 21 Jul 2008 21:55:21 +0900 Cc: IPv6 Operations X-Mailer: Apple Mail (2.928.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi all, Thanks for ipv6ops people, 2 documents are published as informational RFC. These docs are describing about problems and requirements related with RFC3484 source/destination address policy in default use. URL: http://www.rfc-editor.org/rfc/rfc5220.txt URL: http://www.rfc-editor.org/rfc/rfc5221.txt Please refer these if you have a look upon the solution document. Regards, ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com From owner-v6ops@ops.ietf.org Mon Jul 21 06:22:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785B33A693E for ; Mon, 21 Jul 2008 06:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMKQfH6i0o7v for ; Mon, 21 Jul 2008 06:22:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8715E3A68A0 for ; Mon, 21 Jul 2008 06:22:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvKC-000LD0-HB for v6ops-data@psg.com; Mon, 21 Jul 2008 13:21:12 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvK7-000LBW-Bq for v6ops@ops.ietf.org; Mon, 21 Jul 2008 13:21:09 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 3B07CD007E; Mon, 21 Jul 2008 03:20:58 -1000 (HST) Date: Mon, 21 Jul 2008 03:20:58 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Alain Durand , Brian E Carpenter , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: <4881629F.60703@gmail.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 21 Jul 2008, Hemant Singh (shemant) wrote: > No. See my earlier email to you that said when the CPE Router is > embedded in, say, a cable modem, then the WAN interface of the CPE > Router becomes an internal logical interface (as opposed to a physically > available port in a standalone CPE Router). The logical interface > bridges to the cable modem. No argument there. > The cable modem is definitely managed by the ISP Perhaps this is true in some cable broadband networks but in my DSL world the DSL modem is un-managed by us and in most cases not by the customer either. Sometimes it's purchased by the end-customer, sometimes by us and shipped to the end-customer and it may have some local management control if it's got an integral NAPT router but regardless we do NOT manage it. > and it is this modem's software that can automatically configure the LAN > interface(s) of the CPE Router. Cable standards have specified this > automatic configuration by the modem. On one hand you say "managed by the ISP" and in the same sentence you say "modem's software that can automatically configure ... the CPE router". ^^^^^ ^^^^^^^^^ ^^^^^^ My head hurts... > The CPE Router when embedded in a cable modem has to comply to Cable > standards. If cable standards already define some part of CPE router behaviour, then what gaps is this draft trying to fill in? > When the WAN interface is internal to the modem there is no question of > useable or not. The interface is not even visible to the user. Regardless of whether the modem were a DSL or cable or WIMAX modem, etc., if there's no connection to the SP on startup then the WAN interface is basically not useable for anything until it does have connectivity to the SP. I think it's desirable that the behaviour and desired end-state of the CPE router should be determinate and not depend on the order in which the interfaces acquire external connectivity. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 06:52:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854003A67A6 for ; Mon, 21 Jul 2008 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owx44vH5bvb0 for ; Mon, 21 Jul 2008 06:52:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D5CC3A67C0 for ; Mon, 21 Jul 2008 06:52:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvnN-0002VI-5D for v6ops-data@psg.com; Mon, 21 Jul 2008 13:51:21 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvnF-0002Up-MH for v6ops@ops.ietf.org; Mon, 21 Jul 2008 13:51:18 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14887462" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 13:51:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LDpCU1018141; Mon, 21 Jul 2008 09:51:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LDpCJq010630; Mon, 21 Jul 2008 13:51:12 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 09:51:12 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 09:51:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrNKpsoua9a0+KTL+3U27G+nameAAAMRNQ References: <4881629F.60703@gmail.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" Cc: "Alain Durand" , "Brian E Carpenter" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 13:51:12.0636 (UTC) FILETIME=[D65093C0:01C8EB38] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5422; t=1216648272; x=1217512272; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Antonio=20Querubin=22=20; bh=JS+11hpbT8HuMaDc3LRATkjrLnLVh8tlwbTlcYjBNcY=; b=CypSDMZoyArK8ooA4aL222FDzB4yzbhi8fe50yH7H/ls51pSzho6o+RGTO c6sSjUxWqZQnH0DIibDLzQStcJ3rnUUvFrPrBbvrCq9wwqgHDa1vRjiE3uLk t+J4OdEh/I; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> On one hand you say "managed by the ISP" and in the same sentence you say "modem's software that can automatically configure ... the CPE router". >> ^^^^^ ^^^^^^^^^ ^^^^^^ >> My head hurts... Sorry. Here is Tylenol for your head. It is a MUST in CableLabs (CL) eRouter CM (cable modem) standard that after the CM has initialized its cable interface and acquired an IA_PD then the CM MUST configure the LAN interfaces.=20 >> If cable standards already define some part of CPE router behavior, then what gaps is this draft trying to fill in? Here are the gaps: 1. CL only specifies an embedded CPE Router. We are defining a standalone CPE Router. There are enough difference between the two. Of course, CL standard doesn't discuss cascading of routers since one does not cascade a modem behind another modem. The standalone router does need to discuss cascading. The eRouter doesn't need to deal with LAN init first mode but a standalone router does. The standalone router is usually NOT managed at all by the SP. There are numerous other gaps. 2. We are gathering requirements from the DSL world to also define a standalone and embedded CPE Router suitable for DSL deployment. 3. We don't agree with certain behavior in the CL embedded Router IPv6 and that is why we present our view. Some of the other reason we wrote this draft are as follows: 1. We didn't want DSL going off on their own defining a CPE Router and then break something for cable because cable already has a embedded router standard defined.=20 2. IETF v6ops was discussing security ad nauseam for a home CPE Router, but didn't have a specification for a CPE Router. =20 We have already seen enough evidence in v6ops that folks call all problems and issues as Broadband issues when they clearly mean to discuss only DSL. For example, Cable doesn't need any link model draft that came out recently that says it's a Broadband model. Yeah, right! Call it your DSL model. We know what our cable link, data models are. We don't need the emails on Broadband/SOHO provisioning - cable has a working provisioning systems, aggregator, and modem for IPv6 that are cable standards compliant for IPv6. =20 >> Regardless of whether the modem were a DSL or cable or WIMAX modem, etc., if there's no connection to the SP on startup then the WAN interface is=20 >> basically not useable for anything until it does have connectivity to the SP. I think it's desirable that the behavior and desired end-state of the >> CPE router should be determinate and not depend on the order in which the interfaces acquire external connectivity. Totally agreed. Don't you see our LAN init first before WAN init define deterministic behavior for a standalone CPE Router? Our WAN init first model is also deterministic. =20 We'll continue to work on DSL requirements and make some sensible behavior out of them for the CPE Router. Hemant=20 -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Monday, July 21, 2008 9:21 AM To: Hemant Singh (shemant) Cc: Alain Durand; Brian E Carpenter; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review On Mon, 21 Jul 2008, Hemant Singh (shemant) wrote: > No. See my earlier email to you that said when the CPE Router is=20 > embedded in, say, a cable modem, then the WAN interface of the CPE=20 > Router becomes an internal logical interface (as opposed to a=20 > physically available port in a standalone CPE Router). The logical=20 > interface bridges to the cable modem. No argument there. > The cable modem is definitely managed by the ISP Perhaps this is true in some cable broadband networks but in my DSL world the DSL modem is un-managed by us and in most cases not by the customer either. Sometimes it's purchased by the end-customer, sometimes by us and shipped to the end-customer and it may have some local management control if it's got an integral NAPT router but regardless we do NOT manage it. > and it is this modem's software that can automatically configure the=20 > LAN > interface(s) of the CPE Router. Cable standards have specified this=20 > automatic configuration by the modem. On one hand you say "managed by the ISP" and in the same sentence you say "modem's software that can automatically configure ... the CPE router". ^^^^^ ^^^^^^^^^ ^^^^^^=20 My head hurts... > The CPE Router when embedded in a cable modem has to comply to Cable=20 > standards. If cable standards already define some part of CPE router behaviour, then what gaps is this draft trying to fill in? > When the WAN interface is internal to the modem there is no question=20 > of useable or not. The interface is not even visible to the user. Regardless of whether the modem were a DSL or cable or WIMAX modem, etc., if there's no connection to the SP on startup then the WAN interface is basically not useable for anything until it does have connectivity to the SP. I think it's desirable that the behaviour and desired end-state of the CPE router should be determinate and not depend on the order in which the interfaces acquire external connectivity. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 07:06:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1380C28C0F8 for ; Mon, 21 Jul 2008 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx0RfmVrTd0B for ; Mon, 21 Jul 2008 07:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80D803A68DC for ; Mon, 21 Jul 2008 07:06:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKw0C-0005Oe-H0 for v6ops-data@psg.com; Mon, 21 Jul 2008 14:04:36 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKw08-0005O7-GK for v6ops@ops.ietf.org; Mon, 21 Jul 2008 14:04:34 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 854303EA0B6; Mon, 21 Jul 2008 16:04:10 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id F2B6D3EA0CE; Mon, 21 Jul 2008 16:04:09 +0200 (CEST) Message-ID: <48849736.5050605@free.fr> Date: Mon, 21 Jul 2008 16:03:34 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter , Ed Jankiewicz CC: IPv6 Operations Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 References: <4880ED7A.20007@sri.com> <48815EFD.5090308@gmail.com> In-Reply-To: <48815EFD.5090308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian E Carpenter - Le 7/19/08 5:26 AM : >> 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF >> strongly prefers and recommends [dual stack] as the operational matters >> are simplest" begs for a citation. RFC 4213 says dual stack is the most >> straightforward but does not include language recommending or preferring >> this solution. > > That doesn't belong in that document. You're possibly correct that no > IETF document formally states the strong preference for dual stack as > the coexistence mechanism, but it's the implicit assumption throughout > pretty much everything NGTRANS and V6OPS have done. I don't think we > should rewrite history, and dual stack is still the best way we know > (for reasons stated in RFC 1671, which of course has absolutely no > authority whatever). > >> Also the impetus of this draft is that dual stack solves >> only the simplest part of the problem, and becomes very problematic when >> IPv4 addresses really get scarce (approaching rather than reaching >> exhaustion). Some have already stated (Alain Durand I recall saying >> something like) "a plan that requires all new end-nodes to be dual-stack >> and to have global IPv4 addresses is a non-starter." > > Correct, but that argues for more v4/v4 NAT, not against dual stack. Brian, The role of dual stack during the coexistence period might IMHO be somewhat clarified, and also simplified, as follows: - Host capabilities o DS (ASAP) o IPv6-only (eventually, but slow start) - Router capabilities o DS (ASAP) o IPv6-only (eventually, but slow start) - Interworking functions (at least before global IPv4 shortage) . Dual-stack lite carrier grade NATs (DSL-CGNs) . Dual-stack lite Public address servers (DSL-PASs) The former are those of draft-durand-dual-stack-lite-00. (In ISP infrastructures, they involve carrier grade NAT44s. In IPv4/IPv6 tunnels between customer sites and these NATs, packets contain private IPv4 addresses of customer sites.) The latter are those of draft-despres-v6ops-apbp-01, renamed here to clarify their relationship with DSP-CGNs. (In ISP infrastructures, they involve Public Address Servers, to which public IPv4 addresses can be borrowed together with some limited ranges of ports. In IPv4/IPv6 tunnels between customer sites and these servers, packets contain public IPv4 addresses that have been borrowed. If the CPE is a router, it includes its NAT44; if it is a host, there is no NAT in the path.) IMHO, if CGNs are deployed, NAT64 and NAT46 are no longer necessary, but I understand that this is a subject for debate. This view is submitted as an exploratory contribution. Regards. Rémi From owner-v6ops@ops.ietf.org Mon Jul 21 07:20:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490D128C144 for ; Mon, 21 Jul 2008 07:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILJTuGqRjWm5 for ; Mon, 21 Jul 2008 07:20:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EB9B28C13E for ; Mon, 21 Jul 2008 07:20:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwEn-0008cu-9k for v6ops-data@psg.com; Mon, 21 Jul 2008 14:19:41 +0000 Received: from [212.74.114.1] (helo=mk-outboundfilter-5.mail.uk.tiscali.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwEi-0008cB-KC for v6ops@ops.ietf.org; Mon, 21 Jul 2008 14:19:38 +0000 X-Trace: 60276098/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.122.9 X-SBRS: None X-RemoteIP: 62.188.122.9 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPA3hEg+vHoJ/2dsb2JhbACDXYgKohkD X-IronPort-AV: E=Sophos;i="4.31,223,1215385200"; d="scan'208";a="60276098" X-IP-Direction: IN Received: from 1cust9.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.9]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Jul 2008 15:19:33 +0100 Message-ID: <000601c8eb33$97b155a0$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: "Iljitsch van Beijnum" , "Hemant Singh \(shemant\)" Cc: "IPv6 Operations" References: <883759.12448.qm@web62505.mail.re1.yahoo.com> <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 14:09:31 +0200 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Hemant Singh (shemant)" Cc: "IPv6 Operations" Sent: Sunday, July 20, 2008 9:38 PM Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote: > > >> 3. I disagree with the behavior suggested for "unnumbered" model. I > >> don't think a CPE router should automatically open up a maintenance > >> loopback interface just because it doesn't get a global IP address. > > > > > Would you PLEASE use normal quoting techniques? Reading email costs > enough time as it is without everyone doing stuff in their own > particular way so automation and habits don't work. > Iljitsch I wish that I could but often I cannot; my e-mail client, the one in use in 9x.xx% of the worlds PCs, will indent and > as long as the Content-Transfer-Encoding is 7bit, as yours is, or 8bit. But when it is quoted-printable, as is often the case from mainland Europe, then there are no > and short of editing them all in by hand myself - thanks but no thanks - I know of no way to change this; would that I could. I agree that it is a pain. Tom Petch From owner-v6ops@ops.ietf.org Mon Jul 21 07:20:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897B728C147 for ; Mon, 21 Jul 2008 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngwjtXFo0A5D for ; Mon, 21 Jul 2008 07:20:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94F1C28C145 for ; Mon, 21 Jul 2008 07:20:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwEp-0008dD-Lx for v6ops-data@psg.com; Mon, 21 Jul 2008 14:19:43 +0000 Received: from [212.74.114.1] (helo=mk-outboundfilter-5.mail.uk.tiscali.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwEl-0008cB-26 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 14:19:41 +0000 X-Trace: 60276112/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.122.9 X-SBRS: None X-RemoteIP: 62.188.122.9 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPA3hEg+vHoJ/2dsb2JhbACDXYgKohkDQQ X-IronPort-AV: E=Sophos;i="4.31,223,1215385200"; d="scan'208";a="60276112" X-IP-Direction: IN Received: from 1cust9.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.9]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Jul 2008 15:19:35 +0100 Message-ID: <000701c8eb33$98bc5d00$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: "Antonio Querubin" Cc: "Stark, Barbara" , "v6ops" References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 14:19:42 +0200 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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Antonio Querubin" To: "Hemant Singh (shemant)" Cc: "Stark, Barbara" ; Sent: Friday, July 18, 2008 5:57 PM Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > I wonder, for those who feel a loopback interface is important, is that > because you want the CPE router to be pingable regardless of any PHY > interface status? If that's so, since the document's focus is on router > behaviour, perhaps it is this behaviour should be explicitly mentioned. For me, it is not just pingable but all aspects of control and management. I have always thought the term 'loopback' misleading. I first encountered it with routing protocols, with the need to have a stable IP address to which to send updates, even, especially, when an interface was down and so packets could not be sent to the address of that interface - and there was never any way of knowing which interfaces were still up. I see such a concept, although not necessarily with the same name, in use with ftp, to download configurations and code updates; with snmp, for general purpose management; with telnet, ditto; even with icmp. Commonly, it is possible to have multiple such addresses, to split the traffic and security for different applications, but I expect there to be at least one, whose status is divorced from the physical status of any or all the interfaces. I am talking, as you may deduce, of experience with IPv4, not with IPv6, and appreciate that IPv6 has lots of clever additions, but suspect that the principle remains, that if an interface goes down, then it will not be possible to send packets to the address of that interface, and so a virtual interface address is needed. I assume that the address must be global although where the prefix comes from is a subtlety I have yet to understand. With IPv4, all the routers in a domain could share the prefix with the individual /32 being advertised. Tom Petch > Section 5, paragraph 1 states 'optional Loopback network interface, facing > the Service Provider upstream, which initiates stateless DHCPv6'. A > loopback interface doesn't really 'face' any direction. You might want to > change the wording to something along the lines of 'optional Loopback > network interface initiates a DHCPv6 request toward the upstream SP' > > Also I notice in the same paragraph, "recommend the CPE Router WAN > interface acquire its global IPv6 address using stateful DHCPv6 for > administrative control of the router". This makes it sound like DHCP is > recommended for administrative control where I think you mean the global > address is recommended for administrative control and provisioning of > proxied services to the downstream devices. Why not just say "recommend > the CPE Router acquire a global IPv6 address for administrative control > ..." > > Antonio Querubin > whois: AQ7-ARIN > From owner-v6ops@ops.ietf.org Mon Jul 21 07:37:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CDE3A6816 for ; Mon, 21 Jul 2008 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R48WKVpFBhi2 for ; Mon, 21 Jul 2008 07:37:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC52A3A6803 for ; Mon, 21 Jul 2008 07:37:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwVd-000COy-ME for v6ops-data@psg.com; Mon, 21 Jul 2008 14:37:05 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwV9-000CFD-Ms for v6ops@ops.ietf.org; Mon, 21 Jul 2008 14:36:37 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id F37BD3EA0D0; Mon, 21 Jul 2008 16:36:34 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 006BA3EA118; Mon, 21 Jul 2008 16:36:33 +0200 (CEST) Message-ID: <48849ECE.8040909@free.fr> Date: Mon, 21 Jul 2008 16:35:58 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Dan Wing , 'IPv6 Operations' , 'Fred Baker' , teemu.savolainen@nokia.com, 'Brian E Carpenter' , Alain_Durand@cable.comcast.com, 'Jari Arkko' , 'Philip Matthews' Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <00ba01c8e827$32b15470$c2f0200a@cisco.com> <4881FA93.7090109@it.uc3m.es> In-Reply-To: <4881FA93.7090109@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun - Le 7/19/08 4:30 PM : > BTW, One may also think that this draft is kind of weird, in the sense > that it identifies the 3 scenarios mentioned above and then only defines > the requirements for one of them, i.e. the one requiring translation. > From a document perspective, we can do 3 things, i guess. > Either we keep it as it is, even if it may seems somehow strange. > Or we split in two documents, one as the overview of the scenarios and > another one with the requirements for translation, (and eventually > having two more documents with requirements for the other scenarios, > or we add to this document the requiremetns for the other scenarios) > > I personally preffer the first or the second one, since i would like to > wrap up the transalion requireemtns asap. Marcello, You have well clarified where there is a short term problem, which explains some of our previous mail exchanges. Since the document deals with requirements only for v4-v6 translation mechanisms, what about making it clear in the title, e.g.: "Pv4/IPv6 Coexistence - Requirements for solutions based on IPv4-IPv6 translations". Regards. Rémi From owner-v6ops@ops.ietf.org Mon Jul 21 07:58:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DF53A6828 for ; Mon, 21 Jul 2008 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuMudj2ONS-c for ; Mon, 21 Jul 2008 07:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CDB93A6813 for ; Mon, 21 Jul 2008 07:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwpW-000GeG-EO for v6ops-data@psg.com; Mon, 21 Jul 2008 14:57:38 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwpO-000GcS-Je for v6ops@ops.ietf.org; Mon, 21 Jul 2008 14:57:33 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id F10E01F7; Mon, 21 Jul 2008 16:57:28 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: Alain Durand Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 17:57:38 +0300 User-Agent: KMail/1.9.9 Cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807211757.38784.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit=A0: > Supporting both ULA & GUA at the same time is also a source of complexity > and confusion. The key problem I see is with external referrals in > multi-party communications where some of the hosts are inside, and some a= re > outside. Mixing ULA & GUA can have complex consequences, and again > generates service call. Yeah. Broken RFC3484 implementations will do just that. But all nodes (brok= en=20 and non-broken RFC3484 implementations alike) will *break* without ULA, unt= il=20 we have *instantaneous* 100%-reliable and 100%-available upstream connectio= ns=20 (which we will NEVER have). Without this, the network will simply not work= =20 until the ISP connection is established (if ever), which is a total=20 non-starter. Therefore, it seems like a total non-question that ULA is the= =20 way to go. > Also, if I read the text correctly, if the WAN interface gets configured > first, no ULA are generated. Which leads to confusing situation depending > on whether the customer turns its modem on before or after its CPE. You may have a point here. > I would rather like the text to recommend to only use ULA when nothing el= se > is available and immediately renumber to GUA when those are acquired. And break existing connections on the local network? Total no go. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 21 08:08:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707FC3A67F3 for ; Mon, 21 Jul 2008 08:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JbFIWy0dCYL for ; Mon, 21 Jul 2008 08:08:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6A063A67A6 for ; Mon, 21 Jul 2008 08:08:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwy5-000Ibp-8n for v6ops-data@psg.com; Mon, 21 Jul 2008 15:06:29 +0000 Received: from [69.147.75.94] (helo=web62502.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwy1-000IbC-6h for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:06:27 +0000 Received: (qmail 89815 invoked by uid 60001); 21 Jul 2008 15:06:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=uFHJvFcPDehsfMP7LsfHzUCbWo+20zVk4AKb9YY0CqqlugHcjaiCoYGeO/qEP1Nrit9vifwCZwK3GNA8ihj829taoMiTYcdUjXwT94z+nsrrqCoitcACFJ5QY+fEh4sprPa9456TLpVlQivgZhalOHkigxOVJ1o8IopyYLdbZ1I=; Received: from [193.49.124.107] by web62502.mail.re1.yahoo.com via HTTP; Mon, 21 Jul 2008 08:06:07 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 21 Jul 2008 08:06:07 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt To: "Hemant Singh \(shemant\)" Cc: Iljitsch van Beijnum , Ole Troan , IPv6 Operations In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <994551.88685.qm@web62502.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Yesterday you said "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface." Today you say "The Loopback interface doesn't face the downstream or the upstream." Can explain clearly your architecture? Francois-Xavier --- On Mon, 7/21/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > To: "Ole Troan" > Cc: "Iljitsch van Beijnum" , "IPv6 Operations" > Date: Monday, July 21, 2008, 7:31 AM > We are not even concerned about the draft being a WG work > item. We have > not even completed requirements for the device. > > > no, you cannot use stateless DHCP for prefix > delegation. > > Also, if you say IA_PD is forbidden by stateless DHCPv6, > please point to > a MUST NOT text in any RFC. > > > e.g: > > - false: downstream interfaces (loopback, LAN) can run > SLAAC or DHCP > IA/PD protocols > > The Loopback interface doesn't face the downstream or > the upstream. You > and I both know RFC3633 has no explicit text that prohibits > stateless > DHCPv6 asking for IA_PD as I showed how (using the ORO once > an interface > has acquired a global IPv6 address). > > > - false: you need a global address on the WAN > interface for uRPF > > If you don't see the obvious problem with uRPF with > just a link-local > address on the WAN interface, I suggest you go do a test > and get back to > us. > > > - false: loopback interface is required. (it's > only purpose is to have > a stable always up management interface). > > DSL folks have asked to support the WAN interface acquiring > a link-local > address. So it is the Loopback interface that acquires a > global IPv6 > address to source packets to the WAN. If the Loopback > interface is not > spawned, then since the LAN interface has global IPv6 > address, one could > say, use the LAN interface global address to source packets > to the WAN. > But the CPE Router will not even function if the WAN > interface has only > link-local and the LAN interface has a global IPv6 address > - see section > 4 of > > http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt > > > Hemant > > -----Original Message----- > From: ichiroumakino@gmail.com > [mailto:ichiroumakino@gmail.com] On Behalf > Of Ole Troan > Sent: Monday, July 21, 2008 6:54 AM > To: Hemant Singh (shemant) > Cc: Iljitsch van Beijnum; IPv6 Operations > Subject: Re: Comments on > draft-wbeebee-ipv6-cpe-router-01.txt > > Hemant, > > > For Iljitsch van Beijnum related to his question on > whether IA_PD > > could be asked of by stateless DHCPv6: > > > > Sorry one correction for this statement in the email > below. > > > > "The Loopback interface would need to acquire a > global IPv6 address > > first using stateful DHCPv6 (a MUST, because SLAAC > doesn't support > > getting IA_PD).(a MUST, because SLAAC doesn't > support getting IA_PD)." > > > > The Loopback interface may acquire the global IPv6 > address using SLAAC > > > and not necessarily DHCPv6. Then since the Loopback > interface does > > have a global address, then I believe it is > permissible for stateless > > DHCPv6 to get IA_PD by specifying the IA_PD option in > the ORO? We > > need to check if RFC3633 explicitly prohibits asking > for IA_PD by > > stateless DHCPv6? Ole, what say you - thanks? > > no, you cannot use stateless DHCP for prefix delegation. > > I don't understand where you are going with this draft. > this is all over > the map. several people on this mailing list has tried to > correct your > misconceptions, but we don't seem to be getting > through... > > e.g: > - false: downstream interfaces (loopback, LAN) can run > SLAAC or DHCP > IA/PD protocols > - false: you need a global address on the WAN interface for > uRPF > - false: loopback interface is required. (it's only > purpose is to have a > stable always up management interface). > > > Anyhow, the problem still remains that we expire the > SLAAC address and > > > then reassign an address from IA_PD. Same old > ugliness. > > huh? don't understand this. > > I would not support this draft to become a working group > document. > > /ot From owner-v6ops@ops.ietf.org Mon Jul 21 08:15:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6593A68A7 for ; Mon, 21 Jul 2008 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2v9eB3q2uGS for ; Mon, 21 Jul 2008 08:15:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 776753A67F3 for ; Mon, 21 Jul 2008 08:15:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKx6A-000KDv-Is for v6ops-data@psg.com; Mon, 21 Jul 2008 15:14:50 +0000 Received: from [128.18.84.113] (helo=mailgate-internal3.sri.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKx65-000KCt-Sf for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:14:47 +0000 Received: from smssmtp-internal1.sri.com (128.18.84.115) by mailgate-internal3.sri.com with SMTP; 21 Jul 2008 15:14:00 -0000 X-AuditID: 80125473-a9842bb000000a91-25-4884a7b8f174 Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal1.sri.com (Symantec Mail Security) with ESMTP id 3BD411B2501 for ; Mon, 21 Jul 2008 08:14:00 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4D00D7J3NBXE6Q@mail.sri.com> for v6ops@ops.ietf.org; Mon, 21 Jul 2008 08:14:00 -0700 (PDT) Date: Mon, 21 Jul 2008 11:14:01 -0400 From: Ed Jankiewicz Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 In-reply-to: <48815EFD.5090308@gmail.com> To: Brian E Carpenter Cc: IPv6 Operations Message-id: <4884A7B9.3090607@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <4880ED7A.20007@sri.com> <48815EFD.5090308@gmail.com> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks for the feedback, see comments in-line Brian E Carpenter wrote: > Ed, > > On 2008-07-19 07:22, Ed Jankiewicz wrote: > >> in addition to some editorial comments I sent to Marcelo, I have a few >> substantive comments (some admittedly half-baked) and discussion points >> to raise on the draft. I'm assuming there will be discussion at IETF 72? >> >> 1. transition versus coexistence: recognizing that the period of >> coexistence is likely to be longer, I would rather see consistent use of >> the term coexistence rather than transition throughout the document, >> e.g. coexistence scenarios, coexistence tools, etc. >> > > Yes. As some of us having been saying for *many* years, in my case, since > RFC 1671. > I can't recall who it was, recently I heard a songwriter say "I always been described as 'ahead of my time' but unfortunately, there is no line at the bank with that label..." It seems like there is rough consensus that coexistence is the right term. > >> 2. add a sentence in front of the Problem Statement to explicitly state >> this motivation, e.g. "Settled opinion on the transition from an >> IPv4-dominant network to an IPv6-dominant network was that the period of >> coexistence would be brief, and could be accommodated by dual-stack and >> tunneling. >> > > I deny that. I personally have always expected many years of coexistence, > and I don't know where this "settled opinion" was to be found. > Fair enough, no need to over-analyze the motivation since it is already agreed that this work needs to be done. The "settled opinion" is more folkloric than historic. > >> Operationally, we now expect..." >> >> 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF >> strongly prefers and recommends [dual stack] as the operational matters >> are simplest" begs for a citation. RFC 4213 says dual stack is the most >> straightforward but does not include language recommending or preferring >> this solution. >> > > That doesn't belong in that document. You're possibly correct that no > IETF document formally states the strong preference for dual stack as > the coexistence mechanism, but it's the implicit assumption throughout > pretty much everything NGTRANS and V6OPS have done. I don't think we > should rewrite history, and dual stack is still the best way we know > (for reasons stated in RFC 1671, which of course has absolutely no > authority whatever). > agree. either we justify the statement by citing authoritative source (apparently non-existent) or remove it. > >> Also the impetus of this draft is that dual stack solves >> only the simplest part of the problem, and becomes very problematic when >> IPv4 addresses really get scarce (approaching rather than reaching >> exhaustion). Some have already stated (Alain Durand I recall saying >> something like) "a plan that requires all new end-nodes to be dual-stack >> and to have global IPv4 addresses is a non-starter." >> > > Correct, but that argues for more v4/v4 NAT, not against dual stack. > perhaps a v4/v4 NAT that includes v6 pass-through, if you mean dual-stack end-nodes with private v4 address space. What I meant by "dual stack solves only the simplest part of the problem" is that it permits coexistence of IPv4 and IPv6 nodes and simultaneous native IPv4 and IPv6 interactions, but it leaves the knottiest problems - how to facilitate interaction of IPv4-only nodes with IPv6-only nodes or applications. While the former do and will dominate for some time, the latter are theoretical. That is a bigger problem than just address mapping that a v4/v4 NAT could solve. There is no one size fits all approach. Dual stack and tunneling should cover the preponderance, address mapping much of the rest, leaving the residual to translation as a last resort. > >> Also an emphasis >> on dual stack creates a "must carry" situation where the core network >> continues to route IPv4 indefinitely. While we say in para 2.2 that >> turning off IPv4 will be a business decision, the ISP can't make that >> choice without alienating customers that rely on dual stack. I can >> still plug in a 50 year old rotary dial phone and expect the local telco >> (in the USA at least) to make it work, even though DTMF has been the >> dominant method for nearly that long. >> > > Bingo. I'm sure ISPs will still be routing IPv4 for 15 years; not so > clear about 50. > > >> 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF >> recommends tunnels rather than dual NAT - that also would need a >> citation, unless this document is making the statement for the first >> time. Also, I believe if the two NATs know they are in a reflexive >> relationship, they can avoid at least some of the general NAT problems - >> i.e. they should not attempt to translate addresses in application data. >> > > If you mean by "reflexive" that the NAT mapping is reversed before delivery, > sure, that's invisible to the upper layer and is isomorphic with a tunnel. > But do such devices exist? > The IETF definitely recommends avoiding irreversible NAT when possible, > and therefore the statement that tunnels are preferred is definitely true. > Translators definitely exist and I have had discussions with developers about that kind of deployment scenario - it has been considered but not implemented (that I know of) to add the intelligence to the translator to pair up like this. Good point, it is effectively like tunneling with substitution of header rather than wrapping. I can't see reflexive NAT having any advantage over tunneling, so it is more of an academic discussion. as I said, some of my comments were half-baked: reflexive NAT is not truly reversible, but could effectively be within a v4v6v4 scenario that carries the v4 address as part of the v6 mapping. > Brian > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From owner-v6ops@ops.ietf.org Mon Jul 21 08:15:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F75E3A68A7 for ; Mon, 21 Jul 2008 08:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8DdH62qU-5g for ; Mon, 21 Jul 2008 08:15:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 451473A67F3 for ; Mon, 21 Jul 2008 08:15:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKx68-000KDB-0W for v6ops-data@psg.com; Mon, 21 Jul 2008 15:14:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKx60-000KBA-HA for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:14:42 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14884258" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 15:14:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFEdXQ020128; Mon, 21 Jul 2008 11:14:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFEdF9015699; Mon, 21 Jul 2008 15:14:39 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:14:39 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 11:14:38 -0400 Message-ID: In-Reply-To: <200807211757.38784.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrQl9YDUutPRCjT3Kvjdhe/xL7xwAARX+Q References: <200807211757.38784.rdenis@simphalempin.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" Cc: , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 15:14:39.0127 (UTC) FILETIME=[7E6A7A70:01C8EB44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2824; t=1216653279; x=1217517279; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20,=0A=20=20=20=20=20=20=20=20=22Alain=20D urand=22=20; bh=tVFRDEgFv+aloWGXHRxLqFii9PMgFbNvWmN0jcrVszg=; b=NmM58+aVr6NUON7wopdnAUMGk1qb/xChk1hROGo+RzpZY6hMvmEcjhXk2i iEzmpIz4W7R0OmcubuIbvJVB9EaFwvIzQCwLmwLZwevJ9kwZrQwOJXmAORwH PrdnpuwtWw; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Remi and Alain, It's a very general statement to refer to broken RFC3484 implementations = and I agree with that sentiment. However, please note that our source = address selection behavior for ULA and GUA coexisting on the LAN = interface is really simple - odds of broken CPE Router implementations = are less. We are pointing to Rule#2 in RFC3484 for scope comparison. = Here is some relevant text from our draft: [After this process, every LAN interface has a link-local unicast = address, a ULA, and a global unicast address (GUA). Therefore, the = interface has to apply source address selection to determine which = address to use as a source for outgoing packets. Since the GUA has a = larger scope than the link-local address, or the ULA (rule #2 of = [RFC3484], the GUA will be used as a source address of outgoing packets = that are not subject to rule #1.]. Also, if ULA is not used, what choice does one have to configure an IPv6 = address on the CPE Router for manual configuration in a standalone CPE = Router? Thanks. Hemant=20 -----Original Message----- From: R=E9mi Denis-Courmont [mailto:rdenis@simphalempin.com]=20 Sent: Monday, July 21, 2008 10:58 AM To: Alain Durand Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit=A0: > Supporting both ULA & GUA at the same time is also a source of=20 > complexity and confusion. The key problem I see is with external=20 > referrals in multi-party communications where some of the hosts are=20 > inside, and some are outside. Mixing ULA & GUA can have complex=20 > consequences, and again generates service call. Yeah. Broken RFC3484 implementations will do just that. But all nodes = (broken and non-broken RFC3484 implementations alike) will *break* = without ULA, until we have *instantaneous* 100%-reliable and = 100%-available upstream connections (which we will NEVER have). Without = this, the network will simply not work until the ISP connection is = established (if ever), which is a total non-starter. Therefore, it seems = like a total non-question that ULA is the way to go. > Also, if I read the text correctly, if the WAN interface gets=20 > configured first, no ULA are generated. Which leads to confusing=20 > situation depending on whether the customer turns its modem on before = or after its CPE. You may have a point here. > I would rather like the text to recommend to only use ULA when nothing = > else is available and immediately renumber to GUA when those are = acquired. And break existing connections on the local network? Total no go. -- R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Jul 21 08:18:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE653A6851 for ; Mon, 21 Jul 2008 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.714 X-Spam-Level: X-Spam-Status: No, score=-4.714 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNHo1+WrEy4e for ; Mon, 21 Jul 2008 08:18:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C5363A67F3 for ; Mon, 21 Jul 2008 08:18:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxAB-000L8v-BL for v6ops-data@psg.com; Mon, 21 Jul 2008 15:18:59 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxA7-000L8P-29 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:18:57 +0000 X-IronPort-AV: E=Sophos;i="4.31,223,1215388800"; d="scan'208";a="14884749" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 15:18:42 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFIgij011671; Mon, 21 Jul 2008 11:18:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFIgAP019022; Mon, 21 Jul 2008 15:18:42 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:18:42 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Mon, 21 Jul 2008 11:18:42 -0400 Message-ID: In-Reply-To: <994551.88685.qm@web62502.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjrQ4RxdgNIH7ZnRHOyABg5vpNIYQAAQw9Q References: <994551.88685.qm@web62502.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" Cc: "Iljitsch van Beijnum" , "Ole Troan" , "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2008 15:18:42.0712 (UTC) FILETIME=[0F9A9980:01C8EB45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5199; t=1216653522; x=1217517522; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20; bh=iGKPlkfT5jlN4za8x8Y4sMe0Gqml/Dvo7Yrf7Ktfx2M=; b=qh2wjbPapmp6Qqo6tmtuxSOhAdRfVYv27ykuPauZhifH4/YVZrX2eHv/E1 5nL2JmQMTBwYYaoNOKlvqmvhpaA29K8YLF4aXbsydiLRI2cxo6tL3VCgx/SQ WIEI4d4cfZ; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The traffic direction of the Loopback interface in the generic router sense is that the Loopback interface does not face any traffic direction. However, the Loopback interface for the CPE Router can initiate IPv6 address acquisition via the WAN interface to the SP. =20 The architecture, I am referring to is Integrated Routing and Bridging (IRB) - google it. Such routing can send the RA to other virtual interfaces of a router. Hemant -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Monday, July 21, 2008 11:06 AM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; Ole Troan; IPv6 Operations Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Yesterday you said "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface." Today you say "The Loopback interface doesn't face the downstream or the upstream." Can explain clearly your architecture? Francois-Xavier --- On Mon, 7/21/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > To: "Ole Troan" > Cc: "Iljitsch van Beijnum" , "IPv6 Operations"=20 > > Date: Monday, July 21, 2008, 7:31 AM > We are not even concerned about the draft being a WG work item. We=20 > have not even completed requirements for the device. >=20 > > no, you cannot use stateless DHCP for prefix > delegation. >=20 > Also, if you say IA_PD is forbidden by stateless DHCPv6, please point=20 > to a MUST NOT text in any RFC. >=20 > > e.g: > > - false: downstream interfaces (loopback, LAN) can run > SLAAC or DHCP > IA/PD protocols >=20 > The Loopback interface doesn't face the downstream or the upstream. =20 > You and I both know RFC3633 has no explicit text that prohibits=20 > stateless > DHCPv6 asking for IA_PD as I showed how (using the ORO once an=20 > interface has acquired a global IPv6 address). >=20 > > - false: you need a global address on the WAN > interface for uRPF >=20 > If you don't see the obvious problem with uRPF with just a link-local=20 > address on the WAN interface, I suggest you go do a test and get back=20 > to us. >=20 > > - false: loopback interface is required. (it's > only purpose is to have > a stable always up management interface). >=20 > DSL folks have asked to support the WAN interface acquiring a=20 > link-local address. So it is the Loopback interface that acquires a=20 > global IPv6 address to source packets to the WAN. If the Loopback=20 > interface is not spawned, then since the LAN interface has global IPv6 > address, one could say, use the LAN interface global address to source > packets to the WAN. > But the CPE Router will not even function if the WAN interface has=20 > only link-local and the LAN interface has a global IPv6 address > - see section > 4 of >=20 > http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt >=20 >=20 > Hemant >=20 > -----Original Message----- > From: ichiroumakino@gmail.com > [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Monday, July 21, 2008 6:54 AM > To: Hemant Singh (shemant) > Cc: Iljitsch van Beijnum; IPv6 Operations > Subject: Re: Comments on > draft-wbeebee-ipv6-cpe-router-01.txt >=20 > Hemant, >=20 > > For Iljitsch van Beijnum related to his question on > whether IA_PD > > could be asked of by stateless DHCPv6: > > > > Sorry one correction for this statement in the email > below. > > > > "The Loopback interface would need to acquire a > global IPv6 address > > first using stateful DHCPv6 (a MUST, because SLAAC > doesn't support > > getting IA_PD).(a MUST, because SLAAC doesn't > support getting IA_PD)." > > > > The Loopback interface may acquire the global IPv6 > address using SLAAC >=20 > > and not necessarily DHCPv6. Then since the Loopback > interface does > > have a global address, then I believe it is > permissible for stateless > > DHCPv6 to get IA_PD by specifying the IA_PD option in > the ORO? We > > need to check if RFC3633 explicitly prohibits asking > for IA_PD by > > stateless DHCPv6? Ole, what say you - thanks? >=20 > no, you cannot use stateless DHCP for prefix delegation. >=20 > I don't understand where you are going with this draft. > this is all over > the map. several people on this mailing list has tried to correct your > misconceptions, but we don't seem to be getting through... >=20 > e.g: > - false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP=20 > IA/PD protocols > - false: you need a global address on the WAN interface for uRPF > - false: loopback interface is required. (it's only purpose is to have > a stable always up management interface). >=20 > > Anyhow, the problem still remains that we expire the > SLAAC address and >=20 > > then reassign an address from IA_PD. Same old > ugliness. >=20 > huh? don't understand this. >=20 > I would not support this draft to become a working group document. >=20 > /ot =20 From owner-v6ops@ops.ietf.org Mon Jul 21 08:19:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB0A3A67FF for ; Mon, 21 Jul 2008 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fuo41mDP4DDU for ; Mon, 21 Jul 2008 08:19:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F9EA3A6780 for ; Mon, 21 Jul 2008 08:19:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxB7-000LOe-FA for v6ops-data@psg.com; Mon, 21 Jul 2008 15:19:57 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxAz-000LMe-OX for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:19:55 +0000 Received: (qmail 65196 invoked by uid 1007); 21 Jul 2008 15:19:48 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=PdtLt1r9kBPXU5rPHJQtt2plp+YKVv7XinxttyCu6qEktF4woX67yTIFzNgfK7tS ; Date: Mon, 21 Jul 2008 17:19:48 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Cc: Ole Troan , Iljitsch van Beijnum , IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Message-ID: <20080721151948.GF11038@Space.Net> References: <7582BC68E4994F4ABF0BD4723975C3FA09B24B65@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Mon, Jul 21, 2008 at 07:31:58AM -0400, Hemant Singh (shemant) wrote: > > - false: you need a global address on the WAN interface for uRPF > > If you don't see the obvious problem with uRPF with just a link-local > address on the WAN interface, I suggest you go do a test and get back to > us. Whether or not a specific *implementation* fails with this has nothing to do whatsoever with "obvious problems". There is no fundamental problem with uRPF over "unnumbered" interfaces (be it link-local or explicitely configured as "ipv6 unnumbered "). The example that you have given ("default route is special") is fairly irrelevant - because it's still special, even if you have a global IPv6 address on the WAN interface. So you if you do uRPF without a default route, you will still not be able to receive packets "from the world" - you'll be able to receive packets from connected neighbours, and nothing else. Which isn't overly useful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 owner-v6ops@ops.ietf.org Mon Jul 21 08:21:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF9A28C10E for ; Mon, 21 Jul 2008 08:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk3HCVTdMq3V for ; Mon, 21 Jul 2008 08:21:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF5533A69C4 for ; Mon, 21 Jul 2008 08:21:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxCb-000LiQ-UC for v6ops-data@psg.com; Mon, 21 Jul 2008 15:21:29 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxCX-000Lhm-RC for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:21:28 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14901251" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 15:21:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFLOg6024212; Mon, 21 Jul 2008 11:21:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFLO37020045; Mon, 21 Jul 2008 15:21:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:21:24 -0400 Received: from dhcp-161-44-112-105.cisco.com ([161.44.112.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:21:23 -0400 Cc: Ralph Droms , Alain Durand , "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Message-Id: <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> From: Ralph Droms To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200807211757.38784.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 11:21:22 -0400 References: <200807211757.38784.rdenis@simphalempin.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 15:21:23.0973 (UTC) FILETIME=[6FB91350:01C8EB45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3155; t=1216653684; x=1217517684; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=3D?ISO-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=20; bh=2L4AlIIuUBMWB/L7IDrvghEyLiXSnoH9EfPByOteRyc=; b=neacPklJ8Nq0IO7lyB2LSslDO3MX8L0ozlIN/tEJtIaJgpCeh7KWPbT/tc AeE9PcZGER6+gePW4eBSTgAnLh5wYO/cWnZ1A7QOXpe0rRBL1msKHIwTZJEw JY7GG/K54C; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The only time the CPE router needs to use GUA is if it has never =20 received a delegated prefix. Prefix delegation uses the same leasing =20= mechanism as address assignment; if the WAN interface on the CPE =20 router is not up, the CPE router can still use the previously =20 delegated prefix on the subscriber network. So, as long as the CPE router has been connected to the ISP network at =20= least once and has obtained a delegated prefix, there is no need for =20 GUA. To avoid unnecessary complexity, I would strongly recommend that =20= the CPE router be required to complete an initial prefix delegation =20 operation when first connected to the ISP before enabling any =20 downstream interfaces. Once that prefix delegation takes place, it is =20= immaterial whether the LAN or WAN interface comes up first. This discussion brings up the problem of subscriber network operation =20= - is it an explicit goal of this document that the subscriber network =20= be able to operate even if the WAN interface is not up? What are the =20= expectations for that unconnected operation and what services must the =20= CPE router provide to meet those expectations? According to the spec, the requesting router can only use the =20 delegated prefix until the lease on the prefix expires. We hadn't =20 thought about relaxing that restriction to allow the requesting router =20= to continue to use the delegated prefix until it has a WAN connection =20= back to the delegating router. - Ralph On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont wrote: > Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit : >> Supporting both ULA & GUA at the same time is also a source of =20 >> complexity >> and confusion. The key problem I see is with external referrals in >> multi-party communications where some of the hosts are inside, and =20= >> some are >> outside. Mixing ULA & GUA can have complex consequences, and again >> generates service call. > > Yeah. Broken RFC3484 implementations will do just that. But all =20 > nodes (broken > and non-broken RFC3484 implementations alike) will *break* without =20 > ULA, until > we have *instantaneous* 100%-reliable and 100%-available upstream =20 > connections > (which we will NEVER have). Without this, the network will simply =20 > not work > until the ISP connection is established (if ever), which is a total > non-starter. Therefore, it seems like a total non-question that ULA =20= > is the > way to go. > >> Also, if I read the text correctly, if the WAN interface gets =20 >> configured >> first, no ULA are generated. Which leads to confusing situation =20 >> depending >> on whether the customer turns its modem on before or after its CPE. > > You may have a point here. > >> I would rather like the text to recommend to only use ULA when =20 >> nothing else >> is available and immediately renumber to GUA when those are acquired. > > And break existing connections on the local network? Total no go. > > --=20 > R=E9mi Denis-Courmont > http://www.remlab.net/ > From owner-v6ops@ops.ietf.org Mon Jul 21 08:41:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6983A680A for ; Mon, 21 Jul 2008 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktvGkzjU1XQ1 for ; Mon, 21 Jul 2008 08:41:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 370823A67DB for ; Mon, 21 Jul 2008 08:41:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxUl-00001o-AS for v6ops-data@psg.com; Mon, 21 Jul 2008 15:40:15 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxUh-000Q0b-7I for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:40:13 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14888016" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 15:40:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFeAtW004034; Mon, 21 Jul 2008 11:40:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFe6Kn027097; Mon, 21 Jul 2008 15:40:10 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:40:05 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 11:39:54 -0400 Message-ID: In-Reply-To: <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrRW/X8X/Upfn2Tr2tF++Ccs1U4AAAO+kQ References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Cc: "Alain Durand" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 15:40:05.0635 (UTC) FILETIME=[0C491D30:01C8EB48] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4793; t=1216654810; x=1217518810; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=20=20=20=20=20=3D?iso-8859-1?Q?R=3DE9mi_Denis-C ourmont?=3D=20; bh=oMD+0v/w4lgPG0brp8j592As6NcjzPa0GuPJI2aQzX0=; b=icm9g2gxVYGRsQ33g6zkW6bYWqlVMod7QLmjh4zWM9DY546/yIB/C8aKOO nLOJj5Uum0ipH943j31oOJsAUqVX+NdtTG1Hvd5ywtJZDClhUaNhyPbB1FEm RtROAMhfLe; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Monday, July 21, 2008 11:21 AM To: R=E9mi Denis-Courmont Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); = v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review > The only time the CPE router needs to use GUA is if it has never = received a delegated prefix. =20 Huh? Did you mean to say ULA? Anyhow, the rest of your discussion does = not map to the problem at hand. Our problem is that I have bought this = standalone CPE router from Best Buy (in the U.S.) and now I want to = configure it at home via the web for the first time. I have still not = connected the router to the SP WAN. I just connect an Ethernet cable = between the CPE Router LAN interface and my PC and power up the router. = Now I need to configure the router via the web. Initially we had = suggested to use link-local address of the LAN interface to access the = router from the web. But Remi said that needs the full network name = interface configuration in some browsers (we didn't need that in our = test at Cisco) and also the access has some non-compliance with HTTP. = So then we said, we'll use a ULA. At this juncture of the router = operation/configuration, the router doesn't have any GUA. A lot of = folks in private emails to us have agreed to supporting ULA on the LAN = interface(s) of the CPE Router. We really don't think a coexisting ULA = with GUA on the LAN in a problem for any data forwarding or source = address selection. We have one solution using ULA. If a better solution is available for = the problem described above, we are open to it. Thanks. Hemant > Prefix delegation uses the same leasing mechanism as address = assignment; if the WAN interface on the CPE router is not up, the CPE = router can still use > the previously delegated prefix on the subscriber = network. >=20 > So, as long as the CPE router has been connected to the ISP network at = least once and has obtained a delegated prefix, there is no need for = GUA. To=20 > avoid unnecessary complexity, I would strongly recommend that the CPE = router be required to complete an initial prefix delegation operation = when first=20 > connected to the ISP before enabling any downstream interfaces. Once = that prefix delegation takes place, it is immaterial whether the LAN or = WAN=20 > interface comes up first. >=20 > This discussion brings up the problem of subscriber network operation > - is it an explicit goal of this document that the subscriber network = be able to operate even if the WAN interface is not up? What are the = expectations > for that unconnected operation and what services must the = CPE router provide to meet those expectations? >=20 > According to the spec, the requesting router can only use the = delegated prefix until the lease on the prefix expires. We hadn't = thought about relaxing > that restriction to allow the requesting router = to continue to use the delegated prefix until it has a WAN connection = back to the delegating router. > - Ralph On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont wrote: > Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit : >> Supporting both ULA & GUA at the same time is also a source of =20 >> complexity >> and confusion. The key problem I see is with external referrals in >> multi-party communications where some of the hosts are inside, and =20 >> some are >> outside. Mixing ULA & GUA can have complex consequences, and again >> generates service call. > > Yeah. Broken RFC3484 implementations will do just that. But all =20 > nodes (broken > and non-broken RFC3484 implementations alike) will *break* without =20 > ULA, until > we have *instantaneous* 100%-reliable and 100%-available upstream =20 > connections > (which we will NEVER have). Without this, the network will simply =20 > not work > until the ISP connection is established (if ever), which is a total > non-starter. Therefore, it seems like a total non-question that ULA =20 > is the > way to go. > >> Also, if I read the text correctly, if the WAN interface gets =20 >> configured >> first, no ULA are generated. Which leads to confusing situation =20 >> depending >> on whether the customer turns its modem on before or after its CPE. > > You may have a point here. > >> I would rather like the text to recommend to only use ULA when =20 >> nothing else >> is available and immediately renumber to GUA when those are acquired. > > And break existing connections on the local network? Total no go. > > --=20 > R=E9mi Denis-Courmont > http://www.remlab.net/ > From owner-v6ops@ops.ietf.org Mon Jul 21 08:50:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2BC3A6A35 for ; Mon, 21 Jul 2008 08:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.146 X-Spam-Level: X-Spam-Status: No, score=-5.146 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wPLodpZ4tVE for ; Mon, 21 Jul 2008 08:49:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C55823A6828 for ; Mon, 21 Jul 2008 08:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxe0-0002GQ-Sy for v6ops-data@psg.com; Mon, 21 Jul 2008 15:49:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxdw-0002Fq-Lu for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:49:46 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14889391" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 15:49:43 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFnhwF010019; Mon, 21 Jul 2008 11:49:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFnhMb029305; Mon, 21 Jul 2008 15:49:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:49:43 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:49:42 -0400 Cc: Ralph Droms , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" Message-Id: <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> From: Ralph Droms To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 11:49:41 -0400 References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 15:49:43.0156 (UTC) FILETIME=[6483D340:01C8EB49] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5982; t=1216655383; x=1217519383; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20; bh=SJvjfFmU0Tn8YvsHv2Tp8O07x5rYTM4WGzXRQKBE+rw=; b=jXKUnbQ1E5Ayryu57smvUn+u/eqW2zwionTyjWCBEdvT5+YZiWqUsyVvCO 94037UeWsH5r6JNu+voWrymvHgm3o9i81Z/WNyOcZu/aznKVZYhG661Cozbt yaffsPXFQE; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sorry; yes, please s/GUA/ULA> The discussion is not irrelevant. I've seen references in the thread =20= to generically enabling the LAN interface before the WAN interface. =20 One of the points I explained in my e-mail is that *once the CPE has =20 received a prefix* the order of interface enabling is irrelevant. I also explicitly discussed the corner case you describe. I don't =20 understand why we want to add complexity to allow the customer to =20 configure the CPE router before connecting to the WAN. Once you =20 understand that the CPE router can retain the delegated prefix, there =20= is no point to worrying about ULA and then renumbering for global =20 addresses. Simply require that the CPE router connect to the WAN long =20= enough to get a delegated prefix and then allow the subscriber to do =20 any customized config. - RAlph On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 11:21 AM > To: R=E9mi Denis-Courmont > Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); = v6ops@ops.ietf.org=20 > ; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available =20= > for review > >> The only time the CPE router needs to use GUA is if it has never =20 >> received a delegated prefix. > > Huh? Did you mean to say ULA? Anyhow, the rest of your discussion =20 > does not map to the problem at hand. Our problem is that I have =20 > bought this standalone CPE router from Best Buy (in the U.S.) and =20 > now I want to configure it at home via the web for the first time. =20= > I have still not connected the router to the SP WAN. I just connect =20= > an Ethernet cable between the CPE Router LAN interface and my PC and =20= > power up the router. Now I need to configure the router via the =20 > web. Initially we had suggested to use link-local address of the =20 > LAN interface to access the router from the web. But Remi said that =20= > needs the full network name interface configuration in some browsers =20= > (we didn't need that in our test at Cisco) and also the access has =20 > some non-compliance with HTTP. So then we said, we'll use a ULA. =20 > At this juncture of the router operation/configuration, the router =20 > doesn't have any GUA. A lot of folks in private emails to us have =20 > agreed to supporting ULA on the LAN interface(s) of the CPE Router. =20= > We really don't think a coexisting ULA with GUA on the LAN in a =20 > problem for any data forwarding or source address selection. > > We have one solution using ULA. If a better solution is available =20 > for the problem described above, we are open to it. > > Thanks. > > Hemant > >> Prefix delegation uses the same leasing mechanism as address =20 >> assignment; if the WAN interface on the CPE router is not up, the =20 >> CPE router can still use > the previously delegated prefix on the =20 >> subscriber network. >> >> So, as long as the CPE router has been connected to the ISP network =20= >> at least once and has obtained a delegated prefix, there is no need =20= >> for GUA. To >> avoid unnecessary complexity, I would strongly recommend that the =20 >> CPE router be required to complete an initial prefix delegation =20 >> operation when first >> connected to the ISP before enabling any downstream interfaces. =20 >> Once that prefix delegation takes place, it is immaterial whether =20 >> the LAN or WAN >> interface comes up first. >> >> This discussion brings up the problem of subscriber network operation >> - is it an explicit goal of this document that the subscriber =20 >> network be able to operate even if the WAN interface is not up? =20 >> What are the expectations > for that unconnected operation and what =20= >> services must the CPE router provide to meet those expectations? >> >> According to the spec, the requesting router can only use the =20 >> delegated prefix until the lease on the prefix expires. We hadn't =20= >> thought about relaxing > that restriction to allow the requesting =20 >> router to continue to use the delegated prefix until it has a WAN =20 >> connection back to the delegating router. > >> - Ralph > > > On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont = wrote: > >> Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit = : >>> Supporting both ULA & GUA at the same time is also a source of >>> complexity >>> and confusion. The key problem I see is with external referrals in >>> multi-party communications where some of the hosts are inside, and >>> some are >>> outside. Mixing ULA & GUA can have complex consequences, and again >>> generates service call. >> >> Yeah. Broken RFC3484 implementations will do just that. But all >> nodes (broken >> and non-broken RFC3484 implementations alike) will *break* without >> ULA, until >> we have *instantaneous* 100%-reliable and 100%-available upstream >> connections >> (which we will NEVER have). Without this, the network will simply >> not work >> until the ISP connection is established (if ever), which is a total >> non-starter. Therefore, it seems like a total non-question that ULA >> is the >> way to go. >> >>> Also, if I read the text correctly, if the WAN interface gets >>> configured >>> first, no ULA are generated. Which leads to confusing situation >>> depending >>> on whether the customer turns its modem on before or after its CPE. >> >> You may have a point here. >> >>> I would rather like the text to recommend to only use ULA when >>> nothing else >>> is available and immediately renumber to GUA when those are =20 >>> acquired. >> >> And break existing connections on the local network? Total no go. >> >> --=20 >> R=E9mi Denis-Courmont >> http://www.remlab.net/ >> > From owner-v6ops@ops.ietf.org Mon Jul 21 08:53:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A4F3A686B for ; Mon, 21 Jul 2008 08:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5IY299LO8se for ; Mon, 21 Jul 2008 08:53:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C7B13A684A for ; Mon, 21 Jul 2008 08:53:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxhJ-000363-CT for v6ops-data@psg.com; Mon, 21 Jul 2008 15:53:13 +0000 Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxhE-000354-LI for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:53:11 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id C13D3ADADC; Mon, 21 Jul 2008 17:53:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B870BADAD9; Mon, 21 Jul 2008 17:53:07 +0200 (CEST) Date: Mon, 21 Jul 2008 17:53:07 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" cc: Francois-Xavier Le Bail , Iljitsch van Beijnum , Ole Troan , IPv6 Operations Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt In-Reply-To: Message-ID: References: <994551.88685.qm@web62502.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 21 Jul 2008, Hemant Singh (shemant) wrote: > The traffic direction of the Loopback interface in the generic router > sense is that the Loopback interface does not face any traffic > direction. However, the Loopback interface for the CPE Router can > initiate IPv6 address acquisition via the WAN interface to the SP. > > The architecture, I am referring to is Integrated Routing and Bridging > (IRB) - google it. Such routing can send the RA to other virtual > interfaces of a router. For me, a loopback interface is a virtual interface, as per your first part. "interface loopback 0" in cisco routers. If the IP address is in IRB, then it's no longer a loopback interface, it's a bridge- or vlan-interface. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Jul 21 08:58:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996933A6924 for ; Mon, 21 Jul 2008 08:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.705 X-Spam-Level: X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09V-vzoLhin2 for ; Mon, 21 Jul 2008 08:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF9AB3A67A6 for ; Mon, 21 Jul 2008 08:58:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxlb-0003uw-L5 for v6ops-data@psg.com; Mon, 21 Jul 2008 15:57:39 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxlX-0003uT-5h for v6ops@ops.ietf.org; Mon, 21 Jul 2008 15:57:37 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14890687" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 15:57:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LFvYV6015655; Mon, 21 Jul 2008 11:57:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LFvYHg004519; Mon, 21 Jul 2008 15:57:34 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 11:57:33 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 11:57:33 -0400 Message-ID: In-Reply-To: <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrSWTGNqNJkQ6fSlqCGx7ubeDIrAAAElBw References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 15:57:33.0931 (UTC) FILETIME=[7D1E63B0:01C8EB4A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6960; t=1216655854; x=1217519854; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20, =0A=20=20=20=20=20=20=20=20=22Mark=20Townsley=20(townsley)=2 2=20,=0A=20=20=20=20=20=20=20=20=22Jimmy =20Chuang=20(cchuang)=22=20; bh=P25h6/BKDga4g1cNx2XMnZqoZYq9Z565KJndGBNvmXY=; b=k8fGlaUDZYqcLOlEfR4UhpfpPOCBT+yRXQdy9w2ajA+Dkh/3smfDc2rHww TSAV3bk85QORqusHIPuhTp28rjaTN45v6EPcFwIpovhFPxoynua4B13b4LJl aNR4UDWmvM; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I repeat myself. I am only discussing the case when the CPE Router is = powered up without connecting the router WAN interface to the SP. This = is also the first time the CPE Router is powered up. Further this is = NOT a corner case. Moreover, all IPv4 home router customers are used to = one stable private IPv4 address to access their say, Linksys router, no = matter when and what global IPv4 address gets assigned to the WAN = interface. Why not use one ULA for the same purpose in IPv6? With your = proposal, if the WAN GUA is used to configure the CPE Router, that GUA = may change over time and now the user has to remember a new GUA.=20 Sorry, I don't think this user experience should be brushed away for = IPv6. Hemant -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Monday, July 21, 2008 11:50 AM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); R=E9mi Denis-Courmont; Alain Durand; = v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Sorry; yes, please s/GUA/ULA> The discussion is not irrelevant. I've seen references in the thread =20 to generically enabling the LAN interface before the WAN interface. =20 One of the points I explained in my e-mail is that *once the CPE has = received a prefix* the order of interface enabling is irrelevant. I also explicitly discussed the corner case you describe. I don't = understand why we want to add complexity to allow the customer to = configure the CPE router before connecting to the WAN. Once you = understand that the CPE router can retain the delegated prefix, there is = no point to worrying about ULA and then renumbering for global = addresses. Simply require that the CPE router connect to the WAN long = enough to get a delegated prefix and then allow the subscriber to do any = customized config. - RAlph On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 11:21 AM > To: R=E9mi Denis-Courmont > Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant);=20 > v6ops@ops.ietf.org ; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review > >> The only time the CPE router needs to use GUA is if it has never=20 >> received a delegated prefix. > > Huh? Did you mean to say ULA? Anyhow, the rest of your discussion=20 > does not map to the problem at hand. Our problem is that I have=20 > bought this standalone CPE router from Best Buy (in the U.S.) and > now I want to configure it at home via the web for the first time. =20 > I have still not connected the router to the SP WAN. I just connect=20 > an Ethernet cable between the CPE Router LAN interface and my PC and=20 > power up the router. Now I need to configure the router via the web. = > Initially we had suggested to use link-local address of the LAN=20 > interface to access the router from the web. But Remi said that needs = > the full network name interface configuration in some browsers (we=20 > didn't need that in our test at Cisco) and also the access has > some non-compliance with HTTP. So then we said, we'll use a ULA. =20 > At this juncture of the router operation/configuration, the router=20 > doesn't have any GUA. A lot of folks in private emails to us have > agreed to supporting ULA on the LAN interface(s) of the CPE Router. =20 > We really don't think a coexisting ULA with GUA on the LAN in a=20 > problem for any data forwarding or source address selection. > > We have one solution using ULA. If a better solution is available for = > the problem described above, we are open to it. > > Thanks. > > Hemant > >> Prefix delegation uses the same leasing mechanism as address=20 >> assignment; if the WAN interface on the CPE router is not up, the CPE = >> router can still use > the previously delegated prefix on the=20 >> subscriber network. >> >> So, as long as the CPE router has been connected to the ISP network=20 >> at least once and has obtained a delegated prefix, there is no need=20 >> for GUA. To avoid unnecessary complexity, I would strongly recommend = >> that the CPE router be required to complete an initial prefix=20 >> delegation operation when first >> connected to the ISP before enabling any downstream interfaces. =20 >> Once that prefix delegation takes place, it is immaterial whether the = >> LAN or WAN interface comes up first. >> >> This discussion brings up the problem of subscriber network operation >> - is it an explicit goal of this document that the subscriber =20 >> network be able to operate even if the WAN interface is not up? =20 >> What are the expectations > for that unconnected operation and what=20 >> services must the CPE router provide to meet those expectations? >> >> According to the spec, the requesting router can only use the=20 >> delegated prefix until the lease on the prefix expires. We hadn't=20 >> thought about relaxing > that restriction to allow the requesting=20 >> router to continue to use the delegated prefix until it has a WAN=20 >> connection back to the delegating router. > >> - Ralph > > > On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont = wrote: > >> Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit = : >>> Supporting both ULA & GUA at the same time is also a source of=20 >>> complexity and confusion. The key problem I see is with external=20 >>> referrals in multi-party communications where some of the hosts are=20 >>> inside, and some are outside. Mixing ULA & GUA can have complex=20 >>> consequences, and again generates service call. >> >> Yeah. Broken RFC3484 implementations will do just that. But all nodes = >> (broken and non-broken RFC3484 implementations alike) will *break*=20 >> without ULA, until we have *instantaneous* 100%-reliable and=20 >> 100%-available upstream connections (which we will NEVER have).=20 >> Without this, the network will simply not work until the ISP=20 >> connection is established (if ever), which is a total non-starter.=20 >> Therefore, it seems like a total non-question that ULA is the way to=20 >> go. >> >>> Also, if I read the text correctly, if the WAN interface gets=20 >>> configured first, no ULA are generated. Which leads to confusing=20 >>> situation depending on whether the customer turns its modem on=20 >>> before or after its CPE. >> >> You may have a point here. >> >>> I would rather like the text to recommend to only use ULA when=20 >>> nothing else is available and immediately renumber to GUA when those = >>> are acquired. >> >> And break existing connections on the local network? Total no go. >> >> -- >> R=E9mi Denis-Courmont >> http://www.remlab.net/ >> > From owner-v6ops@ops.ietf.org Mon Jul 21 09:11:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1203A680A for ; Mon, 21 Jul 2008 09:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJIV-A1ulTwb for ; Mon, 21 Jul 2008 09:11:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D55CD3A684A for ; Mon, 21 Jul 2008 09:11:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxxE-00061W-4X for v6ops-data@psg.com; Mon, 21 Jul 2008 16:09:40 +0000 Received: from [128.18.84.114] (helo=mailgate-internal4.sri.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxx9-000618-Ji for v6ops@ops.ietf.org; Mon, 21 Jul 2008 16:09:38 +0000 Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 21 Jul 2008 16:09:34 -0000 X-AuditID: 80125474-ad131bb000000a5e-75-4884b4be6bf7 Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id A0F921B2501 for ; Mon, 21 Jul 2008 09:09:34 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4D00FLD67WM503@mail.sri.com> for v6ops@ops.ietf.org; Mon, 21 Jul 2008 09:09:34 -0700 (PDT) Date: Mon, 21 Jul 2008 12:09:35 -0400 From: Ed Jankiewicz Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 In-reply-to: <48822ADD.4010409@it.uc3m.es> To: marcelo bagnulo braun Cc: IPv6 Operations Message-id: <4884B4BF.1010901@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT References: <4880ED7A.20007@sri.com> <48822ADD.4010409@it.uc3m.es> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: some follow-up in line, also see my response to Brian's points not repeated here. marcelo bagnulo braun wrote: > Hi Ed, > > thanks for the feedback > > some comments in line... > > Ed Jankiewicz escribió: >> in addition to some editorial comments I sent to Marcelo, I have a >> few substantive comments (some admittedly half-baked) and discussion >> points to raise on the draft. I'm assuming there will be discussion >> at IETF 72? >> >> 1. transition versus coexistence: recognizing that the period of >> coexistence is likely to be longer, I would rather see consistent use >> of the term coexistence rather than transition throughout the >> document, e.g. coexistence scenarios, coexistence tools, etc. >> > right, i will make this change, if nobody opposes > >> 2. add a sentence in front of the Problem Statement to explicitly >> state this motivation, e.g. "Settled opinion on the transition from >> an IPv4-dominant network to an IPv6-dominant network was that the >> period of coexistence would be brief, and could be accommodated by >> dual-stack and tunneling. Operationally, we now expect..." >> > I don't think this was an assumption... at least for a long period now... ok, I agree that current opinion has accepted reality of long term coexistence. > >> 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF >> strongly prefers and recommends [dual stack] as the operational >> matters are simplest" begs for a citation. RFC 4213 says dual stack >> is the most straightforward but does not include language >> recommending or preferring this solution. Also the impetus of this >> draft is that dual stack solves only the simplest part of the >> problem, and becomes very problematic when IPv4 addresses really get >> scarce (approaching rather than reaching exhaustion). Some have >> already stated (Alain Durand I recall saying something like) "a plan >> that requires all new end-nodes to be dual-stack and to have global >> IPv4 addresses is a non-starter." Also an emphasis on dual stack >> creates a "must carry" situation where the core network continues to >> route IPv4 indefinitely. While we say in para 2.2 that turning off >> IPv4 will be a business decision, the ISP can't make that choice >> without alienating customers that rely on dual stack. I can still >> plug in a 50 year old rotary dial phone and expect the local telco >> (in the USA at least) to make it work, even though DTMF has been the >> dominant method for nearly that long. >> > i understand that this was what the document was reccomending > > Best option, native connectivity i.e. talk to v4 hosts using native v4 > and talke to v6 hosts using native v6, hence dual stack > Second best option, tunnel. this keeps packet unchanged > Third option, translation > > do you think this is the wrong reccomendation to make? not disagreeing with the recommendation - see Brian's comment and my response, also Remi's remarks relate. If we say "the IETF strongly prefers and recommends..." that needs to be justified with a citation. If there isn't a published statement to that effect, this draft can simply make the case, as you do in your comment. This draft does focus on the translation case as a last resort where dual stack or tunneling do not solve the problem. Maybe we just need explicit statement of the applicability of each class of solution right up front in the introductory paragraphs. > >> 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF >> recommends tunnels rather than dual NAT - that also would need a >> citation, unless this document is making the statement for the first >> time. Also, I believe if the two NATs know they are in a reflexive >> relationship, they can avoid at least some of the general NAT >> problems - i.e. they should not attempt to translate addresses in >> application data. >> >> 5. translation network architecture: this may be beyond scope, but >> it seems to me that in para 2.1.3 there could be several >> sub-scenarios depending on the location of the translator >> a. translator coupled to IPv6 end-nodes (IPv6 on the LAN side, >> IPv4 on the WAN side) >> b. translator coupled to IPv4 end-nodes (IPv4 on the LAN side, >> IPv6 on the WAN side) >> c. in-network translation gateway (most like NAT-PT) >> There are some commercial products in development that fit these >> sub-scenarios, and each has its own strengths and weaknesses. >> Pulling the translator into an IPv6-only or IPv4-only edge network (a >> or b) avoids some issues and those developers made the choice to >> restrict deployment architecture to simplify their job. The >> different deployment architectures also have impact on the addressing >> concerns (para 3.3) and namespace (para 3.4). >> > i don't understand the scenarios you mention above > > I mean, for me a would be mostly nat64 and b would be mostly nat46 and > c is the sum of both > > I am now considering having two different sets of requirements, one > for nat64 and another for nat46, would that make sense to you? yes. my gut feeling is that solutions could be rather difficult if the deployment is restricted to "one foot firmly planted" in v6 versus v4, i.e. if the translator can assume everything on one side is restricted to v4 or v6 rather than an unrestricted topology. I have not studied all the solution space drafts (apbp and ds-lite) that may address some of the differences. It seems the unrestricted topology (in-network scenario c) starts to fall into the same traps as NAT-PT. not to reopen what might be settled - but it does seem like a generic "problem statement" draft that encompasses the taxonomy of approaches would still be useful, while a set of requirements drafts defining the solution space would be as well. To some extent we are reverse engineering the proposed solutions into a problem statement. > >> 6. para 3.5 on market timing seems out of place as an >> implementation/deployment statement in a requirements draft >> > don't know, you want to remove it? > seems a pretty reasonable statement to me... no I don't object to keeping it, it is relevant to the topic. > >> 7. Requirement R3 would be better stated in the negative: >> Translation mechanism MUST NOT interfere with native >> connectivity...depending where the NAT64 is in the network it may be >> a pass-through, or it may not be involved at all in the native flow >> and thus do nothing but non-interference. >> > right, so why is this not expressed in the current form just a style point - I prefer that when introducing something new into an architecture, the new thing is explicitly forbidden to interfere with pre-existing functionality. The new thing has no positive requirement to enable that functionality but is required NOT to interfere with it. If the native flow bypasses the translator, it does nothing; if the native flow is through the translator it must be passed without modification, another flavor of "do nothing" or "first, do no harm." > >> 8. Requirement R4 is very broad. the essence of translating DNS in >> support of NAT64 is to map a query on one side to the equivalent >> query on the other, and do the same with the response. Of course >> that mapping of names and addresses is non-trivial. It might help to >> illustrate this mapping process as well as some of the bad behavior >> that must be avoided. >> > so any suggestion how to rephrase it? I'll follow up with some language. > >> 9. Requirement R5 seems to forbid any routing table update, but >> don't the addresses that the NAT64 is mapping have to be routable? >> > no, i don't think it is what it means, I think the goal here is to > preclude mechanisms that would for instance map each v4 prefix into a > different v6 prefix and that for some reason cannot be aggregated. If > such a mechanism would exist, then we would importing all the v4 > routing table into v6, which would be a bad idea. > But certainly the v6 addresses that are used to map v4 addresses need > to be routable. I mean, think about the deprecated natpt, it does not > requires additional global routing table entries, right? true - the v6 addresses used in the mechanism should not require new routing table entries. I definitely agree on the badness of importing the v4 table. > >> 10. Requirement R6 lists a few protocols, but I'm sure others might >> be seen as highly desirable too. Are we avoiding ALG issues by not >> mentioning higher level protocols like FTP? >> > No, the idea here was to mention the very basci protocols and go into > the application level protocols. Do you think we should try to list > all the application level protocols thta should be supported? that > seems difficult to me agreed > >> 11. where does the interpretation in Requirement R7 that sees the >> IPv6 side being like the private side of an IPv4 NAT come from? > This only applies to behave requirements > > I think this is the most stringent way of seeing this. > I mean, take a look in endpoint independence. this makes sense if the > v4 is the public address. If the v6 is the public address, then we are > likely to easily satisfy this and we are likely to require more that > just endpoint indepdence, but we are requiring a stable one to one > association, between the v4 address and the v6 addres,s cause we can > provide tha cause we have enough v6 addresses. > > So, all these requireemtns that are means to express difficult > tradeoffs make sense when the v4 side is the public address. If the v6 > is the publci address, we are likely to have much more stringent > requirements than those >> the opposite could be reasonable too - i.e. if there is no NAT >> between the NAT64 and the v4-only nodes the v4-only nodes might be >> using private addresses, and the IPv6 side of the NAT64 is the public >> side. The way it is described in R7, the IPv6 addresses are like >> IPv4 private addresses, mapped to the global addresses on the public >> side. >> >> 12. Requirement R9 is a noble statement but hardly a "testable" >> requirement; at least we should cite RFC 4942 as guidance, and >> analyze some of the security issues that arise in the different >> scenarios and architectures discussed in the draft. >> >> > i am not sure what you would like to see here... could you provide > some more explicit guidance? definitely cite RFC 4942, and I will try to come up with some language which can go in the Security Considerations section. The onus will be on the solutions developers to show how each solution at least does no harm. > > Regards, marcelo > > >> >> > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From owner-v6ops@ops.ietf.org Mon Jul 21 09:24:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A9B3A6846 for ; Mon, 21 Jul 2008 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.984 X-Spam-Level: X-Spam-Status: No, score=-4.984 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdVJsm6RKjt0 for ; Mon, 21 Jul 2008 09:24:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16D153A67A6 for ; Mon, 21 Jul 2008 09:24:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyBA-00083p-Ma for v6ops-data@psg.com; Mon, 21 Jul 2008 16:24:04 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyAx-000825-Hu for v6ops@ops.ietf.org; Mon, 21 Jul 2008 16:23:54 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14910231" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 16:23:50 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LGNoH8030773; Mon, 21 Jul 2008 12:23:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LGNkD5012188; Mon, 21 Jul 2008 16:23:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 12:23:47 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 12:23:21 -0400 Cc: Ralph Droms , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" Message-Id: <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> From: Ralph Droms To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 12:23:20 -0400 References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 16:23:21.0796 (UTC) FILETIME=[17B7D840:01C8EB4E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7869; t=1216657430; x=1217521430; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20; bh=Wjk1dkzPqiib2TgPtF6lZLF7p1b3yJbE2CYw2VKB82Q=; b=rvNDJ3QJ3nP1MrS2VC+gr8Ltbd6NtT826xnmiSVWvFxwzwcARQUCehstbW WaEZXoKh3KVgxorZbZuHe0tQAVTpZBVVwNbgQSTBulneUo86FbQ4DjWqRMEW d1xMT/OkG/; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Perhaps we could have a more constructive conversation about solutions =20= if we had a detailed description of the requirements for subscriber =20 network and device operation. Certainly assigning both ULA and GUA prefixes across the subscriber =20 network is doable, at the cost of extra complexity and the assumption =20= that RFC 3484 will actually . Use of ULA will give a stable address - =20= but that stable address is only useful in the unlikely case the home =20 network operator actually enters the IPv6 address for the gateway =20 instead of using DNS or other naming. And, it's up to the ISP to provide global prefix stability... - Ralph On Jul 21, 2008, at Jul 21, 2008,11:57 AM, Hemant Singh (shemant) wrote: > I repeat myself. I am only discussing the case when the CPE Router =20 > is powered up without connecting the router WAN interface to the =20 > SP. This is also the first time the CPE Router is powered up. =20 > Further this is NOT a corner case. Moreover, all IPv4 home router =20 > customers are used to one stable private IPv4 address to access =20 > their say, Linksys router, no matter when and what global IPv4 =20 > address gets assigned to the WAN interface. Why not use one ULA for =20= > the same purpose in IPv6? With your proposal, if the WAN GUA is =20 > used to configure the CPE Router, that GUA may change over time and =20= > now the user has to remember a new GUA. > > Sorry, I don't think this user experience should be brushed away for =20= > IPv6. > > Hemant > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 11:50 AM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); R=E9mi Denis-Courmont; Alain Durand; = v6ops@ops.ietf.org=20 > ; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available =20= > for review > > Sorry; yes, please s/GUA/ULA> > > The discussion is not irrelevant. I've seen references in the thread > to generically enabling the LAN interface before the WAN interface. > One of the points I explained in my e-mail is that *once the CPE has =20= > received a prefix* the order of interface enabling is irrelevant. > > I also explicitly discussed the corner case you describe. I don't =20 > understand why we want to add complexity to allow the customer to =20 > configure the CPE router before connecting to the WAN. Once you =20 > understand that the CPE router can retain the delegated prefix, =20 > there is no point to worrying about ULA and then renumbering for =20 > global addresses. Simply require that the CPE router connect to the =20= > WAN long enough to get a delegated prefix and then allow the =20 > subscriber to do any customized config. > > - RAlph > > On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) =20 > wrote: > >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Monday, July 21, 2008 11:21 AM >> To: R=E9mi Denis-Courmont >> Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); >> v6ops@ops.ietf.org ; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >> for review >> >>> The only time the CPE router needs to use GUA is if it has never >>> received a delegated prefix. >> >> Huh? Did you mean to say ULA? Anyhow, the rest of your discussion >> does not map to the problem at hand. Our problem is that I have >> bought this standalone CPE router from Best Buy (in the U.S.) and >> now I want to configure it at home via the web for the first time. >> I have still not connected the router to the SP WAN. I just connect >> an Ethernet cable between the CPE Router LAN interface and my PC and >> power up the router. Now I need to configure the router via the web. >> Initially we had suggested to use link-local address of the LAN >> interface to access the router from the web. But Remi said that =20 >> needs >> the full network name interface configuration in some browsers (we >> didn't need that in our test at Cisco) and also the access has >> some non-compliance with HTTP. So then we said, we'll use a ULA. >> At this juncture of the router operation/configuration, the router >> doesn't have any GUA. A lot of folks in private emails to us have >> agreed to supporting ULA on the LAN interface(s) of the CPE Router. >> We really don't think a coexisting ULA with GUA on the LAN in a >> problem for any data forwarding or source address selection. >> >> We have one solution using ULA. If a better solution is available =20= >> for >> the problem described above, we are open to it. >> >> Thanks. >> >> Hemant >> >>> Prefix delegation uses the same leasing mechanism as address >>> assignment; if the WAN interface on the CPE router is not up, the =20= >>> CPE >>> router can still use > the previously delegated prefix on the >>> subscriber network. >>> >>> So, as long as the CPE router has been connected to the ISP network >>> at least once and has obtained a delegated prefix, there is no need >>> for GUA. To avoid unnecessary complexity, I would strongly =20 >>> recommend >>> that the CPE router be required to complete an initial prefix >>> delegation operation when first >>> connected to the ISP before enabling any downstream interfaces. >>> Once that prefix delegation takes place, it is immaterial whether =20= >>> the >>> LAN or WAN interface comes up first. >>> >>> This discussion brings up the problem of subscriber network =20 >>> operation >>> - is it an explicit goal of this document that the subscriber >>> network be able to operate even if the WAN interface is not up? >>> What are the expectations > for that unconnected operation and what >>> services must the CPE router provide to meet those expectations? >>> >>> According to the spec, the requesting router can only use the >>> delegated prefix until the lease on the prefix expires. We hadn't >>> thought about relaxing > that restriction to allow the requesting >>> router to continue to use the delegated prefix until it has a WAN >>> connection back to the delegating router. >> >>> - Ralph >> >> >> On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont = wrote: >> >>> Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit = : >>>> Supporting both ULA & GUA at the same time is also a source of >>>> complexity and confusion. The key problem I see is with external >>>> referrals in multi-party communications where some of the hosts are >>>> inside, and some are outside. Mixing ULA & GUA can have complex >>>> consequences, and again generates service call. >>> >>> Yeah. Broken RFC3484 implementations will do just that. But all =20 >>> nodes >>> (broken and non-broken RFC3484 implementations alike) will *break* >>> without ULA, until we have *instantaneous* 100%-reliable and >>> 100%-available upstream connections (which we will NEVER have). >>> Without this, the network will simply not work until the ISP >>> connection is established (if ever), which is a total non-starter. >>> Therefore, it seems like a total non-question that ULA is the way to >>> go. >>> >>>> Also, if I read the text correctly, if the WAN interface gets >>>> configured first, no ULA are generated. Which leads to confusing >>>> situation depending on whether the customer turns its modem on >>>> before or after its CPE. >>> >>> You may have a point here. >>> >>>> I would rather like the text to recommend to only use ULA when >>>> nothing else is available and immediately renumber to GUA when =20 >>>> those >>>> are acquired. >>> >>> And break existing connections on the local network? Total no go. >>> >>> -- >>> R=E9mi Denis-Courmont >>> http://www.remlab.net/ >>> >> > From owner-v6ops@ops.ietf.org Mon Jul 21 09:44:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DBD3A68A0 for ; Mon, 21 Jul 2008 09:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAhoWKYr-no9 for ; Mon, 21 Jul 2008 09:44:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 907CE28C143 for ; Mon, 21 Jul 2008 09:44:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyUi-000B5C-1y for v6ops-data@psg.com; Mon, 21 Jul 2008 16:44:16 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyUZ-000B3g-Qj for v6ops@ops.ietf.org; Mon, 21 Jul 2008 16:44:13 +0000 X-IronPort-AV: E=Sophos;i="4.31,224,1215388800"; d="scan'208";a="14896521" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2008 16:44:06 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LGi6MG031270; Mon, 21 Jul 2008 12:44:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LGi6lG019247; Mon, 21 Jul 2008 16:44:06 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 12:44:06 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 12:43:59 -0400 Message-ID: In-Reply-To: <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICA References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 16:44:06.0025 (UTC) FILETIME=[FD561F90:01C8EB50] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8995; t=1216658646; x=1217522646; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Ralph=20Droms=20(rdroms)=22=20; bh=qfASrPvdO3i6QnhKbdx6jNUB/i8Ki8HgTFHwadE5E0c=; b=MrL5lmXMloMRwKXSTpgjWz8PbNYexopS0le6vaAiN1lx9fu0tASCfPM0B8 ++PiPjz90uyXe8bc47rQTli+1E339GK70F2iVK0Ec3CO8xMNf2HHx6yhQtFA 6rm5Mx/4sa; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ralph, Yes, we can continue the discussion. Also, by definition a standalone = CPE Router is not expected to be managed by the SP - so relying on a GUA = from the SP kind of goes against the philosophy of the device. Folks on = the CPE Router thread have been arguing as one voice that the standalone = CPE Router should be able to work for configuration without any access = to the SP.=20 I have repeatedly said, I am not convinced the ULA gets appreciable = complexity into the CPE Router. Our section 5.5.1 has clearly outlined = any complexity and shown it's minimal. The ULA fixes a very common = problem for the CPE Router which is configuring the router without any = SP access - the problem is not a corner case. Hemant -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Monday, July 21, 2008 12:23 PM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Mark Townsley (townsley); Jimmy Chuang = (cchuang); R=E9mi Denis-Courmont; Alain Durand; v6ops@ops.ietf.org; Wes = Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Perhaps we could have a more constructive conversation about solutions = if we had a detailed description of the requirements for subscriber = network and device operation. Certainly assigning both ULA and GUA prefixes across the subscriber = network is doable, at the cost of extra complexity and the assumption = that RFC 3484 will actually . Use of ULA will give a stable address - = but that stable address is only useful in the unlikely case the home = network operator actually enters the IPv6 address for the gateway = instead of using DNS or other naming. And, it's up to the ISP to provide global prefix stability... - Ralph On Jul 21, 2008, at Jul 21, 2008,11:57 AM, Hemant Singh (shemant) wrote: > I repeat myself. I am only discussing the case when the CPE Router is=20 > powered up without connecting the router WAN interface to the > SP. This is also the first time the CPE Router is powered up. =20 > Further this is NOT a corner case. Moreover, all IPv4 home router=20 > customers are used to one stable private IPv4 address to access their=20 > say, Linksys router, no matter when and what global IPv4 address gets=20 > assigned to the WAN interface. Why not use one ULA for the same=20 > purpose in IPv6? With your proposal, if the WAN GUA is used to=20 > configure the CPE Router, that GUA may change over time and now the=20 > user has to remember a new GUA. > > Sorry, I don't think this user experience should be brushed away for=20 > IPv6. > > Hemant > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 11:50 AM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); R=E9mi Denis-Courmont; Alain Durand;=20 > v6ops@ops.ietf.org ; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review > > Sorry; yes, please s/GUA/ULA> > > The discussion is not irrelevant. I've seen references in the thread=20 > to generically enabling the LAN interface before the WAN interface. > One of the points I explained in my e-mail is that *once the CPE has=20 > received a prefix* the order of interface enabling is irrelevant. > > I also explicitly discussed the corner case you describe. I don't=20 > understand why we want to add complexity to allow the customer to=20 > configure the CPE router before connecting to the WAN. Once you=20 > understand that the CPE router can retain the delegated prefix, there=20 > is no point to worrying about ULA and then renumbering for global=20 > addresses. Simply require that the CPE router connect to the WAN long = > enough to get a delegated prefix and then allow the subscriber to do=20 > any customized config. > > - RAlph > > On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) > wrote: > >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Monday, July 21, 2008 11:21 AM >> To: R=E9mi Denis-Courmont >> Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant);=20 >> v6ops@ops.ietf.org ; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 >> for review >> >>> The only time the CPE router needs to use GUA is if it has never=20 >>> received a delegated prefix. >> >> Huh? Did you mean to say ULA? Anyhow, the rest of your discussion=20 >> does not map to the problem at hand. Our problem is that I have=20 >> bought this standalone CPE router from Best Buy (in the U.S.) and now = >> I want to configure it at home via the web for the first time. >> I have still not connected the router to the SP WAN. I just connect=20 >> an Ethernet cable between the CPE Router LAN interface and my PC and=20 >> power up the router. Now I need to configure the router via the web. >> Initially we had suggested to use link-local address of the LAN=20 >> interface to access the router from the web. But Remi said that=20 >> needs the full network name interface configuration in some browsers=20 >> (we didn't need that in our test at Cisco) and also the access has=20 >> some non-compliance with HTTP. So then we said, we'll use a ULA. >> At this juncture of the router operation/configuration, the router=20 >> doesn't have any GUA. A lot of folks in private emails to us have=20 >> agreed to supporting ULA on the LAN interface(s) of the CPE Router. >> We really don't think a coexisting ULA with GUA on the LAN in a=20 >> problem for any data forwarding or source address selection. >> >> We have one solution using ULA. If a better solution is available=20 >> for the problem described above, we are open to it. >> >> Thanks. >> >> Hemant >> >>> Prefix delegation uses the same leasing mechanism as address=20 >>> assignment; if the WAN interface on the CPE router is not up, the=20 >>> CPE router can still use > the previously delegated prefix on the=20 >>> subscriber network. >>> >>> So, as long as the CPE router has been connected to the ISP network=20 >>> at least once and has obtained a delegated prefix, there is no need=20 >>> for GUA. To avoid unnecessary complexity, I would strongly=20 >>> recommend that the CPE router be required to complete an initial=20 >>> prefix delegation operation when first connected to the ISP before=20 >>> enabling any downstream interfaces. >>> Once that prefix delegation takes place, it is immaterial whether=20 >>> the LAN or WAN interface comes up first. >>> >>> This discussion brings up the problem of subscriber network=20 >>> operation >>> - is it an explicit goal of this document that the subscriber=20 >>> network be able to operate even if the WAN interface is not up? >>> What are the expectations > for that unconnected operation and what=20 >>> services must the CPE router provide to meet those expectations? >>> >>> According to the spec, the requesting router can only use the=20 >>> delegated prefix until the lease on the prefix expires. We hadn't=20 >>> thought about relaxing > that restriction to allow the requesting=20 >>> router to continue to use the delegated prefix until it has a WAN=20 >>> connection back to the delegating router. >> >>> - Ralph >> >> >> On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont = wrote: >> >>> Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit = : >>>> Supporting both ULA & GUA at the same time is also a source of=20 >>>> complexity and confusion. The key problem I see is with external=20 >>>> referrals in multi-party communications where some of the hosts are = >>>> inside, and some are outside. Mixing ULA & GUA can have complex=20 >>>> consequences, and again generates service call. >>> >>> Yeah. Broken RFC3484 implementations will do just that. But all=20 >>> nodes (broken and non-broken RFC3484 implementations alike) will=20 >>> *break* without ULA, until we have *instantaneous* 100%-reliable and = >>> 100%-available upstream connections (which we will NEVER have). >>> Without this, the network will simply not work until the ISP=20 >>> connection is established (if ever), which is a total non-starter. >>> Therefore, it seems like a total non-question that ULA is the way to = >>> go. >>> >>>> Also, if I read the text correctly, if the WAN interface gets=20 >>>> configured first, no ULA are generated. Which leads to confusing=20 >>>> situation depending on whether the customer turns its modem on=20 >>>> before or after its CPE. >>> >>> You may have a point here. >>> >>>> I would rather like the text to recommend to only use ULA when=20 >>>> nothing else is available and immediately renumber to GUA when=20 >>>> those are acquired. >>> >>> And break existing connections on the local network? Total no go. >>> >>> -- >>> R=E9mi Denis-Courmont >>> http://www.remlab.net/ >>> >> > From owner-v6ops@ops.ietf.org Mon Jul 21 13:08:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE373A6872 for ; Mon, 21 Jul 2008 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbwfCgXCD-v8 for ; Mon, 21 Jul 2008 13:08:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A07933A6808 for ; Mon, 21 Jul 2008 13:08:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL1ae-0003ys-De for v6ops-data@psg.com; Mon, 21 Jul 2008 20:02:36 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL1aZ-0003yS-IX for v6ops@ops.ietf.org; Mon, 21 Jul 2008 20:02:34 +0000 X-IronPort-AV: E=Sophos;i="4.31,225,1215388800"; d="scan'208";a="14940414" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 20:02:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6LK2Ux1002631; Mon, 21 Jul 2008 16:02:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LK2UqV007086; Mon, 21 Jul 2008 20:02:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 16:02:30 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 16:02:29 -0400 Cc: Ralph Droms , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" Message-Id: <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> From: Ralph Droms To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 16:02:28 -0400 References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 21 Jul 2008 20:02:29.0651 (UTC) FILETIME=[B4734E30:01C8EB6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9616; t=1216670550; x=1217534550; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20; bh=DRN+alw/Cr9JE8d+uCL2R8/45pTRUzS/qHq50yhSGe0=; b=DH9qhHtvdTuE299Y36nrC89cHcFtXtH1utM6beWCDxyOGt3LGz8REb2zMC O5JNbdGsOAgZpw7bsYdGXrSanZVnMSI0N84l8PLZJKRja0fDhcjvFNBwamF/ 5/vlWsMv+z; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Do you acknowledge that once the CPE router has obtained a delegated =20 prefix it is no longer necessary for the WAN interface on the CPE =20 router to be enabled for that delegated prefix to be used on the =20 subscriber network? We'll have to agree to disagree about whether configuring the CPE =20 router prior to any SP access is a corner case. - Ralph On Jul 21, 2008, at Jul 21, 2008,12:43 PM, Hemant Singh (shemant) wrote: > Ralph, > > Yes, we can continue the discussion. Also, by definition a =20 > standalone CPE Router is not expected to be managed by the SP - so =20 > relying on a GUA from the SP kind of goes against the philosophy of =20= > the device. > Folks on the CPE Router thread have been arguing as one voice that =20= > the standalone CPE Router should be able to work for configuration =20 > without any access to the SP. > > > I have repeatedly said, I am not convinced the ULA gets appreciable =20= > complexity into the CPE Router. Our section 5.5.1 has clearly =20 > outlined any complexity and shown it's minimal. The ULA fixes a =20 > very common problem for the CPE Router which is configuring the =20 > router without any SP access - the problem is not a corner case. > > Hemant > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: Monday, July 21, 2008 12:23 PM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); Mark Townsley (townsley); Jimmy Chuang =20 > (cchuang); R=E9mi Denis-Courmont; Alain Durand; v6ops@ops.ietf.org; =20= > Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available =20= > for review > > Perhaps we could have a more constructive conversation about =20 > solutions if we had a detailed description of the requirements for =20 > subscriber network and device operation. > > Certainly assigning both ULA and GUA prefixes across the subscriber =20= > network is doable, at the cost of extra complexity and the =20 > assumption that RFC 3484 will actually . Use of ULA will give a =20 > stable address - but that stable address is only useful in the =20 > unlikely case the home network operator actually enters the IPv6 =20 > address for the gateway instead of using DNS or other naming. > > And, it's up to the ISP to provide global prefix stability... > > - Ralph > > On Jul 21, 2008, at Jul 21, 2008,11:57 AM, Hemant Singh (shemant) =20 > wrote: > >> I repeat myself. I am only discussing the case when the CPE Router is >> powered up without connecting the router WAN interface to the >> SP. This is also the first time the CPE Router is powered up. >> Further this is NOT a corner case. Moreover, all IPv4 home router >> customers are used to one stable private IPv4 address to access their >> say, Linksys router, no matter when and what global IPv4 address gets >> assigned to the WAN interface. Why not use one ULA for the same >> purpose in IPv6? With your proposal, if the WAN GUA is used to >> configure the CPE Router, that GUA may change over time and now the >> user has to remember a new GUA. >> >> Sorry, I don't think this user experience should be brushed away for >> IPv6. >> >> Hemant >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Monday, July 21, 2008 11:50 AM >> To: Hemant Singh (shemant) >> Cc: Ralph Droms (rdroms); R=E9mi Denis-Courmont; Alain Durand; >> v6ops@ops.ietf.org ; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >> for review >> >> Sorry; yes, please s/GUA/ULA> >> >> The discussion is not irrelevant. I've seen references in the thread >> to generically enabling the LAN interface before the WAN interface. >> One of the points I explained in my e-mail is that *once the CPE has >> received a prefix* the order of interface enabling is irrelevant. >> >> I also explicitly discussed the corner case you describe. I don't >> understand why we want to add complexity to allow the customer to >> configure the CPE router before connecting to the WAN. Once you >> understand that the CPE router can retain the delegated prefix, there >> is no point to worrying about ULA and then renumbering for global >> addresses. Simply require that the CPE router connect to the WAN =20 >> long >> enough to get a delegated prefix and then allow the subscriber to do >> any customized config. >> >> - RAlph >> >> On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) >> wrote: >> >>> >>> -----Original Message----- >>> From: Ralph Droms (rdroms) >>> Sent: Monday, July 21, 2008 11:21 AM >>> To: R=E9mi Denis-Courmont >>> Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); >>> v6ops@ops.ietf.org ; Wes Beebee (wbeebee) >>> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >>> for review >>> >>>> The only time the CPE router needs to use GUA is if it has never >>>> received a delegated prefix. >>> >>> Huh? Did you mean to say ULA? Anyhow, the rest of your discussion >>> does not map to the problem at hand. Our problem is that I have >>> bought this standalone CPE router from Best Buy (in the U.S.) and =20= >>> now >>> I want to configure it at home via the web for the first time. >>> I have still not connected the router to the SP WAN. I just connect >>> an Ethernet cable between the CPE Router LAN interface and my PC and >>> power up the router. Now I need to configure the router via the =20 >>> web. >>> Initially we had suggested to use link-local address of the LAN >>> interface to access the router from the web. But Remi said that >>> needs the full network name interface configuration in some browsers >>> (we didn't need that in our test at Cisco) and also the access has >>> some non-compliance with HTTP. So then we said, we'll use a ULA. >>> At this juncture of the router operation/configuration, the router >>> doesn't have any GUA. A lot of folks in private emails to us have >>> agreed to supporting ULA on the LAN interface(s) of the CPE Router. >>> We really don't think a coexisting ULA with GUA on the LAN in a >>> problem for any data forwarding or source address selection. >>> >>> We have one solution using ULA. If a better solution is available >>> for the problem described above, we are open to it. >>> >>> Thanks. >>> >>> Hemant >>> >>>> Prefix delegation uses the same leasing mechanism as address >>>> assignment; if the WAN interface on the CPE router is not up, the >>>> CPE router can still use > the previously delegated prefix on the >>>> subscriber network. >>>> >>>> So, as long as the CPE router has been connected to the ISP network >>>> at least once and has obtained a delegated prefix, there is no need >>>> for GUA. To avoid unnecessary complexity, I would strongly >>>> recommend that the CPE router be required to complete an initial >>>> prefix delegation operation when first connected to the ISP before >>>> enabling any downstream interfaces. >>>> Once that prefix delegation takes place, it is immaterial whether >>>> the LAN or WAN interface comes up first. >>>> >>>> This discussion brings up the problem of subscriber network >>>> operation >>>> - is it an explicit goal of this document that the subscriber >>>> network be able to operate even if the WAN interface is not up? >>>> What are the expectations > for that unconnected operation and what >>>> services must the CPE router provide to meet those expectations? >>>> >>>> According to the spec, the requesting router can only use the >>>> delegated prefix until the lease on the prefix expires. We hadn't >>>> thought about relaxing > that restriction to allow the requesting >>>> router to continue to use the delegated prefix until it has a WAN >>>> connection back to the delegating router. >>> >>>> - Ralph >>> >>> >>> On Jul 21, 2008, at Jul 21, 2008,10:57 AM, R=E9mi Denis-Courmont =20 >>> wrote: >>> >>>> Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =20 >>>> =E9crit : >>>>> Supporting both ULA & GUA at the same time is also a source of >>>>> complexity and confusion. The key problem I see is with external >>>>> referrals in multi-party communications where some of the hosts =20= >>>>> are >>>>> inside, and some are outside. Mixing ULA & GUA can have complex >>>>> consequences, and again generates service call. >>>> >>>> Yeah. Broken RFC3484 implementations will do just that. But all >>>> nodes (broken and non-broken RFC3484 implementations alike) will >>>> *break* without ULA, until we have *instantaneous* 100%-reliable =20= >>>> and >>>> 100%-available upstream connections (which we will NEVER have). >>>> Without this, the network will simply not work until the ISP >>>> connection is established (if ever), which is a total non-starter. >>>> Therefore, it seems like a total non-question that ULA is the way =20= >>>> to >>>> go. >>>> >>>>> Also, if I read the text correctly, if the WAN interface gets >>>>> configured first, no ULA are generated. Which leads to confusing >>>>> situation depending on whether the customer turns its modem on >>>>> before or after its CPE. >>>> >>>> You may have a point here. >>>> >>>>> I would rather like the text to recommend to only use ULA when >>>>> nothing else is available and immediately renumber to GUA when >>>>> those are acquired. >>>> >>>> And break existing connections on the local network? Total no go. >>>> >>>> -- >>>> R=E9mi Denis-Courmont >>>> http://www.remlab.net/ >>>> >>> >> > From owner-v6ops@ops.ietf.org Mon Jul 21 13:10:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708693A695A for ; Mon, 21 Jul 2008 13:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.077 X-Spam-Level: X-Spam-Status: No, score=-105.077 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WxNTMf9JYpS for ; Mon, 21 Jul 2008 13:10:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48D373A6867 for ; Mon, 21 Jul 2008 13:10:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL1fq-0005LK-9c for v6ops-data@psg.com; Mon, 21 Jul 2008 20:07:58 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL1fl-0005Kr-Sw for v6ops@ops.ietf.org; Mon, 21 Jul 2008 20:07:56 +0000 X-IronPort-AV: E=Sophos;i="4.31,225,1215388800"; d="scan'208";a="67521639" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2008 20:07:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LK7r2e013294; Mon, 21 Jul 2008 13:07:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LK7rTR024966; Mon, 21 Jul 2008 20:07:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 13:07:52 -0700 Received: from stealth-10-32-244-220.cisco.com ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 13:07:52 -0700 Message-Id: <6870CBC7-7D42-4697-BE61-53178D438845@cisco.com> From: Fred Baker To: IPv6 Operations , IETF Agenda Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: IPv6 Operations Agenda for Dublin Date: Mon, 21 Jul 2008 13:07:52 -0700 Cc: Behave Chairs X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 21 Jul 2008 20:07:52.0372 (UTC) FILETIME=[74CE9F40:01C8EB6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1624; t=1216670873; x=1217534873; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20IPv6=20Operations=20Agenda=20for=20Dublin |Sender:=20; bh=tc//6JvWqlHXLmE0m19FoLHJvWuB+jVzEQ1+Lzapva0=; b=LyhiF+4NG7Dq+RaDZkRDHpScKC+erHSFrmiM+teVgtliZFltXEFkZC1gGR cz5TzKCwDIYx9/g3mYkxNHqJS2HFCnE0rDlKp0mpWC7Ik0txTFGvYqjfgUD1 fXFjStEsVNB2ZMpYRxht59KPR7Lvtj9JR/Q6yuOU8/ijFHW+EzgUM=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The draft agenda is as follows. If anyone has any agenda bashing to do, please contact me off-list. I had asked for two slots, and got them. Behave asked for two slots and didn't, and we are cooperating with them on the NAT-PT++ project. I think we can do this in one slot. Hence, Marcia, I yield our Thursday slot to Behave - please list it so on the general agenda. My objectives in this meeting are: - conclude any open issues on the Rogue RA, Address, and CPE matters, adopt as working group items if there is consensus to do so, and if possible close them - conclude any open issues on the NAT-PT++ requirements. I intend to ask for WG last call on both the v6ops and behave working group mailers, and would appreciate all commentary in a timely fashion - conclude any open issues on Teredo/tunnels Ten discussions in 150 minutes is 15 minutes per discussion. I am hoping that we can in fact do that. We will need a jabber scribe and someone to take minutes. Volunteers, please drop me a note. Monday 28 July, 2008 9:00-11:30 Dublin Time Agenda bashing Rogue RA issues draft-chown-v6ops-rogue-ra draft-ietf-v6ops-ra-guard Address issues draft-ietf-v6ops-addcon NAT-PT++ Problem Statement draft-despres-v6ops-apbp draft-ietf-v6ops-nat64-pb-statement-req Teredo and tunnels draft-ietf-v6ops-tunnel-security-concerns draft-krishnan-v6ops-teredo-update draft-thaler-v6ops-teredo-extensions CPE Router draft-wbeebee-ipv6-cpe-router Broadband issues draft-kaippallimalil-v6ops-ipv6-bbnet From owner-v6ops@ops.ietf.org Mon Jul 21 14:27:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E174D28C1A9 for ; Mon, 21 Jul 2008 14:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYXaeyELe5dL for ; Mon, 21 Jul 2008 14:27:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A81B028C1A0 for ; Mon, 21 Jul 2008 14:27:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2sr-000McD-77 for v6ops-data@psg.com; Mon, 21 Jul 2008 21:25:29 +0000 Received: from [74.125.46.30] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2sn-000MbV-C3 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 21:25:27 +0000 Received: by yw-out-2324.google.com with SMTP id 9so804542ywe.71 for ; Mon, 21 Jul 2008 14:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6NHkSYVcUWd3BzjF2Kns7p2t9mKzPImm66jmw5zojJE=; b=otAftMK7CJQ+Ud4X+lEXPuWiCAa2HzHOWtLAP3b/ju2I0Buzsh6Hq+Al6Va8Fx9zv3 DL0A0I2cnCtdMlOrUCh1dSSDc5i+MWqRlTh4HQ6f4+NsMAhDeM6zBEwBbjMmvyzWFNDQ ti82BOATVopycMoE2ERH19DMAFjWTGUvUGkfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=gidfJ0WCFXGF2qy5CYJDabozDS6jKOg9Wh+buymot5/kh7sKob6hfPhLihiao2ep28 qDl/+ZYyv6ghM019ekttwCwTYXIxQkSmrDwyPDxqAfinlTiYRBSDjZ1RPGLqLTxdO6ht Q3UyLzNNqw5jXA07trFdoz1e/I9aqGcvDNqHg= Received: by 10.150.198.20 with SMTP id v20mr4399559ybf.151.1216675524629; Mon, 21 Jul 2008 14:25:24 -0700 (PDT) Received: by 10.151.26.7 with HTTP; Mon, 21 Jul 2008 14:25:24 -0700 (PDT) Message-ID: <2bbba3c10807211425i2321d542ja30933c45bae2150@mail.gmail.com> Date: Mon, 21 Jul 2008 23:25:24 +0200 From: "Ole Troan" To: "Hemant Singh (shemant)" Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Cc: "Iljitsch van Beijnum" , "IPv6 Operations" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> X-Google-Sender-Auth: 68ea838f0ba9e6c6 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > We are not even concerned about the draft being a WG work item. We have > not even completed requirements for the device. perhaps you would have more success if you wrote down the requirements instead of arguing for solutions. >> no, you cannot use stateless DHCP for prefix delegation. > > Also, if you say IA_PD is forbidden by stateless DHCPv6, please point to > a MUST NOT text in any RFC. am I the only one thinking this discussion is becoming a little surreal? _stateless_ DHCP is used in cases where the DHCP server does not need to keep and maintain dynamic state for the client. read RFC3736. PD just as address assignment requires state. >> e.g: >> - false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP > IA/PD protocols > > The Loopback interface doesn't face the downstream or the upstream. You > and I both know RFC3633 has no explicit text that prohibits stateless > DHCPv6 asking for IA_PD as I showed how (using the ORO once an interface > has acquired a global IPv6 address). I don't understand what you are trying to say here. you are alluding to some model where the "loopback" (lets call this a virtual interface) interface is bridged with the WAN interface. I have no idea where you are going with that. when I'm talking about a loopback interface or a virtual interface on a router it is a L3 interface connected to a separate albeit virtual link. you cannot run PD on this interface for obvious reasons. it isn't connected to a DHCP server. >> - false: you need a global address on the WAN interface for uRPF > > If you don't see the obvious problem with uRPF with just a link-local > address on the WAN interface, I suggest you go do a test and get back to > us. I don't see the obvious problem, nor do I see any other problems. perhaps you can enlighten me? >> - false: loopback interface is required. (it's only purpose is to have > a stable always up management interface). > > DSL folks have asked to support the WAN interface acquiring a link-local > address. So it is the Loopback interface that acquires a global IPv6 > address to source packets to the WAN. If the Loopback interface is not > spawned, then since the LAN interface has global IPv6 address, one could > say, use the LAN interface global address to source packets to the WAN. how do you intend that a (routed) loopback interface should acquire an address? (as a matter of terminology, link-local addresses aren't acquired. they are generated). > But the CPE Router will not even function if the WAN interface has only > link-local and the LAN interface has a global IPv6 address - see section > 4 of > > http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt untrue, for the host function, routers in general implement the weak host model. even the implementation alluded to in the draft can be configured to do that. isn't the purpose of your draft to specify _how_ a CPE router should be provisioned? or do you want to find the lowest common denominator among existing IPv6 implementations... /ot From owner-v6ops@ops.ietf.org Mon Jul 21 14:29:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2180628C1B8 for ; Mon, 21 Jul 2008 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWeuDbWPS3On for ; Mon, 21 Jul 2008 14:29:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC36E28C1B5 for ; Mon, 21 Jul 2008 14:29:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2wg-000NiW-VI for v6ops-data@psg.com; Mon, 21 Jul 2008 21:29:26 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2wd-000NgZ-03 for v6ops@ops.ietf.org; Mon, 21 Jul 2008 21:29:25 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 445B2D009E; Mon, 21 Jul 2008 11:29:17 -1000 (HST) Date: Mon, 21 Jul 2008 11:29:17 -1000 (HST) From: Antonio Querubin X-X-Sender: tony@localhost.localdomain To: Ralph Droms cc: =?ISO-8859-15?Q?R=E9mi_Denis-Courmont?= , Alain Durand , "Hemant Singh (shemant)" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> Message-ID: References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 21 Jul 2008, Ralph Droms wrote: > This discussion brings up the problem of subscriber network operation - is it > an explicit goal of this document that the subscriber network be able to > operate even if the WAN interface is not up? What are the expectations for > that unconnected operation and what services must the CPE router provide to > meet those expectations? I suspect I'm over-simplifying but this comes down to whether the 'dentist office' operation needs to continue operations. I think it does. Should the CPE router even send RAs or any hint of it's presence until the WAN connection is confirmed to be working? On one hand, a CPE router with a single logical LAN interface can be designed to provide virtual presence of the SP connection iff connectivity through the WAN is available. And that can be predicated on whether the CPE router is able to obtain or sense some kind of connectivity from the SP. Once that single LAN/WAN behaviour is pinned down, then what remains to be determined is how multiple LAN interfaces in a CPE router should interact if the WAN or upstream connectivity is down. > According to the spec, the requesting router can only use the delegated > prefix until the lease on the prefix expires. We hadn't thought about > relaxing that restriction to allow the requesting router to continue to use > the delegated prefix until it has a WAN connection back to the delegating > router. Difficult to predict how this will play out but if the design goal of this draft is a hands-off CPE router, it's hard to see how connectivity between multiple LANs in the subscriber's network can be maintained reliably without some kind of forced persistence behaviour. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 16:14:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FAC3A69B4 for ; Mon, 21 Jul 2008 16:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU352t9mDccM for ; Mon, 21 Jul 2008 16:14:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 508353A68E4 for ; Mon, 21 Jul 2008 16:14:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Wn-000KbS-Pl for v6ops-data@psg.com; Mon, 21 Jul 2008 23:10:49 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Wj-000KUu-JA for v6ops@ops.ietf.org; Mon, 21 Jul 2008 23:10:47 +0000 X-IronPort-AV: E=Sophos;i="4.31,226,1215388800"; d="scan'208";a="14961690" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 23:10:40 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LNAeEA024305; Mon, 21 Jul 2008 19:10:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LNAeHc010244; Mon, 21 Jul 2008 23:10:40 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 19:10:40 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 19:10:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjreN2kzgUjVxa3RtWwuE65CvlNXwADVDWQ References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" , "Ralph Droms (rdroms)" Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 23:10:40.0547 (UTC) FILETIME=[FE594F30:01C8EB86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2878; t=1216681840; x=1217545840; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Antonio=20Querubin=22=20,=0A=20=20 =20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=22=20; bh=ZzBJd2JHlVtegVpCLjEH8uN1/kNDrCBHubRgAhQIm0M=; b=WYyhJD3o9Iez1W3RSpbSOM8GemRnfm7Od+lqMcfvrfYEsI82wbYngvLN8d evl/43J/zRNDWssVoVvsNmDb/56570fZa/OpYxwfLVieGlDvZGtayYMWBzqe NegyIVihwH; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Antonio and Ralph, Even if the CPE Router WAN interface is down, one does expect LAN = services between devices in the home to work. My printer server is = connected to one LAN interface while few PC's in my home are connected = to another LAN interface. Therefore IPv6 data forwarding and routing = should continue to work in the home. Only use of ULA then provides this = continued operation in the home. Also, a home router always includes a = bridge internally (it has been mentioned in the mailer) that is always = on if the device is powered up. The LAN of the CPE router is connected = to this bridge. LAN can totally continue to work in the home even if = WAN is down. Hemant -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Monday, July 21, 2008 5:29 PM To: Ralph Droms (rdroms) Cc: R=E9mi Denis-Courmont; Alain Durand; Hemant Singh (shemant); = v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review On Mon, 21 Jul 2008, Ralph Droms wrote: > This discussion brings up the problem of subscriber network operation=20 > - is it an explicit goal of this document that the subscriber network=20 > be able to operate even if the WAN interface is not up? What are the=20 > expectations for that unconnected operation and what services must the = > CPE router provide to meet those expectations? I suspect I'm over-simplifying but this comes down to whether the = 'dentist office' operation needs to continue operations. I think it = does. Should the CPE router even send RAs or any hint of it's presence = until the WAN connection is confirmed to be working? On one hand, a CPE = router with a single logical LAN interface can be designed to provide = virtual presence of the SP connection iff connectivity through the WAN = is available. And that can be predicated on whether the CPE router is = able to obtain or sense some kind of connectivity from the SP. Once = that single LAN/WAN behaviour is pinned down, then what remains to be = determined is how multiple LAN interfaces in a CPE router should = interact if the WAN or upstream connectivity is down. > According to the spec, the requesting router can only use the=20 > delegated prefix until the lease on the prefix expires. We hadn't=20 > thought about relaxing that restriction to allow the requesting router = > to continue to use the delegated prefix until it has a WAN connection=20 > back to the delegating router. Difficult to predict how this will play out but if the design goal of = this draft is a hands-off CPE router, it's hard to see how connectivity = between multiple LANs in the subscriber's network can be maintained = reliably without some kind of forced persistence behaviour. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 18:01:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E30E3A6767 for ; Mon, 21 Jul 2008 18:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guDMSXTkWSG1 for ; Mon, 21 Jul 2008 18:01:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5A0A3A63D3 for ; Mon, 21 Jul 2008 18:01:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL6DK-000GL0-Q8 for v6ops-data@psg.com; Tue, 22 Jul 2008 00:58:50 +0000 Received: from [209.85.146.180] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL6DG-000GGP-RK for v6ops@ops.ietf.org; Tue, 22 Jul 2008 00:58:48 +0000 Received: by wa-out-1112.google.com with SMTP id j37so947294waf.23 for ; Mon, 21 Jul 2008 17:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Kwd6gjcxzJn/z9aCu4lGEPi3ekpgKCgR+IYUh67gBJI=; b=ucfAICM5LClR9yNuw4hOvNkdYh18x0LJkDzomcEWbQ1Fr7W9w/xTph8rl/PjRiGKOq o7t8WsidcxkxINfl52iIlQuXArtzX/R5L4gCUGsZ7EGUzwDxNSFHbgFUsPXlBjkaONO2 KpIKYD1puzDDpXMfGY8mbHkbsW5vyDFkLnySg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Kqok4SiAsLtQawBIIRPcgdeiVUXwsKgoVHwbvwZ9JJ3JGs/9q0Oz6FysGpJmk9WnLx or75nRiGFURPP6sgZ56OzM7nlnKKPnxozSmWHPlCWv3fy3O9bc6hZyCkMRVfu3vHfVYb w/x61RGoLPu8JrxIKZX5FEtVPopblwiOgzsnc= Received: by 10.114.103.4 with SMTP id a4mr3212615wac.172.1216688324411; Mon, 21 Jul 2008 17:58:44 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m40sm9766764waf.46.2008.07.21.17.58.41 (version=SSLv3 cipher=RC4-MD5); Mon, 21 Jul 2008 17:58:43 -0700 (PDT) Message-ID: <488530CA.9090406@gmail.com> Date: Tue, 22 Jul 2008 12:58:50 +1200 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)" CC: Antonio Querubin , "Ralph Droms (rdroms)" , =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= , Alain Durand , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Regardless of whether the WAN interface is up or down, it's a normal and legitimate use of a ULA prefix to run it in parallel with a GUA prefix. So there is never, ever, any need to withdraw the ULA prefix once it has been created (as you say, it's as stable as the RFC1918 prefix that most CPEs use today). And supporting multiple prefixes is standard in every IPv6 node, so there isn't actually any scope to debate this. Brian On 2008-07-22 11:10, Hemant Singh (shemant) wrote: > Antonio and Ralph, >=20 > Even if the CPE Router WAN interface is down, one does expect LAN servi= ces between devices in the home to work. My printer server is connected = to one LAN interface while few PC's in my home are connected to another L= AN interface. Therefore IPv6 data forwarding and routing should continue= to work in the home. Only use of ULA then provides this continued opera= tion in the home. Also, a home router always includes a bridge internall= y (it has been mentioned in the mailer) that is always on if the device i= s powered up. The LAN of the CPE router is connected to this bridge. LA= N can totally continue to work in the home even if WAN is down. >=20 > Hemant >=20 > -----Original Message----- > From: Antonio Querubin [mailto:tony@lava.net]=20 > Sent: Monday, July 21, 2008 5:29 PM > To: Ralph Droms (rdroms) > Cc: R=C3=A9mi Denis-Courmont; Alain Durand; Hemant Singh (shemant); v6o= ps@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available fo= r review >=20 > On Mon, 21 Jul 2008, Ralph Droms wrote: >=20 >> This discussion brings up the problem of subscriber network operation = >> - is it an explicit goal of this document that the subscriber network = >> be able to operate even if the WAN interface is not up? What are the = >> expectations for that unconnected operation and what services must the= =20 >> CPE router provide to meet those expectations? >=20 > I suspect I'm over-simplifying but this comes down to whether the 'dent= ist office' operation needs to continue operations. I think it does. Sh= ould the CPE router even send RAs or any hint of it's presence until the = WAN connection is confirmed to be working? On one hand, a CPE router wit= h a single logical LAN interface can be designed to provide virtual prese= nce of the SP connection iff connectivity through the WAN is available. = And that can be predicated on whether the CPE router is able to obtain or= sense some kind of connectivity from the SP. Once that single LAN/WAN b= ehaviour is pinned down, then what remains to be determined is how multip= le LAN interfaces in a CPE router should interact if the WAN or upstream = connectivity is down. >=20 >> According to the spec, the requesting router can only use the=20 >> delegated prefix until the lease on the prefix expires. We hadn't=20 >> thought about relaxing that restriction to allow the requesting router= =20 >> to continue to use the delegated prefix until it has a WAN connection = >> back to the delegating router. >=20 > Difficult to predict how this will play out but if the design goal of t= his draft is a hands-off CPE router, it's hard to see how connectivity be= tween multiple LANs in the subscriber's network can be maintained reliabl= y without some kind of forced persistence behaviour. >=20 > Antonio Querubin > whois: AQ7-ARIN >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jul 21 19:27:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD5A3A67A4 for ; Mon, 21 Jul 2008 19:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ir-MXFvyAD for ; Mon, 21 Jul 2008 19:27:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01B2A3A65A6 for ; Mon, 21 Jul 2008 19:27:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7Yi-0007gM-IM for v6ops-data@psg.com; Tue, 22 Jul 2008 02:25:00 +0000 Received: from [134.134.136.21] (helo=orsmga101.jf.intel.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7Yd-0007e0-1p for v6ops@ops.ietf.org; Tue, 22 Jul 2008 02:24:58 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 21 Jul 2008 19:24:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.31,228,1215414000"; d="scan'208";a="420680271" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga001.jf.intel.com with ESMTP; 21 Jul 2008 19:24:27 -0700 Received: from mail pickup service by orsmsx334.jf.intel.com with Microsoft SMTPSVC; Mon, 21 Jul 2008 19:24:32 -0700 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 16:18:59 -0700 Received: from fmsmga101.fm.intel.com ([10.1.193.65]) by fmsmga002-1.fm.intel.com with ESMTP; 21 Jul 2008 16:16:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8AALy2hEiTHAA+mmdsb2JhbACSRwEBAQEBCAUIBxEFl1yEcA X-IronPort-AV: E=Sophos;i="4.31,226,1215414000"; d="scan'208";a="234312020" Received: from psg.com ([147.28.0.62]) by mga01.intel.com with ESMTP; 21 Jul 2008 16:16:05 -0700 Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Wn-000KbS-Pl for v6ops-data@psg.com; Mon, 21 Jul 2008 23:10:49 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Wj-000KUu-JA for v6ops@ops.ietf.org; Mon, 21 Jul 2008 23:10:47 +0000 X-IronPort-AV: E=Sophos;i="4.31,226,1215388800"; d="scan'208";a="14961690" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2008 23:10:40 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6LNAeEA024305; Mon, 21 Jul 2008 19:10:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6LNAeHc010244; Mon, 21 Jul 2008 23:10:40 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 19:10:40 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 19:10:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjreN2kzgUjVxa3RtWwuE65CvlNXwADVDWQ References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" , "Ralph Droms (rdroms)" Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "Alain Durand" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 21 Jul 2008 23:10:40.0547 (UTC) FILETIME=[FE594F30:01C8EB86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2878; t=1216681840; x=1217545840; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Antonio=20Querubin=22=20,=0A=20=20 =20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=22=20; bh=ZzBJd2JHlVtegVpCLjEH8uN1/kNDrCBHubRgAhQIm0M=; b=WYyhJD3o9Iez1W3RSpbSOM8GemRnfm7Od+lqMcfvrfYEsI82wbYngvLN8d evl/43J/zRNDWssVoVvsNmDb/56570fZa/OpYxwfLVieGlDvZGtayYMWBzqe NegyIVihwH; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); List-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Antonio and Ralph, Even if the CPE Router WAN interface is down, one does expect LAN = services between devices in the home to work. My printer server is = connected to one LAN interface while few PC's in my home are connected = to another LAN interface. Therefore IPv6 data forwarding and routing = should continue to work in the home. Only use of ULA then provides this = continued operation in the home. Also, a home router always includes a = bridge internally (it has been mentioned in the mailer) that is always = on if the device is powered up. The LAN of the CPE router is connected = to this bridge. LAN can totally continue to work in the home even if = WAN is down. Hemant -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Monday, July 21, 2008 5:29 PM To: Ralph Droms (rdroms) Cc: R=E9mi Denis-Courmont; Alain Durand; Hemant Singh (shemant); = v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review On Mon, 21 Jul 2008, Ralph Droms wrote: > This discussion brings up the problem of subscriber network operation=20 > - is it an explicit goal of this document that the subscriber network=20 > be able to operate even if the WAN interface is not up? What are the=20 > expectations for that unconnected operation and what services must the = > CPE router provide to meet those expectations? I suspect I'm over-simplifying but this comes down to whether the = 'dentist office' operation needs to continue operations. I think it = does. Should the CPE router even send RAs or any hint of it's presence = until the WAN connection is confirmed to be working? On one hand, a CPE = router with a single logical LAN interface can be designed to provide = virtual presence of the SP connection iff connectivity through the WAN = is available. And that can be predicated on whether the CPE router is = able to obtain or sense some kind of connectivity from the SP. Once = that single LAN/WAN behaviour is pinned down, then what remains to be = determined is how multiple LAN interfaces in a CPE router should = interact if the WAN or upstream connectivity is down. > According to the spec, the requesting router can only use the=20 > delegated prefix until the lease on the prefix expires. We hadn't=20 > thought about relaxing that restriction to allow the requesting router = > to continue to use the delegated prefix until it has a WAN connection=20 > back to the delegating router. Difficult to predict how this will play out but if the design goal of = this draft is a hands-off CPE router, it's hard to see how connectivity = between multiple LANs in the subscriber's network can be maintained = reliably without some kind of forced persistence behaviour. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 21 22:15:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8DA53A6846 for ; Mon, 21 Jul 2008 22:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0d4DUwtd3eh for ; Mon, 21 Jul 2008 22:15:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E03853A67FF for ; Mon, 21 Jul 2008 22:15:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLABH-000EsF-2H for v6ops-data@psg.com; Tue, 22 Jul 2008 05:12:59 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLABD-000Err-AJ for v6ops@ops.ietf.org; Tue, 22 Jul 2008 05:12:57 +0000 Received: (qmail 31870 invoked by uid 417); 22 Jul 2008 05:11:56 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 22 Jul 2008 05:11:56 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 21 Jul 2008 23:11:56 -0600 References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 23:11:56 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.107.79] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > I repeat myself. I am only discussing the case when the CPE Router is powered up without connecting the router WAN interface to the SP. This is also the first time the CPE Router is powered up. Further this is NOT a corner case. Moreover, all IPv4 home router customers are used to one stable private IPv4 address to access their say, Linksys router, no matter when and what global IPv4 address gets assigned to the WAN interface. I think this describes the confusion here. You are looking for a default IP address for the device so that users can connect to it for configuring it? In IPv4 there is usually a default RFC 1918 address that will do just this function in order to enable configuration. So would it meet your needs if we used something like ::192:168:0:1 for the default address if it is used via the Ethernet or wireless (802.11x) port? \ From owner-v6ops@ops.ietf.org Mon Jul 21 22:21:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9423A6846 for ; Mon, 21 Jul 2008 22:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVfAnvzJIzli for ; Mon, 21 Jul 2008 22:21:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 107B93A67FF for ; Mon, 21 Jul 2008 22:21:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLAJa-000GUA-3H for v6ops-data@psg.com; Tue, 22 Jul 2008 05:21:34 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLAJW-000GTd-60 for v6ops@ops.ietf.org; Tue, 22 Jul 2008 05:21:32 +0000 Received: (qmail 9120 invoked by uid 417); 22 Jul 2008 05:20:40 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 22 Jul 2008 05:20:40 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 21 Jul 2008 23:20:40 -0600 References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> In-Reply-To: <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> From: EricLKlein@softhome.net To: Ralph Droms Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 21 Jul 2008 23:20:40 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.107.79] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ralph Droms writes: > Do you acknowledge that once the CPE router has obtained a delegated > prefix it is no longer necessary for the WAN interface on the CPE router > to be enabled for that delegated prefix to be used on the subscriber > network? > > We'll have to agree to disagree about whether configuring the CPE router > prior to any SP access is a corner case. > Ralph, I think I understand what is being asked for here. Think of the Cisco ONS 15327 with the default IP address of 192.1.0.2 or the Cisco AIR-WGB350 with the default IP address of 10.0.0.1. In both cases it is possible to connect to the router via an Ethernet (not console) port using a default IP address to configure the router via a browser or telnet session. I suspect that this is the requirement that is being misunderstood here. In my previous e-mail (today) I half jokingly suggested ::192.168.0.1 as an example. For manufacturer consistency we may want to look at using ::192:1:0:2 for the ONS 1537 and ::10:0:0:1 for the AIR-WGB350. Eric From owner-v6ops@ops.ietf.org Mon Jul 21 23:41:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440203A68FA for ; Mon, 21 Jul 2008 23:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdThEnp2tyxX for ; Mon, 21 Jul 2008 23:41:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 391D73A6880 for ; Mon, 21 Jul 2008 23:41:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBWX-0005IV-Di for v6ops-data@psg.com; Tue, 22 Jul 2008 06:39:01 +0000 Received: from [217.5.214.82] (helo=tcmail12.telekom.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBWT-0005I0-1R for v6ops@ops.ietf.org; Tue, 22 Jul 2008 06:38:59 +0000 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail11.telekom.de with ESMTP; Tue, 22 Jul 2008 08:38:55 +0200 Received: from S4DE9JSAACY.ost.t-com.de ([10.125.177.233]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 08:38:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 08:38:51 +0200 Message-Id: In-reply-to: <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrbmF5tHEAL26xRa6TYmtg+zkbIwAVr5VA References: <200807211757.38784.rdenis@simphalempin.com> <9E7D6028-9102-41C0-8C26-67E3FECB646B@cisco.com> <19B4D19C-C10F-4F6D-A7C8-0EEB6D4267E0@cisco.com> <90E4EB60-8625-4505-AC55-C2B77DA672CC@cisco.com> <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> From: "Bonness, Olaf" To: , Cc: , , , , , X-OriginalArrivalTime: 22 Jul 2008 06:38:52.0639 (UTC) FILETIME=[9B48E6F0:01C8EBC5] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 > On Monday, July 21, 2008 10:02 PM Ralph Droms wrote: > > ... >=20 > Do you acknowledge that once the CPE router has obtained a delegated =20 > prefix it is no longer necessary for the WAN interface on the CPE =20 > router to be enabled for that delegated prefix to be used on the =20 > subscriber network? >=20 > We'll have to agree to disagree about whether configuring the CPE =20 > router prior to any SP access is a corner case. >=20 > - Ralph In my eyes the CPE should be able to connect devices in the several = links of the customer LAN - also in the case that it is not yet = connected via its WAN interface to the SP. Hence I think that ULAs are = needed for the LAN site of the CPE. My 2 cent. Olaf From owner-v6ops@ops.ietf.org Mon Jul 21 23:57:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE383A692F for ; Mon, 21 Jul 2008 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-Hmr23c9qtz for ; Mon, 21 Jul 2008 23:57:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47D283A6947 for ; Mon, 21 Jul 2008 23:57:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBnp-0008hB-W9 for v6ops-data@psg.com; Tue, 22 Jul 2008 06:56:53 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBnj-0008gU-RX for v6ops@ops.ietf.org; Tue, 22 Jul 2008 06:56:51 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id A92AD219; Tue, 22 Jul 2008 08:56:46 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: Ralph Droms Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 09:56:55 +0300 User-Agent: KMail/1.9.9 Cc: "Hemant Singh (shemant)" , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , "Alain Durand" , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" References: <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> In-Reply-To: <62476984-7440-4287-B4C4-11A9DAE00FB1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807220956.56205.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le lundi 21 juillet 2008 23:02:28 Ralph Droms, vous avez =E9crit=A0: > Do you acknowledge that once the CPE router has obtained a delegated > prefix it is no longer necessary for the WAN interface on the CPE > router to be enabled for that delegated prefix to be used on the > subscriber network? > > We'll have to agree to disagree about whether configuring the CPE > router prior to any SP access is a corner case. Setting up the DSL upstream can be a rather slow procedure if the signal le= vel=20 on the line is close to the technical limits. Cable connections can sometim= e=20 just fail... and when they get up again, they might renumber. And what if t= he=20 upstream connection is down for so long that the GUA prefix times out? As far as I can tell, provisioning a ULA always, regardless of the GUA is=20 actually simpler and less failure-prone. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Tue Jul 22 00:32:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2283A689D for ; Tue, 22 Jul 2008 00:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrI5Syu12wtE for ; Tue, 22 Jul 2008 00:31:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65D2C3A6885 for ; Tue, 22 Jul 2008 00:31:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCKP-000GFg-Q6 for v6ops-data@psg.com; Tue, 22 Jul 2008 07:30:33 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCKL-000GEz-1S for v6ops@ops.ietf.org; Tue, 22 Jul 2008 07:30:31 +0000 Received: (qmail 63740 invoked by uid 1007); 22 Jul 2008 07:30:15 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=i4Javnqz4TykIg6ga2+YiHoAEQ+ycxwRTJtcx7r9HYI791GMCt+RnfA5Fy98pn9B ; Date: Tue, 22 Jul 2008 09:30:15 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Cc: "Stark, Barbara" , Antonio Querubin , v6ops@ops.ietf.org Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Message-ID: <20080722073014.GN11038@Space.Net> References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE841@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, Jul 17, 2008 at 02:35:05PM -0400, Hemant Singh (shemant) wrote: > Further, even I agree with you that it's not wise for a CPE Router to > respond to pings. Just for the record: we very much value CPEs that respond to pings. (Configurable rate-limits and/or non-responsiveness is fine, but hard-wiring anything that hinders network diagnosis is very bad) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 owner-v6ops@ops.ietf.org Tue Jul 22 02:21:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CA33A69A6 for ; Tue, 22 Jul 2008 02:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY753Xpu0Ex9 for ; Tue, 22 Jul 2008 02:21:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE55B3A68B2 for ; Tue, 22 Jul 2008 02:21:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLE1q-000E9l-B7 for v6ops-data@psg.com; Tue, 22 Jul 2008 09:19:30 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLE1l-000E8s-Vx for v6ops@ops.ietf.org; Tue, 22 Jul 2008 09:19:28 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 479B415; Tue, 22 Jul 2008 11:19:23 +0200 (CEST) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net To: dthaler@microsoft.com, v6ops@ops.ietf.org Subject: Comments on draft-thaler-v6ops-teredo-extensions-01 Date: Tue, 22 Jul 2008 12:19:28 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807221219.28743.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, Generally, the document should probably use the Teredo IANA prefix rather t= han=20 the former 6bone Microsoft prefix, no? I can also understand why the sample= =20 IPv4 prefix is not used (need several addresses in preferrably separate=20 submets), but I wonder if this is acceptable. Section 3 could mention that the connectivity matrix is symmetric, or even = not=20 draw one half to make it obvious. There seems to be some XML typo here: Yes =3D Supported by . Section 3.2 is spelt UPnP-specifically. I may well be missing something, bu= t=20 it would seem to work with any middlebox mapping protocol, including SOCKSv= 5,=20 NAT-PMP, or even TURN (though I am not convinced that Teredo over TURN make= s=20 much practical sense). Regards =2D-=20 R=C3=A9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Tue Jul 22 05:52:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3603A6822 for ; Tue, 22 Jul 2008 05:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EM8S4pC6qn0 for ; Tue, 22 Jul 2008 05:52:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 987C33A68A0 for ; Tue, 22 Jul 2008 05:52:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLHHh-0007Wr-DZ for v6ops-data@psg.com; Tue, 22 Jul 2008 12:48:05 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLHHd-0007W8-8B for v6ops@ops.ietf.org; Tue, 22 Jul 2008 12:48:03 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6MCkguZ026109; Tue, 22 Jul 2008 15:46:59 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 15:46:44 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 15:46:43 +0300 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 Subject: RE: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Date: Tue, 22 Jul 2008 15:46:42 +0300 Message-ID: In-Reply-To: <48847184.9020906@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt Thread-Index: AcjrJCVaDVYJeQ9CS2GN1rlr1tp0WwA1D7ow References: <487F5BCB.1070209@it.uc3m.es> <48847184.9020906@it.uc3m.es> From: To: Cc: , , , , , , , X-OriginalArrivalTime: 22 Jul 2008 12:46:43.0979 (UTC) FILETIME=[FED41DB0:01C8EBF8] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> The solution can be tunneling, but also also double=20 >translation (4->6->4) as described at least in NATv4v6v4 and=20 >MNAT-PT drafts. >> =20 >but we are not reccomending that, right? Right.=20 I'm looking forward to see the next version of the draft. Teemu From owner-v6ops@ops.ietf.org Tue Jul 22 08:00:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F61B28C13B for ; Tue, 22 Jul 2008 08:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.308 X-Spam-Level: ** X-Spam-Status: No, score=2.308 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhRfNZxLQ1nP for ; Tue, 22 Jul 2008 08:00:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E431D28C164 for ; Tue, 22 Jul 2008 08:00:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJJD-0007Gp-1E for v6ops-data@psg.com; Tue, 22 Jul 2008 14:57:47 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJJ5-0007G5-AU for v6ops@ops.ietf.org; Tue, 22 Jul 2008 14:57:41 +0000 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8828015; Tue, 22 Jul 2008 10:57:09 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:57:08 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 14:56:47 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 10:56:45 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , Brian E Carpenter CC: , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpUX2gLik3YsKjQ6ms+cph8Bxp+QAAX4YqAF23ajAAUFPOjQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 14:57:08.0994 (UTC) FILETIME=[36E6A620:01C8EC0B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, I have no problem using ULA *in*the*absence*of* GUA. I understand that the network has to be workable in the absence of upstream connectivity. What I'd like to see is ULA being renumbered into GUA as soon as those becomes available. Brian is suggesting to have a mode where the user may also want to keep the ULA *after* GUA are acquired, I'm fine with that as long as it is not the default config. - Alain. On 7/20/08 8:47 PM, "Hemant Singh (shemant)" wrote: > Alain, > > Please go back to this draft's emails and see how Wes, I, and Remi > discussed the ULA case and a MUST requirement. Your idea below is not > valid because you have not considered the case of a standalone CPE > Router that is purchased from retail. The user will power on the CPE > Router at home and the LAN interface(s) of the router will be up first - > the user hasn't connected the WAN port yet to the broadband network. > The user needs some IPv6 address to configure the CPE Router via the > web. That is why the ULA will be used. We have also said in our draft > that manual configuration is out of scope of our draft - therefore we > are not worried about details like how does the user get to know the ULA > prior to logging on to the CPE Router over the web using this ULA. If > need be, we can also work on such details but there is no dispensing > with ULA. I too like Brian's suggestion of once per factory-reset and > further I prefer a well-known ULA address publishes apriori in the CPE > Router manuals for the user to use that address to configure the CPE > Router. After configuration, any other ULA may be generated and the > router reset to use the new ULA and associated ULA prefix(es). > > Only for the case when the CPE Router is embedded in a broadband device > like a modem and thus managed by the SP, the ULA's will not be spawned > as this is a WAN init first before LAN init model of our draft. See my > other comments about WAN init first model also complying with CableLab > docsis 3.0 standards. > > Hemant > > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Friday, July 18, 2008 11:53 PM > To: Brian E Carpenter > Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review > > > > > On 7/18/08 11:42 PM, "Brian E Carpenter" > wrote: > >>> I would rather like the text to recommend to only use ULA when >>> nothing else is available and immediately renumber to GUA when those > are acquired. >> >> IMHO that is only acceptable if there MUST be a configurable option to > >> support a ULA (generated once per factory-reset) in parallel with a >> GUA, if that's what the user wants. I think that is needed for >> scenarios where people want addresses for devices that are guaranteed >> never to reply to external packets. > > I'd agree to this if, by default, parallel ULA support is off. > > - Alain. > > > From owner-v6ops@ops.ietf.org Tue Jul 22 08:20:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EA13A6A74 for ; Tue, 22 Jul 2008 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7SRjfhXH7Ex for ; Tue, 22 Jul 2008 08:20:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 733593A6987 for ; Tue, 22 Jul 2008 08:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJe5-000Bri-Ca for v6ops-data@psg.com; Tue, 22 Jul 2008 15:19:21 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJe0-000Br4-Mh for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:19:19 +0000 X-IronPort-AV: E=Sophos;i="4.31,231,1215388800"; d="scan'208";a="15039741" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2008 15:19:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MFJABT003598; Tue, 22 Jul 2008 11:19:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MFJAiG023867; Tue, 22 Jul 2008 15:19:10 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 11:19:09 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 11:19:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjpUX2gLik3YsKjQ6ms+cph8Bxp+QAAX4YqAF23ajAAUFPOjQAAGpKw References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Brian E Carpenter" Cc: , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 15:19:09.0871 (UTC) FILETIME=[4A347BF0:01C8EC0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5005; t=1216739950; x=1217603950; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Brian=20E=20Carpenter=22=2 0; bh=mxmJMm2KYPjBppNVDR2fCVg2zyNzp2uIy6Dv6SypWzQ=; b=fsC+bhJAPDQrm2/oaySwUO6T4pSxJTs1Zj0XtYTVWqNC8cQE18Qli6rr78 k5bqqIyaeC6CLVXLUmdlo/mzyCk+CX4QO7Uoh1UPbwZfEWpSdAJ3KFWOSRKp KZ7TXx3Ydy; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, What is the concern if ULA is permanent and always present on the CPE Router? Till we see a strong justification for not having this mode of operation on the router, we will not change the draft. However, we do collect input like yours (it's totally appreciated as well) and we will keep it in mind to track for proper justification. I have heard source-address selection issues but they are not sufficient justification. The SP also does not see these ULA in their network - granted some day in future, the SP may, but then if ULA changes that much to be globally routable, then the CPE Router specification also has to change.=20 The ULA has additional justification to be permanent. The user at home does not want to be nickel and dimed by the SP who can say, I will dole out only one IA_PD to your home and that IA_PD is /56. The ULA has a much shorter prefix of /48 to serve the home network better. I want devices in my home to have permanent IPv6 addresses - ULA gives me that, GUA will not (GUA can be renumbered). Permanent ULA in IPv6 is also what the user is used to from IPv4 and it RFC1918 addresses - thanks Brian Carpenter. You see, we don't want to add another knob to the CPE Router or any new state machine unless the knob or state machine is justified. Please show us a case where concurrent ULA and GUA on the CPE Router totally breaks something and causes a major problem.=20 Thanks. Hemant -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 10:57 AM To: Hemant Singh (shemant); Brian E Carpenter Cc: v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Hemant, I have no problem using ULA *in*the*absence*of* GUA. I understand that the network has to be workable in the absence of upstream connectivity. What I'd like to see is ULA being renumbered into GUA as soon as those becomes available. Brian is suggesting to have a mode where the user may also want to keep the ULA *after* GUA are acquired, I'm fine with that as long as it is not the default config. - Alain. On 7/20/08 8:47 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Please go back to this draft's emails and see how Wes, I, and Remi=20 > discussed the ULA case and a MUST requirement. Your idea below is not > valid because you have not considered the case of a standalone CPE=20 > Router that is purchased from retail. The user will power on the CPE=20 > Router at home and the LAN interface(s) of the router will be up first > - the user hasn't connected the WAN port yet to the broadband network. > The user needs some IPv6 address to configure the CPE Router via the=20 > web. That is why the ULA will be used. We have also said in our=20 > draft that manual configuration is out of scope of our draft -=20 > therefore we are not worried about details like how does the user get=20 > to know the ULA prior to logging on to the CPE Router over the web=20 > using this ULA. If need be, we can also work on such details but=20 > there is no dispensing with ULA. I too like Brian's suggestion of=20 > once per factory-reset and further I prefer a well-known ULA address=20 > publishes apriori in the CPE Router manuals for the user to use that=20 > address to configure the CPE Router. After configuration, any other=20 > ULA may be generated and the router reset to use the new ULA and associated ULA prefix(es). >=20 > Only for the case when the CPE Router is embedded in a broadband=20 > device like a modem and thus managed by the SP, the ULA's will not be=20 > spawned as this is a WAN init first before LAN init model of our=20 > draft. See my other comments about WAN init first model also=20 > complying with CableLab docsis 3.0 standards. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Friday, July 18, 2008 11:53 PM > To: Brian E Carpenter > Cc: Hemant Singh (shemant); v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 >=20 >=20 >=20 > On 7/18/08 11:42 PM, "Brian E Carpenter" > wrote: >=20 >>> I would rather like the text to recommend to only use ULA when=20 >>> nothing else is available and immediately renumber to GUA when those > are acquired. >>=20 >> IMHO that is only acceptable if there MUST be a configurable option=20 >> to >=20 >> support a ULA (generated once per factory-reset) in parallel with a=20 >> GUA, if that's what the user wants. I think that is needed for=20 >> scenarios where people want addresses for devices that are guaranteed >> never to reply to external packets. >=20 > I'd agree to this if, by default, parallel ULA support is off. >=20 > - Alain. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 08:40:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1BF3A6A88 for ; Tue, 22 Jul 2008 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU-PprGJ+7Cf for ; Tue, 22 Jul 2008 08:40:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86F6E3A6A90 for ; Tue, 22 Jul 2008 08:40:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJxS-000GRg-1G for v6ops-data@psg.com; Tue, 22 Jul 2008 15:39:22 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJxG-000GQp-Hx for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:39:20 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 81ABF234; Tue, 22 Jul 2008 17:39:09 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: Alain Durand Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 18:39:07 +0300 User-Agent: KMail/1.9.9 Cc: "Hemant Singh (shemant)" , Brian E Carpenter , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807221839.07850.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le mardi 22 juillet 2008 17:56:45 Alain Durand, vous avez =E9crit=A0: > I have no problem using ULA *in*the*absence*of* GUA. I understand that the > network has to be workable in the absence of upstream connectivity. > > What I'd like to see is ULA being renumbered into GUA as soon as those > becomes available. > > Brian is suggesting to have a mode where the user may also want to keep t= he > ULA *after* GUA are acquired, I'm fine with that as long as it is not the > default config. Renumbering break applications. Maybe ISPs don't care less about the user L= AN=20 working properly. But users and CPE vendors do care. My IPv4 file shares, jobs-being-printed and UPnP AV streams don't break whe= n=20 my IPv4 NAT router gets the WAN interface (re)configured, because the LAN=20 IPv4 address do not change through the process. That's one of the few merit= s=20 of NAT. Like it or not, most LAN applications require/assume stable=20 addresses. Hence *constant* ULA addresses are needed on the LAN side=20 all_the_time *regardless* of the state and state changes on the WAN side. Not only that, but I fail to see the problem with ULA. The extra complexity= in=20 supporting ULA on the CPE is a lot less than the extra complexity of=20 rewriting all LAN applications and transport protocols (including TCP...) t= o=20 handle unstable addresses. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Tue Jul 22 08:41:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB363A6ABA for ; Tue, 22 Jul 2008 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.158 X-Spam-Level: *** X-Spam-Status: No, score=3.158 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtGZu-L9o1Xd for ; Tue, 22 Jul 2008 08:41:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93D2E3A6A48 for ; Tue, 22 Jul 2008 08:41:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJz7-000Gq2-9J for v6ops-data@psg.com; Tue, 22 Jul 2008 15:41:05 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJyu-000Ggo-8s for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:40:59 +0000 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58041152; Tue, 22 Jul 2008 11:40:37 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 11:40:37 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 15:39:46 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 11:39:44 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont CC: "Hemant Singh (shemant)" , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrRD+LwZvKB/kSSiS43hVGPloc7gAzOpDu In-Reply-To: <200807211757.38784.rdenis@simphalempin.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2008 15:40:37.0124 (UTC) FILETIME=[4977B440:01C8EC11] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/21/08 10:57 AM, "R=E9mi Denis-Courmont" wrote: > Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez =E9crit=A0: >> Supporting both ULA & GUA at the same time is also a source of complexit= y >> and confusion. The key problem I see is with external referrals in >> multi-party communications where some of the hosts are inside, and some = are >> outside. Mixing ULA & GUA can have complex consequences, and again >> generates service call. >=20 > Yeah. Broken RFC3484 implementations will do just that. But all nodes (br= oken > and non-broken RFC3484 implementations alike) will *break* without ULA, u= ntil > we have *instantaneous* 100%-reliable and 100%-available upstream connect= ions > (which we will NEVER have). Without this, the network will simply not wor= k > until the ISP connection is established (if ever), which is a total > non-starter. Therefore, it seems like a total non-question that ULA is th= e > way to go. I have said a couple times, I have no objection to using ULA when nothing else is available.=20 >> Also, if I read the text correctly, if the WAN interface gets configured >> first, no ULA are generated. Which leads to confusing situation dependin= g >> on whether the customer turns its modem on before or after its CPE. >=20 > You may have a point here. >=20 >> I would rather like the text to recommend to only use ULA when nothing e= lse >> is available and immediately renumber to GUA when those are acquired. >=20 > And break existing connections on the local network? Total no go. Simple use short prefix lifetime for ULA and deprecate. Normal renumbering procedure. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 08:44:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D443A6A90 for ; Tue, 22 Jul 2008 08:44:32 -0700 (PDT) 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=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf-cHc4p3oUC for ; Tue, 22 Jul 2008 08:44:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E6D73A6A7D for ; Tue, 22 Jul 2008 08:44:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK2J-000HWk-C1 for v6ops-data@psg.com; Tue, 22 Jul 2008 15:44:23 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK29-000HVR-DU for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:44:18 +0000 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58041424; Tue, 22 Jul 2008 11:43:46 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 11:43:44 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 15:43:44 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 11:43:43 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" CC: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrSWTGNqNJkQ6fSlqCGx7ubeDIrAAAElBwADICj+A= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 15:43:44.0563 (UTC) FILETIME=[B930A030:01C8EC11] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/21/08 11:57 AM, "Hemant Singh (shemant)" wrote: > I repeat myself. I am only discussing the case when the CPE Router is powered > up without connecting the router WAN interface to the SP. This is also the > first time the CPE Router is powered up. Further this is NOT a corner case. > Moreover, all IPv4 home router customers are used to one stable private IPv4 > address to access their say, Linksys router, no matter when and what global > IPv4 address gets assigned to the WAN interface. Why not use one ULA for the > same purpose in IPv6? With your proposal, if the WAN GUA is used to configure > the CPE Router, that GUA may change over time and now the user has to remember > a new GUA. > > Sorry, I don't think this user experience should be brushed away for IPv6. I sure hope you are not expecting the customer to remember or type a well know IPv6 ULA address to configure the home router... There need to be a dynamic discovery mechanism, a la Apple bonjour. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 08:45:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811953A6A92 for ; Tue, 22 Jul 2008 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.692 X-Spam-Level: X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRdKnonsTxzg for ; Tue, 22 Jul 2008 08:45:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 186433A6A9D for ; Tue, 22 Jul 2008 08:45:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK37-000Hkq-EU for v6ops-data@psg.com; Tue, 22 Jul 2008 15:45:13 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK30-000HhY-0x for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:45:08 +0000 X-IronPort-AV: E=Sophos;i="4.31,232,1215388800"; d="scan'208";a="15027949" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2008 15:45:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MFj4sn022483; Tue, 22 Jul 2008 11:45:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MFj4Nj026767; Tue, 22 Jul 2008 15:45:04 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 11:45:04 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Tue, 22 Jul 2008 11:45:04 -0400 Message-ID: In-Reply-To: <2bbba3c10807211425i2321d542ja30933c45bae2150@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjreFCHK5bwEL/pRHW232Jn8NvzTAAl4W5g References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> <2bbba3c10807211425i2321d542ja30933c45bae2150@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Ole Troan" Cc: "Iljitsch van Beijnum" , "IPv6 Operations" X-OriginalArrivalTime: 22 Jul 2008 15:45:04.0706 (UTC) FILETIME=[E8F57A20:01C8EC11] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1857; t=1216741504; x=1217605504; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Ole=20Troan=22=20; bh=NQCvAp4eVKOeDOSyARh1zVwUbkbWT6w4qMdMaFYcQC8=; b=LdxhOMHPW5QBoCOAjovCmv1kR0Wn8G9zHrD3Gh9o4CQGeM1ArkLK1dpebY tynxHMJGVbIjiGIAcZM07eJxijEr7gGVwEVyPKTPpvbqs/PN2xX+M4ltflNq aJeQ9Y4jTM; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, July 21, 2008 5:25 PM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > We are not even concerned about the draft being a WG work item. We=20 > have not even completed requirements for the device. >> perhaps you would have more success if you wrote down the requirements instead of arguing for solutions. I think so too. We thought we could provide solutions to some early requirements from DSL folks, but as you can see, those solutions need some ironing out. We have to get consensus between AT&T, NTT, Mikael Abrahamsson, and David Miles who works with DSL IPv6 Forum for requirements. In that process we also have to filter some requirements because a requirement might not be possible. We heard some consensus between AT&T and NTT when AT&T agreed that they also support a MUST for global IPv6 address on the WAN interface. There are other requirements to be ironed out. I had told the mailer, unless I meet NTT folks at IETF 72, I am not clear on their requirements and our draft is subject to change. We understand David Miles' requirements fine. We'll see what we can do to add a requirements section to the document and eventually that section also the lists what other section to go to for what requirement so that any given solution is identifiable for a given requirement. If you see the first email from Mikael on our draft, that's his requirement. Then see the first email from Shin - that's NTT's requirement. Then see the first email from David Miles to see his requirement. AT&T's requirements are best seen from any of Barbara's recent emails marching backwards. Hemant=20 From owner-v6ops@ops.ietf.org Tue Jul 22 08:50:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9623A6979 for ; Tue, 22 Jul 2008 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.363 X-Spam-Level: ** X-Spam-Status: No, score=2.363 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM7cPWtvsP+A for ; Tue, 22 Jul 2008 08:50:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1399C28C10D for ; Tue, 22 Jul 2008 08:50:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK7A-000Ibp-9b for v6ops-data@psg.com; Tue, 22 Jul 2008 15:49:24 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK76-000Ib4-E3 for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:49:22 +0000 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8837165; Tue, 22 Jul 2008 11:48:56 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 11:48:56 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 15:48:12 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 11:48:11 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 15:48:56.0064 (UTC) FILETIME=[72DBE800:01C8EC12] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: > I have repeatedly said, I am not convinced the ULA gets appreciable complexity > into the CPE Router. Our section 5.5.1 has clearly outlined any complexity and > shown it's minimal. The ULA fixes a very common problem for the CPE Router > which is configuring the router without any SP access - the problem is not a > corner case. Hemant, 2 party communications in the presence of mixed ULA & GUA work ok, given proper default address selection rules. Multi-party communications *with* address referral do not work in the general case in such a mixed environment, regardless of default address selection. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 08:50:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814F03A6AB3 for ; Tue, 22 Jul 2008 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POrxAH1UIfBj for ; Tue, 22 Jul 2008 08:50:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0FF63A6A65 for ; Tue, 22 Jul 2008 08:50:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK8F-000Ite-Cy for v6ops-data@psg.com; Tue, 22 Jul 2008 15:50:31 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLK83-000Ird-OP for v6ops@ops.ietf.org; Tue, 22 Jul 2008 15:50:24 +0000 X-IronPort-AV: E=Sophos;i="4.31,232,1215388800"; d="scan'208";a="15047690" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2008 15:50:18 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MFoInI012739; Tue, 22 Jul 2008 11:50:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MFoImH029027; Tue, 22 Jul 2008 15:50:18 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 11:50:18 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 11:50:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrSWTGNqNJkQ6fSlqCGx7ubeDIrAAAElBwADICj+AAABkHQA== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" , "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" Cc: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 15:50:18.0401 (UTC) FILETIME=[A3EF8910:01C8EC12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1723; t=1216741818; x=1217605818; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20,=0A=20=20=20=20=20=20=20=20=22Mark=20 Townsley=20(townsley)=22=20,=0A=20=20=20 =20=20=20=20=20=22Jimmy=20Chuang=20(cchuang)=22=20; bh=c+sUsr8NlBZsPT7ikNz89UWC1d7M9bb6sM5EP7ySdEQ=; b=zYcV2lzD6/bTvA4kGNHKOyWYFmxxx7f2BD56S8bmCLJiQ2K4SktnOIZXfL WEDTZL9+vT3AuT+KpKl3R2aShDk11vlvVP2tCv1lKWiyl9Q/9xRWjGX3puBk riA6rCuzfQ; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 11:44 AM To: Hemant Singh (shemant); Ralph Droms (rdroms); Mark Townsley = (townsley); Jimmy Chuang (cchuang) Cc: R=E9mi Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review On 7/21/08 11:57 AM, "Hemant Singh (shemant)" wrote: >> I repeat myself. I am only discussing the case when the CPE Router is = >> powered up without connecting the router WAN interface to the SP. =20 >> This is also the first time the CPE Router is powered up. Further = this is NOT a corner case. >> Moreover, all IPv4 home router customers are used to one stable=20 >> private IPv4 address to access their say, Linksys router, no matter=20 >> when and what global >> IPv4 address gets assigned to the WAN interface. Why not use one ULA = >> for the same purpose in IPv6? With your proposal, if the WAN GUA is=20 >> used to configure the CPE Router, that GUA may change over time and=20 >> now the user has to remember a new GUA. >>=20 >> Sorry, I don't think this user experience should be brushed away for = IPv6. > I sure hope you are not expecting the customer to remember or type a = well know IPv6 ULA address to configure the home router... >There need to be a dynamic discovery mechanism, a la Apple bonjour. > - Alain. Heck no! My good colleague in Tony Hain already pointed us to = http://en.wikipedia.org/wiki/Zeroconf. We envision every CPE Router to = have a unique ULA but the router will be accessed by a URL like = http://linksyslocal. Hemant From owner-v6ops@ops.ietf.org Tue Jul 22 09:04:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E43F28C162 for ; Tue, 22 Jul 2008 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.362 X-Spam-Level: ** X-Spam-Status: No, score=2.362 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkubZnKfOL4V for ; Tue, 22 Jul 2008 09:04:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD96A3A6A53 for ; Tue, 22 Jul 2008 09:04:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLKJP-000LLz-3M for v6ops-data@psg.com; Tue, 22 Jul 2008 16:02:03 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLKJH-000LL5-BC for v6ops@ops.ietf.org; Tue, 22 Jul 2008 16:01:57 +0000 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8839266; Tue, 22 Jul 2008 12:01:23 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 12:01:23 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 16:00:36 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 12:00:34 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: , "Hemant Singh (shemant)" CC: Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrvE/6OMScgkj+SsGBfqlgWGDyNAAV8Ljs In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 16:01:23.0654 (UTC) FILETIME=[30751660:01C8EC14] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/22/08 1:11 AM, "EricLKlein@softhome.net" wrote: > Hemant Singh (shemant) writes: > >> I repeat myself. I am only discussing the case when the CPE Router is powered >> up without connecting the router WAN interface to the SP. This is also the >> first time the CPE Router is powered up. Further this is NOT a corner case. >> Moreover, all IPv4 home router customers are used to one stable private IPv4 >> address to access their say, Linksys router, no matter when and what global >> IPv4 address gets assigned to the WAN interface. > > I think this describes the confusion here. You are looking for a default IP > address for the device so that users can connect to it for configuring it? > In IPv4 there is usually a default RFC 1918 address that will do just this > function in order to enable configuration. So would it meet your needs if we > used something like ::192:168:0:1 for the default address if it is used via > the Ethernet or wireless (802.11x) port? Eric, You are right in the analysis of the confusion. However, I think we should move away from such things as well know IP addresses and use some form of service discovery protocol instead. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 10:20:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94DC3A69D8 for ; Tue, 22 Jul 2008 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeyJE0s9E+Sl for ; Tue, 22 Jul 2008 10:19:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 978A43A6820 for ; Tue, 22 Jul 2008 10:19:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLUR-000AND-L3 for v6ops-data@psg.com; Tue, 22 Jul 2008 17:17:31 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLUN-000AMc-IA for v6ops@ops.ietf.org; Tue, 22 Jul 2008 17:17:29 +0000 X-IronPort-AV: E=Sophos;i="4.31,232,1215388800"; d="scan'208";a="15071430" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2008 17:17:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MHHQgW015998; Tue, 22 Jul 2008 13:17:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MHHQRC014103; Tue, 22 Jul 2008 17:17:26 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:17:26 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 13:17:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cA== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 17:17:26.0233 (UTC) FILETIME=[CFF76490:01C8EC1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1749; t=1216747046; x=1217611046; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20; bh=I+i99mnTBKpC56PVQ533b2cb9DpqzLUzE7PrVcswOhU=; b=doqik9jLoYjFXjk8LVi1s+DAD67BNweRitxPlYKS4DGjuXPuhwInhyD7V1 gV979b0TBW6+BahU3bC/A+N28sRCWiB8r9iTs/DlrUYd90X4lMmwGvS3URG8 +kYAx6tG6R; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Sorry I don't understand. If any node in the home using an ULA sends a = packet out the WAN interface of the CPE Router, the src-addr of the = packet used is the GUA before the packet heads out of the node because, = as we said in our draft, GUA has larger scope. So any multi-party host = on the Internet sees only the GUA. I will need a specific example to = show me how multi-party communications will break down with ULA and GUA = configured on an interface of any node in the home behind the CPE Router = or if ULA and GUA is configured on the LAN Interface of the CPE Router. Thanks. Hemant -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 11:48 AM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: > I have repeatedly said, I am not convinced the ULA gets appreciable=20 > complexity into the CPE Router. Our section 5.5.1 has clearly outlined = > any complexity and shown it's minimal. The ULA fixes a very common=20 > problem for the CPE Router which is configuring the router without any = > SP access - the problem is not a corner case. Hemant, 2 party communications in the presence of mixed ULA & GUA work ok, given = proper default address selection rules. Multi-party communications *with* address referral do not work in the = general case in such a mixed environment, regardless of default address = selection. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 10:26:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECEA3A67FD for ; Tue, 22 Jul 2008 10:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.059 X-Spam-Level: *** X-Spam-Status: No, score=3.059 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drLBmNBbEcfP for ; Tue, 22 Jul 2008 10:26:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 278AC3A6A36 for ; Tue, 22 Jul 2008 10:26:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLdG-000CHN-Qb for v6ops-data@psg.com; Tue, 22 Jul 2008 17:26:38 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLdC-000CCI-A6 for v6ops@ops.ietf.org; Tue, 22 Jul 2008 17:26:36 +0000 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8852977; Tue, 22 Jul 2008 13:26:05 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 13:26:05 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 17:25:05 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 13:25:05 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRY In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2008 17:26:05.0090 (UTC) FILETIME=[053AB020:01C8EC20] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, You missed the phrase "*with* address referral" in my response. Say A & B are inside their home and use ULA & GUA. C and D are within another home and are also using ULA & GUA. Now, A B C & D enter a 4 way communication where they initially exchange th= e addresses of their pier. If A passes C the ULA and GUA of B, C might prefer to use B's ULA because o= f address selection rules and C->B communication would fail or worse, go somewhere else. There are multiple variants of this. The point is that you cannot expect apps that passes addresses to be smart enough to know about ULA & GUA. BTw, using DNS does not help at all if you include both ULA & GUA AAAAs in your zone... - Alain. On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Sorry I don't understand. If any node in the home using an ULA sends a p= acket > out the WAN interface of the CPE Router, the src-addr of the packet used = is > the GUA before the packet heads out of the node because, as we said in ou= r > draft, GUA has larger scope. So any multi-party host on the Internet see= s > only the GUA. I will need a specific example to show me how multi-party > communications will break down with ULA and GUA configured on an interfac= e of > any node in the home behind the CPE Router or if ULA and GUA is configure= d on > the LAN Interface of the CPE Router. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 11:48 AM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi Denis-Courmont= ; > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review >=20 > On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: >=20 >> I have repeatedly said, I am not convinced the ULA gets appreciable >> complexity into the CPE Router. Our section 5.5.1 has clearly outlined >> any complexity and shown it's minimal. The ULA fixes a very common >> problem for the CPE Router which is configuring the router without any >> SP access - the problem is not a corner case. >=20 > Hemant, >=20 > 2 party communications in the presence of mixed ULA & GUA work ok, given > proper default address selection rules. >=20 > Multi-party communications *with* address referral do not work in the gen= eral > case in such a mixed environment, regardless of default address selection= . >=20 > - Alain. >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 10:45:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339E83A68F0 for ; Tue, 22 Jul 2008 10:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NsPW2Pj6o-D for ; Tue, 22 Jul 2008 10:45:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 404723A6A5E for ; Tue, 22 Jul 2008 10:45:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLus-000FyL-Qv for v6ops-data@psg.com; Tue, 22 Jul 2008 17:44:50 +0000 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLLuo-000FtZ-P7 for v6ops@ops.ietf.org; Tue, 22 Jul 2008 17:44:48 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6MHhuUG009250 for ; Tue, 22 Jul 2008 13:43:56 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6MHhuTA239552 for ; Tue, 22 Jul 2008 13:43:56 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6MHhuYG009889 for ; Tue, 22 Jul 2008 13:43:56 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MHhsas009814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 13:43:56 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6MHhrt4019274; Tue, 22 Jul 2008 13:43:53 -0400 Message-Id: <200807221743.m6MHhrt4019274@cichlid.raleigh.ibm.com> To: Iljitsch van Beijnum cc: David Conrad , ericlklein@softhome.net, IPv6 Operations Subject: Re: new draft on IPv6 CPE router available for review In-reply-to: <65A6E4E5-D3E4-4104-8F72-BCAC6354ACA3@muada.com> References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> <8DF03C59-15BE-4707-9607-6121A0706875@virtualized.org> <65A6E4E5-D3E4-4104-8F72-BCAC6354ACA3@muada.com> Comments: In-reply-to Iljitsch van Beijnum message dated "Sun, 20 Jul 2008 14:00:40 +0200." Date: Tue, 22 Jul 2008 13:43:53 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Iljitsch van Beijnum writes: > On 4 jul 2008, at 17:37, David Conrad wrote: > > Because renumbering IPv6 prefixes will not be transparent, there > > will be a market for NATv6. > This is such nonsense. I wish you would stop spewing it. FWIW, I agree with David. And I wish others would get their heads out of the sand. The reality is that NAT does have both benefits and drawbacks. Some may think the drawbacks dwarf all benefits, but anyone who has followed this discussion for more than 30 seconds has to see that reasonable people disagree on how to weigh the cost vs. benefits. Can't we just accept that and move on? Thomas From owner-v6ops@ops.ietf.org Tue Jul 22 12:53:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C4A3A6965 for ; Tue, 22 Jul 2008 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ3xhQuHtSmT for ; Tue, 22 Jul 2008 12:53:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C713D3A68CB for ; Tue, 22 Jul 2008 12:53:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNsl-000Fbq-4f for v6ops-data@psg.com; Tue, 22 Jul 2008 19:50:47 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNsd-000Fap-33 for v6ops@ops.ietf.org; Tue, 22 Jul 2008 19:50:41 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 669B2D0075; Tue, 22 Jul 2008 09:50:28 -1000 (HST) Date: Tue, 22 Jul 2008 09:50:28 -1000 (HST) From: Antonio Querubin To: =?ISO-8859-15?Q?R=E9mi_Denis-Courmont?= cc: Alain Durand , "Hemant Singh (shemant)" , Brian E Carpenter , v6ops@ops.ietf.org, "Wes Beebee (wbeebee)" Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: <200807221839.07850.rdenis@simphalempin.com> Message-ID: References: <200807221839.07850.rdenis@simphalempin.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1094719054-2102720840-1216756237=:3017" Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1094719054-2102720840-1216756237=:3017 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 22 Jul 2008, Rémi Denis-Courmont wrote: > Renumbering break applications. Maybe ISPs don't care less about the user LAN > working properly. But users and CPE vendors do care. *Ahem* ISPs do care. For the intended mass-market of this CPE router, the end-customer probably has no full-time IT expert. Guess who they call first when things break? The consultant who costs money? Nephew Tim who might have a real day job? Or the ISP support line? Antonio Querubin whois: AQ7-ARIN --1094719054-2102720840-1216756237=:3017-- From owner-v6ops@ops.ietf.org Tue Jul 22 14:04:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DD93A677D for ; Tue, 22 Jul 2008 14:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szHrPybIKGQe for ; Tue, 22 Jul 2008 14:04:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 938063A682A for ; Tue, 22 Jul 2008 14:04:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLOzh-0003V0-Dg for v6ops-data@psg.com; Tue, 22 Jul 2008 21:02:01 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLOzZ-0003Ue-GJ for v6ops@ops.ietf.org; Tue, 22 Jul 2008 21:01:55 +0000 X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="15082490" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2008 21:01:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6ML1h5d015757; Tue, 22 Jul 2008 17:01:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6ML1hfb001134; Tue, 22 Jul 2008 21:01:44 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:01:44 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 17:01:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdA= References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 21:01:44.0004 (UTC) FILETIME=[256C4840:01C8EC3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4498; t=1216760504; x=1217624504; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20; bh=DwXagFKCgjrFoEsr9lQqNr04GP9YqIwSQaa8oF1dW3s=; b=piNvPn83scpD5XIOeq8d+le8ZsrbiwzdpYLuL9fvu+EkG5S4T7f3pSFX0V 1F3kkHQE9xRMnIH0FBJq153FA9bU/vxLY4VdjoItfN3XQIZCMky1LGrtBRls XWPICDV4Pb; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain, Very sorry, I missed your "*with* address referral" phrase. Thanks for = providing the example. Here is the analysis: Yes, if C tries to communicate with B using B's ULA for destination, C = will also slap its ULA on the packet src address. Thereafter before the = CPE Router WAN interface egresses the packet, the router has to comply = to ULA forwarding rules. As per section 4.3 of RFC4193, the CPE Router = will drop the packet (unless the router is explicitly configured for a = route to destination ULA) and send an ICMPv6 Destination Unreachable to = C. Here is the text from the RFC. [Site border routers and firewalls should be configured to not forward any packets with Local IPv6 source or destination addresses outside of the site, unless they have been explicitly configured with routing information about specific /48 or longer Local IPv6 prefixes.] I don't expect the CPE Router to be supporting a site connected to = another ULA site so the question of any configuration on the CPE Router = for a neighbor ULA site is out of the question. Since C gets some error = indication, the app then needs to figure out fixes in its = implementation. Sorry, I don't see this as rustication to change the CPE Router = permanent ULA. Some brain-dead apps need fixing. I need more people to = speak up and give their opinion. I am still open to change. Thanks. Hemant -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 1:25 PM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Hemant, You missed the phrase "*with* address referral" in my response. Say A & B are inside their home and use ULA & GUA. C and D are within = another home and are also using ULA & GUA. Now, A B C & D enter a 4 way communication where they initially exchange = the addresses of their pier. If A passes C the ULA and GUA of B, C might prefer to use B's ULA = because of address selection rules and C->B communication would fail or = worse, go somewhere else. There are multiple variants of this. The point is that you cannot expect = apps that passes addresses to be smart enough to know about ULA & GUA. BTw, using DNS does not help at all if you include both ULA & GUA AAAAs = in your zone... - Alain. On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Sorry I don't understand. If any node in the home using an ULA sends=20 > a packet out the WAN interface of the CPE Router, the src-addr of the=20 > packet used is the GUA before the packet heads out of the node=20 > because, as we said in our draft, GUA has larger scope. So any=20 > multi-party host on the Internet sees only the GUA. I will need a=20 > specific example to show me how multi-party communications will break=20 > down with ULA and GUA configured on an interface of any node in the=20 > home behind the CPE Router or if ULA and GUA is configured on the LAN = Interface of the CPE Router. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 11:48 AM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 > Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 > On 7/21/08 12:43 PM, "Hemant Singh (shemant)" = wrote: >=20 >> I have repeatedly said, I am not convinced the ULA gets appreciable=20 >> complexity into the CPE Router. Our section 5.5.1 has clearly=20 >> outlined any complexity and shown it's minimal. The ULA fixes a very = >> common problem for the CPE Router which is configuring the router=20 >> without any SP access - the problem is not a corner case. >=20 > Hemant, >=20 > 2 party communications in the presence of mixed ULA & GUA work ok,=20 > given proper default address selection rules. >=20 > Multi-party communications *with* address referral do not work in the=20 > general case in such a mixed environment, regardless of default = address selection. >=20 > - Alain. >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 14:11:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9244D3A6970 for ; Tue, 22 Jul 2008 14:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.093 X-Spam-Level: *** X-Spam-Status: No, score=3.093 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVDMuhg8qIYa for ; Tue, 22 Jul 2008 14:11:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 509063A6955 for ; Tue, 22 Jul 2008 14:11:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLP96-0005B6-NA for v6ops-data@psg.com; Tue, 22 Jul 2008 21:11:44 +0000 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLP92-0005Ai-5A for v6ops@ops.ietf.org; Tue, 22 Jul 2008 21:11:42 +0000 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48455223; Tue, 22 Jul 2008 17:11:08 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 17:11:08 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 21:10:08 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 17:10:07 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2008 21:11:08.0505 (UTC) FILETIME=[75E44C90:01C8EC3F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant, Thank you for looking into this. The issue is that C's connection to B may have to wait for TCP timeout, which is 3 min. This is long. Too long. - Alain. On 7/22/08 5:01 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Very sorry, I missed your "*with* address referral" phrase. Thanks for > providing the example. Here is the analysis: >=20 > Yes, if C tries to communicate with B using B's ULA for destination, C wi= ll > also slap its ULA on the packet src address. Thereafter before the CPE R= outer > WAN interface egresses the packet, the router has to comply to ULA forwar= ding > rules. As per section 4.3 of RFC4193, the CPE Router will drop the packe= t > (unless the router is explicitly configured for a route to destination UL= A) > and send an ICMPv6 Destination Unreachable to C. Here is the text from th= e > RFC. >=20 > [Site border routers and firewalls should be configured to not forward > any packets with Local IPv6 source or destination addresses outside > of the site, unless they have been explicitly configured with routing > information about specific /48 or longer Local IPv6 prefixes.] >=20 > I don't expect the CPE Router to be supporting a site connected to anothe= r ULA > site so the question of any configuration on the CPE Router for a neighbo= r ULA > site is out of the question. Since C gets some error indication, the app= then > needs to figure out fixes in its implementation. >=20 > Sorry, I don't see this as rustication to change the CPE Router permanent= ULA. > Some brain-dead apps need fixing. I need more people to speak up and giv= e > their opinion. I am still open to change. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 1:25 PM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi Denis-Courmont= ; > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review >=20 > Hemant, >=20 > You missed the phrase "*with* address referral" in my response. >=20 > Say A & B are inside their home and use ULA & GUA. C and D are within ano= ther > home and are also using ULA & GUA. >=20 > Now, A B C & D enter a 4 way communication where they initially exchange = the > addresses of their pier. > If A passes C the ULA and GUA of B, C might prefer to use B's ULA because= of > address selection rules and C->B communication would fail or worse, go > somewhere else. >=20 > There are multiple variants of this. The point is that you cannot expect = apps > that passes addresses to be smart enough to know about ULA & GUA. >=20 > BTw, using DNS does not help at all if you include both ULA & GUA AAAAs i= n > your zone... >=20 > - Alain. >=20 >=20 > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: >=20 >> Alain, >>=20 >> Sorry I don't understand. If any node in the home using an ULA sends >> a packet out the WAN interface of the CPE Router, the src-addr of the >> packet used is the GUA before the packet heads out of the node >> because, as we said in our draft, GUA has larger scope. So any >> multi-party host on the Internet sees only the GUA. I will need a >> specific example to show me how multi-party communications will break >> down with ULA and GUA configured on an interface of any node in the >> home behind the CPE Router or if ULA and GUA is configured on the LAN >> Interface of the CPE Router. >>=20 >> Thanks. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >> Sent: Tuesday, July 22, 2008 11:48 AM >> To: Hemant Singh (shemant); Ralph Droms (rdroms) >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >> for review >>=20 >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: >>=20 >>> I have repeatedly said, I am not convinced the ULA gets appreciable >>> complexity into the CPE Router. Our section 5.5.1 has clearly >>> outlined any complexity and shown it's minimal. The ULA fixes a very >>> common problem for the CPE Router which is configuring the router >>> without any SP access - the problem is not a corner case. >>=20 >> Hemant, >>=20 >> 2 party communications in the presence of mixed ULA & GUA work ok, >> given proper default address selection rules. >>=20 >> Multi-party communications *with* address referral do not work in the >> general case in such a mixed environment, regardless of default address >> selection. >>=20 >> - Alain. >>=20 >>=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 14:36:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4743A6818 for ; Tue, 22 Jul 2008 14:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZlGGz6oeP6z for ; Tue, 22 Jul 2008 14:36:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8CA83A63EC for ; Tue, 22 Jul 2008 14:36:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPVo-0009QK-LQ for v6ops-data@psg.com; Tue, 22 Jul 2008 21:35:12 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPVj-0009Pv-MV for v6ops@ops.ietf.org; Tue, 22 Jul 2008 21:35:10 +0000 X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="15102514" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2008 21:35:03 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MLZ3i9007982; Tue, 22 Jul 2008 17:35:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MLZ3Ev011353; Tue, 22 Jul 2008 21:35:03 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:35:03 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 17:35:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/AAA2Pog References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 21:35:03.0430 (UTC) FILETIME=[CD2C7A60:01C8EC42] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5551; t=1216762503; x=1217626503; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20; bh=y8fIUYd3FmMlMRBEDpl+GA+q6ABjUeXRZvnVz1wRRrA=; b=woVpz+ubaRk2JWDTpJivAc5RmXePSXVe54p4H4JbqZK5J4t1Bv0aFrLbaZ FAp6KU0Fu6uOagZoO75SQc3gmzZzpKD6xphMer6Dv5XBFShFAfVQjLQ5HxHh b5BFYUm+eo; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sure thing. But I would expect that node C would receive the ICMPv6 = Destination Unreachable before TCP times out, wouldn't you? Hemant -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 5:10 PM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Hemant, Thank you for looking into this. The issue is that C's connection to B may have to wait for TCP timeout, = which is 3 min. This is long. Too long. - Alain. On 7/22/08 5:01 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Very sorry, I missed your "*with* address referral" phrase. Thanks=20 > for providing the example. Here is the analysis: >=20 > Yes, if C tries to communicate with B using B's ULA for destination, C = > will also slap its ULA on the packet src address. Thereafter before=20 > the CPE Router WAN interface egresses the packet, the router has to=20 > comply to ULA forwarding rules. As per section 4.3 of RFC4193, the=20 > CPE Router will drop the packet (unless the router is explicitly=20 > configured for a route to destination ULA) and send an ICMPv6=20 > Destination Unreachable to C. Here is the text from the RFC. >=20 > [Site border routers and firewalls should be configured to not forward = =20 > any packets with Local IPv6 source or destination addresses outside =20 > of the site, unless they have been explicitly configured with routing = > information about specific /48 or longer Local IPv6 prefixes.] >=20 > I don't expect the CPE Router to be supporting a site connected to=20 > another ULA site so the question of any configuration on the CPE=20 > Router for a neighbor ULA site is out of the question. Since C gets=20 > some error indication, the app then needs to figure out fixes in its = implementation. >=20 > Sorry, I don't see this as rustication to change the CPE Router = permanent ULA. > Some brain-dead apps need fixing. I need more people to speak up and=20 > give their opinion. I am still open to change. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 1:25 PM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 > Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 > Hemant, >=20 > You missed the phrase "*with* address referral" in my response. >=20 > Say A & B are inside their home and use ULA & GUA. C and D are within=20 > another home and are also using ULA & GUA. >=20 > Now, A B C & D enter a 4 way communication where they initially=20 > exchange the addresses of their pier. > If A passes C the ULA and GUA of B, C might prefer to use B's ULA=20 > because of address selection rules and C->B communication would fail=20 > or worse, go somewhere else. >=20 > There are multiple variants of this. The point is that you cannot=20 > expect apps that passes addresses to be smart enough to know about ULA = & GUA. >=20 > BTw, using DNS does not help at all if you include both ULA & GUA=20 > AAAAs in your zone... >=20 > - Alain. >=20 >=20 > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" = wrote: >=20 >> Alain, >>=20 >> Sorry I don't understand. If any node in the home using an ULA sends = >> a packet out the WAN interface of the CPE Router, the src-addr of the = >> packet used is the GUA before the packet heads out of the node=20 >> because, as we said in our draft, GUA has larger scope. So any=20 >> multi-party host on the Internet sees only the GUA. I will need a=20 >> specific example to show me how multi-party communications will break = >> down with ULA and GUA configured on an interface of any node in the=20 >> home behind the CPE Router or if ULA and GUA is configured on the LAN = >> Interface of the CPE Router. >>=20 >> Thanks. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >> Sent: Tuesday, July 22, 2008 11:48 AM >> To: Hemant Singh (shemant); Ralph Droms (rdroms) >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 >> for review >>=20 >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" = wrote: >>=20 >>> I have repeatedly said, I am not convinced the ULA gets appreciable=20 >>> complexity into the CPE Router. Our section 5.5.1 has clearly=20 >>> outlined any complexity and shown it's minimal. The ULA fixes a=20 >>> very common problem for the CPE Router which is configuring the=20 >>> router without any SP access - the problem is not a corner case. >>=20 >> Hemant, >>=20 >> 2 party communications in the presence of mixed ULA & GUA work ok,=20 >> given proper default address selection rules. >>=20 >> Multi-party communications *with* address referral do not work in the = >> general case in such a mixed environment, regardless of default=20 >> address selection. >>=20 >> - Alain. >>=20 >>=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 14:44:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6641E3A6A58 for ; Tue, 22 Jul 2008 14:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNf0NfdWWslH for ; Tue, 22 Jul 2008 14:44:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C81DE3A6A26 for ; Tue, 22 Jul 2008 14:44:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPex-000BKv-I0 for v6ops-data@psg.com; Tue, 22 Jul 2008 21:44:39 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPer-000BG2-Os for v6ops@ops.ietf.org; Tue, 22 Jul 2008 21:44:37 +0000 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8896838; Tue, 22 Jul 2008 17:44:00 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 17:44:00 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 21:43:36 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 17:43:35 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/AAA2PogAABSPZw= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2008 21:44:00.0467 (UTC) FILETIME=[0D45D230:01C8EC44] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This has not been my experience using multiple addresses. You may want to read some of my earlier work: http://www.ietf.org/rfc/rfc4943.txt?number=3D4943 http://www.watersprings.org/pub/id/draft-roy-v6ops-v6onbydefault-01.txt - Alain. On 7/22/08 5:35 PM, "Hemant Singh (shemant)" wrote: > Sure thing. But I would expect that node C would receive the ICMPv6 > Destination Unreachable before TCP times out, wouldn't you? >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 5:10 PM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi Denis-Courmont= ; > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review >=20 > Hemant, >=20 > Thank you for looking into this. > The issue is that C's connection to B may have to wait for TCP timeout, w= hich > is 3 min. This is long. Too long. >=20 > - Alain. >=20 >=20 > On 7/22/08 5:01 PM, "Hemant Singh (shemant)" wrote: >=20 >> Alain, >>=20 >> Very sorry, I missed your "*with* address referral" phrase. Thanks >> for providing the example. Here is the analysis: >>=20 >> Yes, if C tries to communicate with B using B's ULA for destination, C >> will also slap its ULA on the packet src address. Thereafter before >> the CPE Router WAN interface egresses the packet, the router has to >> comply to ULA forwarding rules. As per section 4.3 of RFC4193, the >> CPE Router will drop the packet (unless the router is explicitly >> configured for a route to destination ULA) and send an ICMPv6 >> Destination Unreachable to C. Here is the text from the RFC. >>=20 >> [Site border routers and firewalls should be configured to not forward >> any packets with Local IPv6 source or destination addresses outside >> of the site, unless they have been explicitly configured with routing >> information about specific /48 or longer Local IPv6 prefixes.] >>=20 >> I don't expect the CPE Router to be supporting a site connected to >> another ULA site so the question of any configuration on the CPE >> Router for a neighbor ULA site is out of the question. Since C gets >> some error indication, the app then needs to figure out fixes in its >> implementation. >>=20 >> Sorry, I don't see this as rustication to change the CPE Router permanen= t >> ULA. >> Some brain-dead apps need fixing. I need more people to speak up and >> give their opinion. I am still open to change. >>=20 >> Thanks. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >> Sent: Tuesday, July 22, 2008 1:25 PM >> To: Hemant Singh (shemant); Ralph Droms (rdroms) >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >> for review >>=20 >> Hemant, >>=20 >> You missed the phrase "*with* address referral" in my response. >>=20 >> Say A & B are inside their home and use ULA & GUA. C and D are within >> another home and are also using ULA & GUA. >>=20 >> Now, A B C & D enter a 4 way communication where they initially >> exchange the addresses of their pier. >> If A passes C the ULA and GUA of B, C might prefer to use B's ULA >> because of address selection rules and C->B communication would fail >> or worse, go somewhere else. >>=20 >> There are multiple variants of this. The point is that you cannot >> expect apps that passes addresses to be smart enough to know about ULA &= GUA. >>=20 >> BTw, using DNS does not help at all if you include both ULA & GUA >> AAAAs in your zone... >>=20 >> - Alain. >>=20 >>=20 >> On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: >>=20 >>> Alain, >>>=20 >>> Sorry I don't understand. If any node in the home using an ULA sends >>> a packet out the WAN interface of the CPE Router, the src-addr of the >>> packet used is the GUA before the packet heads out of the node >>> because, as we said in our draft, GUA has larger scope. So any >>> multi-party host on the Internet sees only the GUA. I will need a >>> specific example to show me how multi-party communications will break >>> down with ULA and GUA configured on an interface of any node in the >>> home behind the CPE Router or if ULA and GUA is configured on the LAN >>> Interface of the CPE Router. >>>=20 >>> Thanks. >>>=20 >>> Hemant >>>=20 >>> -----Original Message----- >>> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >>> Sent: Tuesday, July 22, 2008 11:48 AM >>> To: Hemant Singh (shemant); Ralph Droms (rdroms) >>> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi >>> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >>> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >>> for review >>>=20 >>> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote= : >>>=20 >>>> I have repeatedly said, I am not convinced the ULA gets appreciable >>>> complexity into the CPE Router. Our section 5.5.1 has clearly >>>> outlined any complexity and shown it's minimal. The ULA fixes a >>>> very common problem for the CPE Router which is configuring the >>>> router without any SP access - the problem is not a corner case. >>>=20 >>> Hemant, >>>=20 >>> 2 party communications in the presence of mixed ULA & GUA work ok, >>> given proper default address selection rules. >>>=20 >>> Multi-party communications *with* address referral do not work in the >>> general case in such a mixed environment, regardless of default >>> address selection. >>>=20 >>> - Alain. >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 15:02:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F63A6891 for ; Tue, 22 Jul 2008 15:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.679 X-Spam-Level: X-Spam-Status: No, score=-4.679 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY+g7RpxIPhe for ; Tue, 22 Jul 2008 15:02:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 834DF3A676A for ; Tue, 22 Jul 2008 15:02:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPun-000EOr-W8 for v6ops-data@psg.com; Tue, 22 Jul 2008 22:01:01 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPuf-000EN8-UK for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:01:00 +0000 X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="15088255" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2008 22:00:43 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MM0hXl017719; Tue, 22 Jul 2008 18:00:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MM0hHP001213; Tue, 22 Jul 2008 22:00:43 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:00:42 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 18:00:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/AAA2PogAABSPZwAACaOgA== References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 22:00:42.0861 (UTC) FILETIME=[62BF01D0:01C8EC46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1110; t=1216764043; x=1217628043; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20; bh=sHZIiQ4ycPcTZZH2qUZxlzFgBzDkRr5Nuqsvy681g5w=; b=zgeC4GaE9IhUnbaV1PN2kxC7jINWziq9LbbDc3dA+63CxHhKRiQ+AVtQzl NSZBlr8C95HAb+j7y2iXxx5mf4cKq/Ry8RBkQXd9nHRii2Qyh7Aca+BYwWC/ w4wyiqRY/e; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I see. Thanks for sharing the experience. But the TCP issue mentioned = in section 3.2 of RFC4943 says the host is in a router-less network. = Host C in the example you gave sits in a routed network because host C = is behind the CPE Router. Does that make any difference? =20 Anyhow, for your example since C and B sit in different home, their ULA = and GUA prefixes are off-link to each other, so why would host C issue = an address resolution? Hemant=20 -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 5:44 PM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review This has not been my experience using multiple addresses. You may want = to read some of my earlier work: http://www.ietf.org/rfc/rfc4943.txt?number=3D4943 http://www.watersprings.org/pub/id/draft-roy-v6ops-v6onbydefault-01.txt - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 15:06:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EBE3A688F for ; Tue, 22 Jul 2008 15:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.699 X-Spam-Level: X-Spam-Status: No, score=-104.699 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqCqOI+D88L8 for ; Tue, 22 Jul 2008 15:06:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 485FA3A676A for ; Tue, 22 Jul 2008 15:06:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPzM-000FC8-JH for v6ops-data@psg.com; Tue, 22 Jul 2008 22:05:44 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLPzI-000FBe-FJ for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:05:42 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1216764337!37268158!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 29993 invoked from network); 22 Jul 2008 22:05:38 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 22 Jul 2008 22:05:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6MM5ajg010314; Tue, 22 Jul 2008 18:05:37 -0400 Received: from 01GAF5142010621.AD.BLS.COM ([139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6MM5UCY009940; Tue, 22 Jul 2008 18:05:31 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jul 2008 18:05:30 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jul 2008 18:05:30 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 18:05:29 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA09DDF45B@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review thread-index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAtoCwA== References: From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Alain Durand" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 22:05:30.0480 (UTC) FILETIME=[0E2E2F00:01C8EC47] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Please don't change the ULA requirement. I believe ULA is needed. And I = agree that apps need to be intelligent about the scope of the addresses = they are using. I do not want to see the ULA go away. It needs to be = persistent and always there, from my perspective. Barbara=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Hemant Singh (shemant) Sent: Tuesday, July 22, 2008 5:02 PM To: Alain Durand; Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: New (-02) version of IPv6 CPE Router draft is available for = review Alain, Very sorry, I missed your "*with* address referral" phrase. Thanks for = providing the example. Here is the analysis: Yes, if C tries to communicate with B using B's ULA for destination, C = will also slap its ULA on the packet src address. Thereafter before the = CPE Router WAN interface egresses the packet, the router has to comply = to ULA forwarding rules. As per section 4.3 of RFC4193, the CPE Router = will drop the packet (unless the router is explicitly configured for a = route to destination ULA) and send an ICMPv6 Destination Unreachable to = C. Here is the text from the RFC. [Site border routers and firewalls should be configured to not forward any packets with Local IPv6 source or destination addresses outside of the site, unless they have been explicitly configured with routing information about specific /48 or longer Local IPv6 prefixes.] I don't expect the CPE Router to be supporting a site connected to = another ULA site so the question of any configuration on the CPE Router = for a neighbor ULA site is out of the question. Since C gets some error = indication, the app then needs to figure out fixes in its = implementation. Sorry, I don't see this as rustication to change the CPE Router = permanent ULA. Some brain-dead apps need fixing. I need more people to = speak up and give their opinion. I am still open to change. Thanks. Hemant -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 1:25 PM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review Hemant, You missed the phrase "*with* address referral" in my response. Say A & B are inside their home and use ULA & GUA. C and D are within = another home and are also using ULA & GUA. Now, A B C & D enter a 4 way communication where they initially exchange = the addresses of their pier. If A passes C the ULA and GUA of B, C might prefer to use B's ULA = because of address selection rules and C->B communication would fail or = worse, go somewhere else. There are multiple variants of this. The point is that you cannot expect = apps that passes addresses to be smart enough to know about ULA & GUA. BTw, using DNS does not help at all if you include both ULA & GUA AAAAs = in your zone... - Alain. On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: > Alain, >=20 > Sorry I don't understand. If any node in the home using an ULA sends=20 > a packet out the WAN interface of the CPE Router, the src-addr of the=20 > packet used is the GUA before the packet heads out of the node=20 > because, as we said in our draft, GUA has larger scope. So any=20 > multi-party host on the Internet sees only the GUA. I will need a=20 > specific example to show me how multi-party communications will break=20 > down with ULA and GUA configured on an interface of any node in the=20 > home behind the CPE Router or if ULA and GUA is configured on the LAN = Interface of the CPE Router. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 11:48 AM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 > Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 > On 7/21/08 12:43 PM, "Hemant Singh (shemant)" = wrote: >=20 >> I have repeatedly said, I am not convinced the ULA gets appreciable=20 >> complexity into the CPE Router. Our section 5.5.1 has clearly=20 >> outlined any complexity and shown it's minimal. The ULA fixes a very = >> common problem for the CPE Router which is configuring the router=20 >> without any SP access - the problem is not a corner case. >=20 > Hemant, >=20 > 2 party communications in the presence of mixed ULA & GUA work ok,=20 > given proper default address selection rules. >=20 > Multi-party communications *with* address referral do not work in the=20 > general case in such a mixed environment, regardless of default = address selection. >=20 > - Alain. >=20 >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 From owner-v6ops@ops.ietf.org Tue Jul 22 15:09:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541C23A688F for ; Tue, 22 Jul 2008 15:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.453 X-Spam-Level: ** X-Spam-Status: No, score=2.453 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpdZ37r3lU1h for ; Tue, 22 Jul 2008 15:09:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 69A793A68AD for ; Tue, 22 Jul 2008 15:09:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ2i-000FpL-RH for v6ops-data@psg.com; Tue, 22 Jul 2008 22:09:12 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ2f-000Fok-8Q for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:09:11 +0000 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8899346; Tue, 22 Jul 2008 18:08:30 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 18:08:30 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 22:08:10 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 18:08:09 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: "Hemant Singh (shemant)" , "Ralph Droms (rdroms)" CC: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , , "Wes Beebee (wbeebee)" Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/AAA2PogAABSPZwAACaOgAAAtRce In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 22:08:30.0154 (UTC) FILETIME=[794642A0:01C8EC47] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/22/08 6:00 PM, "Hemant Singh (shemant)" wrote: > I see. Thanks for sharing the experience. But the TCP issue mentioned in > section 3.2 of RFC4943 says the host is in a router-less network. Host C in > the example you gave sits in a routed network because host C is behind the CPE > Router. Does that make any difference? > > Anyhow, for your example since C and B sit in different home, their ULA and > GUA prefixes are off-link to each other, so why would host C issue an address > resolution? The on-link/off-link is just an example to illustrate the larger problem that trying multiple addresses that will fail first can introduce long delays. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 15:16:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E2C3A676A for ; Tue, 22 Jul 2008 15:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.146 X-Spam-Level: *** X-Spam-Status: No, score=3.146 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTGvrzFPskG2 for ; Tue, 22 Jul 2008 15:16:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC0B13A688F for ; Tue, 22 Jul 2008 15:16:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ9S-000HZn-Ft for v6ops-data@psg.com; Tue, 22 Jul 2008 22:16:10 +0000 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ9O-000HZF-Cb for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:16:08 +0000 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48458365; Tue, 22 Jul 2008 18:15:39 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 18:15:38 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 22:15:05 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 18:15:04 -0400 Subject: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) From: Alain Durand To: Message-ID: Thread-Topic: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAtoCwAAAdmVZ In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA09DDF45B@crexc41p> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2008 22:15:38.0808 (UTC) FILETIME=[78C5AB80:01C8EC48] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: [Changing the title of this long thread to focus the discussion and trimmin= g the distribution list] We have a trade-off here to make between network stability and application complexity: either modify apps to deal with renumbering (ie try reconnecting, avoid well know literal addresses, use some kind of service location,...) or to teach application when it is ok to use ULA vs GUA, especially in referrals. My take is that the former is simpler and lead to less service calls. The later introduce the notion that apps have to be aware of the topology, whic= h I found disturbing. - Alain. On 7/22/08 6:05 PM, "Stark, Barbara" wrote: > Please don't change the ULA requirement. I believe ULA is needed. And I a= gree > that apps need to be intelligent about the scope of the addresses they ar= e > using. I do not want to see the ULA go away. It needs to be persistent an= d > always there, from my perspective. > Barbara >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behal= f Of > Hemant Singh (shemant) > Sent: Tuesday, July 22, 2008 5:02 PM > To: Alain Durand; Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi Denis-Courmont= ; > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: RE: New (-02) version of IPv6 CPE Router draft is available for > review >=20 > Alain, >=20 > Very sorry, I missed your "*with* address referral" phrase. Thanks for > providing the example. Here is the analysis: >=20 > Yes, if C tries to communicate with B using B's ULA for destination, C wi= ll > also slap its ULA on the packet src address. Thereafter before the CPE R= outer > WAN interface egresses the packet, the router has to comply to ULA forwar= ding > rules. As per section 4.3 of RFC4193, the CPE Router will drop the packe= t > (unless the router is explicitly configured for a route to destination UL= A) > and send an ICMPv6 Destination Unreachable to C. Here is the text from th= e > RFC. >=20 > [Site border routers and firewalls should be configured to not forward > any packets with Local IPv6 source or destination addresses outside > of the site, unless they have been explicitly configured with routing > information about specific /48 or longer Local IPv6 prefixes.] >=20 > I don't expect the CPE Router to be supporting a site connected to anothe= r ULA > site so the question of any configuration on the CPE Router for a neighbo= r ULA > site is out of the question. Since C gets some error indication, the app= then > needs to figure out fixes in its implementation. >=20 > Sorry, I don't see this as rustication to change the CPE Router permanent= ULA. > Some brain-dead apps need fixing. I need more people to speak up and giv= e > their opinion. I am still open to change. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 1:25 PM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi Denis-Courmont= ; > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review >=20 > Hemant, >=20 > You missed the phrase "*with* address referral" in my response. >=20 > Say A & B are inside their home and use ULA & GUA. C and D are within ano= ther > home and are also using ULA & GUA. >=20 > Now, A B C & D enter a 4 way communication where they initially exchange = the > addresses of their pier. > If A passes C the ULA and GUA of B, C might prefer to use B's ULA because= of > address selection rules and C->B communication would fail or worse, go > somewhere else. >=20 > There are multiple variants of this. The point is that you cannot expect = apps > that passes addresses to be smart enough to know about ULA & GUA. >=20 > BTw, using DNS does not help at all if you include both ULA & GUA AAAAs i= n > your zone... >=20 > - Alain. >=20 >=20 > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: >=20 >> Alain, >>=20 >> Sorry I don't understand. If any node in the home using an ULA sends >> a packet out the WAN interface of the CPE Router, the src-addr of the >> packet used is the GUA before the packet heads out of the node >> because, as we said in our draft, GUA has larger scope. So any >> multi-party host on the Internet sees only the GUA. I will need a >> specific example to show me how multi-party communications will break >> down with ULA and GUA configured on an interface of any node in the >> home behind the CPE Router or if ULA and GUA is configured on the LAN >> Interface of the CPE Router. >>=20 >> Thanks. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >> Sent: Tuesday, July 22, 2008 11:48 AM >> To: Hemant Singh (shemant); Ralph Droms (rdroms) >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available >> for review >>=20 >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: >>=20 >>> I have repeatedly said, I am not convinced the ULA gets appreciable >>> complexity into the CPE Router. Our section 5.5.1 has clearly >>> outlined any complexity and shown it's minimal. The ULA fixes a very >>> common problem for the CPE Router which is configuring the router >>> without any SP access - the problem is not a corner case. >>=20 >> Hemant, >>=20 >> 2 party communications in the presence of mixed ULA & GUA work ok, >> given proper default address selection rules. >>=20 >> Multi-party communications *with* address referral do not work in the >> general case in such a mixed environment, regardless of default address >> selection. >>=20 >> - Alain. >>=20 >>=20 >=20 >=20 >=20 >=20 > ***** >=20 > The information transmitted is intended only for the person or entity to = which > it is addressed and may contain confidential, proprietary, and/or privile= ged > material. Any review, retransmission, dissemination or other use of, or t= aking > of any action in reliance upon this information by persons or entities ot= her > than the intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from all computers. GA6= 21 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 15:33:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FBF3A680C for ; Tue, 22 Jul 2008 15:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsukqvi9Llvz for ; Tue, 22 Jul 2008 15:33:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5464B3A676A for ; Tue, 22 Jul 2008 15:33:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQQP-000L3v-QO for v6ops-data@psg.com; Tue, 22 Jul 2008 22:33:41 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQQL-000L3M-IT for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:33:39 +0000 X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="15091228" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2008 22:33:36 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MMXaVA024891; Tue, 22 Jul 2008 18:33:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MMXaHa010200; Tue, 22 Jul 2008 22:33:36 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:33:36 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) Date: Tue, 22 Jul 2008 18:33:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAtoCwAAAdmVZAACXepA= References: <7582BC68E4994F4ABF0BD4723975C3FA09DDF45B@crexc41p> From: "Hemant Singh (shemant)" To: "Alain Durand" , X-OriginalArrivalTime: 22 Jul 2008 22:33:36.0552 (UTC) FILETIME=[FB285A80:01C8EC4A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7343; t=1216766016; x=1217630016; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Permanent=20ULA=20support=20in=20home=2 0networking=20(Re=3A=20New=20(-02)=20version=20of=20IPv6=20C PE=20Router=20draft=20is=20available=20for=20review) |Sender:=20 |To:=20=22Alain=20Durand=22=20,=20; bh=kVG3H1ykI4LzN4tXiYkCo3cnb0eM1g6Wr/PWmnakwiM=; b=ITkJZ1FLDpCKpyxA85gAWzrgkfHpYdETc6UFYplfNWuueRQqDDy+MBxj71 jGTDa7i7wjIY8lXLRHIt93PFf3sCRFbWOujC1rO5KZ1fwoKyBNkDUZQXic12 U/g8JdvfkE; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I don't believe apps have to know topology if apps receive a GUA and a = ULA. The app has to just ignore the ULA. I will continue to discuss this lot with my internal Cisco colleagues = and see what we can do. Anyone else on the mailer is welcome to chime = in. Hemant=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Alain Durand Sent: Tuesday, July 22, 2008 6:15 PM To: v6ops@ops.ietf.org Subject: Permanent ULA support in home networking (Re: New (-02) version = of IPv6 CPE Router draft is available for review) [Changing the title of this long thread to focus the discussion and = trimming the distribution list] We have a trade-off here to make between network stability and = application complexity: either modify apps to deal with renumbering (ie try = reconnecting, avoid well know literal addresses, use some kind of = service location,...) or to teach application when it is ok to use ULA vs GUA, = especially in referrals. My take is that the former is simpler and lead to less service calls. = The later introduce the notion that apps have to be aware of the = topology, which I found disturbing. - Alain. On 7/22/08 6:05 PM, "Stark, Barbara" wrote: > Please don't change the ULA requirement. I believe ULA is needed. And=20 > I agree that apps need to be intelligent about the scope of the=20 > addresses they are using. I do not want to see the ULA go away. It=20 > needs to be persistent and always there, from my perspective. > Barbara >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Hemant Singh (shemant) > Sent: Tuesday, July 22, 2008 5:02 PM > To: Alain Durand; Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 > Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: RE: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 > Alain, >=20 > Very sorry, I missed your "*with* address referral" phrase. Thanks=20 > for providing the example. Here is the analysis: >=20 > Yes, if C tries to communicate with B using B's ULA for destination, C = > will also slap its ULA on the packet src address. Thereafter before=20 > the CPE Router WAN interface egresses the packet, the router has to=20 > comply to ULA forwarding rules. As per section 4.3 of RFC4193, the=20 > CPE Router will drop the packet (unless the router is explicitly=20 > configured for a route to destination ULA) and send an ICMPv6=20 > Destination Unreachable to C. Here is the text from the RFC. >=20 > [Site border routers and firewalls should be configured to not forward = =20 > any packets with Local IPv6 source or destination addresses outside =20 > of the site, unless they have been explicitly configured with routing = > information about specific /48 or longer Local IPv6 prefixes.] >=20 > I don't expect the CPE Router to be supporting a site connected to=20 > another ULA site so the question of any configuration on the CPE=20 > Router for a neighbor ULA site is out of the question. Since C gets=20 > some error indication, the app then needs to figure out fixes in its = implementation. >=20 > Sorry, I don't see this as rustication to change the CPE Router = permanent ULA. > Some brain-dead apps need fixing. I need more people to speak up and=20 > give their opinion. I am still open to change. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > Sent: Tuesday, July 22, 2008 1:25 PM > To: Hemant Singh (shemant); Ralph Droms (rdroms) > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 > Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 > for review >=20 > Hemant, >=20 > You missed the phrase "*with* address referral" in my response. >=20 > Say A & B are inside their home and use ULA & GUA. C and D are within=20 > another home and are also using ULA & GUA. >=20 > Now, A B C & D enter a 4 way communication where they initially=20 > exchange the addresses of their pier. > If A passes C the ULA and GUA of B, C might prefer to use B's ULA=20 > because of address selection rules and C->B communication would fail=20 > or worse, go somewhere else. >=20 > There are multiple variants of this. The point is that you cannot=20 > expect apps that passes addresses to be smart enough to know about ULA = & GUA. >=20 > BTw, using DNS does not help at all if you include both ULA & GUA=20 > AAAAs in your zone... >=20 > - Alain. >=20 >=20 > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" = wrote: >=20 >> Alain, >>=20 >> Sorry I don't understand. If any node in the home using an ULA sends = >> a packet out the WAN interface of the CPE Router, the src-addr of the = >> packet used is the GUA before the packet heads out of the node=20 >> because, as we said in our draft, GUA has larger scope. So any=20 >> multi-party host on the Internet sees only the GUA. I will need a=20 >> specific example to show me how multi-party communications will break = >> down with ULA and GUA configured on an interface of any node in the=20 >> home behind the CPE Router or if ULA and GUA is configured on the LAN = >> Interface of the CPE Router. >>=20 >> Thanks. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] >> Sent: Tuesday, July 22, 2008 11:48 AM >> To: Hemant Singh (shemant); Ralph Droms (rdroms) >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi=20 >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available=20 >> for review >>=20 >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" = wrote: >>=20 >>> I have repeatedly said, I am not convinced the ULA gets appreciable=20 >>> complexity into the CPE Router. Our section 5.5.1 has clearly=20 >>> outlined any complexity and shown it's minimal. The ULA fixes a=20 >>> very common problem for the CPE Router which is configuring the=20 >>> router without any SP access - the problem is not a corner case. >>=20 >> Hemant, >>=20 >> 2 party communications in the presence of mixed ULA & GUA work ok,=20 >> given proper default address selection rules. >>=20 >> Multi-party communications *with* address referral do not work in the = >> general case in such a mixed environment, regardless of default=20 >> address selection. >>=20 >> - Alain. >>=20 >>=20 >=20 >=20 >=20 >=20 > ***** >=20 > The information transmitted is intended only for the person or entity=20 > to which it is addressed and may contain confidential, proprietary,=20 > and/or privileged material. Any review, retransmission, dissemination=20 > or other use of, or taking of any action in reliance upon this=20 > information by persons or entities other than the intended recipient=20 > is prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. GA621 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jul 22 15:34:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADBB3A680C for ; Tue, 22 Jul 2008 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyeyLhVcok09 for ; Tue, 22 Jul 2008 15:34:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C9A83A676A for ; Tue, 22 Jul 2008 15:34:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQQC-000L2t-CF for v6ops-data@psg.com; Tue, 22 Jul 2008 22:33:28 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQQ8-000L2T-Kw for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:33:26 +0000 X-IronPort-AV: E=Sophos;i="4.31,233,1215388800"; d="scan'208";a="15107248" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2008 22:31:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MMVAcD023464; Tue, 22 Jul 2008 18:31:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MMVA7d009485; Tue, 22 Jul 2008 22:31:10 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:31:10 -0400 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 22 Jul 2008 18:31:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAQu0/AAA2PogAABSPZwAACaOgAAAtRceAACtj1A= References: From: "Hemant Singh (shemant)" To: "Alain Durand" , "Ralph Droms (rdroms)" Cc: "Mark Townsley (townsley)" , "Jimmy Chuang (cchuang)" , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 22 Jul 2008 22:31:10.0610 (UTC) FILETIME=[A42B5F20:01C8EC4A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1463; t=1216765870; x=1217629870; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20=22Ralph=20Droms=20(rdroms)=2 2=20; bh=7qnJVnxEs75uSClGdANjkdA3xK8ONh8DeHElys0ZGPM=; b=r6RJAN5ib7wyXAG2+csYH3j+N4b5u95HLRieyh2KRtFDUnrIefJl8Z90xH fT/JKXjMPn2dTfNe0Zy2oasb8dVp8oxjHPzvlWp2sq2c2hN1pC6w3Lc1LOCn 0Jrvvl91p/; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Alain Durand [mailto:alain_durand@cable.comcast.com]=20 Sent: Tuesday, July 22, 2008 6:08 PM To: Hemant Singh (shemant); Ralph Droms (rdroms) Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); R=E9mi = Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for = review On 7/22/08 6:00 PM, "Hemant Singh (shemant)" wrote: > I see. Thanks for sharing the experience. But the TCP issue=20 > mentioned in section 3.2 of RFC4943 says the host is in a router-less=20 > network. Host C in the example you gave sits in a routed network=20 > because host C is behind the CPE Router. Does that make any = difference? >=20 > Anyhow, for your example since C and B sit in different home, their=20 > ULA and GUA prefixes are off-link to each other, so why would host C=20 > issue an address resolution? >> The on-link/off-link is just an example to illustrate the larger = problem that trying multiple addresses that will fail first can = introduce long delays. >> - Alain. Ah, OK, I understand you and also since I read the last para of section = 3.2 of your draft. To nip this problem in the bud, as I said before, = let the host app fix its bug to first not send ULA in "address info" to = another host and also if any host app receives a ULA and GUA, the app = should ignore the ULA. Hemant From owner-v6ops@ops.ietf.org Tue Jul 22 15:53:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95F33A6A82 for ; Tue, 22 Jul 2008 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEZ8dQmDYJ8T for ; Tue, 22 Jul 2008 15:53:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAFB43A6820 for ; Tue, 22 Jul 2008 15:53:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQi6-000Ocm-8q for v6ops-data@psg.com; Tue, 22 Jul 2008 22:51:58 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQi2-000OcG-Oa for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:51:56 +0000 Received: from e34.co.us.ibm.com ([32.97.110.152]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLNOwN025476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jul 2008 17:23:25 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6MLKE76030403 for ; Tue, 22 Jul 2008 17:20:14 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6MLKEjW134348 for ; Tue, 22 Jul 2008 15:20:14 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6MLKEAV021802 for ; Tue, 22 Jul 2008 15:20:14 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLKCTl021721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Jul 2008 15:20:13 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6MLKAnL010018 for ; Tue, 22 Jul 2008 17:20:11 -0400 Message-Id: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: v6ops-nat64-pb-statement-req: DNSSEC requirement Date: Tue, 22 Jul 2008 17:20:10 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > R10: DNSSec support > > DNSSec support MUST NOT be prevented. > o R10.1: In particular, if an IPv6 node is initiating a > communication with an IPv4 that is located behind a translator, > the IPv6 initiator MUST be able to perform DNSSec verification of > the DNS information of the IPv4 target. (strong consensus on this > one). > o R10.2: In particular, if an IPv4 node is initiating a > communication with an IPv6 that is located behind a translator, > the IPv4 initiator MUST be able to perform DNSSec verification of > the DNS information of the IPv4 target. This may require the > modification of the IPv4 node as well. (not clear if there > consensus on this one) Maybe I don't understand what the above means, but it seems to me to be unworkable. I.e., If an IPv6 node requests an AAAA record for an IPv4-only node, there won't be a AAAA record and it will need to be synthesized. By definition, such a synthesized DNS RR won't be verifiable via DNSSEC because it is in fact an unauthorized fabrication. What am I missing here? Thomas From owner-v6ops@ops.ietf.org Tue Jul 22 15:56:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25F93A69BA for ; Tue, 22 Jul 2008 15:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.473 X-Spam-Level: ** X-Spam-Status: No, score=2.473 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB+m26p-iz+O for ; Tue, 22 Jul 2008 15:56:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D58743A6862 for ; Tue, 22 Jul 2008 15:56:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQlx-000POs-Aj for v6ops-data@psg.com; Tue, 22 Jul 2008 22:55:57 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQlt-000POY-5B for v6ops@ops.ietf.org; Tue, 22 Jul 2008 22:55:55 +0000 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8902091; Tue, 22 Jul 2008 18:39:08 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 18:39:07 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Jul 2008 22:38:34 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 22 Jul 2008 18:38:33 -0400 Subject: Re: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) From: Alain Durand To: "Hemant Singh (shemant)" , Message-ID: Thread-Topic: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) Thread-Index: AcjrThuKJCUmqqzKRF6hiUoRl3nIpwAAcICAADCenbEAAr/2cAAAomRYAAbQQdAAAtoCwAAAdmVZAACXepAAADp7pQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2008 22:39:07.0631 (UTC) FILETIME=[C07EFFF0:01C8EC4B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/22/08 6:33 PM, "Hemant Singh (shemant)" wrote: > I don't believe apps have to know topology if apps receive a GUA and a ULA. > The app has to just ignore the ULA. Exactly my point. Apps need to be made aware of the difference between ULA & GUA, which is what the ULA proponents have been saying all along will not be necessary. - Alain. From owner-v6ops@ops.ietf.org Tue Jul 22 16:24:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A9F28C106 for ; Tue, 22 Jul 2008 16:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo2VrSaIzz1P for ; Tue, 22 Jul 2008 16:24:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E4BE3A6955 for ; Tue, 22 Jul 2008 16:24:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRBs-0004oO-Ne for v6ops-data@psg.com; Tue, 22 Jul 2008 23:22:44 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRBp-0004o4-1A for v6ops@ops.ietf.org; Tue, 22 Jul 2008 23:22:43 +0000 Received: from e1.ny.us.ibm.com ([192.168.1.101]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLVqIi031684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jul 2008 17:31:52 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6MLShPK019239 for ; Tue, 22 Jul 2008 17:28:43 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6MLShnh198364 for ; Tue, 22 Jul 2008 17:28:43 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6MLSgZc022466 for ; Tue, 22 Jul 2008 17:28:42 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLSfGe022407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Jul 2008 17:28:42 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6MLSe3F010065 for ; Tue, 22 Jul 2008 17:28:40 -0400 Message-Id: <200807222128.m6MLSe3F010065@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: v6ops-nat64-pb-statement-req: MIPv6 RO requirement Date: Tue, 22 Jul 2008 17:28:40 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > I5: MIPv6 support > > The translation mechanism SHOULD not prevent MIPv6 Route Optimization > when the CN is a v4-only node What exactly is meant by this? Is the intention that a MIPv6 MN should be able to use RO with an IPv4-only CN? To invoke MIPv6 RO, the CN must actively participate in the signalling. Presumably, an IPv4-only node doesn't implement MIPv6 at all. What exactly is this requirement intended to achieve? Thomas From owner-v6ops@ops.ietf.org Tue Jul 22 17:05:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D3D28C164 for ; Tue, 22 Jul 2008 17:05:23 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-DUrn4ZuT1p for ; Tue, 22 Jul 2008 17:05:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4A6528C160 for ; Tue, 22 Jul 2008 17:05:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRor-000D28-Gt for v6ops-data@psg.com; Wed, 23 Jul 2008 00:03:01 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRok-000Cbm-GN for v6ops@ops.ietf.org; Wed, 23 Jul 2008 00:02:58 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6N01NFT021992; Wed, 23 Jul 2008 00:01:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6N01NoH021991; Wed, 23 Jul 2008 00:01:23 GMT Date: Wed, 23 Jul 2008 00:01:22 +0000 From: bmanning@vacation.karoshi.com To: Alain Durand Cc: v6ops@ops.ietf.org, arin-ppml@arin.net Subject: Re: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) Message-ID: <20080723000122.GA21946@vacation.karoshi.com.> References: <7582BC68E4994F4ABF0BD4723975C3FA09DDF45B@crexc41p> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: you know, this outcome (ULA == GUA) was predicted from the begining of the ULA emergence. and the many assurances that *never* would ULA's *ever* become GUAs are hollow. --bill On Tue, Jul 22, 2008 at 06:15:04PM -0400, Alain Durand wrote: > [Changing the title of this long thread to focus the discussion and trimming > the distribution list] > > We have a trade-off here to make between network stability and application > complexity: either modify apps to deal with renumbering (ie try > reconnecting, avoid well know literal addresses, use some kind of service > location,...) or to teach application when it is ok to use ULA vs GUA, > especially in referrals. > > My take is that the former is simpler and lead to less service calls. The > later introduce the notion that apps have to be aware of the topology, which > I found disturbing. > > - Alain. > > > On 7/22/08 6:05 PM, "Stark, Barbara" wrote: > > > Please don't change the ULA requirement. I believe ULA is needed. And I agree > > that apps need to be intelligent about the scope of the addresses they are > > using. I do not want to see the ULA go away. It needs to be persistent and > > always there, from my perspective. > > Barbara > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of > > Hemant Singh (shemant) > > Sent: Tuesday, July 22, 2008 5:02 PM > > To: Alain Durand; Ralph Droms (rdroms) > > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont; > > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > > Subject: RE: New (-02) version of IPv6 CPE Router draft is available for > > review > > > > Alain, > > > > Very sorry, I missed your "*with* address referral" phrase. Thanks for > > providing the example. Here is the analysis: > > > > Yes, if C tries to communicate with B using B's ULA for destination, C will > > also slap its ULA on the packet src address. Thereafter before the CPE Router > > WAN interface egresses the packet, the router has to comply to ULA forwarding > > rules. As per section 4.3 of RFC4193, the CPE Router will drop the packet > > (unless the router is explicitly configured for a route to destination ULA) > > and send an ICMPv6 Destination Unreachable to C. Here is the text from the > > RFC. > > > > [Site border routers and firewalls should be configured to not forward > > any packets with Local IPv6 source or destination addresses outside > > of the site, unless they have been explicitly configured with routing > > information about specific /48 or longer Local IPv6 prefixes.] > > > > I don't expect the CPE Router to be supporting a site connected to another ULA > > site so the question of any configuration on the CPE Router for a neighbor ULA > > site is out of the question. Since C gets some error indication, the app then > > needs to figure out fixes in its implementation. > > > > Sorry, I don't see this as rustication to change the CPE Router permanent ULA. > > Some brain-dead apps need fixing. I need more people to speak up and give > > their opinion. I am still open to change. > > > > Thanks. > > > > Hemant > > > > -----Original Message----- > > From: Alain Durand [mailto:alain_durand@cable.comcast.com] > > Sent: Tuesday, July 22, 2008 1:25 PM > > To: Hemant Singh (shemant); Ralph Droms (rdroms) > > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont; > > v6ops@ops.ietf.org; Wes Beebee (wbeebee) > > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > > review > > > > Hemant, > > > > You missed the phrase "*with* address referral" in my response. > > > > Say A & B are inside their home and use ULA & GUA. C and D are within another > > home and are also using ULA & GUA. > > > > Now, A B C & D enter a 4 way communication where they initially exchange the > > addresses of their pier. > > If A passes C the ULA and GUA of B, C might prefer to use B's ULA because of > > address selection rules and C->B communication would fail or worse, go > > somewhere else. > > > > There are multiple variants of this. The point is that you cannot expect apps > > that passes addresses to be smart enough to know about ULA & GUA. > > > > BTw, using DNS does not help at all if you include both ULA & GUA AAAAs in > > your zone... > > > > - Alain. > > > > > > On 7/22/08 1:17 PM, "Hemant Singh (shemant)" wrote: > > > >> Alain, > >> > >> Sorry I don't understand. If any node in the home using an ULA sends > >> a packet out the WAN interface of the CPE Router, the src-addr of the > >> packet used is the GUA before the packet heads out of the node > >> because, as we said in our draft, GUA has larger scope. So any > >> multi-party host on the Internet sees only the GUA. I will need a > >> specific example to show me how multi-party communications will break > >> down with ULA and GUA configured on an interface of any node in the > >> home behind the CPE Router or if ULA and GUA is configured on the LAN > >> Interface of the CPE Router. > >> > >> Thanks. > >> > >> Hemant > >> > >> -----Original Message----- > >> From: Alain Durand [mailto:alain_durand@cable.comcast.com] > >> Sent: Tuesday, July 22, 2008 11:48 AM > >> To: Hemant Singh (shemant); Ralph Droms (rdroms) > >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi > >> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee) > >> Subject: Re: New (-02) version of IPv6 CPE Router draft is available > >> for review > >> > >> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" wrote: > >> > >>> I have repeatedly said, I am not convinced the ULA gets appreciable > >>> complexity into the CPE Router. Our section 5.5.1 has clearly > >>> outlined any complexity and shown it's minimal. The ULA fixes a very > >>> common problem for the CPE Router which is configuring the router > >>> without any SP access - the problem is not a corner case. > >> > >> Hemant, > >> > >> 2 party communications in the presence of mixed ULA & GUA work ok, > >> given proper default address selection rules. > >> > >> Multi-party communications *with* address referral do not work in the > >> general case in such a mixed environment, regardless of default address > >> selection. > >> > >> - Alain. > >> > >> > > > > > > > > > > ***** > > > > The information transmitted is intended only for the person or entity to which > > it is addressed and may contain confidential, proprietary, and/or privileged > > material. Any review, retransmission, dissemination or other use of, or taking > > of any action in reliance upon this information by persons or entities other > > than the intended recipient is prohibited. If you received this in error, > > please contact the sender and delete the material from all computers. GA621 > > > > > > > From owner-v6ops@ops.ietf.org Tue Jul 22 17:45:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DFA3A6825 for ; Tue, 22 Jul 2008 17:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkWpjGisp4bM for ; Tue, 22 Jul 2008 17:45:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EED163A67E2 for ; Tue, 22 Jul 2008 17:45:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLSSp-000LnP-W8 for v6ops-data@psg.com; Wed, 23 Jul 2008 00:44:19 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLSSm-000Ln5-F5 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 00:44:18 +0000 Received: from e34.co.us.ibm.com ([32.97.110.152]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLPtKH025960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jul 2008 17:25:56 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6MLMk59001867 for ; Tue, 22 Jul 2008 17:22:46 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6MLMjYw176544 for ; Tue, 22 Jul 2008 15:22:45 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6MLMjE5029122 for ; Tue, 22 Jul 2008 15:22:45 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6MLMhng028927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Jul 2008 15:22:45 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6MLMgEE010033 for ; Tue, 22 Jul 2008 17:22:42 -0400 Message-Id: <200807222122.m6MLMgEE010033@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: v6ops-nat64-pb-statement-req: IPsec requirement Date: Tue, 22 Jul 2008 17:22:42 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > R11: IPsec support. > > The translator MUST support communication between IPv4 node and IPv6 > node using UDP Encapsulation of IPsec ESP Packets as defined in > [RFC3948] as applicable. RFC3948 should be interpreted as with the > IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of > the conventional NAT. IPsec support MAY require updating also the > IPv4 side. Actually, I think the real requirement is that both IPsec and IKEv2 work. IPsec without key management is pretty useless in practice. Is that what is meant? Thomas From owner-v6ops@ops.ietf.org Tue Jul 22 22:05:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285B53A6ABE for ; Tue, 22 Jul 2008 22:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.028 X-Spam-Level: X-Spam-Status: No, score=-105.028 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYiFvtHoRTOZ for ; Tue, 22 Jul 2008 22:05:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CE543A6AAA for ; Tue, 22 Jul 2008 22:05:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLWU8-000L33-TG for v6ops-data@psg.com; Wed, 23 Jul 2008 05:01:56 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLWU5-000L2o-40 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 05:01:55 +0000 X-IronPort-AV: E=Sophos;i="4.31,236,1215388800"; d="scan'208";a="89205496" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2008 05:01:43 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6N51gdJ024349 for ; Tue, 22 Jul 2008 22:01:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6N51gWi014943 for ; Wed, 23 Jul 2008 05:01:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:01:42 -0700 Received: from [172.17.187.241] ([10.21.124.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:01:41 -0700 Message-Id: <43458632-056E-451C-A0FA-CE9C0B099CDC@cisco.com> From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: 72nd IETF - Agenda Changes Date: Tue, 22 Jul 2008 22:01:32 -0700 References: <20080723044632.CDB443A695B@core3.amsl.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 23 Jul 2008 05:01:42.0774 (UTC) FILETIME=[32D3D960:01C8EC81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=817; t=1216789303; x=1217653303; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=2072nd=20IETF=20-=20Agenda=20Changes=20 |Sender:=20; bh=dj/yb0/GQBOjP3S/L9dN7hI2b26OWqM4DAMpvIx1LnY=; b=GJqtCtp6DI353/pUgUdVowzE/eS1FSwDzVfby8pgWRBDyQ/jS+xt4wm89A iBDbDZ9SaPYrnGYVtcftUwtbcFBLevYT7VRqIVzzgHDjI1dJeM57sg90Hi5B rh4EukNVZj; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We are adding 3777bis and Alain's dual stack lite to the agenda, and dividing it over the two days. That will give more time for each discussion. Begin forwarded message: > From: IETF Secretariat > Date: July 22, 2008 9:46:32 PM PDT > To: IETF Announcement list > Cc: irsg@isi.edu, wgchairs@ietf.org, bofchairs@ietf.org > Subject: 72nd IETF - Agenda Changes > > The second session of v6ops, scheduled for Thursday at 1300-1500, will > take place as scheduled. Please disregard the session cancellation > notice > for v6ops that was sent out July 22. > > Thanks, > > Marcia > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Wed Jul 23 02:09:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D7528C1A2 for ; Wed, 23 Jul 2008 02:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WInb6wwTaLuf for ; Wed, 23 Jul 2008 02:09:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D1B13A6AAA for ; Wed, 23 Jul 2008 02:09:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLaIm-000LQd-F3 for v6ops-data@psg.com; Wed, 23 Jul 2008 09:06:28 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLaIi-000LQL-P8 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 09:06:26 +0000 Received: from dummyhost26.it.uc3m.es (unknown [163.117.139.225])by smtp03.uc3m.es (Postfix) with ESMTP id 88ABC495E5D;Wed, 23 Jul 2008 11:04:04 +0200 (CEST) Message-ID: <4886F404.30807@it.uc3m.es> Date: Wed, 23 Jul 2008 11:04:04 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= CC: Dan Wing , 'IPv6 Operations' , 'Fred Baker' , teemu.savolainen@nokia.com, 'Brian E Carpenter' , Alain_Durand@cable.comcast.com, 'Jari Arkko' , 'Philip Matthews' Subject: Re: changes to draft-ietf-v6ops-nat64-pb-statement-req-00.txt References: <487F5BCB.1070209@it.uc3m.es> <00ba01c8e827$32b15470$c2f0200a@cisco.com> <4881FA93.7090109@it.uc3m.es> <48849ECE.8040909@free.fr> In-Reply-To: <48849ECE.8040909@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.6125 TC:1F TRN:26 TV:5.5.1026(16048.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Després escribió: > marcelo bagnulo braun - Le 7/19/08 4:30 PM : > >> BTW, One may also think that this draft is kind of weird, in the >> sense that it identifies the 3 scenarios mentioned above and then >> only defines the requirements for one of them, i.e. the one requiring >> translation. >> From a document perspective, we can do 3 things, i guess. >> Either we keep it as it is, even if it may seems somehow strange. >> Or we split in two documents, one as the overview of the scenarios >> and another one with the requirements for translation, (and >> eventually having two more documents with requirements for the other >> scenarios, >> or we add to this document the requiremetns for the other scenarios) >> >> I personally preffer the first or the second one, since i would like >> to wrap up the transalion requireemtns asap. > > Marcello, > > You have well clarified where there is a short term problem, which > explains some of our previous mail exchanges. > > Since the document deals with requirements only for v4-v6 translation > mechanisms, what about making it clear in the title, e.g.: > > "Pv4/IPv6 Coexistence - Requirements for solutions based on IPv4-IPv6 > translations". cause due the dual nature of the document, the current tittle actually fits the first part of the doccment > gards. > > Rémi > > > From owner-v6ops@ops.ietf.org Wed Jul 23 02:49:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E67E3A6AD4 for ; Wed, 23 Jul 2008 02:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=1.475, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtAxmyCv3Kub for ; Wed, 23 Jul 2008 02:49:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F4BD3A6AC0 for ; Wed, 23 Jul 2008 02:49:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLax6-0004Qp-IW for v6ops-data@psg.com; Wed, 23 Jul 2008 09:48:08 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLax2-0004Pb-Ba for v6ops@ops.ietf.org; Wed, 23 Jul 2008 09:48:06 +0000 Received: from [IPv6:::1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6N9lneZ035699; Wed, 23 Jul 2008 11:47:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org Message-Id: From: Iljitsch van Beijnum To: Thomas Narten In-Reply-To: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement Date: Wed, 23 Jul 2008 11:48:02 +0200 References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 22 jul 2008, at 23:20, Thomas Narten wrote: >> DNSSec support MUST NOT be prevented. >> o R10.1: In particular, if an IPv6 node is initiating a >> communication with an IPv4 that is located behind a translator, >> the IPv6 initiator MUST be able to perform DNSSec verification >> of >> the DNS information of the IPv4 target. (strong consensus on >> this >> one). >> o R10.2: In particular, if an IPv4 node is initiating a >> communication with an IPv6 that is located behind a translator, >> the IPv4 initiator MUST be able to perform DNSSec verification >> of >> the DNS information of the IPv4 target. This may require the >> modification of the IPv4 node as well. (not clear if there >> consensus on this one) > Maybe I don't understand what the above means, but it seems to me to > be unworkable. I.e., If an IPv6 node requests an AAAA record for an > IPv4-only node, there won't be a AAAA record and it will need to be > synthesized. By definition, such a synthesized DNS RR won't be > verifiable via DNSSEC because it is in fact an unauthorized > fabrication. That's true in an unmodified host that performs the DNSSEC validation itself. If the DNSSEC validation is performed by a system that knows about NAT64 that system will reject the fake AAAA records by virtue of the EDNS0 SAS option (or simply because the validation fails) and can then retrieve the original A record and validate that. Then, it can either conclude that the lower 32 bits of the fake AAAA record match the validated IPv4 address and allow the AAAA record, or determine the value of the 96 upper bits through a more secure mechanism and create a full 128-bit address that way. The idea is that it's ok to break (some) stuff for existing systems as long as it's possible to fix this for updated systems. From owner-v6ops@ops.ietf.org Wed Jul 23 03:16:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5901A3A6920 for ; Wed, 23 Jul 2008 03:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=3.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNUyJ-GYb2xt for ; Wed, 23 Jul 2008 03:16:22 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9AF993A6AE9 for ; Wed, 23 Jul 2008 03:16:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLa-0009KA-JC for v6ops-data@psg.com; Wed, 23 Jul 2008 10:13:26 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLV-0009Ja-V6 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 10:13:24 +0000 Received: (qmail 2916 invoked by uid 417); 23 Jul 2008 08:26:13 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 23 Jul 2008 08:26:13 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 23 Jul 2008 02:26:12 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Wed, 23 Jul 2008 02:26:12 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand writes: >> I think this describes the confusion here. You are looking for a default IP >> address for the device so that users can connect to it for configuring it? >> In IPv4 there is usually a default RFC 1918 address that will do just this >> function in order to enable configuration. So would it meet your needs if we >> used something like ::192:168:0:1 for the default address if it is used via >> the Ethernet or wireless (802.11x) port? > > You are right in the analysis of the confusion. However, I think we should > move away from such things as well know IP addresses and use some form of > service discovery protocol instead. Alain, The problem with addressing this problem with a service discovery protocol is that it will not meet the requirement of what to do when the router is the only service and is in need of initial configuration. In the past Cisco mandated that the console port was the way to do this while others have gone for a direct connect USB, but in a wireless situation there is no physical port to connect to while configuring the CPE. So unless you want to replace a "well known IP address" with a "well known ULA" then we need to find another solution. Or are you proposing that we make the discovery protocol enable a "find and configure CPE/router" option? If so I have a problem with the security implications of such a wide open configuration requirement. Eric From owner-v6ops@ops.ietf.org Wed Jul 23 03:16:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BFE3A6A5E for ; Wed, 23 Jul 2008 03:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.104 X-Spam-Level: X-Spam-Status: No, score=-103.104 tagged_above=-999 required=5 tests=[AWL=2.845, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7jmUg27YLcP for ; Wed, 23 Jul 2008 03:16:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 603513A6AD4 for ; Wed, 23 Jul 2008 03:16:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLn-0009Vn-MG for v6ops-data@psg.com; Wed, 23 Jul 2008 10:13:39 +0000 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLd-0009KQ-2P for v6ops@ops.ietf.org; Wed, 23 Jul 2008 10:13:37 +0000 Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id F09EF3EA0E7; Wed, 23 Jul 2008 12:13:06 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 9A7FC3EA0D2; Wed, 23 Jul 2008 12:13:03 +0200 (CEST) Message-ID: <4887040C.4030702@free.fr> Date: Wed, 23 Jul 2008 12:12:28 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: 'IPv6 Operations' , 'Fred Baker' , 'Jari Arkko' Subject: Title of draft-ietf-v6ops-nat64-pb-statement-req-0x References: <487F5BCB.1070209@it.uc3m.es> <00ba01c8e827$32b15470$c2f0200a@cisco.com> <4881FA93.7090109@it.uc3m.es> <48849ECE.8040909@free.fr> <4886F404.30807@it.uc3m.es> In-Reply-To: <4886F404.30807@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun - Le 7/23/08 11:04 AM : > Rémi Després escribió: >> Since the document deals with requirements only for v4-v6 translation >> mechanisms, what about making it clear in the title, e.g.: >> >> "Pv4/IPv6 Coexistence - Requirements for solutions based on IPv4-IPv6 >> translations". > > cause due the dual nature of the document, the current tittle actually > fits the first part of the doccment Yes, exactly. The first part is about scenarios, all of them, and the second part is about requirements, but only for NAT64 based solutions. "IPv4/IPv6 Coexistence and Transition: Requirements for solutions", suggests that all solutions have their requirements covered, which is misleading. Including requirements for other solutions would solve the problem, but your legitimate wish to wrap up asap makes it unrealistic. Examples of others title that IMO would fit: "IPv4/IPv6 Coexistence scenarios - Requirements for v4-v6 translation mechanisms" "IPv4/IPv6 Coexistence scenarios - Requirements for NAT64 based solutions" Note that updating the title doesn't imply a change of the file-name (draft-ietf-v6ops-nat64-pb-statement-req-0x is OK). Regards RD From owner-v6ops@ops.ietf.org Wed Jul 23 03:16:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0023A6A26 for ; Wed, 23 Jul 2008 03:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI8wxpUNGEZR for ; Wed, 23 Jul 2008 03:16:29 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D288F3A6920 for ; Wed, 23 Jul 2008 03:16:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLS-0009JR-Dx for v6ops-data@psg.com; Wed, 23 Jul 2008 10:13:18 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbLN-0009Ip-7G for v6ops@ops.ietf.org; Wed, 23 Jul 2008 10:13:15 +0000 Received: from dummyhost26.it.uc3m.es (unknown [163.117.139.225])by smtp02.uc3m.es (Postfix) with ESMTP id 7BE96422F5F;Wed, 23 Jul 2008 11:38:49 +0200 (CEST) Message-ID: <4886FC28.6020908@it.uc3m.es> Date: Wed, 23 Jul 2008 11:38:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ed Jankiewicz CC: IPv6 Operations Subject: Re: comments on draft-ipv6-v6ops-nat64-pb-statement-req-00 References: <4880ED7A.20007@sri.com> <48822ADD.4010409@it.uc3m.es> <4884B4BF.1010901@sri.com> In-Reply-To: <4884B4BF.1010901@sri.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.4265 TC:1F TRN:93 TV:5.5.1026(16048.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ed Jankiewicz escribió: > 3. Deemphasize dual stack. In para 2.1.1 the statement "the IETF > strongly prefers and recommends [dual stack] as the operational > matters are simplest" begs for a citation. RFC 4213 says dual stack > is the most straightforward but does not include language recommending > or preferring this solution. Also the impetus of this draft is that > dual stack solves only the simplest part of the problem, and becomes > very problematic when IPv4 addresses really get scarce (approaching > rather than reaching exhaustion). Some have already stated (Alain > Durand I recall saying something like) "a plan that requires all new > end-nodes to be dual-stack and to have global IPv4 addresses is a > non-starter." Also an emphasis on dual stack creates a "must carry" > situation where the core network continues to route IPv4 > indefinitely. While we say in para 2.2 that turning off IPv4 will be > a business decision, the ISP can't make that choice without alienating > customers that rely on dual stack. I can still plug in a 50 year old > rotary dial phone and expect the local telco (in the USA at least) to > make it work, even though DTMF has been the dominant method for nearly > that long. >>> >> i understand that this was what the document was reccomending >> >> Best option, native connectivity i.e. talk to v4 hosts using native >> v4 and talke to v6 hosts using native v6, hence dual stack >> Second best option, tunnel. this keeps packet unchanged >> Third option, translation >> >> do you think this is the wrong reccomendation to make? > not disagreeing with the recommendation - see Brian's comment and my > response, also Remi's remarks relate. If we say "the IETF strongly > prefers and recommends..." that needs to be justified with a > citation. If there isn't a published statement to that effect, this > draft can simply make the case, as you do in your comment. > > This draft does focus on the translation case as a last resort where > dual stack or tunneling do not solve the problem. Maybe we just need > explicit statement of the applicability of each class of solution > right up front in the introductory paragraphs. I am a bit confused at this point It seems that we all agree that native is better and tunnel should be used if not possible and the last option should be nat. This is what imho it is contained in the document and it succintly explains it what changes do you think need to be made? >> >>> 4. tunnel versus dual NAT: in para 2.1.2 the statement that IETF >>> recommends tunnels rather than dual NAT - that also would need a >>> citation, unless this document is making the statement for the first >>> time. Also, I believe if the two NATs know they are in a reflexive >>> relationship, they can avoid at least some of the general NAT >>> problems - i.e. they should not attempt to translate addresses in >>> application data. >>> >>> 5. translation network architecture: this may be beyond scope, but >>> it seems to me that in para 2.1.3 there could be several >>> sub-scenarios depending on the location of the translator >>> a. translator coupled to IPv6 end-nodes (IPv6 on the LAN side, >>> IPv4 on the WAN side) >>> b. translator coupled to IPv4 end-nodes (IPv4 on the LAN side, >>> IPv6 on the WAN side) >>> c. in-network translation gateway (most like NAT-PT) >>> There are some commercial products in development that fit these >>> sub-scenarios, and each has its own strengths and weaknesses. >>> Pulling the translator into an IPv6-only or IPv4-only edge network >>> (a or b) avoids some issues and those developers made the choice to >>> restrict deployment architecture to simplify their job. The >>> different deployment architectures also have impact on the >>> addressing concerns (para 3.3) and namespace (para 3.4). >>> >> i don't understand the scenarios you mention above >> >> I mean, for me a would be mostly nat64 and b would be mostly nat46 >> and c is the sum of both >> >> I am now considering having two different sets of requirements, one >> for nat64 and another for nat46, would that make sense to you? > yes. my gut feeling is that solutions could be rather difficult if > the deployment is restricted to "one foot firmly planted" in v6 versus > v4, i.e. if the translator can assume everything on one side is > restricted to v4 or v6 rather than an unrestricted topology. I have > not studied all the solution space drafts (apbp and ds-lite) that may > address some of the differences. It seems the unrestricted topology > (in-network scenario c) starts to fall into the same traps as NAT-PT. > not to reopen what might be settled - but it does seem like a generic > "problem statement" draft that encompasses the taxonomy of approaches > would still be useful, while a set of requirements drafts defining the > solution space would be as well. To some extent we are reverse > engineering the proposed solutions into a problem statement. i will try to expand on how we can make requirements for the different scenarios. > >> >>> 7. Requirement R3 would be better stated in the negative: >>> Translation mechanism MUST NOT interfere with native >>> connectivity...depending where the NAT64 is in the network it may be >>> a pass-through, or it may not be involved at all in the native flow >>> and thus do nothing but non-interference. >>> >> right, so why is this not expressed in the current form > just a style point - I prefer that when introducing something new into > an architecture, the new thing is explicitly forbidden to interfere > with pre-existing functionality. The new thing has no positive > requirement to enable that functionality but is required NOT to > interfere with it. If the native flow bypasses the translator, it > does nothing; if the native flow is through the translator it must be > passed without modification, another flavor of "do nothing" or "first, > do no harm." but the problem is that it is not that the nat will do something in the flow that it shouldn't but rahter that it is important to expose somehow the fact that using a given address would result in translated connectivity tot he end host, so it can make an informed decision, that is why i don't think expressing it in the negative form fully captures what we want to day i will wait fo rthe text yo promised below... regards, marcelo >> >>> 8. Requirement R4 is very broad. the essence of translating DNS in >>> support of NAT64 is to map a query on one side to the equivalent >>> query on the other, and do the same with the response. Of course >>> that mapping of names and addresses is non-trivial. It might help >>> to illustrate this mapping process as well as some of the bad >>> behavior that must be avoided. >>> >> so any suggestion how to rephrase it? > I'll follow up with some language. >> >>> 9. Requirement R5 seems to forbid any routing table update, but >>> don't the addresses that the NAT64 is mapping have to be routable? >>> >> no, i don't think it is what it means, I think the goal here is to >> preclude mechanisms that would for instance map each v4 prefix into a >> different v6 prefix and that for some reason cannot be aggregated. If >> such a mechanism would exist, then we would importing all the v4 >> routing table into v6, which would be a bad idea. >> But certainly the v6 addresses that are used to map v4 addresses need >> to be routable. I mean, think about the deprecated natpt, it does not >> requires additional global routing table entries, right? > true - the v6 addresses used in the mechanism should not require new > routing table entries. I definitely agree on the badness of importing > the v4 table. >> >>> 10. Requirement R6 lists a few protocols, but I'm sure others might >>> be seen as highly desirable too. Are we avoiding ALG issues by not >>> mentioning higher level protocols like FTP? >>> >> No, the idea here was to mention the very basci protocols and go into >> the application level protocols. Do you think we should try to list >> all the application level protocols thta should be supported? that >> seems difficult to me > agreed >> >>> 11. where does the interpretation in Requirement R7 that sees the >>> IPv6 side being like the private side of an IPv4 NAT come from? >> This only applies to behave requirements >> >> I think this is the most stringent way of seeing this. >> I mean, take a look in endpoint independence. this makes sense if the >> v4 is the public address. If the v6 is the public address, then we >> are likely to easily satisfy this and we are likely to require more >> that just endpoint indepdence, but we are requiring a stable one to >> one association, between the v4 address and the v6 addres,s cause we >> can provide tha cause we have enough v6 addresses. >> >> So, all these requireemtns that are means to express difficult >> tradeoffs make sense when the v4 side is the public address. If the >> v6 is the publci address, we are likely to have much more stringent >> requirements than those >>> the opposite could be reasonable too - i.e. if there is no NAT >>> between the NAT64 and the v4-only nodes the v4-only nodes might be >>> using private addresses, and the IPv6 side of the NAT64 is the >>> public side. The way it is described in R7, the IPv6 addresses are >>> like IPv4 private addresses, mapped to the global addresses on the >>> public side. >>> >>> 12. Requirement R9 is a noble statement but hardly a "testable" >>> requirement; at least we should cite RFC 4942 as guidance, and >>> analyze some of the security issues that arise in the different >>> scenarios and architectures discussed in the draft. >>> >>> >> i am not sure what you would like to see here... could you provide >> some more explicit guidance? > definitely cite RFC 4942, and I will try to come up with some language > which can go in the Security Considerations section. The onus will be > on the solutions developers to show how each solution at least does no > harm. >> >> Regards, marcelo >> >> >>> >>> >> >> > From owner-v6ops@ops.ietf.org Wed Jul 23 03:18:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E156F3A6987 for ; Wed, 23 Jul 2008 03:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.134 X-Spam-Level: X-Spam-Status: No, score=-104.134 tagged_above=-999 required=5 tests=[AWL=2.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D-cGVQAYc9v for ; Wed, 23 Jul 2008 03:18:43 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3C2DA3A6920 for ; Wed, 23 Jul 2008 03:18:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbQ1-000A7E-UL for v6ops-data@psg.com; Wed, 23 Jul 2008 10:18:01 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbPe-000A6E-98 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 10:17:43 +0000 Received: (qmail 8280 invoked by uid 417); 23 Jul 2008 08:30:42 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 23 Jul 2008 08:30:42 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 23 Jul 2008 02:30:42 -0600 References: <20080704.011411.193726649.miyakawa@nttv6.jp> <200807032152.11321.rdenis@simphalempin.com> <67966A61-E788-4F0B-8FCB-8E6185264CB0@cisco.com> <8DF03C59-15BE-4707-9607-6121A0706875@virtualized.org> <65A6E4E5-D3E4-4104-8F72-BCAC6354ACA3@muada.com> <200807221743.m6MHhrt4019274@cichlid.raleigh.ibm.com> In-Reply-To: <200807221743.m6MHhrt4019274@cichlid.raleigh.ibm.com> From: EricLKlein@softhome.net To: Thomas Narten Cc: IPv6 Operations Subject: Re: new draft on IPv6 CPE router available for review Date: Wed, 23 Jul 2008 02:30:42 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten writes: > And I wish others would get their heads out of the sand. The reality > is that NAT does have both benefits and drawbacks. Some may think the > drawbacks dwarf all benefits, but anyone who has followed this > discussion for more than 30 seconds has to see that reasonable people > disagree on how to weigh the cost vs. benefits. Can't we just accept > that and move on? > Thomas, The WG went down that road and more than a year ago agreed that the problems out weighed the benefits and thus published RFC4864 after more than 2 years of discussion. I do not think that this is the right draft to reopen that discussion. Eric From owner-v6ops@ops.ietf.org Wed Jul 23 03:37:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EA33A6A5E for ; Wed, 23 Jul 2008 03:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdYgcl7QH-tn for ; Wed, 23 Jul 2008 03:37:50 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DF6C33A6987 for ; Wed, 23 Jul 2008 03:37:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbiE-000CuZ-6a for v6ops-data@psg.com; Wed, 23 Jul 2008 10:36:50 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLbhb-000CsO-00 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 10:36:17 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 976E5548; Wed, 23 Jul 2008 12:35:30 +0200 (CEST) To: Alain Durand Subject: Re: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) MIME-Version: 1.0 Date: Wed, 23 Jul 2008 12:35:30 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: References: Message-ID: <90803013a5a6eeef9e7b732cb04f1c00@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 22 Jul 2008 18:15:04 -0400, Alain Durand wrote: > [Changing the title of this long thread to focus the discussion and > trimming the distribution list] > > We have a trade-off here to make between network stability and application > complexity: either modify apps to deal with renumbering (ie try > reconnecting, avoid well know literal addresses, use some kind of service > location,...) or to teach application when it is ok to use ULA vs GUA, > especially in referrals. Avoiding literal addresses is orthogonal to using ULA. Human beings will not remember ULA addresses, neither GUA addresses. In both cases, a local DNS server, or a multicast discovery system will be required. In the mean time, CPE vendors will continue to document http://192.168.0.1 alike as the way to configure the (dual-stack) CPE. Same thing with service location. People will use UPnP, Bonjour, SAP or whatever. There is actually some value in using ULAs here, as the applications can easily check that this is "Intranet". With GUAs, it is do-able but more difficult to tell semi-trusted local peers from untrusted remote ones. > My take is that the former is simpler and lead to less service calls. > The later introduce the notion that apps have to be aware of the > topology, which I found disturbing. Most applications do not do referrals. And those that do... they will need to have some IPv6 logic _anyway_ (e.g. to discard link-local), know multicast groups, do AAAA lookups, etc. Most applications will screw up, especially LANish applications (file shares, printers, ...) if they need to reconnect. In fact, reconnecting is typically not a complete solution due to protocol limitations. To the contrary, enumerating addresses properly is an implementation issue that does not affect protocol design. Also, it is fairly typical for LAN applications to start doing discovery right at boot. Precisely when renumbering from ULA to GUA is likely to occur and break things up. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Jul 23 04:24:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E6C28C1B5 for ; Wed, 23 Jul 2008 04:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.545 X-Spam-Level: X-Spam-Status: No, score=-104.545 tagged_above=-999 required=5 tests=[AWL=2.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I45nYMlAYWhP for ; Wed, 23 Jul 2008 04:24:41 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 71CA128C1B4 for ; Wed, 23 Jul 2008 04:24:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLcOw-000Jow-LY for v6ops-data@psg.com; Wed, 23 Jul 2008 11:20:58 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLcOs-000JoJ-OO for v6ops@ops.ietf.org; Wed, 23 Jul 2008 11:20:56 +0000 Received: (qmail 11966 invoked by uid 417); 23 Jul 2008 08:33:14 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 23 Jul 2008 08:33:14 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 23 Jul 2008 02:33:14 -0600 References: <200807221839.07850.rdenis@simphalempin.com> In-Reply-To: From: EricLKlein@softhome.net To: Antonio Querubin Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Wed, 23 Jul 2008 02:33:14 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Antonio Querubin writes: > > *Ahem* ISPs do care. For the intended mass-market of this CPE router, the > end-customer probably has no full-time IT expert. Guess who they call > first when things break? The consultant who costs money? Nephew Tim who > might have a real day job? Or the ISP support line? > Of the choices, my experience says Nephew Tim is first called. People hate having to call tech support more than consultants. The long wait, the "select 1 for..." menu, etc. From owner-v6ops@ops.ietf.org Wed Jul 23 04:43:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287BD3A6927 for ; Wed, 23 Jul 2008 04:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6eG9i3PQoPc for ; Wed, 23 Jul 2008 04:43:46 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5F5183A6A66 for ; Wed, 23 Jul 2008 04:43:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLciw-000NAu-UM for v6ops-data@psg.com; Wed, 23 Jul 2008 11:41:38 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLcis-000NAD-T3 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 11:41:36 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id E49A7532; Wed, 23 Jul 2008 12:43:06 +0200 (CEST) To: Alain Durand Subject: Re: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review) MIME-Version: 1.0 Date: Wed, 23 Jul 2008 12:43:06 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: "Hemant Singh (shemant)" , v6ops@ops.ietf.org Organization: Remlab.net In-Reply-To: References: Message-ID: <29c3cb6f731ec86fe0b5ceab269b571f@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Tue, 22 Jul 2008 18:38:33 -0400, Alain Durand wrote: > On 7/22/08 6:33 PM, "Hemant Singh (shemant)" wrote: > >> I don't believe apps have to know topology if apps receive a GUA and a >> ULA. The app has to just ignore the ULA. > > Exactly my point. Apps need to be made aware of the difference between ULA > & GUA, which is what the ULA proponents have been saying all along will not > be necessary. That depends how the applications learn the ULA in the first place... If an application uses referral, it might well be that the rendez-vous mechanism provides GUA even for on-link hosts, so the application will not even see the ULA ever and there will be no issues. For an Internet-wide service, I would expect the application to connect to a global location server (from/to GUA) and register that source address, the GUA, with the service. Conversely, if the service is not intended to work outside of the LAN: it is OK for my file sharing and printing service to use ULA in referrals because it is not supposed to work from the outside in the first place. -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Jul 23 07:13:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F212D3A689B for ; Wed, 23 Jul 2008 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.712 X-Spam-Level: X-Spam-Status: No, score=-103.712 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3S6oSp4lrWB for ; Wed, 23 Jul 2008 07:13:22 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 04E593A67D7 for ; Wed, 23 Jul 2008 07:13:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf1c-00003z-NQ for v6ops-data@psg.com; Wed, 23 Jul 2008 14:09:04 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf1U-00003H-Mc for v6ops@ops.ietf.org; Wed, 23 Jul 2008 14:08:58 +0000 Received: from dummyhost25.it.uc3m.es (dummyhost14.it.uc3m.es [163.117.139.225])by smtp02.uc3m.es (Postfix) with ESMTP id 5563A4236C9;Wed, 23 Jul 2008 16:08:54 +0200 (CEST) Message-ID: <48873B75.8060908@it.uc3m.es> Date: Wed, 23 Jul 2008 16:08:53 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: MIPv6 RO requirement References: <200807222128.m6MLSe3F010065@cichlid.raleigh.ibm.com> In-Reply-To: <200807222128.m6MLSe3F010065@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.3675 TC:1F TRN:23 TV:5.5.1026(16048.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > > >> I5: MIPv6 support >> >> The translation mechanism SHOULD not prevent MIPv6 Route Optimization >> when the CN is a v4-only node >> > > What exactly is meant by this? Is the intention that a MIPv6 MN should > be able to use RO with an IPv4-only CN? > > To invoke MIPv6 RO, the CN must actively participate in the > signalling. Presumably, an IPv4-only node doesn't implement MIPv6 at > all. > > What exactly is this requirement intended to achieve? > > FWIW; this req is gone in the 01 version cause people ask to remove it (so stop reading here if that is enough) For background, what this req really meant is that nat should behave as a CN in the RO operation, so while it was not possible to optimize all the way till the v4 CN, it would be able to preform ro with the nat box. In any case, it is gone now (unless you want to revisit this) Regards, marcelo > Thomas > > > From owner-v6ops@ops.ietf.org Wed Jul 23 07:13:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB03D3A689B for ; Wed, 23 Jul 2008 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.714 X-Spam-Level: X-Spam-Status: No, score=-103.714 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR8cZYwM6S-a for ; Wed, 23 Jul 2008 07:13:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DF6D53A67D7 for ; Wed, 23 Jul 2008 07:13:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf5m-0001BU-Vg for v6ops-data@psg.com; Wed, 23 Jul 2008 14:13:22 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf5c-00013G-G4 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 14:13:17 +0000 Received: from dummyhost25.it.uc3m.es (dummyhost14.it.uc3m.es [163.117.139.225])by smtp02.uc3m.es (Postfix) with ESMTP id 8C4CE4236BD;Wed, 23 Jul 2008 16:05:52 +0200 (CEST) Message-ID: <48873AC0.5090401@it.uc3m.es> Date: Wed, 23 Jul 2008 16:05:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> In-Reply-To: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.6825 TC:1F TRN:27 TV:5.5.1026(16048.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > > >> R10: DNSSec support >> >> DNSSec support MUST NOT be prevented. >> o R10.1: In particular, if an IPv6 node is initiating a >> communication with an IPv4 that is located behind a translator, >> the IPv6 initiator MUST be able to perform DNSSec verification of >> the DNS information of the IPv4 target. (strong consensus on this >> one). >> > > > >> o R10.2: In particular, if an IPv4 node is initiating a >> communication with an IPv6 that is located behind a translator, >> the IPv4 initiator MUST be able to perform DNSSec verification of >> the DNS information of the IPv4 target. This may require the >> modification of the IPv4 node as well. (not clear if there >> consensus on this one) >> > > Maybe I don't understand what the above means, but it seems to me to > be unworkable. I.e., If an IPv6 node requests an AAAA record for an > IPv4-only node, there won't be a AAAA record and it will need to be > synthesized. By definition, such a synthesized DNS RR won't be > verifiable via DNSSEC because it is in fact an unauthorized > fabrication. > > What am I missing here? > if the verification is performed before the synthesis of the RR and there is a trsut relationship betwen the receiver and the node that has performed the verification and synthesis, this should do it. In particular, if everything happens at the end node, we are in business, right? (i.e. the v6 end node asks for the A RR, perfomrs the dnssec validation and then internally generates the v6 address) it is not so trivial for the v4 case though (actually i think it is not possible for the v4 case, hence the question mark) Regards, marcelo > Thomas > > > From owner-v6ops@ops.ietf.org Wed Jul 23 07:17:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AD83A681E for ; Wed, 23 Jul 2008 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.968 X-Spam-Level: X-Spam-Status: No, score=-100.968 tagged_above=-999 required=5 tests=[AWL=3.563, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA6LT483nArW for ; Wed, 23 Jul 2008 07:17:05 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E0B3E3A67D7 for ; Wed, 23 Jul 2008 07:17:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf98-00022a-5f for v6ops-data@psg.com; Wed, 23 Jul 2008 14:16:50 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLf8z-00020u-FP for v6ops@ops.ietf.org; Wed, 23 Jul 2008 14:16:43 +0000 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8940009; Wed, 23 Jul 2008 10:15:59 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 10:15:58 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Jul 2008 14:15:29 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 23 Jul 2008 10:15:27 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: CC: Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjsneFXev2WAiioTqCeCv+UAQZmegAMKyr2 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jul 2008 14:15:58.0959 (UTC) FILETIME=[A10EF7F0:01C8ECCE] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/23/08 4:26 AM, "EricLKlein@softhome.net" wrote: > The problem with addressing this problem with a service discovery protocol > is that it will not meet the requirement of what to do when the router is > the only service and is in need of initial configuration. In the past Cisco > mandated that the console port was the way to do this while others have gone > for a direct connect USB, but in a wireless situation there is no physical > port to connect to while configuring the CPE. > > So unless you want to replace a "well known IP address" with a "well known > ULA" then we need to find another solution. Or are you proposing that we > make the discovery protocol enable a "find and configure CPE/router" option? > If so I have a problem with the security implications of such a wide open > configuration requirement. Eric, >From a security perspective, what is the difference between: A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a similar range, asking people to configure it using http://[10.0.0.1] B) the same thing using link local address, with the router being configured using fe80::1 and asking people to configure it using http://[fe80::1] C) the same replacing link local by ULA D) having the router advertizing itself as a router using a service discovery protocol a la Apple Bonjour? In all those case, a 'bad guy' can easily impersonate the router. - Alain. From owner-v6ops@ops.ietf.org Wed Jul 23 07:37:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21973A67A7 for ; Wed, 23 Jul 2008 07:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2tYajyP6Q+c for ; Wed, 23 Jul 2008 07:37:09 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 29BE93A6881 for ; Wed, 23 Jul 2008 07:37:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLfRp-0006qx-AU for v6ops-data@psg.com; Wed, 23 Jul 2008 14:36:09 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLfRl-0006l4-46 for v6ops@ops.ietf.org; Wed, 23 Jul 2008 14:36:07 +0000 Received: from dummyhost25.it.uc3m.es (dummyhost14.it.uc3m.es [163.117.139.225])by smtp03.uc3m.es (Postfix) with ESMTP id 8514F4962E9;Wed, 23 Jul 2008 16:06:46 +0200 (CEST) Message-ID: <48873AF6.80303@it.uc3m.es> Date: Wed, 23 Jul 2008 16:06:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: IPsec requirement References: <200807222122.m6MLMgEE010033@cichlid.raleigh.ibm.com> In-Reply-To: <200807222122.m6MLMgEE010033@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.5150 TC:1F TRN:19 TV:5.5.1026(16048.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > > >> R11: IPsec support. >> >> The translator MUST support communication between IPv4 node and IPv6 >> node using UDP Encapsulation of IPsec ESP Packets as defined in >> [RFC3948] as applicable. RFC3948 should be interpreted as with the >> IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of >> the conventional NAT. IPsec support MAY require updating also the >> IPv4 side. >> > > > Actually, I think the real requirement is that both IPsec and IKEv2 > work. IPsec without key management is pretty useless in practice. Is > that what is meant? > i think so, i have changed that to The translator MUST support communication between IPv4 node and IPv6 node using UDP Encapsulation of IKE and IPsec ESP Packets as defined in [RFC3948] as applicable. RFC3948 should be interpreted as with the IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of the conventional NAT. IPsec support MAY require updating also the IPv4 side. would that be better? > Thomas > > > From owner-v6ops@ops.ietf.org Wed Jul 23 08:36:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939903A69B9 for ; Wed, 23 Jul 2008 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.838 X-Spam-Level: X-Spam-Status: No, score=-104.838 tagged_above=-999 required=5 tests=[AWL=1.760, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OclZmf+Atg85 for ; Wed, 23 Jul 2008 08:35:59 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B85643A6A58 for ; Wed, 23 Jul 2008 08:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgJo-000Jzw-0e for v6ops-data@psg.com; Wed, 23 Jul 2008 15:31:56 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgJj-000JzG-PG for v6ops@ops.ietf.org; Wed, 23 Jul 2008 15:31:53 +0000 Received: (qmail 23849 invoked by uid 417); 23 Jul 2008 15:31:08 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 23 Jul 2008 15:31:08 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 23 Jul 2008 09:31:08 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Wed, 23 Jul 2008 09:31:08 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand writes: >> The problem with addressing this problem with a service discovery protocol >> is that it will not meet the requirement of what to do when the router is >> the only service and is in need of initial configuration. In the past Cisco >> mandated that the console port was the way to do this while others have gone >> for a direct connect USB, but in a wireless situation there is no physical >> port to connect to while configuring the CPE. >> >> So unless you want to replace a "well known IP address" with a "well known >> ULA" then we need to find another solution. Or are you proposing that we >> make the discovery protocol enable a "find and configure CPE/router" option? >> If so I have a problem with the security implications of such a wide open >> configuration requirement. > > Eric, > > From a security perspective, what is the difference between: > > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a similar > range, asking people to configure it using http://[10.0.0.1] > B) the same thing using link local address, with the router being configured > using fe80::1 and asking people to configure it using http://[fe80::1] > C) the same replacing link local by ULA > D) having the router advertizing itself as a router using a service > discovery protocol a la Apple Bonjour? > > > In all those case, a 'bad guy' can easily impersonate the router. > Alain, Your example B is exactly what I am suggesting, a it is identical to A in an IPV6 world. C link local is going to be a new option for people. D sounds like a problem to me as you don't want to advertise a "come configure me" service. This is the one I am most against in my previous e-mail. The if there is a local address to be connected to (either link local or ULA or fixed IP address) then it is possible to fulfill the configuration prior to having an IP address from the ISP scenario. Thus the "bad guys" who are spoofing would need to both know the address (and that works for any fixed predefined address) and admin password (also usually a default one until changed). And impersonating the router would be meaningless as it is only the initial configuration that I am addressing and I doubt that someone would set themselves up hoping to catch a new setup that could happen anytime if at all. From owner-v6ops@ops.ietf.org Wed Jul 23 08:36:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B9D3A69AC for ; Wed, 23 Jul 2008 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.725 X-Spam-Level: X-Spam-Status: No, score=-105.725 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CPsjUJCZT4r for ; Wed, 23 Jul 2008 08:36:18 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 580833A67EE for ; Wed, 23 Jul 2008 08:36:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgMA-000KVL-MI for v6ops-data@psg.com; Wed, 23 Jul 2008 15:34:22 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgLs-000KUY-RM for v6ops@ops.ietf.org; Wed, 23 Jul 2008 15:34:13 +0000 X-IronPort-AV: E=Sophos;i="4.31,239,1215388800"; d="scan'208";a="15191072" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2008 15:33:48 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6NFXmVB023669; Wed, 23 Jul 2008 11:33:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6NFXmA4001753; Wed, 23 Jul 2008 15:33:48 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 11:33:48 -0400 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 Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Date: Wed, 23 Jul 2008 11:33:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-wbeebee-ipv6-cpe-router-01.txt Thread-Index: AcjreFCHK5bwEL/pRHW232Jn8NvzTAAl4W5gADHHVxA= References: <7582BC68E4994F4ABF0BD4723975C3FA09B24DEB@crexc41p> <0F0CD8E8-917D-4F26-8C86-BDB1DD42B5EF@muada.com> <2bbba3c10807210354n4e00da26jc2c698843c35b49f@mail.gmail.com> <2bbba3c10807211425i2321d542ja30933c45bae2150@mail.gmail.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Ole Troan" Cc: "Iljitsch van Beijnum" , "IPv6 Operations" X-OriginalArrivalTime: 23 Jul 2008 15:33:48.0513 (UTC) FILETIME=[80545D10:01C8ECD9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3316; t=1216827228; x=1217691228; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Comments=20on=20draft-wbeebee-ipv6-cpe- router-01.txt |Sender:=20 |To:=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22Ole=20Troan=22=20; bh=THqJNeOm0MGShXhaQBj0JZj14y9nHKSALed4oMX6qFc=; b=Ufte7CHtNWYlqHrLmu4Ha9MQa62nRadCsuTYpShjSfg9u1VtGXkeCXGnpe Xk73qHOQZnWaPrdLFcDRFQsRK14RPXxUfOY7LjGpIMzOE+uTJSXx6tT5mmqB FQsk9jmRx0; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: BTW, Ole, the high level requirements for DSL are already in the draft, like totally high level features such as PPP and then new Softwires. It's more detailed requirements such as WAN with link-local only vs. only allowing WAN with GUA that are pending. Also as I said in the past there is one stock change in the -02 draft replacing stateless DHCPv6 with stateful DHCPv6 for IA_PD acquisition and then draft it fixed - these are 3-4 places.=20 IRB is something we have used time and time on routers and as I said to this mailer, we have a working CPE Router using IRB in a cable modem at Cisco. Any interface on our cable modem router can receive the RA sent to the modem WAN interface if the interface has joined the bridged group. Anyhow, we are open to replacing IRB for a different solution. For example, let users just configure the Loopback interface manually or automatically (where the interface gets IPv6 address from IA_PD) if NTT would like that for the CPE Router.=20 Some folks have asked for pictures. We plan to include pictures showing external and internals of the CPE Router in our IETF 72 presentation.=20 Hemant=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, July 22, 2008 11:45 AM To: Ole Troan Cc: Iljitsch van Beijnum; IPv6 Operations Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt -----Original Message----- From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, July 21, 2008 5:25 PM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; IPv6 Operations Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt > We are not even concerned about the draft being a WG work item. We=20 > have not even completed requirements for the device. >> perhaps you would have more success if you wrote down the requirements instead of arguing for solutions. I think so too. We thought we could provide solutions to some early requirements from DSL folks, but as you can see, those solutions need some ironing out. We have to get consensus between AT&T, NTT, Mikael Abrahamsson, and David Miles who works with DSL IPv6 Forum for requirements. In that process we also have to filter some requirements because a requirement might not be possible. We heard some consensus between AT&T and NTT when AT&T agreed that they also support a MUST for global IPv6 address on the WAN interface. There are other requirements to be ironed out. I had told the mailer, unless I meet NTT folks at IETF 72, I am not clear on their requirements and our draft is subject to change. We understand David Miles' requirements fine. We'll see what we can do to add a requirements section to the document and eventually that section also the lists what other section to go to for what requirement so that any given solution is identifiable for a given requirement. If you see the first email from Mikael on our draft, that's his requirement. Then see the first email from Shin - that's NTT's requirement. Then see the first email from David Miles to see his requirement. AT&T's requirements are best seen from any of Barbara's recent emails marching backwards. Hemant=20 From owner-v6ops@ops.ietf.org Wed Jul 23 08:52:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2393A67EE for ; Wed, 23 Jul 2008 08:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.105 X-Spam-Level: X-Spam-Status: No, score=-101.105 tagged_above=-999 required=5 tests=[AWL=3.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDgnvj8W3q8Y for ; Wed, 23 Jul 2008 08:52:42 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7CD383A69B8 for ; Wed, 23 Jul 2008 08:52:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgbn-000OQI-Pd for v6ops-data@psg.com; Wed, 23 Jul 2008 15:50:31 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLgbj-000OPo-Pv for v6ops@ops.ietf.org; Wed, 23 Jul 2008 15:50:29 +0000 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58092736; Wed, 23 Jul 2008 11:50:10 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 11:50:10 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Jul 2008 15:50:08 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 23 Jul 2008 11:50:06 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: CC: Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: Acjs28b1kjiG8w0lAkWR0wmVvP+01g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jul 2008 15:50:10.0160 (UTC) FILETIME=[C96FCF00:01C8ECDB] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/23/08 11:31 AM, "EricLKlein@softhome.net" wrote: > D sounds like a problem to me as you don't want to advertise a "come > configure me" service. This is the one I am most against in my previous > e-mail. Why? I fail to see any more problems with this than with the other approaches. - Alain. From owner-v6ops@ops.ietf.org Wed Jul 23 09:19:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141643A69FF for ; Wed, 23 Jul 2008 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv-772kd8m-V for ; Wed, 23 Jul 2008 09:19:20 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D58FB3A6918 for ; Wed, 23 Jul 2008 09:19:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLh2B-00052T-W1 for v6ops-data@psg.com; Wed, 23 Jul 2008 16:17:47 +0000 Received: from [91.121.105.214] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLh1z-000514-CC for v6ops@ops.ietf.org; Wed, 23 Jul 2008 16:17:38 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 82AEE11; Wed, 23 Jul 2008 18:17:03 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: EricLKlein@softhome.net Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Wed, 23 Jul 2008 19:17:00 +0300 User-Agent: KMail/1.9.9 Cc: v6ops@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807231917.02629.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le mercredi 23 juillet 2008 18:31:08 EricLKlein@softhome.net, vous avez=20 =E9crit=A0: > Alain Durand writes: > >> The problem with addressing this problem with a service discovery > >> protocol is that it will not meet the requirement of what to do when t= he > >> router is the only service and is in need of initial configuration. In > >> the past Cisco mandated that the console port was the way to do this > >> while others have gone for a direct connect USB, but in a wireless > >> situation there is no physical port to connect to while configuring the > >> CPE. > >> > >> So unless you want to replace a "well known IP address" with a "well > >> known ULA" then we need to find another solution. Or are you proposing > >> that we make the discovery protocol enable a "find and configure > >> CPE/router" option? If so I have a problem with the security > >> implications of such a wide open configuration requirement. > > > > Eric, > > > > From a security perspective, what is the difference between: > > > > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a > > similar range, asking people to configure it using http://[10.0.0.1] > > B) the same thing using link local address, with the router being > > configured using fe80::1 and asking people to configure it using > > http://[fe80::1] C) the same replacing link local by ULA > Your example B is exactly what I am suggesting, a it is identical to A in > an IPV6 world. As already pointed out in this same thread, link-local addresses do NOT wor= k=20 in most web browsers, as you need to know which local interface to use - no= t=20 suited at all within a for-dummies installation guide. ULAs will not fit the bill either because the prefix ought to be=20 pseudo-random, and different for each and every shipped box. GUAs do not fit as they also depend on the customer, and by definition, are= =20 not available until the CPE has been successfully configured. Site-local addresses would have worked, but they're now deprecated. Multicast service discovery does not work because it is not implemented wit= h=20 current hosts - if we specify if now, it will be years before it can be use= d. So... you're stuck instructing the customer to use the constant IPv4 addres= s.=20 That works today and will continue to work for the foreseeable future of=20 dual-stack hosts on unmanaged networks. As much as I believe the CPE ought to provision a permament ULA prefix, I a= lso=20 believe the initial configuration argument is completely bogus. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Wed Jul 23 13:21:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A673A6809 for ; Wed, 23 Jul 2008 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.022 X-Spam-Level: X-Spam-Status: No, score=-106.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW-3FIeJUQ18 for ; Wed, 23 Jul 2008 13:21:35 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4FFC13A6407 for ; Wed, 23 Jul 2008 13:21:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkmO-000ABO-JZ for v6ops-data@psg.com; Wed, 23 Jul 2008 20:17:44 +0000 Received: from [32.97.110.153] (helo=e35.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkmK-000A5F-Ap for v6ops@ops.ietf.org; Wed, 23 Jul 2008 20:17:42 +0000 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6NKHch3017349 for ; Wed, 23 Jul 2008 16:17:38 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6NKHa9V091962 for ; Wed, 23 Jul 2008 14:17:36 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6NKHX7n032193 for ; Wed, 23 Jul 2008 14:17:33 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6NKHVC2032120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 14:17:32 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6NKHT6R004772; Wed, 23 Jul 2008 16:17:29 -0400 Message-Id: <200807232017.m6NKHT6R004772@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun cc: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: IPsec requirement In-reply-to: <48873AF6.80303@it.uc3m.es> References: <200807222122.m6MLMgEE010033@cichlid.raleigh.ibm.com> <48873AF6.80303@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Wed, 23 Jul 2008 16:06:46 +0200." Date: Wed, 23 Jul 2008 16:17:29 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun writes: > i think so, i have changed that to > The translator MUST support communication between IPv4 node and IPv6 > node using UDP Encapsulation of IKE and IPsec ESP Packets as defined in > [RFC3948] as applicable. RFC3948 should be interpreted as with the > IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of > the conventional NAT. IPsec support MAY require updating also the > IPv4 side. > would that be better? Yes, but... Question: Why was UDP encapsulation chosen? Should we even have that requirement at this point? Seems to me that the requirement should be more like: The translator MUST be able to support the translation of at least one mode of IPsec and IKE flows sufficient to allow nodes using IKE and IPsec to successfully set up and use IPsec SAs. Although desirable, it is not a requirement that such a capability be done with no changes to the IPv4 node's IKE/IPsec implementation. Thoughts? Thomas From owner-v6ops@ops.ietf.org Wed Jul 23 13:21:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F343A6809 for ; Wed, 23 Jul 2008 13:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.086 X-Spam-Level: X-Spam-Status: No, score=-106.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1aRYoEn5KJh for ; Wed, 23 Jul 2008 13:21:45 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2325E3A6407 for ; Wed, 23 Jul 2008 13:21:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkq3-000B6U-S2 for v6ops-data@psg.com; Wed, 23 Jul 2008 20:21:31 +0000 Received: from [32.97.182.144] (helo=e4.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkpz-000B5s-Vt for v6ops@ops.ietf.org; Wed, 23 Jul 2008 20:21:29 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6NKLOCs025955 for ; Wed, 23 Jul 2008 16:21:24 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6NKK8tZ184144 for ; Wed, 23 Jul 2008 16:20:08 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6NKK86e002185 for ; Wed, 23 Jul 2008 16:20:08 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6NKK5lr001906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 16:20:07 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6NKK1KD004786; Wed, 23 Jul 2008 16:20:03 -0400 Message-Id: <200807232020.m6NKK1KD004786@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun cc: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: MIPv6 RO requirement In-reply-to: <48873B75.8060908@it.uc3m.es> References: <200807222128.m6MLSe3F010065@cichlid.raleigh.ibm.com> <48873B75.8060908@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Wed, 23 Jul 2008 16:08:53 +0200." Date: Wed, 23 Jul 2008 16:20:01 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun writes: > Thomas Narten escribiĂ³: > > draft-ietf-v6ops-nat64-pb-statement-req-00.txt says: > > > > > >> I5: MIPv6 support > >> > >> The translation mechanism SHOULD not prevent MIPv6 Route Optimization > >> when the CN is a v4-only node > >> > > > > What exactly is meant by this? Is the intention that a MIPv6 MN should > > be able to use RO with an IPv4-only CN? > > > > To invoke MIPv6 RO, the CN must actively participate in the > > signalling. Presumably, an IPv4-only node doesn't implement MIPv6 at > > all. > > > > What exactly is this requirement intended to achieve? > > > > > FWIW; this req is gone in the 01 version cause people ask to remove it > (so stop reading here if that is enough) It is! > For background, what this req really meant is that nat should behave as > a CN in the RO operation, so while it was not possible to optimize all > the way till the v4 CN, it would be able to preform ro with the nat box. > In any case, it is gone now (unless you want to revisit this) I do not want to revisit this. Given the amount of deployment experience we have with MIPv6 RO, it would be seriously premature to have this sort of requirement (IMO). Thomas From owner-v6ops@ops.ietf.org Wed Jul 23 13:30:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C853A6940 for ; Wed, 23 Jul 2008 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0P3ckSVFQGc for ; Wed, 23 Jul 2008 13:30:30 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 61D1E3A6887 for ; Wed, 23 Jul 2008 13:30:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLky2-000DDI-4b for v6ops-data@psg.com; Wed, 23 Jul 2008 20:29:46 +0000 Received: from [32.97.182.146] (helo=e6.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkxy-000DCr-EN for v6ops@ops.ietf.org; Wed, 23 Jul 2008 20:29:44 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6NKVsqJ009953 for ; Wed, 23 Jul 2008 16:31:54 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6NKTRC1212044 for ; Wed, 23 Jul 2008 16:29:27 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6NKTRQo029980 for ; Wed, 23 Jul 2008 16:29:27 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6NKTPul029919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 16:29:27 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6NKTPx2004828; Wed, 23 Jul 2008 16:29:25 -0400 Message-Id: <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun cc: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement In-reply-to: <48873AC0.5090401@it.uc3m.es> References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Wed, 23 Jul 2008 16:05:52 +0200." Date: Wed, 23 Jul 2008 16:29:24 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun writes: > if the verification is performed before the synthesis of the RR and > there is a trsut relationship betwen the receiver and the node that has > performed the verification and synthesis, this should do it. Well, yes, but there are an awful lot of ifs in the above. Certainly more than are appropriate for the original MUST requirement. > In particular, if everything happens at the end node, we are in > business, right? (i.e. the v6 end node asks for the A RR, perfomrs > the dnssec validation and then internally generates the v6 address) Ahem. If the end node is doing this, why isn't it just doing dual stack? After all, it (or rather the embedded translator) is sending out IPv4... > it is not so trivial for the v4 case though (actually i think it is not > possible for the v4 case, hence the question mark) In other words, the MUST needs some serious scoping. If it makes sense at all. I'm still not sure this requirement is acheivable in practice. So I'm not at all sure it is appropriate to make it a MUST, at least not without a lot more text explaining what is meant. Thomas From owner-v6ops@ops.ietf.org Thu Jul 24 00:52:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E98C3A69B3 for ; Thu, 24 Jul 2008 00:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrzCJVIheU1q for ; Thu, 24 Jul 2008 00:52:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29E423A697C for ; Thu, 24 Jul 2008 00:52:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLvbV-000NGd-TM for v6ops-data@psg.com; Thu, 24 Jul 2008 07:51:13 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLvbS-000NGO-6K for v6ops@ops.ietf.org; Thu, 24 Jul 2008 07:51:12 +0000 Received: (qmail 14406 invoked by uid 509); 24 Jul 2008 07:44:28 -0000 Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.3/7809. spamassassin: 3.2.5. Clear:RC:1(211.28.128.246):. Processed in 0.04434 secs); 24 Jul 2008 07:44:28 -0000 Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246) by 0 with SMTP; Thu, 24 Jul 2008 02:44:28 -0500 Cc: v6ops WG Message-Id: <50091C86-8E3E-441F-B721-5CEE07A53ECD@thetiger.com> From: David Miles To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Thu, 24 Jul 2008 17:44:23 +1000 References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > > Some comments on draft-02: > - The un-numbered model doesn't require a loopback interface > > > It does. You may be behind checking your emails on this thread. > Please > read ample evidence given for this one. > > When Shin was pointing out the considerations for a loopback, Francois- Xavier noted: "When the CPE router has only a link-local address on the WAN port, if the CPE has a LAN bridge, I hope there is an option to have the global- scope address set on the LAN bridge (from IA_PD via DHCPv6) as an alternative to loopback solution." Between Shin, Francois-Xavier, Ole and others it seemed there was an appreciation that loopbacks were not required to support the unnumbered model - best summarised in Shin's email on 3 July. (I'm not suggesting everyone thought the unnumbered model was preferred, but that there was no technical obstacle). RFC 3484 says: It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. This seems to hit the nail on the head - we are describing a router that MAY use a unicast address assigned to any interface (LAN) subject to the restrictions in RFC 3484 (which do not pose any problem in my interpretation). I initially raised the use of a loopback as an option because I was concerned about LAN interface state (and said so in the original thread). If the LAN interface is a bridge (always up) I see no mandatory need for a loopback. I would urge continued discussion in- list if there are technical arguments against a un-numbered model without loopback. The two points raised in favour of such an option are that : it avoids an additional /64 for the loopback, and; caters to CPE that may not support a loopback interface (may need to be qualified). IE (a reference for a routing CPE with internal MAC bridge): +------------------------+ | Routing CPE w/ bridge | | +------+ +------+ | Port1-|-| | | | | | |Bridge|-----|Router|--|----WAN Port2-|-| | LAN| | | | +------+ +------+ | +------------------------+ LAN is connected to a bridge device so it is always up. Addresses: WAN: fe80::%wan prefixlen 64 LAN: 2001:db8:0:1:: prefixlen 64 (example) fe80::%lan prefixlen 64 From owner-v6ops@ops.ietf.org Thu Jul 24 00:53:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B098B3A6902 for ; Thu, 24 Jul 2008 00:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMmUrit8CxDu for ; Thu, 24 Jul 2008 00:53:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C62B23A697C for ; Thu, 24 Jul 2008 00:53:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLvZe-000Mlr-Q0 for v6ops-data@psg.com; Thu, 24 Jul 2008 07:49:18 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLvZa-000MlW-Nu for v6ops@ops.ietf.org; Thu, 24 Jul 2008 07:49:16 +0000 Received: from marcelo-bagnulos-macbook-pro.local (129.pool85-53-131.dynamic.orange.es [85.53.131.129])by smtp03.uc3m.es (Postfix) with ESMTP id 16F88497145;Thu, 24 Jul 2008 09:49:12 +0200 (CEST) Message-ID: <488833F7.7030606@it.uc3m.es> Date: Thu, 24 Jul 2008 09:49:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> In-Reply-To: <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-11.0335 TC:1F TRN:43 TV:5.5.1026(16050.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > marcelo bagnulo braun writes: > > >> if the verification is performed before the synthesis of the RR and >> there is a trsut relationship betwen the receiver and the node that has >> performed the verification and synthesis, this should do it. >> > > Well, yes, but there are an awful lot of ifs in the above. Certainly > more than are appropriate for the original MUST requirement. > > but what i was describing here is a solution the describe that this is possible and so it makes sense to keep the requirement there may be other solutions that also satisfy the requirement, >> In particular, if everything happens at the end node, we are in >> business, right? (i.e. the v6 end node asks for the A RR, perfomrs >> the dnssec validation and then internally generates the v6 address) >> > > Ahem. If the end node is doing this, why isn't it just doing dual > stack? After all, it (or rather the embedded translator) is sending > out IPv4... > cause the main scenario that we are targeting here is the case where the source node has no v4 address configured in its stack, so it cannot send v4 packets. > >> it is not so trivial for the v4 case though (actually i think it is not >> possible for the v4 case, hence the question mark) >> > > In other words, the MUST needs some serious scoping. If it makes > sense at all. > > I'm still not sure this requirement is acheivable in practice. my take is that this is possible to achieve for v6 initiated communications (i.e. when AAAA RR are synthesized) I don't think that it is achievable for v4 initiated communications (i.e. when A RR are synthesized) I am lately thinking that we need two different lists of requirements one for v4 initiated communications and another one for v6 initiated communications especially for dealing with dns requirements. In v4 initiated communications the state in the nat box has close relationship with the RR synthesis, while in v6 initiated communication they are completely decoupled, which makes possible to satisfy most of the dns requirements. so, what do you think? regards, marcelo > So I'm > not at all sure it is appropriate to make it a MUST, at least not > without a lot more text explaining what is meant. > > Thomas > > From owner-v6ops@ops.ietf.org Thu Jul 24 01:27:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED06C3A6902 for ; Thu, 24 Jul 2008 01:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG+6kVNAw6bq for ; Thu, 24 Jul 2008 01:27:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 135B63A68DE for ; Thu, 24 Jul 2008 01:27:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLw9J-0005ql-8X for v6ops-data@psg.com; Thu, 24 Jul 2008 08:26:09 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLw9F-0005qM-2U for v6ops@ops.ietf.org; Thu, 24 Jul 2008 08:26:06 +0000 Received: from marcelo-bagnulos-macbook-pro.local (129.pool85-53-131.dynamic.orange.es [85.53.131.129])by smtp03.uc3m.es (Postfix) with ESMTP id B08F849715B;Thu, 24 Jul 2008 09:42:33 +0200 (CEST) Message-ID: <48883269.9020204@it.uc3m.es> Date: Thu, 24 Jul 2008 09:42:33 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: IPsec requirement References: <200807222122.m6MLMgEE010033@cichlid.raleigh.ibm.com> <48873AF6.80303@it.uc3m.es> <200807232017.m6NKHT6R004772@cichlid.raleigh.ibm.com> In-Reply-To: <200807232017.m6NKHT6R004772@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.6445 TC:1F TRN:39 TV:5.5.1026(16050.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > marcelo bagnulo braun writes: > > >> i think so, i have changed that to >> > > >> The translator MUST support communication between IPv4 node and IPv6 >> node using UDP Encapsulation of IKE and IPsec ESP Packets as defined in >> [RFC3948] as applicable. RFC3948 should be interpreted as with the >> IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of >> the conventional NAT. IPsec support MAY require updating also the >> IPv4 side. >> > > >> would that be better? >> > > Yes, but... > > Question: Why was UDP encapsulation chosen? Should we even have that > requirement at this point? more background the point made in the previous meeting was that this must provide at least the same functionality than current v4 nats, and that is what nats currently support as defined in rfc3948, hence the wording, but i certainly agree that what you write below is what we want to say, so i will change this to your wording in the document if nobody opposes one more question, people have asked me explicitly to have the reference to 3948, do you think we should keep that somehow is we can drop it? > Seems to me that the requirement should be > more like: > > The translator MUST be able to support the translation of at least > one mode of IPsec and IKE flows sufficient to allow nodes using IKE > and IPsec to successfully set up and use IPsec SAs. Although > desirable, it is not a requirement that such a capability be done > with no changes to the IPv4 node's IKE/IPsec implementation. > > Thoughts? > > Thomas > > From owner-v6ops@ops.ietf.org Thu Jul 24 03:37:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3F43A67A4 for ; Thu, 24 Jul 2008 03:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-1.691, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj0YAI+tZQWQ for ; Thu, 24 Jul 2008 03:37:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C7ED3A659B for ; Thu, 24 Jul 2008 03:37:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLy9K-000B40-UQ for v6ops-data@psg.com; Thu, 24 Jul 2008 10:34:18 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLy9H-000B1q-5h for v6ops@ops.ietf.org; Thu, 24 Jul 2008 10:34:17 +0000 Received: (qmail 11277 invoked by uid 417); 24 Jul 2008 10:33:40 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 24 Jul 2008 10:33:40 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 24 Jul 2008 04:33:40 -0600 References: <200807231917.02629.rdenis@simphalempin.com> In-Reply-To: <200807231917.02629.rdenis@simphalempin.com> From: EricLKlein@softhome.net To: "=?iso-8859-1?Q?R=E9mi?= Denis-Courmont" Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Thu, 24 Jul 2008 04:33:40 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Denis-Courmont writes: >> > >> > From a security perspective, what is the difference between: >> > >> > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a >> > similar range, asking people to configure it using http://[10.0.0.1] >> > B) the same thing using link local address, with the router being >> > configured using fe80::1 and asking people to configure it using >> > http://[fe80::1] C) the same replacing link local by ULA > >> Your example B is exactly what I am suggesting, a it is identical to A in >> an IPV6 world. > > As already pointed out in this same thread, link-local addresses do NOT work > in most web browsers, as you need to know which local interface to use - not > suited at all within a for-dummies installation guide. > > ULAs will not fit the bill either because the prefix ought to be > pseudo-random, and different for each and every shipped box. > > GUAs do not fit as they also depend on the customer, and by definition, are > not available until the CPE has been successfully configured. > > Site-local addresses would have worked, but they're now deprecated. > > Multicast service discovery does not work because it is not implemented with > current hosts - if we specify if now, it will be years before it can be used. > > So... you're stuck instructing the customer to use the constant IPv4 address. > That works today and will continue to work for the foreseeable future of > dual-stack hosts on unmanaged networks. > I agree with your assessment here. > As much as I believe the CPE ought to provision a permament ULA prefix, I also > believe the initial configuration argument is completely bogus. > > Bogus or not, this seems to be one of the problems that was being addressed by this draft. We need to look at 2 things: 1. What is the problem being pointed out and what solutions are available to fix it? 2. Is this a big enough problem to be worth our time in addressing. You seem to have done a good job on number 1, now the WG needs to decided on number 2. From owner-v6ops@ops.ietf.org Thu Jul 24 03:58:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AD03A69E7 for ; Thu, 24 Jul 2008 03:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev0LRXpJlJSN for ; Thu, 24 Jul 2008 03:58:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1587C3A692C for ; Thu, 24 Jul 2008 03:58:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLyUw-000FGA-FL for v6ops-data@psg.com; Thu, 24 Jul 2008 10:56:38 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLyUs-000FFl-KS for v6ops@ops.ietf.org; Thu, 24 Jul 2008 10:56:36 +0000 Received: (qmail 5407 invoked by uid 417); 24 Jul 2008 10:29:24 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 24 Jul 2008 10:29:24 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Thu, 24 Jul 2008 04:29:24 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Thu, 24 Jul 2008 04:29:24 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand writes: > On 7/23/08 11:31 AM, "EricLKlein@softhome.net" > wrote: > >> D sounds like a problem to me as you don't want to advertise a "come >> configure me" service. This is the one I am most against in my previous >> e-mail. > > Why? I fail to see any more problems with this than with the other > approaches. > Having a known address is not the same as advertising it out to anyone that is locally connected. Admittedly it is only a short term improvement until the fixed address becomes commonly known via the internet, but even then it is only a problem if someone comes to the area of a wireless network where the security has not been changed from the default. Consider the situation as follows: Person x goes and buys a WiFI router to connect to their DSL link. But prior to connecting to the DSL they plug it in to configure it. The only way that someone would know to try to configure it would be to see it in their available networks and then recognize the brand and to try to connect to the default IP address. Vs. Someone sees a new hotspot advertising a "come configure me" service. In the first case you need to proactivly go looking for things to hack, in the second you are invited in to do so. Maybe I am alone on this, but I prefer to make the hacker try harder without inviting them inside. Eric From owner-v6ops@ops.ietf.org Thu Jul 24 04:25:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC6E3A6A37 for ; Thu, 24 Jul 2008 04:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.824 X-Spam-Level: ** X-Spam-Status: No, score=2.824 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8yrbAV8qTLq for ; Thu, 24 Jul 2008 04:25:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A4263A6A46 for ; Thu, 24 Jul 2008 04:25:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLyw4-000Kem-D8 for v6ops-data@psg.com; Thu, 24 Jul 2008 11:24:40 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLyw0-000KZu-4o for v6ops@ops.ietf.org; Thu, 24 Jul 2008 11:24:38 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9039624; Thu, 24 Jul 2008 07:24:03 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 07:24:03 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Jul 2008 11:23:23 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 24 Jul 2008 07:23:22 -0400 Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review From: Alain Durand To: CC: Message-ID: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjteEMDYrg89pdyS0CsyA0VwMytfgAB2s4k In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jul 2008 11:24:03.0909 (UTC) FILETIME=[C738FF50:01C8ED7F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/24/08 6:29 AM, "EricLKlein@softhome.net" wrote: > Having a known address is not the same as advertising it out to anyone that > is locally connected. Admittedly it is only a short term improvement until > the fixed address becomes commonly known via the internet, but even then it > is only a problem if someone comes to the area of a wireless network where > the security has not been changed from the default. > > Consider the situation as follows: > Person x goes and buys a WiFI router to connect to their DSL link. But prior > to connecting to the DSL they plug it in to configure it. The only way that > someone would know to try to configure it would be to see it in their > available networks and then recognize the brand and to try to connect to the > default IP address. Vs. Someone sees a new hotspot advertising a "come > configure me" service. In the first case you need to proactivly go looking > for things to hack, in the second you are invited in to do so. > > Maybe I am alone on this, but I prefer to make the hacker try harder without > inviting them inside. Eric, The property of well known address is that, well, they are well known. So if a vendor start to use fe80::1, I guess most vendors will use it and there is little guesswork to be done. Now, with service discovery, I would expect that as soon as the device is configured the first time, some king of security will be put in place, if only using a password. This can be done before the ISP connection is up. If the user decide not to use a passwd or any other form of security, well, this is a different issue. I have seen this discovery being implemented already: simply try to configure an Apple airport. - Alain. From owner-v6ops@ops.ietf.org Thu Jul 24 04:51:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDA23A6957 for ; Thu, 24 Jul 2008 04:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PArRrCYdRmy for ; Thu, 24 Jul 2008 04:51:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E971F3A67FA for ; Thu, 24 Jul 2008 04:51:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLzKc-000PnH-Qj for v6ops-data@psg.com; Thu, 24 Jul 2008 11:50:02 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLzKY-000PmV-RJ for v6ops@ops.ietf.org; Thu, 24 Jul 2008 11:50:00 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id 5161C250; Thu, 24 Jul 2008 13:49:57 +0200 (CEST) To: dthaler@microsoft.com, suresh.krishnan@ericsson.com, Jim_Hoagland@symantec.com, v6ops@ops.ietf.org Subject: Comments on draft-krishnan-v6ops-teredo-update-03 MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:49:57 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net Message-ID: <2a8b27f3a973059d422e7a6e1c42d8d7@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, The last paragraph in section 3.2 says "clients SHOULD ignore the cone bit". Should this not apply not only to clients but also to relays? And should servers stop replying to cone bit requests in an attempt to force legacy clients into not using it? (I guess not) Section 4 says "Teredo is NOT RECOMMENDED as a solution for managed networks.". "NOT RECOMMENDED" is not an RFC2119 keyword. I guess it should be all lowercase. Or it should be replaced with a stronger statement: "Teredo SHOULD NOT be used within managed networks" ? Regards, -- RĂ©mi Denis-Courmont From owner-v6ops@ops.ietf.org Thu Jul 24 08:07:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD8B3A694F for ; Thu, 24 Jul 2008 08:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.323 X-Spam-Level: X-Spam-Status: No, score=-4.323 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z9qwFt4xbWK for ; Thu, 24 Jul 2008 08:07:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB9243A687C for ; Thu, 24 Jul 2008 08:07:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM2Lb-000DtC-LF for v6ops-data@psg.com; Thu, 24 Jul 2008 15:03:15 +0000 Received: from [128.18.84.114] (helo=mailgate-internal4.sri.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM2LX-000Dsk-KE for v6ops@ops.ietf.org; Thu, 24 Jul 2008 15:03:13 +0000 Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 24 Jul 2008 14:56:31 -0000 X-AuditID: 80125474-ae133bb000000a5e-c5-4888981f805f Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id 10BE41B2501 for ; Thu, 24 Jul 2008 07:56:31 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4I00DKVMU5XFQ0@mail.sri.com> for v6ops@ops.ietf.org; Thu, 24 Jul 2008 07:56:31 -0700 (PDT) Date: Thu, 24 Jul 2008 10:56:29 -0400 From: Ed Jankiewicz Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title In-reply-to: <488833F7.7030606@it.uc3m.es> To: marcelo bagnulo braun Cc: Thomas Narten , v6ops@ops.ietf.org, =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Message-id: <4888981D.5090701@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: commenting to foster discussion in particular about the title and scope of the problem statement/requirement draft. this has come up in other comments as well, in particular Rémi on 7/23. It seems to me the problem statement needs to be general: need for translation at some point in the network; the current title includes NAT64, which already makes some assumptions about solution approach. I would rather see the problem statement (and title) generalized. I like Rémi's suggestion of "IPv4/IPv6 Coexistence Scenarios - Requirements for Translation Mechanisms." On the other hand, the requirements section of this draft would be a good place to start distinguishing among the solution approaches. Rather than spinning off separate documents (which we could always do at some future point) a sub-section for NAT64 specific requirements and another for NAT46 (at least) would be appropriate, and avoid duplication of general requirements that apply to both. As it is there are already a lot of solution drafts circulating, and being discussed in too many places (behave, v6ops and intarea) to keep up. I'm not complaining about the attention it is finally getting, because I strongly believe v4-v6 coexistence tools is a really big hurdle we need to clear, but I would like us to maintain focus on defining the problem and general requirements, and this draft seems to be the right place to do that. I am assuming that NAT64=="v6 initiated communication" and NAT46=="v4 initiated communication". However a translator is built, it would have to be cognizant of particular requirements depending on which side initiates. Restricting it to one or the other simplifies the problem, but this draft would not rule out an implementation that meets both. I think Thomas's point that one set of requirements would need a lot of scoping language (do X if v6 initiated but X' if v4...) which would be easier to handle in two separate lists tailored to each. Vertical rather than horizontal slicing... edj marcelo bagnulo braun wrote: > Thomas Narten escribió: >> >>> it is not so trivial for the v4 case though (actually i think it is >>> not possible for the v4 case, hence the question mark) >>> >> >> In other words, the MUST needs some serious scoping. If it makes >> sense at all. >> >> I'm still not sure this requirement is acheivable in practice. > my take is that this is possible to achieve for v6 initiated > communications (i.e. when AAAA RR are synthesized) > I don't think that it is achievable for v4 initiated communications > (i.e. when A RR are synthesized) > > I am lately thinking that we need two different lists of requirements > one for v4 initiated communications and another one for v6 initiated > communications especially for dealing with dns requirements. In v4 > initiated communications the state in the nat box has close > relationship with the RR synthesis, while in v6 initiated > communication they are completely decoupled, which makes possible to > satisfy most of the dns requirements. > > so, what do you think? > > regards, marcelo > > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From owner-v6ops@ops.ietf.org Thu Jul 24 13:11:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1752928C12D for ; Thu, 24 Jul 2008 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-1.672, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfP0Agh5e6Cc for ; Thu, 24 Jul 2008 13:11:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4E2B28C0EB for ; Thu, 24 Jul 2008 13:11:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM75V-000PvT-8C for v6ops-data@psg.com; Thu, 24 Jul 2008 20:06:57 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM75R-000Pv5-AD for v6ops@ops.ietf.org; Thu, 24 Jul 2008 20:06:55 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-203.messagelabs.com!1216929987!27711454!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 11297 invoked from network); 24 Jul 2008 20:06:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-4.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 24 Jul 2008 20:06:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6OK6nrM007141; Thu, 24 Jul 2008 16:06:50 -0400 Received: from 01GAF5142010622.AD.BLS.COM ([139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6OK4ZCF000999; Thu, 24 Jul 2008 16:06:45 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jul 2008 16:06:35 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jul 2008 16:06:34 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Thu, 24 Jul 2008 16:06:33 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review thread-index: AcjteEMDYrg89pdyS0CsyA0VwMytfgAB2s4kABFBB+A= References: From: "Stark, Barbara" To: "Alain Durand" , CC: X-OriginalArrivalTime: 24 Jul 2008 20:06:34.0965 (UTC) FILETIME=[C5E88050:01C8EDC8] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'd rather the IETF didn't try to mandate some specific well-known address for routers, or a service discovery protocol. Personally, since I "play" with so many different home routers from different manufacturers, I don't bother trying any well-known address to get to the UI. I can't remember who uses what. And I hate reading the manual. There are so many different values in use, that I find it easier to just run ipconfig / ifconfig and see what my Default Gateway is set to. Put that in the browser, and I'm at the router UI.=20 I do know that if a device has a DSL modem in it, then it is likely to support the standard domain name specified by the Broadband Forum (formerly DSL Forum): dsldevice I expect that to continue. If there is to be some sort of discovery and then presenting the results to the user in a friendly manner, then there will need to be an application that does all this. If there's an application, it probably doesn't care where the info comes from. Surely somewhere between all the ND and RA and such, there must be an IPv6 address that can lead an application to the router, without trying to mandate or recommend support for some service discovery protocol. I don't need for a device to advertise that it has an HTTP server at port 80 on a particular IP address. I just need the device's IP address.=20 Barbara -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alain Durand Sent: Thursday, July 24, 2008 7:23 AM To: EricLKlein@softhome.net Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review On 7/24/08 6:29 AM, "EricLKlein@softhome.net" wrote: > Having a known address is not the same as advertising it out to anyone that > is locally connected. Admittedly it is only a short term improvement until > the fixed address becomes commonly known via the internet, but even then it > is only a problem if someone comes to the area of a wireless network where > the security has not been changed from the default. >=20 > Consider the situation as follows: > Person x goes and buys a WiFI router to connect to their DSL link. But prior > to connecting to the DSL they plug it in to configure it. The only way that > someone would know to try to configure it would be to see it in their > available networks and then recognize the brand and to try to connect to the > default IP address. Vs. Someone sees a new hotspot advertising a "come > configure me" service. In the first case you need to proactivly go looking > for things to hack, in the second you are invited in to do so. >=20 > Maybe I am alone on this, but I prefer to make the hacker try harder without > inviting them inside. Eric, The property of well known address is that, well, they are well known. So if a vendor start to use fe80::1, I guess most vendors will use it and there is little guesswork to be done. Now, with service discovery, I would expect that as soon as the device is configured the first time, some king of security will be put in place, if only using a password. This can be done before the ISP connection is up. If the user decide not to use a passwd or any other form of security, well, this is a different issue. I have seen this discovery being implemented already: simply try to configure an Apple airport. - Alain. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 From owner-v6ops@ops.ietf.org Fri Jul 25 02:28:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4FE3A698F for ; Fri, 25 Jul 2008 02:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uShpejXwxPl for ; Fri, 25 Jul 2008 02:28:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B75273A69DF for ; Fri, 25 Jul 2008 02:28:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMJW0-0001iM-Nq for v6ops-data@psg.com; Fri, 25 Jul 2008 09:23:08 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMJVw-0001hv-Jx for v6ops@ops.ietf.org; Fri, 25 Jul 2008 09:23:06 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp02.uc3m.es (Postfix) with ESMTP id B9CEB424BC1;Fri, 25 Jul 2008 11:10:32 +0200 (CEST) Message-ID: <48899888.9060006@it.uc3m.es> Date: Fri, 25 Jul 2008 11:10:32 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ed Jankiewicz CC: Thomas Narten , v6ops@ops.ietf.org, =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> In-Reply-To: <4888981D.5090701@sri.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.6005 TC:1F TRN:55 TV:5.5.1026(16052.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ed Jankiewicz escribió: > commenting to foster discussion in particular about the title and > scope of the problem statement/requirement draft. this has come up in > other comments as well, in particular Rémi on 7/23. > > It seems to me the problem statement needs to be general: need for > translation at some point in the network; the current title includes > NAT64, which already makes some assumptions about solution approach. > I would rather see the problem statement (and title) generalized. I > like Rémi's suggestion of "IPv4/IPv6 Coexistence Scenarios - > Requirements for Translation Mechanisms." will do then > > On the other hand, the requirements section of this draft would be a > good place to start distinguishing among the solution approaches. > Rather than spinning off separate documents (which we could always do > at some future point) a sub-section for NAT64 specific requirements > and another for NAT46 (at least) would be appropriate, and avoid > duplication of general requirements that apply to both. i will do a proposal for this in the ml and see what people think > As it is there are already a lot of solution drafts circulating, and > being discussed in too many places (behave, v6ops and intarea) to keep > up. I'm not complaining about the attention it is finally getting, > because I strongly believe v4-v6 coexistence tools is a really big > hurdle we need to clear, but I would like us to maintain focus on > defining the problem and general requirements, and this draft seems to > be the right place to do that. > > I am assuming that NAT64=="v6 initiated communication" and NAT46=="v4 > initiated communication". mmm, i think the term has evolved initially, i think that nat64 meant a new version of natpt but now we make a distinction between nat64 and nat46 as you say we could expliclty state it this way in the document if you think so > However a translator is built, it would have to be cognizant of > particular requirements depending on which side initiates. > Restricting it to one or the other simplifies the problem, but this > draft would not rule out an implementation that meets both. I think > Thomas's point that one set of requirements would need a lot of > scoping language (do X if v6 initiated but X' if v4...) which would be > easier to handle in two separate lists tailored to each. Vertical > rather than horizontal slicing... > ok, let me try to come up with something regards, marcelo > edj > > marcelo bagnulo braun wrote: >> Thomas Narten escribió: >>> >>>> it is not so trivial for the v4 case though (actually i think it is >>>> not possible for the v4 case, hence the question mark) >>>> >>> >>> In other words, the MUST needs some serious scoping. If it makes >>> sense at all. >>> >>> I'm still not sure this requirement is acheivable in practice. >> my take is that this is possible to achieve for v6 initiated >> communications (i.e. when AAAA RR are synthesized) >> I don't think that it is achievable for v4 initiated communications >> (i.e. when A RR are synthesized) >> >> I am lately thinking that we need two different lists of requirements >> one for v4 initiated communications and another one for v6 initiated >> communications especially for dealing with dns requirements. In v4 >> initiated communications the state in the nat box has close >> relationship with the RR synthesis, while in v6 initiated >> communication they are completely decoupled, which makes possible to >> satisfy most of the dns requirements. >> >> so, what do you think? >> >> regards, marcelo >> >> >> > From owner-v6ops@ops.ietf.org Fri Jul 25 05:19:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6A93A6AB7 for ; Fri, 25 Jul 2008 05:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3rgPi6gJ1Y7 for ; Fri, 25 Jul 2008 05:18:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BBBF3A6AAD for ; Fri, 25 Jul 2008 05:18:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMMD0-0009HL-Nd for v6ops-data@psg.com; Fri, 25 Jul 2008 12:15:42 +0000 Received: from [32.97.110.153] (helo=e35.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMMCx-0009Gm-2F for v6ops@ops.ietf.org; Fri, 25 Jul 2008 12:15:40 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6PCF9Z3016745 for ; Fri, 25 Jul 2008 08:15:09 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6PCF8cm161466 for ; Fri, 25 Jul 2008 06:15:08 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6PCF8gl023177 for ; Fri, 25 Jul 2008 06:15:08 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PCF6uT023112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 06:15:07 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6PCF4d1017179; Fri, 25 Jul 2008 08:15:05 -0400 Message-Id: <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun cc: Ed Jankiewicz , v6ops@ops.ietf.org, =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title In-reply-to: <48899888.9060006@it.uc3m.es> References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> <48899888.9060006@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Fri, 25 Jul 2008 11:10:32 +0200." Date: Fri, 25 Jul 2008 08:15:04 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun writes: > > I am assuming that NAT64=="v6 initiated communication" and NAT46=="v4 > > initiated communication". > mmm, i think the term has evolved > initially, i think that nat64 meant a new version of natpt but now we > make a distinction between nat64 and nat46 as you say > we could expliclty state it this way in the document if you think so Yes. Clarity is good. Thomas From owner-v6ops@ops.ietf.org Fri Jul 25 08:00:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D57828C1E5 for ; Fri, 25 Jul 2008 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUyoDsGobCFN for ; Fri, 25 Jul 2008 08:00:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05CEE3A69F3 for ; Fri, 25 Jul 2008 08:00:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMOiK-0002oA-GA for v6ops-data@psg.com; Fri, 25 Jul 2008 14:56:12 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMOiF-0002nT-Bo for v6ops@ops.ietf.org; Fri, 25 Jul 2008 14:56:10 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id EBDD649AE54;Fri, 25 Jul 2008 16:22:05 +0200 (CEST) Message-ID: <4889E18D.5060600@it.uc3m.es> Date: Fri, 25 Jul 2008 16:22:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> In-Reply-To: <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.5172 TC:1F TRN:79 TV:5.5.1026(16052.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten escribió: > marcelo bagnulo braun writes: > > >> Thomas Narten escribiĂ³: >> >>> marcelo bagnulo braun writes: >>> >>> >>> >>>> if the verification is performed before the synthesis of the RR and >>>> there is a trsut relationship betwen the receiver and the node that has >>>> performed the verification and synthesis, this should do it. >>>> >>>> >>> Well, yes, but there are an awful lot of ifs in the above. Certainly >>> more than are appropriate for the original MUST requirement. >>> >>> >>> >> but what i was describing here is a solution the describe that this is >> possible and so it makes sense to keep the requirement >> there may be other solutions that also satisfy the requirement, >> > > Sorry, but no. if you have a simple MUST as a requirement, you can't > have the solution involve a bunch of ifs that will not be true in > general, and/or that change the meaning of meeting the requirement. > > DNSSEC is about e2e security. The recipient of the data (the DNS > querier), using DNSSEC, is able to verify that the data has not been > modified. This is no longer true in the solution outline you proposed > above. > How is that? Suppose we have node H6 that is a v6 only node. Suppose that node H6 wants to perform DNSSec validation Suppose that it wants to initiate a communication with a node H4 that is v4 only Suppose that node H6 makes a AAAA RR query for H4 and gets nothing and then it makes a A RR query and gets an IPv4 address. Upon the recpetion of the A RR, it also obtains DNSec information to validate the A RR. Node H6 then performs the DNSsec validation and then translates the H4 address into an IPv6 address by prepending a /96 prefix. Node H6 then sends IPv6 packet towards H4 which are translated into IPv4 in a nat64 box soemwhere along the way AFAIU, in this approach, DNSSec validation works e2e and we can state that this solution fulfills the proposed requirement to keep DNSSec working. However, i don't think it is possible to make dnssec to work in the opposite direction, where the initiator is a v4 node. Hence my suggestion to separate the v4 intiiated communication requirements from the v6 intiiated communication requirement. (If what you are saying is that we cannot find a solution that would dnssec work for v4 initiated communications and that should be removed, i certianly agree) In any case, many people expressed that a nat64 mechanism should not prevent dnssec from working (it is also true that these same people also expressed that for them having v4 intiiated communications was not a requirement) The requirement contained in the draft is an attempt to express that I am all for rewriting it in a better way, do you have any suggestion? > Hence, the requirement needs to significantly expanded upon and/or > clarified. Otherwise, people will assume it means X, when others > assume it actually means Y. > > > right, again, my proposal is to split the reqs one for v4 initiated and another list for v6 initiated, do you think this would do it? other proposal for text? >>>> In particular, if everything happens at the end node, we are in >>>> business, right? (i.e. the v6 end node asks for the A RR, perfomrs >>>> the dnssec validation and then internally generates the v6 address) >>>> >>>> >>> Ahem. If the end node is doing this, why isn't it just doing dual >>> stack? After all, it (or rather the embedded translator) is sending >>> out IPv4... >>> >>> >> cause the main scenario that we are targeting here is the case where the >> source node has no v4 address configured in its stack, so it cannot send >> v4 packets. >> > > What exactly is the difference between a node that has no IPv4 address > configured (so that it can not just use dual stack) and that same node > with an embedded translator attached to it that does send out IPv4 > (after translation - and hence, has to have an IPv4 address > configured)? mmm, this is not what i described What i described is a v6 node that locally generates the v6 address that maps the v4 address locally, but still sends only v6 packets. The translation of packets is done on a different box > From what I can see, in both cases the node has an IPv4 > addresss and the directly attached network is IPv4 enabled. In that > case, dual-stack seems like the obvious thing to use. I certainly > wouldn't think a translater is needed here... > i think we are talking about different cases here. I hope my description of what i had in mind above makes things clearer > >> I am lately thinking that we need two different lists of requirements >> one for v4 initiated communications and another one for v6 initiated >> communications especially for dealing with dns requirements. In v4 >> initiated communications the state in the nat box has close relationship >> with the RR synthesis, while in v6 initiated communication they are >> completely decoupled, which makes possible to satisfy most of the dns >> requirements. >> > > If the requirements are different in the two directions, then yes, two > separate requirments are needed. You can't have a general requirement > (that implicitely implies a solution in both directions) when a > solution in one direction can't be made to work. > that is what i think, but i would like to see if people agree with me. For me the requirement that cannot be meet in the 46 direction (and that can be meet in the 64 direction) are those related to DNS. In particular, DNSSec cannot work with 46 direction and R4: DNS semantics preservation Any modifications to DNS responses associated with translation MUST NOT violate standard DNS semantics. This includes in particular that a DNS response (that has been modified by the translator mechanism) should not be invalid if it ends up in the wrong context, i.e. traversing a non expected part of the topology. can't work neither cause the dns responses in the 46 cases are very context dependent cause the dns response contains the information associated to the nat46 state regards, marcelo PS: i am planning to send a mail describing the changes of the two req list in a moment > Thomas > > From owner-v6ops@ops.ietf.org Fri Jul 25 08:03:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1FB28C1E7 for ; Fri, 25 Jul 2008 08:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDh7P2b0ECze for ; Fri, 25 Jul 2008 08:03:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 583CC28C1F2 for ; Fri, 25 Jul 2008 08:03:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMOp6-0003S0-2o for v6ops-data@psg.com; Fri, 25 Jul 2008 15:03:12 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMOp1-0003Rc-Rd for v6ops@ops.ietf.org; Fri, 25 Jul 2008 15:03:10 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp02.uc3m.es (Postfix) with ESMTP id E3A57424C53;Fri, 25 Jul 2008 16:48:15 +0200 (CEST) Message-ID: <4889E7AF.6080903@it.uc3m.es> Date: Fri, 25 Jul 2008 16:48:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "teemu.savolainen@nokia.com" , 'IPv6 Operations' Subject: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.9155 TC:1F TRN:34 TV:5.5.1026(16052.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Teemu, I am trying to intergrate the text you proposed to the draft draft-ietf-v6ops-nat64-pb-statement-req-01 the last text we come up with was: to add a new scenario: o a dual stack system connected to a IPv6 domain that is connecting to an IPv4 system. and to add new text in the tunnel section: Another scenario that does not involves translation is the case where a dual stack node is connected to an IPv6-only domain and it is communicating with a IPv4-only node as depicted in Figure 2. ,-----. ,-----. ,' `. ,' `. / \ / \ / IPv6-only \ / IPv4-only \ / Domain +-----------+ Domain \ ; | Tunnel | : | | endpoint | | : +-----+ +-----------+ ; \ |Dual | / \ +----+ / \ |Stack| / \ |IPv4| / \ |Host | / \ |Host| / `.+-----+,' `. +----+,' '-----' '-----' Figure 2: Dual stack with IPv4 application in IPv6 domain In this case, the dual stack host needs to establish a IPv4 in IPv6 tunnel to the tunnel endpoint. In addition to that, the dual stack needs to obtain a IPv4 address that is valid in the IPv4-only domain. The simplest option is for the dual stack to obtain an IPv4 public address. However, this may not be possible due to the shortage of IPv4 public addresses. The other option is to use an IPv4 private address (and potentially in conjunction with IPv4 NAT). The other option is for the dual stack to obtain one or more public IPv4 transport addresses. In all the cases, the acquisition of the address can be performed dynamically. the problem that i find is that the scenario described above is simply too broad to what we mean here. I think that something you mentioned in your original mail got lost in the way, basically that this scenario is about dual stack hosts running v4 only apps that are nat aware, that is the main reason why you need them to learn the v4 public address. Dan mentioned that for instance bittorrent is in this situation. So, i think we need to express this somehow. I think that the scenario that we are handling now is o a dual stack system with a NAT-aware IPv4-only application connected to a IPv6 domain that is connecting to an IPv4 system. Now, i am wondering if this is not a bit too far off the simple scenario Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 08:27:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D783A6AF3 for ; Fri, 25 Jul 2008 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6arXazfkq4u4 for ; Fri, 25 Jul 2008 08:27:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3047A28C0DF for ; Fri, 25 Jul 2008 08:27:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMP8R-0005Rl-Aa for v6ops-data@psg.com; Fri, 25 Jul 2008 15:23:11 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMP8N-0005R4-EK for v6ops@ops.ietf.org; Fri, 25 Jul 2008 15:23:09 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp02.uc3m.es (Postfix) with ESMTP id CD21B4251ED;Fri, 25 Jul 2008 17:01:38 +0200 (CEST) Message-ID: <4889EAD2.8060809@it.uc3m.es> Date: Fri, 25 Jul 2008 17:01:38 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jari Arkko , Dave Thaler , 'IPv6 Operations' , Brian E Carpenter Subject: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.6575 TC:1F TRN:25 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, both Jari and Dave have expressed during email exchanges that unmodified dual stack hosts must work well WITHOUT requiring modifications. In particular, they expressed that a dual stack host must be able to distinguish between the transalted connectivity and the native connectivity allowing them to avoid translated connectivity hence avoiding failures in apps that don't work through nats. However, in the current req doc (draft-ietf-v6ops-nat64-pb-statement-req-00) it is stated that: R1: Changes in the hosts The translation mechanism MUST NOT require changes in the v4-only nodes to support the Basic requirements described in this section, unless explicitly stated in the particular requirement. The translation mechanism MAY require changes to v6-only nodes. In the list of basic requirements there is another requirement: R3: Interaction with dual-stack hosts Translation mechanism MUST allow using native connectivity when it is available. This means that if a v6-only nodes wants to communicate with a dual stack, it must use native v6 connectivity and if a v4- only nodes wants to communicate with a dual stack, it must use native v4 connectivity.(In this case, dual stack means a host with both IPv6 and IPv4 stacks, wich are both active, i.e. they have v4 and v6 connectivity). Now, the nice thing about requirements is that when you read them into detail, they can be interpreted in both ways. So, the question is: is a dual stack host a v6 host (i.e. changes are acceptable) or is it a v4 host (i.e. changes are not acceptable)? Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 08:49:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6A928C1C5 for ; Fri, 25 Jul 2008 08:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSmCfBjQwllG for ; Fri, 25 Jul 2008 08:49:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84FA828C1BB for ; Fri, 25 Jul 2008 08:49:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPW3-0007fb-MX for v6ops-data@psg.com; Fri, 25 Jul 2008 15:47:35 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPVz-0007f5-Ow for v6ops@ops.ietf.org; Fri, 25 Jul 2008 15:47:33 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp01.uc3m.es (Postfix) with ESMTP id CA23A7E7C74;Fri, 25 Jul 2008 17:47:28 +0200 (CEST) Message-ID: <4889F590.4040601@it.uc3m.es> Date: Fri, 25 Jul 2008 17:47:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jari Arkko , Dave Thaler , 'IPv6 Operations' Subject: draft-ietf-v6ops-nat64-pb-statement-req-0: native connectivity withdual stack hosts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.0505 TC:1F TRN:29 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi This is follow up on the previous message about dual stack being susceptible to modification or not. As i mentioned earlier, Dave and Jari have expressed that nodes must be able to use native connectivity, in order to avoid apps that are not nat compatible to crash. However, in our current set of requirements, we have R3: Interaction with dual-stack hosts Translation mechanism MUST allow using native connectivity when it is available. This means that if a v6-only nodes wants to communicate with a dual stack, it must use native v6 connectivity and if a v4- only nodes wants to communicate with a dual stack, it must use native v4 connectivity.(In this case, dual stack means a host with both IPv6 and IPv4 stacks, wich are both active, i.e. they have v4 and v6 connectivity). whcih in conjuction with R1: R1: Changes in the hosts The translation mechanism MUST NOT require changes in the v4-only nodes to support the Basic requirements described in this section, unless explicitly stated in the particular requirement. The translation mechanism MAY require changes to v6-only nodes. results that IPv6 only nodes, (which in our document must be interpreted as a node without a v4 address irrespectively whether it has a v4 stack or not) MAY require modifications to satisfy this requirement. So, this means that unmodified ipv6 only hosts may not be able to use prefer the native connectivity and hence the apps that are not nat compatible would not work in these unmodified v6 only hosts. Do people are ok with this, or people think that we should be stronger on this and try that unmodified v6 only hosts can prefer native connectivity? One more comment: Imposing this requirement for unmodified v4 only hosts may be impossible to reach... comments? Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 08:59:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5BB28C1FA for ; Fri, 25 Jul 2008 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP8KJQQPJ6xg for ; Fri, 25 Jul 2008 08:59:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C511A28C1C5 for ; Fri, 25 Jul 2008 08:59:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPh0-0008im-QI for v6ops-data@psg.com; Fri, 25 Jul 2008 15:58:54 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPgx-0008iJ-4O for v6ops@ops.ietf.org; Fri, 25 Jul 2008 15:58:53 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id D4D3D49B350for ; Fri, 25 Jul 2008 17:58:48 +0200 (CEST) Message-ID: <4889F838.8020504@it.uc3m.es> Date: Fri, 25 Jul 2008 17:58:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' Subject: draft-ietf-v6ops-nat64-pb-statement-req-0: DNS semantics Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.0865 TC:1F TRN:19 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, in the current draft we have: R4: DNS semantics preservation Any modifications to DNS responses associated with translation MUST NOT violate standard DNS semantics. This includes in particular that a DNS response (that has been modified by the translator mechanism) should not be invalid if it ends up in the wrong context, i.e. traversing a non expected part of the topology. Question: this can be achieved of v6 intiated communications, but hardly can be the case for v4 intiated connections... Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 09:00:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F17B28C21D for ; Fri, 25 Jul 2008 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZkioTPCyCTG for ; Fri, 25 Jul 2008 09:00:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1F8328C1C5 for ; Fri, 25 Jul 2008 09:00:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPfh-0008XP-St for v6ops-data@psg.com; Fri, 25 Jul 2008 15:57:33 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPfd-0008Wp-H1 for v6ops@ops.ietf.org; Fri, 25 Jul 2008 15:57:31 +0000 X-IronPort-AV: E=Sophos;i="4.31,253,1215388800"; d="scan'208";a="15489715" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2008 15:57:20 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6PFvJI4030607; Fri, 25 Jul 2008 11:57:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6PFvJaN023418; Fri, 25 Jul 2008 15:57:19 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 11:57:19 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 11:57:19 -0400 Message-ID: In-Reply-To: <50091C86-8E3E-441F-B721-5CEE07A53ECD@thetiger.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjtYS9JKagd5J6CQOCzMjSvPM+U3gBCujlQ References: <7582BC68E4994F4ABF0BD4723975C3FA09DDE882@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDEC70@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA09DDED37@crexc41p> <2bbba3c10807171529h1de5c4f2o5026df74628ed36a@mail.gmail.com> <2bbba3c10807171605t7a291fdbwc222f54715606f13@mail.gmail.com> <10729233-41C8-4EDF-9DCF-3E3370F8A254@thetiger.com> <50091C86-8E3E-441F-B721-5CEE07A53ECD@thetiger.com> From: "Hemant Singh (shemant)" To: "David Miles" Cc: "v6ops WG" X-OriginalArrivalTime: 25 Jul 2008 15:57:19.0833 (UTC) FILETIME=[1E5E3490:01C8EE6F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4378; t=1217001439; x=1217865439; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22David=20Miles=22=20; bh=+k6YaZjTyHvIsR1VuUm/ErM7XcKVCumkw+BHKIBIxco=; b=WmV8DlypNXGEgEqZf0bj7aTcw2b6YMcsHTs4Ov1BJ18LgMJ/1SLRSSDzMx Y6hH5G+MzvbLHjV531P7lap4UrX1iaV107f/Hh7DWjbuLZybw6vsMTQp8K5s W6VOdH3oBC; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: David, Barring Shin's concern that even if a LAN interface on the CPE Router is up with a GUA but the WAN interface of the CPE Router does not have a GUA acquired, using a GUA of a LAN interface is fine as source for WAN packet to the SP. This is the Cisco IOS unnumbered interface model. Then the Loopback interface is not required. Sorry, some folks like Iljitsch thought our draft was alluding to the Cisco IOS unnumbered interface model seeing the "Unnumbered Model" section of our draft. Our draft was NOT referring to the IOS unnumbered model, we just used the term in our draft to signify that the WAN doesn't have a GUA assigned to it. The Unnumbered Model is our -02 draft was merely providing a solution with Loopback interface that folks had asked for at the time. Sorry, I haven't been able to understand all of Shin's concerns completely and that is why I am meeting him at IETF to get to the bottom of things. As a separate observation, Ole has shot down the Shin 1plusus64s draft and the draft's concern in section 4. I don't understand all of Shin's concerns to shoot down his draft or not.=20 Yes, the internals of the CPE Router does include a bridge that is always up if the router is powered up. Further, notice from RFC4241 that the Loopback interface used in that RFC's DSL Deployment is provisioned for an anycast address for ping checks. We will add such information to our draft that the optional Loopback interface can be spawned for the anycast address ping. =20 Hemant & Wes -----Original Message----- From: David Miles [mailto:davidm@thetiger.com]=20 Sent: Thursday, July 24, 2008 3:44 AM To: Hemant Singh (shemant) Cc: v6ops WG Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review > > Some comments on draft-02: > - The un-numbered model doesn't require a loopback interface > > > It does. You may be behind checking your emails on this thread. =20 > Please > read ample evidence given for this one. > > When Shin was pointing out the considerations for a loopback, Francois- Xavier noted: "When the CPE router has only a link-local address on the WAN port, if the CPE has a LAN bridge, I hope there is an option to have the global- scope address set on the LAN bridge (from IA_PD via DHCPv6) as an alternative to loopback solution." Between Shin, Francois-Xavier, Ole and others it seemed there was an appreciation that loopbacks were not required to support the unnumbered model - best summarised in Shin's email on 3 July. (I'm not suggesting everyone thought the unnumbered model was preferred, but that there was no technical obstacle). RFC 3484 says: It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. This seems to hit the nail on the head - we are describing a router that MAY use a unicast address assigned to any interface (LAN) subject to the restrictions in RFC 3484 (which do not pose any problem in my interpretation). I initially raised the use of a loopback as an option because I was concerned about LAN interface state (and said so in the original thread). If the LAN interface is a bridge (always up) I see no mandatory need for a loopback. I would urge continued discussion in- list if there are technical arguments against a un-numbered model without loopback. The two points raised in favour of such an option are that : it avoids an additional /64 for the loopback, and; caters to CPE that may not support a loopback interface (may need to be qualified). IE (a reference for a routing CPE with internal MAC bridge): +------------------------+ | Routing CPE w/ bridge | | +------+ +------+ | Port1-|-| | | | | | |Bridge|-----|Router|--|----WAN Port2-|-| | LAN| | | | +------+ +------+ | +------------------------+ LAN is connected to a bridge device so it is always up. Addresses: WAN: fe80::%wan prefixlen 64 LAN: 2001:db8:0:1:: prefixlen 64 (example) fe80::%lan prefixlen 64 From owner-v6ops@ops.ietf.org Fri Jul 25 09:02:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E1F3A67D0 for ; Fri, 25 Jul 2008 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8mEE65ELti3 for ; Fri, 25 Jul 2008 09:02:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE5543A68F4 for ; Fri, 25 Jul 2008 09:02:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPjv-00098C-QV for v6ops-data@psg.com; Fri, 25 Jul 2008 16:01:55 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPjr-00097I-JE for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:01:53 +0000 X-IronPort-AV: E=Sophos;i="4.31,253,1215388800"; d="scan'208";a="15490441" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2008 16:01:47 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6PG1lGp001269; Fri, 25 Jul 2008 12:01:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6PG1lja013593; Fri, 25 Jul 2008 16:01:47 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 12:01:47 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 12:01:46 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjteEMDYrg89pdyS0CsyA0VwMytfgAB2s4kABFBB+AAKqXZkA== References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> From: "Hemant Singh (shemant)" To: "Stark, Barbara" , "Alain Durand" , Cc: X-OriginalArrivalTime: 25 Jul 2008 16:01:47.0465 (UTC) FILETIME=[BDE39B90:01C8EE6F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4685; t=1217001707; x=1217865707; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=0A=20=20= 20=20=20=20=20=20=22Alain=20Durand=22=20,=0A=20=20=20=20=20=20=20=20; bh=Hbx1rlyjEYKka7r7T+T2AZzB2Y6J8tWTMF+zE2WYUEE=; b=Yim+L7t9Y9aVIkiYcgvVlMOjNgK0tOHYEjvJE+juvIcOoG559JABVfVW68 hY0vgrNhGd6oUxaExRyzjEpK8Qg/MuAdbWaE29W3Op/rhM1xAk6uHZwvIlaW 267dWd6Tu+; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, If every CPE Router has a unique ULA that is mapped to something like http://homerouter.local via mDNS (as per zeroconf) standards, does that work for you? If Barbara doesn't want to even look at the device manual for the named URL, then should every device vendor use the same URL which can then be specified in our draft or any other zeroconfg draft? Just some thoughts. Thanks. Hemant =20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Stark, Barbara Sent: Thursday, July 24, 2008 4:07 PM To: Alain Durand; EricLKlein@softhome.net Cc: v6ops@ops.ietf.org Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review I'd rather the IETF didn't try to mandate some specific well-known address for routers, or a service discovery protocol. Personally, since I "play" with so many different home routers from different manufacturers, I don't bother trying any well-known address to get to the UI. I can't remember who uses what. And I hate reading the manual. There are so many different values in use, that I find it easier to just run ipconfig / ifconfig and see what my Default Gateway is set to. Put that in the browser, and I'm at the router UI.=20 I do know that if a device has a DSL modem in it, then it is likely to support the standard domain name specified by the Broadband Forum (formerly DSL Forum): dsldevice I expect that to continue. If there is to be some sort of discovery and then presenting the results to the user in a friendly manner, then there will need to be an application that does all this. If there's an application, it probably doesn't care where the info comes from. Surely somewhere between all the ND and RA and such, there must be an IPv6 address that can lead an application to the router, without trying to mandate or recommend support for some service discovery protocol. I don't need for a device to advertise that it has an HTTP server at port 80 on a particular IP address. I just need the device's IP address.=20 Barbara -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alain Durand Sent: Thursday, July 24, 2008 7:23 AM To: EricLKlein@softhome.net Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review On 7/24/08 6:29 AM, "EricLKlein@softhome.net" wrote: > Having a known address is not the same as advertising it out to anyone that > is locally connected. Admittedly it is only a short term improvement until > the fixed address becomes commonly known via the internet, but even then it > is only a problem if someone comes to the area of a wireless network where > the security has not been changed from the default. >=20 > Consider the situation as follows: > Person x goes and buys a WiFI router to connect to their DSL link. But prior > to connecting to the DSL they plug it in to configure it. The only way that > someone would know to try to configure it would be to see it in their=20 > available networks and then recognize the brand and to try to connect to the > default IP address. Vs. Someone sees a new hotspot advertising a "come > configure me" service. In the first case you need to proactivly go looking > for things to hack, in the second you are invited in to do so. >=20 > Maybe I am alone on this, but I prefer to make the hacker try harder without > inviting them inside. Eric, The property of well known address is that, well, they are well known. So if a vendor start to use fe80::1, I guess most vendors will use it and there is little guesswork to be done. Now, with service discovery, I would expect that as soon as the device is configured the first time, some king of security will be put in place, if only using a password. This can be done before the ISP connection is up. If the user decide not to use a passwd or any other form of security, well, this is a different issue. I have seen this discovery being implemented already: simply try to configure an Apple airport. - Alain. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From owner-v6ops@ops.ietf.org Fri Jul 25 09:08:51 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5A53A6A9D for ; Fri, 25 Jul 2008 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsttBQyBsmn7 for ; Fri, 25 Jul 2008 09:08:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CA8F3A6816 for ; Fri, 25 Jul 2008 09:08:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPpm-0009jS-C5 for v6ops-data@psg.com; Fri, 25 Jul 2008 16:07:58 +0000 Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPpi-0009ht-Pn for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:07:56 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp02.uc3m.es (Postfix) with ESMTP id 74E8F424D00;Fri, 25 Jul 2008 18:07:49 +0200 (CEST) Message-ID: <4889FA54.2090600@it.uc3m.es> Date: Fri, 25 Jul 2008 18:07:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' , 'Magnus Westerlund' Subject: draft-ietf-v6ops-nat64-pb-statement-req-0: protocols supported Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.0215 TC:1F TRN:13 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, in the current draft we have: R6: Protocols supported The translation mechanism MUST support at least TCP, UDP, ICMP, TLS. Question: what is the rationale we include TLS here? souyld we have a citeria of which protocols shoudl be in this req? Question: should we move DCCP and SCTP to MUST rahter than SHOULD? (Magnus, is this what you were requesting in your emails before?) Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 09:12:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0703A6838 for ; Fri, 25 Jul 2008 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn-Ncw10v14T for ; Fri, 25 Jul 2008 09:12:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA3CD3A6AF9 for ; Fri, 25 Jul 2008 09:12:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPt9-000AEo-9I for v6ops-data@psg.com; Fri, 25 Jul 2008 16:11:27 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMPt1-000ADm-Jq for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:11:25 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 556B411; Fri, 25 Jul 2008 18:11:18 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: marcelo bagnulo braun Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? Date: Fri, 25 Jul 2008 19:11:14 +0300 User-Agent: KMail/1.9.9 Cc: Jari Arkko , Dave Thaler , 'IPv6 Operations' , Brian E Carpenter References: <4889EAD2.8060809@it.uc3m.es> In-Reply-To: <4889EAD2.8060809@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807251911.16835.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le vendredi 25 juillet 2008 18:01:38 marcelo bagnulo braun, vous avez =E9cr= it=A0: > Now, the nice thing about requirements is that when you read > them into detail, they can be interpreted in both ways. No. A dual-stack host is NOT a v4-only host. If you read the requirements t= o=20 the letter, nothing excludes changes to dual-stack nodes. But I humbly thin= k=20 the real question is not what the current requirements say. > So, the question is: is a dual stack host a v6 host (i.e. changes are > acceptable) or is it a v4 host (i.e. changes are not acceptable)? Regardless of the current requirements, I would argue it is not acceptable= =20 that dual-stack nodes need to be modified, for the exact same reason as it = is=20 not acceptable that IPv4-only nodes need to be modified: deployment would b= e=20 highly impractical. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Fri Jul 25 09:21:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5909528C205 for ; Fri, 25 Jul 2008 09:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRPo9SwHVHI for ; Fri, 25 Jul 2008 09:21:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 729AF28C17A for ; Fri, 25 Jul 2008 09:21:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ24-000BQw-1I for v6ops-data@psg.com; Fri, 25 Jul 2008 16:20:40 +0000 Received: from [163.117.176.131] (helo=smtp01.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ1z-000BQG-Kn for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:20:37 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp01.uc3m.es (Postfix) with ESMTP id ECB307E7CC0;Fri, 25 Jul 2008 18:20:32 +0200 (CEST) Message-ID: <4889FD50.4060406@it.uc3m.es> Date: Fri, 25 Jul 2008 18:20:32 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= CC: Jari Arkko , Dave Thaler , 'IPv6 Operations' , Brian E Carpenter Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com> In-Reply-To: <200807251911.16835.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.1925 TC:1F TRN:21 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Denis-Courmont escribió: > Le vendredi 25 juillet 2008 18:01:38 marcelo bagnulo braun, vous avez écrit : > >> Now, the nice thing about requirements is that when you read >> them into detail, they can be interpreted in both ways. >> > > No. A dual-stack host is NOT a v4-only host. If you read the requirements to > the letter, nothing excludes changes to dual-stack nodes. But I humbly think > the real question is not what the current requirements say. > > >> So, the question is: is a dual stack host a v6 host (i.e. changes are >> acceptable) or is it a v4 host (i.e. changes are not acceptable)? >> > > Regardless of the current requirements, I would argue it is not acceptable > that dual-stack nodes need to be modified, for the exact same reason as it is > not acceptable that IPv4-only nodes need to be modified: deployment would be > highly impractical. > do you think it is acceptable to require some manual configuration in them to make them work? Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 09:27:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061D83A68FA for ; Fri, 25 Jul 2008 09:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fExoUAgaf9AJ for ; Fri, 25 Jul 2008 09:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F9C63A6816 for ; Fri, 25 Jul 2008 09:27:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ7L-000C88-MN for v6ops-data@psg.com; Fri, 25 Jul 2008 16:26:07 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ7I-000C7Q-5S for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:26:05 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id AE30749B547for ; Fri, 25 Jul 2008 18:16:24 +0200 (CEST) Message-ID: <4889FC58.4020003@it.uc3m.es> Date: Fri, 25 Jul 2008 18:16:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' Subject: draft-ietf-v6ops-nat64-pb-statement-req-0: behave requirements Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:0.7660 TC:1F TRN:12 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The current draft states: R7: Behave requirements The translation mechanism MUST be compliant with the requirements for IPv4 NATs defined in [I-D.ietf-behave-tcp] and in [RFC4787] when applicable. These requirements should be interpreted with the IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of the conventional NAT. First, this heavily assumes v6 initiated communications. If we have nat46, we probably don’t need this Question: should we include the behave requirements for ICMP, DCCP, SCTP? From owner-v6ops@ops.ietf.org Fri Jul 25 09:29:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585DF3A68FA for ; Fri, 25 Jul 2008 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP-U9N6fAZLb for ; Fri, 25 Jul 2008 09:29:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 499063A6816 for ; Fri, 25 Jul 2008 09:29:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ9s-000CSy-4N for v6ops-data@psg.com; Fri, 25 Jul 2008 16:28:44 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQ9o-000CSX-BL for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:28:42 +0000 Received: from e4.ny.us.ibm.com ([192.168.1.104]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PCPbWq017816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2008 08:25:37 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6PCMO42021469 for ; Fri, 25 Jul 2008 08:22:24 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6PCMNuH229062 for ; Fri, 25 Jul 2008 08:22:23 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6PCMNOG030994 for ; Fri, 25 Jul 2008 08:22:23 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PCMK5X030770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 08:22:23 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6PCMEjV017212; Fri, 25 Jul 2008 08:22:15 -0400 Message-Id: <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> To: marcelo bagnulo braun cc: v6ops@ops.ietf.org Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement In-reply-to: <488833F7.7030606@it.uc3m.es> References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> Comments: In-reply-to marcelo bagnulo braun message dated "Thu, 24 Jul 2008 09:49:11 +0200." Date: Fri, 25 Jul 2008 08:22:14 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: marcelo bagnulo braun writes: > Thomas Narten escribiĂ³: > > marcelo bagnulo braun writes: > > > > > >> if the verification is performed before the synthesis of the RR and > >> there is a trsut relationship betwen the receiver and the node that has > >> performed the verification and synthesis, this should do it. > >> > > > > Well, yes, but there are an awful lot of ifs in the above. Certainly > > more than are appropriate for the original MUST requirement. > > > > > but what i was describing here is a solution the describe that this is > possible and so it makes sense to keep the requirement > there may be other solutions that also satisfy the requirement, Sorry, but no. if you have a simple MUST as a requirement, you can't have the solution involve a bunch of ifs that will not be true in general, and/or that change the meaning of meeting the requirement. DNSSEC is about e2e security. The recipient of the data (the DNS querier), using DNSSEC, is able to verify that the data has not been modified. This is no longer true in the solution outline you proposed above. Hence, the requirement needs to significantly expanded upon and/or clarified. Otherwise, people will assume it means X, when others assume it actually means Y. > >> In particular, if everything happens at the end node, we are in > >> business, right? (i.e. the v6 end node asks for the A RR, perfomrs > >> the dnssec validation and then internally generates the v6 address) > >> > > > > Ahem. If the end node is doing this, why isn't it just doing dual > > stack? After all, it (or rather the embedded translator) is sending > > out IPv4... > > > cause the main scenario that we are targeting here is the case where the > source node has no v4 address configured in its stack, so it cannot send > v4 packets. What exactly is the difference between a node that has no IPv4 address configured (so that it can not just use dual stack) and that same node with an embedded translator attached to it that does send out IPv4 (after translation - and hence, has to have an IPv4 address configured)? From what I can see, in both cases the node has an IPv4 addresss and the directly attached network is IPv4 enabled. In that case, dual-stack seems like the obvious thing to use. I certainly wouldn't think a translater is needed here... > I am lately thinking that we need two different lists of requirements > one for v4 initiated communications and another one for v6 initiated > communications especially for dealing with dns requirements. In v4 > initiated communications the state in the nat box has close relationship > with the RR synthesis, while in v6 initiated communication they are > completely decoupled, which makes possible to satisfy most of the dns > requirements. If the requirements are different in the two directions, then yes, two separate requirments are needed. You can't have a general requirement (that implicitely implies a solution in both directions) when a solution in one direction can't be made to work. Thomas From owner-v6ops@ops.ietf.org Fri Jul 25 09:36:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8163A6861 for ; Fri, 25 Jul 2008 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.967 X-Spam-Level: X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AMHU4HGMxHm for ; Fri, 25 Jul 2008 09:36:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7EC03A6838 for ; Fri, 25 Jul 2008 09:36:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQH3-000DN1-7K for v6ops-data@psg.com; Fri, 25 Jul 2008 16:36:09 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQGz-000DMG-6p for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:36:07 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id 3D20949B071for ; Fri, 25 Jul 2008 17:15:56 +0200 (CEST) Message-ID: <4889EE2B.4010608@it.uc3m.es> Date: Fri, 25 Jul 2008 17:15:55 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' Subject: draft-ietf-v6ops-nat64-pb-statement-req-00 - who from the v6 sidecan talk to who in the v4 side? Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.3755 TC:1F TRN:11 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, In the current version of the draft we have that: R2: Basic communication support R2.1: Translation mechanism must support v6-initiated short-lived local handle (as defined in Section 3.1. There is strong consensus on this Question: v6-initiated connections from which v6 address to which v4 address? I have always assumed all v6 address and all v4 addresses, but after some discussion, it is not obvious… Do people think that this goal is achieved is a subset of v6 source address can reach a subset of v4 addresses? Or do people think that this goal is achieved if a subset of v6 addresses can reach all the v4 addresses? Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 09:56:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7D93A6AF9 for ; Fri, 25 Jul 2008 09:56:29 -0700 (PDT) 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=-1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd613TWwQ06z for ; Fri, 25 Jul 2008 09:56:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C8763A68FB for ; Fri, 25 Jul 2008 09:56:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQZT-000Fkm-WC for v6ops-data@psg.com; Fri, 25 Jul 2008 16:55:12 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQZQ-000FkN-9x for v6ops@ops.ietf.org; Fri, 25 Jul 2008 16:55:10 +0000 Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 161071F7; Fri, 25 Jul 2008 18:55:07 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: marcelo bagnulo braun Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-0: protocols supported Date: Fri, 25 Jul 2008 19:55:05 +0300 User-Agent: KMail/1.9.9 Cc: 'IPv6 Operations' , 'Magnus Westerlund' References: <4889FA54.2090600@it.uc3m.es> In-Reply-To: <4889FA54.2090600@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807251955.05599.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Le vendredi 25 juillet 2008 19:07:48 marcelo bagnulo braun, vous avez =E9cr= it=A0: > Question: what is the rationale we include TLS here? souyld we have a > citeria of which protocols shoudl be in this req? Being (wrongly) cut and pasted from the STUN/TURN specs?? > Question: should we move DCCP and SCTP to MUST rahter than SHOULD? > (Magnus, is this what you were requesting in your emails before?) I can't comment on SCTP. But... If TCP can be translated, DCCP can be translated. If UDP can be translated, UDP-Lite can be translated. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Fri Jul 25 10:06:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D42F3A6816 for ; Fri, 25 Jul 2008 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgGL-aPa1Yrz for ; Fri, 25 Jul 2008 10:06:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CFD43A679F for ; Fri, 25 Jul 2008 10:06:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQi9-000GiC-SZ for v6ops-data@psg.com; Fri, 25 Jul 2008 17:04:09 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQi5-000GhV-Nt for v6ops@ops.ietf.org; Fri, 25 Jul 2008 17:04:07 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id 10BAE49B52F;Fri, 25 Jul 2008 19:04:02 +0200 (CEST) Message-ID: <488A0781.3020701@it.uc3m.es> Date: Fri, 25 Jul 2008 19:04:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= CC: 'IPv6 Operations' , 'Magnus Westerlund' Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-0: protocols supported References: <4889FA54.2090600@it.uc3m.es> <200807251955.05599.rdenis@simphalempin.com> In-Reply-To: <200807251955.05599.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.9085 TC:1F TRN:16 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Denis-Courmont escribió: > Le vendredi 25 juillet 2008 19:07:48 marcelo bagnulo braun, vous avez écrit : > >> Question: what is the rationale we include TLS here? souyld we have a >> citeria of which protocols shoudl be in this req? >> > > Being (wrongly) cut and pasted from the STUN/TURN specs?? > :-) could be, but in this case this is not it > >> Question: should we move DCCP and SCTP to MUST rahter than SHOULD? >> (Magnus, is this what you were requesting in your emails before?) >> > > I can't comment on SCTP. But... > > If TCP can be translated, DCCP can be translated. > doesn't dccp support multiaddressing? Regards, marcelo > If UDP can be translated, UDP-Lite can be translated. > > From owner-v6ops@ops.ietf.org Fri Jul 25 10:37:36 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C1A3A6816 for ; Fri, 25 Jul 2008 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.013 X-Spam-Level: X-Spam-Status: No, score=-4.013 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vlb4DLQAL0S for ; Fri, 25 Jul 2008 10:37:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98CF13A679F for ; Fri, 25 Jul 2008 10:37:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRD7-000KVs-81 for v6ops-data@psg.com; Fri, 25 Jul 2008 17:36:09 +0000 Received: from [163.117.176.133] (helo=smtp03.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRD2-000KVK-H6 for v6ops@ops.ietf.org; Fri, 25 Jul 2008 17:36:07 +0000 Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp03.uc3m.es (Postfix) with ESMTP id 7451049B519for ; Fri, 25 Jul 2008 17:33:52 +0200 (CEST) Message-ID: <4889F25F.9060202@it.uc3m.es> Date: Fri, 25 Jul 2008 17:33:51 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 'IPv6 Operations' Subject: draft-ietf-v6ops-nat64-pb-statement-req-00: v4 initiated communications Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.4285 TC:1F TRN:12 TV:5.5.1026(16054.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, in the draft we have: R2: Basic communication support R2.2: Translation mechanim must support v4-initiated short-lived local handle (as defined in Section 3.1). There is not clear if there is consensus for this The problem is that some basic req may not be possible to meet in this case Proposal: keep it, but have separate reqs lists for v4 and v6 initiated communications I will then make a proposal of which reqs can be fulfilled in v4 initiated communications and which ones in v4 initiated communications Comments? Regards, marcelo From owner-v6ops@ops.ietf.org Fri Jul 25 11:26:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6055E28C158 for ; Fri, 25 Jul 2008 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDeKAindQeSE for ; Fri, 25 Jul 2008 11:26:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B97A28C147 for ; Fri, 25 Jul 2008 11:26:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRx7-0000Cz-W2 for v6ops-data@psg.com; Fri, 25 Jul 2008 18:23:41 +0000 Received: from [212.27.60.43] (helo=postfix2-g20.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRx4-0000CS-E2 for v6ops@ops.ietf.org; Fri, 25 Jul 2008 18:23:40 +0000 Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix2-g20.free.fr (Postfix) with ESMTP id 63B4C28646AC for ; Fri, 25 Jul 2008 15:01:22 +0200 (CEST) Received: from smtp2-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp2-g19.free.fr (Postfix) with ESMTP id BBE2312B6E4; Fri, 25 Jul 2008 17:01:08 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g19.free.fr (Postfix) with ESMTP id B0D4012B6F8; Fri, 25 Jul 2008 17:01:07 +0200 (CEST) Message-ID: <4889EA84.9000008@free.fr> Date: Fri, 25 Jul 2008 17:00:20 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Thomas Narten , Ed Jankiewicz , v6ops@ops.ietf.org, =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> <48899888.9060006@it.uc3m.es> <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> In-Reply-To: <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thomas Narten - Le 7/25/08 2:15 PM : > marcelo bagnulo braun writes: > >>> I am assuming that NAT64=="v6 initiated communication" and >>> NAT46=="v4 initiated communication". > >> mmm, i think the term has evolved initially, i think that nat64 >> meant a new version of natpt but now we make a distinction between >> nat64 and nat46 as you say we could expliclty state it this way in >> the document if you think so > > Yes. Clarity is good. Indeed. Note that, using RFC 2663's terminology, the distinction is more precisely: - NAT64: IPv6 internal side, IPv4 external side - NAT46: IPv4 internal side, IPv6 external side (NATs that do port forwarding support connections initiated from both sides.) Regards. Rémi Després From owner-v6ops@ops.ietf.org Fri Jul 25 13:13:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C723A6827 for ; Fri, 25 Jul 2008 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bQaJU8KGYck for ; Fri, 25 Jul 2008 13:13:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBCE93A67FF for ; Fri, 25 Jul 2008 13:13:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMTci-000FLz-H5 for v6ops-data@psg.com; Fri, 25 Jul 2008 20:10:44 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMTce-000FLO-Kz for v6ops@ops.ietf.org; Fri, 25 Jul 2008 20:10:42 +0000 Received: (qmail 8208 invoked by uid 417); 25 Jul 2008 18:23:26 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 25 Jul 2008 18:23:26 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 25 Jul 2008 12:23:26 -0600 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> From: EricLKlein@softhome.net To: "Stark, Barbara" Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 12:23:26 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Stark, Barbara writes: > I'd rather the IETF didn't try to mandate some specific well-known > address for routers, or a service discovery protocol. Agreed, it is more a methodology than a specific address that I am proposing. >Personally, since > I "play" with so many different home routers from different > manufacturers, I don't bother trying any well-known address to get to > the UI. I can't remember who uses what. And I hate reading the manual. > There are so many different values in use, that I find it easier to just > run ipconfig / ifconfig and see what my Default Gateway is set to. Put > that in the browser, and I'm at the router UI. Problem with this is that there is no default gateway unless you have the predefined IP that you are against. Otherwise a new (unconfigured) device has no IP addresses to give out via DHCP (v4 or v6) and thus can not reply to an IPCONFIG command. In that case the default will be 0::00 or such, and will be of little help. > I do know that if a device has a DSL modem in it, then it is likely to > support the standard domain name specified by the Broadband Forum > (formerly DSL Forum): dsldevice > I expect that to continue. > I am not so sure if other devices will have this same type of predefined service. > If there is to be some sort of discovery and then presenting the results > to the user in a friendly manner, then there will need to be an > application that does all this. If there's an application, it probably > doesn't care where the info comes from. Surely somewhere between all the > ND and RA and such, there must be an IPv6 address that can lead an > application to the router, without trying to mandate or recommend > support for some service discovery protocol. I don't need for a device > to advertise that it has an HTTP server at port 80 on a particular IP > address. I just need the device's IP address. This makes sense, it is what is behind the getting of that initial address that is being discussed. Eric > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Alain Durand > Sent: Thursday, July 24, 2008 7:23 AM > To: EricLKlein@softhome.net > Cc: v6ops@ops.ietf.org > Subject: Re: New (-02) version of IPv6 CPE Router draft is available for > review > > > > > On 7/24/08 6:29 AM, "EricLKlein@softhome.net" > wrote: > >> Having a known address is not the same as advertising it out to anyone > that >> is locally connected. Admittedly it is only a short term improvement > until >> the fixed address becomes commonly known via the internet, but even > then it >> is only a problem if someone comes to the area of a wireless network > where >> the security has not been changed from the default. >> >> Consider the situation as follows: >> Person x goes and buys a WiFI router to connect to their DSL link. But > prior >> to connecting to the DSL they plug it in to configure it. The only way > that >> someone would know to try to configure it would be to see it in their >> available networks and then recognize the brand and to try to connect > to the >> default IP address. Vs. Someone sees a new hotspot advertising a "come >> configure me" service. In the first case you need to proactivly go > looking >> for things to hack, in the second you are invited in to do so. >> >> Maybe I am alone on this, but I prefer to make the hacker try harder > without >> inviting them inside. > > > Eric, > > The property of well known address is that, well, they are well known. > So if > a vendor start to use fe80::1, I guess most vendors will use it and > there is > little guesswork to be done. > > Now, with service discovery, I would expect that as soon as the device > is > configured the first time, some king of security will be put in place, > if > only using a password. This can be done before the ISP connection is up. > If > the user decide not to use a passwd or any other form of security, well, > this is a different issue. > > I have seen this discovery being implemented already: simply try to > configure an Apple airport. > > - Alain. > > > > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > From owner-v6ops@ops.ietf.org Fri Jul 25 13:14:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4674C3A6909 for ; Fri, 25 Jul 2008 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMHzMFHmt6tt for ; Fri, 25 Jul 2008 13:14:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BB7B3A68FE for ; Fri, 25 Jul 2008 13:14:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMTgB-000FoO-Tj for v6ops-data@psg.com; Fri, 25 Jul 2008 20:14:19 +0000 Received: from [32.97.182.142] (helo=e2.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMTg8-000Fnn-CL for v6ops@ops.ietf.org; Fri, 25 Jul 2008 20:14:18 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6PKED0T025755 for ; Fri, 25 Jul 2008 16:14:13 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6PKEDBM229256 for ; Fri, 25 Jul 2008 16:14:13 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6PKEDW2006471 for ; Fri, 25 Jul 2008 16:14:13 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PKEBRe006345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jul 2008 16:14:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6PKEA86011871 for ; Fri, 25 Jul 2008 16:14:11 -0400 Message-Id: <200807252014.m6PKEA86011871@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: narten-ipv6-3177bis-48boundary: technical justification Date: Fri, 25 Jul 2008 16:14:10 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: At the Philly meeting, Bob Hinden raised the following issue (my summary of his words): > completely agree with HD ratio. not in favor of this document in > current form. 1. I've not seen any analysis that the current /48 > will result in running out of /48s. there was some analysis with > previous HD ration. But after changing HD ratio, would like to see > justification other than just "its too big". would like to see > technical analysis that there is a problem. > wants to see technical justification that the number needs to be > changed. unless there is technical problem to fix, no need to > change. IMO, this question gets back to "should we change the policy", i.e., where should the actual boundary be. That is not an IETF question, that is for the RIRs to decide. I'm also not trying to make the case that it NEEDS to be changed in this document. (It is true that the RIRs have already changed the policy, because its members didn't like a /48 for everyone and also didn't like a one-size-fits all approach, regardless of what that default value would be). One of the "problems" that I'd like to see fixed is the IETF seeming to be on record as saying that a /48 is necessary and is part of the architecure. That is how RFC 3177 is being intepreted by some. I.e., in RIR discussions about the boundary, it is fairly common for some folk to say "but the IETF said a /48 was necessary, therefore I don't think we should change it." Thomas From owner-v6ops@ops.ietf.org Fri Jul 25 13:23:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970093A68FE for ; Fri, 25 Jul 2008 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMNjkVqlciCX for ; Fri, 25 Jul 2008 13:23:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A67233A6864 for ; Fri, 25 Jul 2008 13:23:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMToI-000H3V-3o for v6ops-data@psg.com; Fri, 25 Jul 2008 20:22:42 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMToE-000H2t-8u for v6ops@ops.ietf.org; Fri, 25 Jul 2008 20:22:40 +0000 Received: (qmail 24647 invoked by uid 417); 25 Jul 2008 18:35:05 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 25 Jul 2008 18:35:05 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 25 Jul 2008 12:35:05 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 12:35:05 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Alain Durand writes: >> Maybe I am alone on this, but I prefer to make the hacker try harder without >> inviting them inside. > > > Eric, > > The property of well known address is that, well, they are well known. So if > a vendor start to use fe80::1, I guess most vendors will use it and there is > little guesswork to be done. > > Now, with service discovery, I would expect that as soon as the device is > configured the first time, some king of security will be put in place, if > only using a password. This can be done before the ISP connection is up. If > the user decide not to use a passwd or any other form of security, well, > this is a different issue. > > I have seen this discovery being implemented already: simply try to > configure an Apple airport. Alain I fail to see the practical difference between these solutions. My main concern is that the majority of users out there are not using Apple type logic but Microsoft's version of logic. Therefore a known process or method is going to become necessary. Today this is done via known IP addresses per brand/model. What you are describing sounds more like finding an available hotspot via WiFi. If this is the consensus that the WG takes that is fine, I am just not sure it is the simplest solution to this requirement in all cases. Eric From owner-v6ops@ops.ietf.org Fri Jul 25 13:58:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7A23A69B6 for ; Fri, 25 Jul 2008 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7yNfkr1-cGB for ; Fri, 25 Jul 2008 13:58:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CAA63A69AD for ; Fri, 25 Jul 2008 13:58:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMULF-000MEk-W7 for v6ops-data@psg.com; Fri, 25 Jul 2008 20:56:46 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMULB-000ME0-RN for v6ops@ops.ietf.org; Fri, 25 Jul 2008 20:56:43 +0000 Received: from e32.co.us.ibm.com ([32.97.110.150]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PKGX3Z001453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2008 16:16:35 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6PK7WrP014890 for ; Fri, 25 Jul 2008 16:07:32 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6PKDHvt148038 for ; Fri, 25 Jul 2008 14:13:23 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6PKDHFF021749 for ; Fri, 25 Jul 2008 14:13:17 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PKDFDL021690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jul 2008 14:13:17 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6PKDFbh011861 for ; Fri, 25 Jul 2008 16:13:15 -0400 Message-Id: <200807252013.m6PKDFbh011861@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: draft-narten-ipv6-3177bis-48boundary-04.txt Date: Fri, 25 Jul 2008 16:13:15 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, I've requested and been granted agnenda time for this document in Thursday's v6ops session. Some background: The document was discussed in Philly, but none of the authors could be in the session. It was also discussed on the list just before and after Philly. My goal for the Thursday session will be to review the purpose of the document, and see if the WG is willing to take it on as a WG document. I will be sending out some followup mail, commenting on the dialog that took place during the Philly session (I just reviewed the audio again). Some points: 1) This document is NOT trying to set or specify policy and say what the actual boundary should be. The main reason for that is that the policy decision is for the RIRs to make. Although we may have opinions (I do!), that discussion should be taken to the RIRs. Also, going back through the previous comments, while a number of people have agreed that a default of /48 is not appropriate, there has been far less agreement on what an appropriate default should be. Thus, I have doubts we'd be able to come up with a consensus recommendation on a particular value. 2) This document is trying to make clear what (if any) the architectural issues are w.r.t. a boundary choice. As the document itself states, the only issues appear to be minor. If you disagree, please be specific about what issues need to be added to the document. 3) Most of the issues about where the end site boundary should be are operational, not architectural (hence, bringing the document to v6ops). I.e, things like using nibble boundaries to facilitate delegation of PTR records, renumbering considerations, etc. 4) The RIRs have already moved away from a single /48 for all. So, this document is not really about getting the RIRs to change their existing policies (that has already effectively been done), than to show that those changes are consistent with the IPv6 archtecture. If folk want to review the previous thread, have a look here: http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00395.html Thomas From owner-v6ops@ops.ietf.org Fri Jul 25 14:19:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1C43A6859 for ; Fri, 25 Jul 2008 14:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkjuPbtb8zen for ; Fri, 25 Jul 2008 14:19:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EECBB3A677D for ; Fri, 25 Jul 2008 14:19:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMUf9-000PX6-8E for v6ops-data@psg.com; Fri, 25 Jul 2008 21:17:19 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMUf5-000PWU-KD for v6ops@ops.ietf.org; Fri, 25 Jul 2008 21:17:17 +0000 Received: (qmail 17027 invoked by uid 417); 25 Jul 2008 18:29:47 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 25 Jul 2008 18:29:47 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 25 Jul 2008 12:29:47 -0600 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: "Stark, Barbara" , "Alain Durand" , v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 12:29:47 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > Folks, > > If every CPE Router has a unique ULA that is mapped to something like > http://homerouter.local via mDNS (as per zeroconf) standards, does that > work for you? If Barbara doesn't want to even look at the device manual > for the named URL, then should every device vendor use the same URL > which can then be specified in our draft or any other zeroconfg draft? > Just some thoughts. > Does this not go back to the known name issue. I do not have a problem with it, all I want is a consistent solution that will work prior to having an ISP assigned IP address available or a DHCP address pool defined. Eric From owner-v6ops@ops.ietf.org Fri Jul 25 14:47:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7EA28C0EE for ; Fri, 25 Jul 2008 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+84AdVNyc6a for ; Fri, 25 Jul 2008 14:47:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9034B3A69CD for ; Fri, 25 Jul 2008 14:47:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMV6J-0003lD-Kt for v6ops-data@psg.com; Fri, 25 Jul 2008 21:45:23 +0000 Received: from [32.97.182.150] (helo=over.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMV67-0003jf-OK for v6ops@ops.ietf.org; Fri, 25 Jul 2008 21:45:13 +0000 Received: from e32.co.us.ibm.com ([32.97.110.150]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PKJ9Qi001975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2008 16:19:10 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6PKA85i018125 for ; Fri, 25 Jul 2008 16:10:08 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6PKFxwf173162 for ; Fri, 25 Jul 2008 14:15:59 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6PKFxcY022095 for ; Fri, 25 Jul 2008 14:15:59 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-213.mts.ibm.com [9.65.248.213]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6PKFvJV022032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jul 2008 14:15:58 -0600 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6PKFuRu011888 for ; Fri, 25 Jul 2008 16:15:57 -0400 Message-Id: <200807252015.m6PKFuRu011888@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: narten-ipv6-3177bis-48boundary: updating an IAB document Date: Fri, 25 Jul 2008 16:15:56 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: There were some comments in earlier mail and at the Philly session saying essentially: 3177 is an IAB document (actually it was a joint IAB/IESG document) and therefore the IAB needs to change it and the WG shouldn't (or can't) be the one to do this. I've had some informal conversations with I* members about this and the impression I got was they'd actually prefer this be a WG document. If it is a regular IETF document, both the IESG/IAB will have a chance to review and have input. But there is no need for those organizations to initiate the document or be the primary drivers for it. If the IAB ends up wanting its name on the document or have some other text included (i.e, to somehow give it the weight needed to updated 3177), we can have that discussion later. But I think first and foremost, this document should be an IETF document, since it is intended to be an IETF recommendation. That means having it come up through a WG is just fine. Having said all that, I will raise the issue again to see if anything has changed in how best to process this document. Thomas From owner-v6ops@ops.ietf.org Fri Jul 25 15:52:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6403A68C4 for ; Fri, 25 Jul 2008 15:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-2.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T6HeGGmjtH2 for ; Fri, 25 Jul 2008 15:52:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 877F03A67E1 for ; Fri, 25 Jul 2008 15:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMW67-000CVD-Nn for v6ops-data@psg.com; Fri, 25 Jul 2008 22:49:15 +0000 Received: from [209.85.198.229] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMW64-000CUn-0v for v6ops@ops.ietf.org; Fri, 25 Jul 2008 22:49:13 +0000 Received: by rv-out-0506.google.com with SMTP id b25so3757282rvf.41 for ; Fri, 25 Jul 2008 15:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cpU+sNikKxYCFDLliEsTPy8FYRma87KDUadkFPZIwUU=; b=gd2ajtubQlPvMSneXgNBGALpZ0aQ7TRsGYDpzxw8ymWBuS3dlc8uRkMOm7VEDpAeDu DdDJwLFWqyYsOfxSjP+/8QdM+V+oDPdyEuL/bjrhixub1wKyo2sKbwNGcnRGkvoD1Qwd XKuM46P05CZpk7p5sp5T1SYM8l4ni+bNTRvvs= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZyGgmQiih1WJXqzePIFkLpY/ZxhL86FIN6ayScKKBQpgVfY1Fd5r8O+wSKoPHpaVR9 /nB3ntGJZg0M1v5We9J+0ERsn3Jd8t6Xi9Emk2Vs3YRTynTJxuJM+THPXxyx9SZy411g 5ez9l4mJI0X665u6Ng6dFcb9Ly7GlMxSKE0tE= Received: by 10.114.179.1 with SMTP id b1mr2682068waf.1.1217024679982; Fri, 25 Jul 2008 15:24:39 -0700 (PDT) Received: from ?192.168.93.81? ( [76.227.114.41]) by mx.google.com with ESMTPS id j34sm14191890waf.48.2008.07.25.15.24.38 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Jul 2008 15:24:39 -0700 (PDT) Message-ID: <488A52A3.5080300@gmail.com> Date: Sat, 26 Jul 2008 10:24:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= CC: IPv6 Operations Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> <48899888.9060006@it.uc3m.es> <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> <4889EA84.9000008@free.fr> In-Reply-To: <4889EA84.9000008@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > Note that, using RFC 2663's terminology, the distinction is more > precisely: > - NAT64: IPv6 internal side, IPv4 external side > - NAT46: IPv4 internal side, IPv6 external side Where do you find that in 2663? In any case I think the notions of "internal" and "external" are not well-defined in a network which mixes regions of pure IPv6, regions of pure IPv4 and dual-stack regions. Also, NAT terminology tends to be based on the distinction between private ambiguous and public global addresses, which makes no sense for IPv6. > (NATs that do port forwarding support connections initiated from both > sides.) Exactly. I don't think this can be reduced to two acronyms. Brian From owner-v6ops@ops.ietf.org Fri Jul 25 17:04:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15633A67D4 for ; Fri, 25 Jul 2008 17:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90MNcUmKnj3S for ; Fri, 25 Jul 2008 17:04:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B354D3A6820 for ; Fri, 25 Jul 2008 17:04:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMXDO-000Kmm-O2 for v6ops-data@psg.com; Sat, 26 Jul 2008 00:00:50 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMXDG-000KmH-KD for v6ops@ops.ietf.org; Sat, 26 Jul 2008 00:00:48 +0000 X-IronPort-AV: E=Sophos;i="4.31,255,1215388800"; d="scan'208";a="15544585" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2008 00:00:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6Q00VW1022008; Fri, 25 Jul 2008 20:00:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6Q00Wu3025202; Sat, 26 Jul 2008 00:00:32 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 20:00:31 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Fri, 25 Jul 2008 20:00:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjuhI2v8VnDdQFVTDy2XlPsyKAL2gALZNAg References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> From: "Hemant Singh (shemant)" To: Cc: "Stark, Barbara" , "Alain Durand" , X-OriginalArrivalTime: 26 Jul 2008 00:00:31.0972 (UTC) FILETIME=[9F078A40:01C8EEB2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1147; t=1217030432; x=1217894432; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20; bh=cUNvlegjoxAtQ7XBPetw6xPzuykN4ua6TeaPtF9MoHA=; b=oOa3ejArMlB/pGZiFGYabaUyP/gQOBGqMIOrlttCgieUJ9H14EPnHFjOGw zEsapbo0JUQuWST2ipIdmB4E+QHUOc5EGfCmD7lFXtwVnOpDqavunN6l2aII UFGbo5ehKk; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Eric, I did go back and read Remi's email. Sorry, I have to catch up with some IETF email. Yes, it does go back to the problem that Remi raised, but I don't see a problem with a web browser adding a Bonjour plugin for mDNS - that may not be asking the user a whole lot. I do appreciate Remi's point that many browsers to not have such a plugin. I and Wes personally don't like using an IPv4 URL to configure the new IPv6 CPE Router. We have to plan for a day "x" years from now when no IPv4 is provisioned on the device. We have got to have an IPv6 solution to configure the device from a web browser. =20 Also, when the CPE Router is powered up for the first time, a unique ULA may be generated by the device that persists for the lifetime of operation of the device. This ULA may be mapped to mDNS - I haven't read the mDNS draft yet to make sure if the protocol allows for a non-link-local address to be returned in the mDNS response. I would think it should be possible. Also since the ULA is pseudo-random, in case a user at home discovers a conflict, a knob on the CPE Router can generate a new ULA. Hemant From owner-v6ops@ops.ietf.org Sat Jul 26 00:19:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C203F3A699E for ; Sat, 26 Jul 2008 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CG3KQWRHmYk for ; Sat, 26 Jul 2008 00:19:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFD913A6991 for ; Sat, 26 Jul 2008 00:19:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMdzz-0009cZ-Qf for v6ops-data@psg.com; Sat, 26 Jul 2008 07:15:27 +0000 Received: from [212.27.42.64] (helo=smtp7-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMdzw-0009cE-7m for v6ops@ops.ietf.org; Sat, 26 Jul 2008 07:15:26 +0000 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 05A01B0179; Sat, 26 Jul 2008 09:15:14 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp7-g19.free.fr (Postfix) with ESMTP id 87E20B0187; Sat, 26 Jul 2008 09:15:13 +0200 (CEST) Message-ID: <488ACED2.9060606@free.fr> Date: Sat, 26 Jul 2008 09:14:26 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> <48899888.9060006@it.uc3m.es> <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> <4889EA84.9000008@free.fr> <488A52A3.5080300@gmail.com> In-Reply-To: <488A52A3.5080300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian E Carpenter - Le 7/26/08 12:24 AM : >> Note that, using RFC 2663's terminology, the distinction is more >> precisely: - NAT64: IPv6 internal side, IPv4 external side - NAT46: >> IPv4 internal side, IPv6 external side > > Where do you find that in 2663? In the introduction: "network's internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network." Another way to say it is that addresses that need translation are those of hosts in the internal side network. They are translated as source addresses in the internal to external direction, as destination addresses in the external to internal direction. > In any case I think the notions of "internal" and "external" are not > well-defined in a network which mixes regions of pure IPv6, regions > of pure IPv4 and dual-stack regions. Also, NAT terminology tends to > be based on the distinction between private ambiguous and public > global addresses, which makes no sense for IPv6. > >> (NATs that do port forwarding support connections initiated from >> both sides.) > > Exactly. I don't think this can be reduced to two acronyms. I also find that more precise acronyms could be useful. For example, private IPv4 address spaces (RFC 1918), say 4p, could advantageously be distinguished from the global IPv4 address space, say 4g. Thus: - NAT4p6 and NAT64g can be cascaded to be equivalent to a NAT4p4g for connections initiated by 4p hosts (no DNS ALG needed). - In the reverse cascade, NAT4g6-NAT64p, the NAT 4g6 has the problem that, for connections initiated by 4g hosts, there is no stateless translation of 4g addresses into routable v6 addresses. Regards Rémi Després From owner-v6ops@ops.ietf.org Sat Jul 26 01:10:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7593A67EB for ; Sat, 26 Jul 2008 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaKcs4leig89 for ; Sat, 26 Jul 2008 01:10:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EB6A3A695A for ; Sat, 26 Jul 2008 01:10:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMepb-000DlC-Ha for v6ops-data@psg.com; Sat, 26 Jul 2008 08:08:47 +0000 Received: from [192.100.122.235] (helo=mgw-fb01.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMepV-000Dkl-Bt for v6ops@ops.ietf.org; Sat, 26 Jul 2008 08:08:45 +0000 Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6Q7HEQG025332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 26 Jul 2008 10:17:15 +0300 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6Q7DnhX013725; Sat, 26 Jul 2008 10:13:52 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jul 2008 10:13:49 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jul 2008 10:13:40 +0300 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-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? Date: Sat, 26 Jul 2008 10:13:39 +0300 Message-ID: In-Reply-To: <200807251911.16835.rdenis@simphalempin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? Thread-Index: AcjuceKDINinv87LSc69AMPEBAMdDgAenbCA References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com> From: "teemu.savolainen@nokia.com" To: , Cc: , , , X-OriginalArrivalTime: 26 Jul 2008 07:13:40.0100 (UTC) FILETIME=[21292C40:01C8EEEF] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I have a general problem here that I do not fully understand: why = _a_solution_ should not require changes for IPv6-only or dual-stack = host, _if_ that gives better functionality than _a_solution_ that does = not require changes? We are not limited to single solution on this = problem space, right? We have number of dual-stack implementations out there for which = solutions that do not require changes are very desirable. We also have a large number of to-be-deployed devices in the pipeline, = which still can be modified in any ways seen useful. I argue that this = number is far larger than the number of already deployed devices, and = that this number of devices should not have suboptimal functionality = just because we do not want to touch to already deployed v6-capable = hosts. IPv6 deployment is anyhow just beginning. Best regards, Teemu >-----Original Message----- >From: owner-v6ops@ops.ietf.org=20 >[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext R=E9mi = Denis-Courmont >Sent: 25 July, 2008 19:11 >To: marcelo bagnulo braun >Cc: Jari Arkko; Dave Thaler; 'IPv6 Operations'; Brian E Carpenter >Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are=20 >changes in dualstack hosts acceptable or not? > >Le vendredi 25 juillet 2008 18:01:38 marcelo bagnulo braun,=20 >vous avez =E9crit=A0: >> Now, the nice thing about requirements is that when you read=20 >them into=20 >> detail, they can be interpreted in both ways. > >No. A dual-stack host is NOT a v4-only host. If you read the=20 >requirements to the letter, nothing excludes changes to=20 >dual-stack nodes. But I humbly think the real question is not=20 >what the current requirements say. > >> So, the question is: is a dual stack host a v6 host (i.e. changes are >> acceptable) or is it a v4 host (i.e. changes are not acceptable)? > >Regardless of the current requirements, I would argue it is=20 >not acceptable that dual-stack nodes need to be modified, for=20 >the exact same reason as it is not acceptable that IPv4-only=20 >nodes need to be modified: deployment would be highly impractical. > >-- >R=E9mi Denis-Courmont >http://www.remlab.net/ > > From owner-v6ops@ops.ietf.org Sat Jul 26 01:41:45 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA29F28C106 for ; Sat, 26 Jul 2008 01:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmkNPr+cqOB9 for ; Sat, 26 Jul 2008 01:41:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE65328C15C for ; Sat, 26 Jul 2008 01:41:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMfJ7-000G91-S7 for v6ops-data@psg.com; Sat, 26 Jul 2008 08:39:17 +0000 Received: from [69.147.75.103] (helo=web62511.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMfJ3-000G8l-Fi for v6ops@ops.ietf.org; Sat, 26 Jul 2008 08:39:15 +0000 Received: (qmail 11076 invoked by uid 60001); 26 Jul 2008 08:32:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=Ywwnihkfux1F1YD6ibRJgurne0W0orNpHicZrr1/u/BmeiTCPZT8mp/5LZQ5zQjhM0//WfBF3xVviEekFf0g3dfCakMkc79R5om21u3ANJbAR5sgLsfSxb6vQuFAgFgaUkPKxtYN60foVwMgBcphg/ygblz1dCePOTQSL9Mwxng=; Received: from [90.32.94.194] by web62511.mail.re1.yahoo.com via HTTP; Sat, 26 Jul 2008 01:32:29 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Sat, 26 Jul 2008 01:32:29 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review To: "Hemant Singh \(shemant\)" Cc: David Miles , v6ops WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <191875.8255.qm@web62511.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Fri, 7/25/08, Hemant Singh (shemant) wrote: > Yes, the internals of the CPE Router does include a bridge > that is always up if the router is powered up. So, the CPE Router need a MLD snooping function [RFC4541] on the LAN bridge. Francois-Xavier From owner-v6ops@ops.ietf.org Sat Jul 26 02:34:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBDB3A6991 for ; Sat, 26 Jul 2008 02:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpsmIr9ePJOE for ; Sat, 26 Jul 2008 02:34:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 874E33A67EB for ; Sat, 26 Jul 2008 02:34:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMg8h-000Kgy-9F for v6ops-data@psg.com; Sat, 26 Jul 2008 09:32:35 +0000 Received: from [212.27.60.42] (helo=postfix1-g20.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMg8d-000Kgd-K1 for v6ops@ops.ietf.org; Sat, 26 Jul 2008 09:32:33 +0000 Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id EB7E428AE3A2 for ; Sat, 26 Jul 2008 11:32:27 +0200 (CEST) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id D0AE73F6225; Sat, 26 Jul 2008 11:31:57 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp5-g19.free.fr (Postfix) with ESMTP id 0E56D3F6209; Sat, 26 Jul 2008 11:31:56 +0200 (CEST) Message-ID: <488AEEDD.5070702@free.fr> Date: Sat, 26 Jul 2008 11:31:09 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "teemu.savolainen@nokia.com" CC: rdenis@simphalempin.com, marcelo@it.uc3m.es, jari.arkko@piuha.net, dthaler@windows.microsoft.com, v6ops@ops.ietf.org, brian.e.carpenter@gmail.com Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: teemu.savolainen@nokia.com - Le 7/26/08 9:13 AM : > We also have a large number of to-be-deployed devices in the > pipeline, which still can be modified in any ways seen useful. I > argue that this number is far larger than the number of already > deployed devices, and that this number of devices should not have > suboptimal functionality just because we do not want to touch to > already deployed v6-capable hosts. > > IPv6 deployment is anyhow just beginning. Full support. One more point: these "modifications" must ensure *backward compatibility*. - This the right way to add fuctionnalities. - Unmodified" devices continue to operate as before. - They don't prevent others do take advantage of new capabilities. When backward compatibility is preserved, I personnally prefer more precise words as "complements", or "enhancements", or "extensions", to "modifications". Regards. Rémi Després From owner-v6ops@ops.ietf.org Sat Jul 26 11:43:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FCA28C1D0 for ; Sat, 26 Jul 2008 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBB6afGh6kRc for ; Sat, 26 Jul 2008 11:43:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84F8F28C1CB for ; Sat, 26 Jul 2008 11:43:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KModq-000J2w-Tj for v6ops-data@psg.com; Sat, 26 Jul 2008 18:37:18 +0000 Received: from [72.14.214.231] (helo=hu-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KModm-000J2W-0n for v6ops@ops.ietf.org; Sat, 26 Jul 2008 18:37:16 +0000 Received: by hu-out-0506.google.com with SMTP id 23so715104huc.11 for ; Sat, 26 Jul 2008 11:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Iq5O7wleC7Vfo8LamNchQkEbkLWrGI63qPea5jNDrEQ=; b=myLJd0+zpl+qnjhMMN1/YU79W8GcKE8L8kZW2Se6H0Fgk3k9gW+rnG7p7YTUhefAOQ Uny2JgEM0KnZRCrLFDpQDG4KR+SnF6O3Qasnck7K0dfZsT/3BXNdqjONzyVNnS/mqGyd ZChLhUPqhsEqRDU6qMzWGO6vt0ocO28sarWto= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=dGS8Y39jDH4m+1xNGAvx7JJwQDPOuIhvtz57F7E2enVpyQCUiCWiGmDdoaXKGZTGOn /F/f/xFia6tfpgNnc//BlRv9m0/eTdeGcPIY8Y08na4JUbU4aQR/H78z2ccpqOgldjkS GZUomBU12yM4E8lcfsp7VTMZQyEzZlUHoAmY8= Received: by 10.210.16.20 with SMTP id 20mr3646233ebp.134.1217097429057; Sat, 26 Jul 2008 11:37:09 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.64.64]) by mx.google.com with ESMTPS id u14sm18163800gvf.6.2008.07.26.11.37.07 (version=SSLv3 cipher=RC4-MD5); Sat, 26 Jul 2008 11:37:08 -0700 (PDT) Message-ID: <488B55F4.1020202@gmail.com> Date: Sun, 27 Jul 2008 04:51:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Jari Arkko , Dave Thaler , 'IPv6 Operations' Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-0: native connectivity withdual stack hosts References: <4889F590.4040601@it.uc3m.es> In-Reply-To: <4889F590.4040601@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Marcelo, On 2008-07-26 03:47, marcelo bagnulo braun wrote: > Hi > > This is follow up on the previous message about dual stack being > susceptible to modification or not. > As i mentioned earlier, Dave and Jari have expressed that nodes must be > able to use native connectivity, in order to avoid apps that are not nat > compatible to crash. > However, in our current set of requirements, we have > R3: Interaction with dual-stack hosts > > Translation mechanism MUST allow using native connectivity when it is > available. This means that if a v6-only nodes wants to communicate > with a dual stack, it must use native v6 connectivity and if a v4- > only nodes wants to communicate with a dual stack, it must use native > v4 connectivity.(In this case, dual stack means a host with both IPv6 > and IPv4 stacks, wich are both active, i.e. they have v4 and v6 > connectivity). > > > whcih in conjuction with R1: > > R1: Changes in the hosts > > The translation mechanism MUST NOT require changes in the v4-only > nodes to support the Basic requirements described in this section, > unless explicitly stated in the particular requirement. The > translation mechanism MAY require changes to v6-only nodes. > > results that IPv6 only nodes, (which in our document must be interpreted > as a node without a v4 address irrespectively whether it has a v4 stack or > not) MAY require modifications to satisfy this requirement. It seems to me that a dual stack node with no (valid) IPv4 address is going to have to do something today, even in the absence of nat64, so we can ask what existing stacks already do in that situation - and once again, it's a good start if nothing gets worse when nat64 exists. > So, this means that unmodified ipv6 only hosts may not be able to use > prefer the native connectivity and hence the apps that are not > nat compatible would not work in these unmodified v6 only hosts. And if so, we have not made things worse. And isn't this a defect that stack maintainers will need to fix in any case? > Do people are ok with this, or people think that we should be stronger > on this and try that unmodified v6 only hosts can prefer native > connectivity? Sorry, I don't really understand what you are suggesting. > > One more comment: Imposing this requirement for unmodified v4 > only hosts may be impossible to reach... comments? You mean that the above MUST NOT may be impossible? Well, then we can all go home ;-) Brian From owner-v6ops@ops.ietf.org Sat Jul 26 11:43:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6429228C1CE for ; Sat, 26 Jul 2008 11:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F76WGc9BZkab for ; Sat, 26 Jul 2008 11:43:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A2F828C1CD for ; Sat, 26 Jul 2008 11:43:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KModk-000J2T-D8 for v6ops-data@psg.com; Sat, 26 Jul 2008 18:37:12 +0000 Received: from [72.14.214.225] (helo=hu-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KModf-000J24-MG for v6ops@ops.ietf.org; Sat, 26 Jul 2008 18:37:09 +0000 Received: by hu-out-0506.google.com with SMTP id 23so715099huc.11 for ; Sat, 26 Jul 2008 11:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ye9J3aCbG9rD6J9v29LcPKliXJdrwvwkOuORB/Aj6Bo=; b=lkeDzmLSEeDvNRWgIj0qfFIvXHcoGroSFacYj9HDDcDwf+S5L2E4prnwbnQvjj0nwF EHd/oDRYhcUv6kurFmOzgT7hcLZtUowSoehQtRCPoec3NZi6htyjRE2bT/C692+zK9by YbXWdb8kbNkcSut0n6T8icQ7jLfSXbr4kH6J8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=uNXpvzxM66Re6LmlVf8RTSur3M244xxb3X3bgYP6+OB3ucu6palMlm3YdWlL70pSei hhPD6QW6gKTihGihh+KoNVGSXGbm4r6dmMrL/H8mDmWHweTGWPgVR6aVwmBJao5INPbE dFPPEECuTWCMOJ2c2NGJ2bpCX2BBQZiC98qL0= Received: by 10.210.56.7 with SMTP id e7mr3650226eba.123.1217097425517; Sat, 26 Jul 2008 11:37:05 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.64.64]) by mx.google.com with ESMTPS id t2sm24547392gve.9.2008.07.26.11.37.04 (version=SSLv3 cipher=RC4-MD5); Sat, 26 Jul 2008 11:37:04 -0700 (PDT) Message-ID: <488B50F2.5010703@gmail.com> Date: Sun, 27 Jul 2008 04:29:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun CC: 'IPv6 Operations' Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - who from the v6 sidecan talk to who in the v4 side? References: <4889EE2B.4010608@it.uc3m.es> In-Reply-To: <4889EE2B.4010608@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Regards Brian Carpenter University of Auckland On 2008-07-26 03:15, marcelo bagnulo braun wrote: > Hi, >=20 > In the current version of the draft we have that: >=20 > R2: Basic communication support > R2.1: Translation mechanism must support v6-initiated short-lived local= > handle (as defined in Section 3.1. >=20 > There is strong consensus on this >=20 > Question: v6-initiated connections from which v6 address to which v4 > address? > I have always assumed all v6 address and all v4 addresses, but after > some discussion, it is not obvious=E2=80=A6 >=20 > Do people think that this goal is achieved is a subset of v6 source > address can reach a subset of v4 addresses? Or do people think that thi= s > goal is achieved if a subset of v6 addresses can reach all the v4 > addresses? In my view, neither is OK for a general solution. There may be communitie= s that can manage with a subset, but I don't see how it can solve the residual general problem of coexistence (i.e. the part that isn't solved by the dual stack model). Brian From owner-v6ops@ops.ietf.org Sat Jul 26 11:53:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAF73A6ACE for ; Sat, 26 Jul 2008 11:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H-6JFuGoFRO for ; Sat, 26 Jul 2008 11:53:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32F053A696F for ; Sat, 26 Jul 2008 11:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMosO-000K0O-0Q for v6ops-data@psg.com; Sat, 26 Jul 2008 18:52:20 +0000 Received: from [72.14.214.230] (helo=hu-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMosJ-000Jzp-S7 for v6ops@ops.ietf.org; Sat, 26 Jul 2008 18:52:17 +0000 Received: by hu-out-0506.google.com with SMTP id 23so716830huc.11 for ; Sat, 26 Jul 2008 11:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qdrd/KWjrsW1oUDp3epl15p1WaqXZY8xWjMQIA+8SW4=; b=Gtsm/dOBl0WKIDS1mTXXjKNFCi4W6yVzGTcCEQKNK9KbqA+qA7hAQGu87t00pWUPor H2z0W65sxg/1YOMp3oV3r+wvbZL/ENU+m8VQdGg8Gm5Qhr1iuSzEmZMaGrMxEcwzohia JrzWFuSMofoOnm9wsZvDciwTAzmCkK2Gf4/cY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=u/QgBMSmTQ0mbkMq/pD7uTbRLhOXTZ333hU7LBaX0ZRVSRn32K/4qGQ8O0SbeBYFkH pJCSdibwZ3JDrVp00RtDTjLoMZKqS9WF4V5wavkM92WyVVnM6GRrY7jPJhUhyTZaef1S fSbJSu/H76lu5p/vBlwq1hzzqqr/eFnjokUOQ= Received: by 10.210.16.11 with SMTP id 11mr3626000ebp.187.1217097422344; Sat, 26 Jul 2008 11:37:02 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.64.64]) by mx.google.com with ESMTPS id t12sm6947955gvd.10.2008.07.26.11.37.00 (version=SSLv3 cipher=RC4-MD5); Sat, 26 Jul 2008 11:37:01 -0700 (PDT) Message-ID: <488B4B8B.3050701@gmail.com> Date: Sun, 27 Jul 2008 04:06:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun CC: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= , Jari Arkko , Dave Thaler , 'IPv6 Operations' Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com> <4889FD50.4060406@it.uc3m.es> In-Reply-To: <4889FD50.4060406@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-26 04:20, marcelo bagnulo braun wrote: > R=C3=A9mi Denis-Courmont escribi=C3=B3: >> Le vendredi 25 juillet 2008 18:01:38 marcelo bagnulo braun, vous avez >> =C3=A9crit : >> =20 >>> Now, the nice thing about requirements is that when you read >>> them into detail, they can be interpreted in both ways. >>> =20 >> >> No. A dual-stack host is NOT a v4-only host. If you read the >> requirements to the letter, nothing excludes changes to dual-stack >> nodes. But I humbly think the real question is not what the current >> requirements say. >> >> =20 >>> So, the question is: is a dual stack host a v6 host (i.e. changes are= >>> acceptable) or is it a v4 host (i.e. changes are not acceptable)? >>> =20 >> >> Regardless of the current requirements, I would argue it is not >> acceptable that dual-stack nodes need to be modified, for the exact >> same reason as it is not acceptable that IPv4-only nodes need to be >> modified: deployment would be highly impractical. >> =20 >=20 > do you think it is acceptable to require some manual configuration in > them to make them work? I think we need to follow the 'first, do no harm' principle to get this right in the requirements. In other words, the situation MUST be no worse for unmodified RFC2460/3484 hosts than it is today. Of course it may be better - otherwise we wouldn't be here at all. If that requires configuration, it seems OK to me. After all, we have to be realistic. Brian From owner-v6ops@ops.ietf.org Sat Jul 26 22:52:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BA53A67DF for ; Sat, 26 Jul 2008 22:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0QO3LWhe-8s for ; Sat, 26 Jul 2008 22:52:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 366953A679C for ; Sat, 26 Jul 2008 22:52:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMz6Y-0007wA-Ko for v6ops-data@psg.com; Sun, 27 Jul 2008 05:47:38 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMz6U-0007vN-TT for v6ops@ops.ietf.org; Sun, 27 Jul 2008 05:47:37 +0000 Received: (qmail 30504 invoked by uid 417); 27 Jul 2008 05:47:09 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 27 Jul 2008 05:47:09 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Sat, 26 Jul 2008 23:47:08 -0600 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: "Stark, Barbara" , "Alain Durand" , v6ops@ops.ietf.org Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Sat, 26 Jul 2008 23:47:08 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [192.117.238.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > I did go back and read Remi's email. Sorry, I have to catch up with > some IETF email. Yes, it does go back to the problem that Remi raised, > but I don't see a problem with a web browser adding a Bonjour plugin for > mDNS - that may not be asking the user a whole lot. I do appreciate > Remi's point that many browsers to not have such a plugin. I am not sure it is in our mandate to require changes in a browser or that they support a mDNS plugin. > I and Wes > personally don't like using an IPv4 URL to configure the new IPv6 CPE > Router. We have to plan for a day "x" years from now when no IPv4 is > provisioned on the device. We have got to have an IPv6 solution to > configure the device from a web browser. Agreed > Also, when the CPE Router is powered up for the first time, a unique ULA > may be generated by the device that persists for the lifetime of > operation of the device. This ULA may be mapped to mDNS - I haven't > read the mDNS draft yet to make sure if the protocol allows for a > non-link-local address to be returned in the mDNS response. I would > think it should be possible. Also since the ULA is pseudo-random, in > case a user at home discovers a conflict, a knob on the CPE Router can > generate a new ULA. See comment above. I am not sure that mandating a change in browser software and CPE hardware is the right answer to this requirement. From owner-v6ops@ops.ietf.org Sat Jul 26 23:31:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB913A6843 for ; Sat, 26 Jul 2008 23:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5JE816SBn1V for ; Sat, 26 Jul 2008 23:31:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F32393A6768 for ; Sat, 26 Jul 2008 23:31:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMzlt-000BCQ-0t for v6ops-data@psg.com; Sun, 27 Jul 2008 06:30:21 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMzlo-000BBy-Ou for v6ops@ops.ietf.org; Sun, 27 Jul 2008 06:30:19 +0000 X-IronPort-AV: E=Sophos;i="4.31,258,1215388800"; d="scan'208";a="15493516" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2008 06:30:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6R6U9f7012257 for ; Sun, 27 Jul 2008 08:30:09 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6R6U9Mr020845 for ; Sun, 27 Jul 2008 06:30:09 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Jul 2008 08:30:08 +0200 Received: from [172.16.7.52] ([10.61.64.35]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Jul 2008 08:30:08 +0200 Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Monday and Thursday Date: Sun, 27 Jul 2008 07:30:08 +0100 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 27 Jul 2008 06:30:08.0555 (UTC) FILETIME=[36F8C7B0:01C8EFB2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=465; t=1217140209; x=1218004209; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Monday=20and=20Thursday |Sender:=20; bh=gH33ziTdA9MLObD+LQEEK9SsBeQ6PDh8kOS6j7dWztM=; b=j84/OmBA0sLWS35EHTru4o6WGI5VH4U54EUgorli5pinUHflkcipCdQZmG 7vIQaNwhKbG/4B5aTZhFQ9lZCUiqiEVRHYk5yT0I+8p7zHDhGaz3JwAb1wXa ldGkgp5LrW; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: A revised agenda is at http://www.ietf.org/proceedings/08jul/agenda/v6ops.html . The meeting will use both the Monday and Thursday slots. This will give us a more relaxed pace and hopefully better discussion, and allow for two additional topics. I am still in need of volunteers to take minutes and t act as jabber scribes. I have specifically been asked to have someone monitor jabber for potential questions from remote attendees. Help, please? From owner-v6ops@ops.ietf.org Sun Jul 27 03:17:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9536D28C105 for ; Sun, 27 Jul 2008 03:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20rp1aYYfKCP for ; Sun, 27 Jul 2008 03:17:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC6F728C116 for ; Sun, 27 Jul 2008 03:17:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KN3Fc-00071r-Bk for v6ops-data@psg.com; Sun, 27 Jul 2008 10:13:16 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KN3FY-000712-E4 for v6ops@ops.ietf.org; Sun, 27 Jul 2008 10:13:14 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6RAD3Q9025544; Sun, 27 Jul 2008 13:13:03 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6RAD2Fi025537; Sun, 27 Jul 2008 13:13:02 +0300 Date: Sun, 27 Jul 2008 13:13:02 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= , IPv6 Operations Subject: Re: v6ops-nat64-pb-statement-req: Scoping and title In-Reply-To: <488A52A3.5080300@gmail.com> Message-ID: References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com><48873AC0.5 090401@it.uc3m.es><200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com><48 8833F7.7030606@it.uc3m.es> <4888981D.5090701@sri.com> <48899888.9060006@it.uc3m.es> <200807251215.m6PCF4d1017179@cichlid.raleigh.ibm.com> <4889EA84.9000008@free.fr> <488A52A3.5080300@gmail.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7840/Sun Jul 27 03:10:52 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, 26 Jul 2008, Brian E Carpenter wrote: > In any case I think the notions of "internal" and > "external" are not well-defined in a network which > mixes regions of pure IPv6, regions of pure IPv4 > and dual-stack regions. Also, NAT terminology tends to > be based on the distinction between private ambiguous > and public global addresses, which makes no sense > for IPv6. FWIW, it's possible to build a router (or NAT) that has a single logical interface. The draft assumes at least two interfaces. Not that such boxes are very widely deployed in practise.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 10:29:44 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CE23A6803 for ; Sun, 27 Jul 2008 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biMYSCLHIHWz for ; Sun, 27 Jul 2008 10:29:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 269D73A689A for ; Sun, 27 Jul 2008 10:29:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KN9zv-0003bj-Ql for v6ops-data@psg.com; Sun, 27 Jul 2008 17:25:31 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KN9zs-0003b7-9z for v6ops@ops.ietf.org; Sun, 27 Jul 2008 17:25:30 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6RHPGni002176; Sun, 27 Jul 2008 20:25:16 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6RHPF6P002171; Sun, 27 Jul 2008 20:25:16 +0300 Date: Sun, 27 Jul 2008 20:25:15 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: alain_durand@cable.comcast.com Subject: draft-durand-dual-stack-lite-00 general comments Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.1/7840/Sun Jul 27 03:10:52 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This architecture is essentially DSTM (base version) with permanent addressing coupled with a v4 NAT functionality. A more generic solution could also be possible which decouples tunnel+NAT functionality because the NAT is not necessarily needed in all deployments. The description of the proposal seems somewhat on the lengthy side. Essentially, it seems that the proposal essentially requires the following: 1) modifications to decapsulating NAT to look into inner v4 header for multiplexing purposes (and not just v6 header). Requires colocating the decapsulator with NAT. 2) a mechanism to distribute tunnel endpoint information to the customer edge devices (not specified in this document). 3) either (unspecified in this document): a) a method to figure out which customers support this approach (a significant issue?) and turn off v4 DHCP on those customer links; b) a change in the client code to first obtain v6 address and tunnel endpoint information, and if that is obtained, not get a DHCPv4 lease; or c) change from providing public v4 addresses to private v4 addresses (i.e. worsening existing service to make a new offering more lucrative) 4) TCP MSS rewriting on edge devices and NAT box to better cope with lowered effective maximum packet size OR a way to use a higher MTU on the path between the edge device and the tunnel box. Of these, 1) is a minor modification. 2) requires standardization. 3) is mostly a (significant) deployment problem -- you can't control all the edge device implementations users may have so the ISP would probably need to do 3.a) and/or 3.c). 4) is commonly used already although probably not specified in any IETF standard. Given the difficulty of 3), it seems that the approach is basically only suitable in deployments where the users can only connect to the ISP using a CPE device provided by the ISP. Users' own CPE boxes or cable/DSL cards attached to a host operating system (e.g. USB sticks) would be a challenge. From my perspective, "you must use our CPE device (and pay dearly for it!)" service provisioning is rather rare and not necessarily a desirable approach from the user POV. As such if 3) can't be solved in a generic fashion, the solution has only limited applicability. Nit: It's not clear why Section 4.1 suggests using 0.0.0.1 as source address. The CPE box is going to have some address on the LAN interface and it could just as well use that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 10:40:02 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023733A6933 for ; Sun, 27 Jul 2008 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+YDQzQ0Hqhm for ; Sun, 27 Jul 2008 10:40:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CDD53A68AA for ; Sun, 27 Jul 2008 10:40:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNACq-0004yw-L6 for v6ops-data@psg.com; Sun, 27 Jul 2008 17:38:52 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNACn-0004yD-VO for v6ops@ops.ietf.org; Sun, 27 Jul 2008 17:38:51 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6RHceAT002491; Sun, 27 Jul 2008 20:38:41 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6RHceMb002487; Sun, 27 Jul 2008 20:38:40 +0300 Date: Sun, 27 Jul 2008 20:38:40 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo braun cc: "'IPv6 Operations'" , "'Magnus Westerlund'" Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-0: protocols supported In-Reply-To: <4889FA54.2090600@it.uc3m.es> Message-ID: References: <4889FA54.2090600@it.uc3m.es> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7840/Sun Jul 27 03:10:52 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 25 Jul 2008, marcelo bagnulo braun wrote: > Question: what is the rationale we include TLS here? souyld we have a citeria > of which protocols shoudl be in this req? > > Question: should we move DCCP and SCTP to MUST rahter than SHOULD? (Magnus, > is this what you were requesting in your emails before?) We could require a lot of things. The main thing this could have impact on is the length of the specification and the time it would take to develop it; I don't see how it could help in selecting solutions because all the solutions could be extended to provide this functionality. In all probability it would have zero impact on what gets deployed out there. I.e.: even if such functionality would be a MUST in a solution, vendors and providers would likely, at least initially, ship a NATxx box that wouldn't support these features. As such, I see little value in practise of adding SCTP or DCCP to the 'must' list. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 10:43:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339833A68AA for ; Sun, 27 Jul 2008 10:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcmetkPV-2uL for ; Sun, 27 Jul 2008 10:43:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BA5D3A6934 for ; Sun, 27 Jul 2008 10:43:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNAGc-0005QS-DA for v6ops-data@psg.com; Sun, 27 Jul 2008 17:42:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNAGY-0005Pk-WC for v6ops@ops.ietf.org; Sun, 27 Jul 2008 17:42:44 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6RHgb2e002578; Sun, 27 Jul 2008 20:42:37 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6RHgbga002575; Sun, 27 Jul 2008 20:42:37 +0300 Date: Sun, 27 Jul 2008 20:42:37 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo braun cc: "'IPv6 Operations'" Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-0: behave requirements In-Reply-To: <4889FC58.4020003@it.uc3m.es> Message-ID: References: <4889FC58.4020003@it.uc3m.es> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7840/Sun Jul 27 03:10:52 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 25 Jul 2008, marcelo bagnulo braun wrote: > R7: Behave requirements > The translation mechanism MUST be compliant with the requirements for IPv4 > NATs defined in [I-D.ietf-behave-tcp] and in [RFC4787] when applicable. These > requirements should be interpreted with the IPv6 side on the IPv6-IPv4 > translator being the IPv4 private side of the conventional NAT. > > First, this heavily assumes v6 initiated communications. If we have nat46, we > probably don?t need this > > Question: should we include the behave requirements for ICMP, DCCP, SCTP? I believe making unmodified "ping", "traceroute" and PMTUD work across the translator is a MUST have. The loss of operational diagnostic capabilities is too big otherwise. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 11:10:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392DD3A67DA for ; Sun, 27 Jul 2008 11:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d73FtpKfiYwC for ; Sun, 27 Jul 2008 11:10:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D076F3A6851 for ; Sun, 27 Jul 2008 11:10:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNAgc-0008Qs-Pk for v6ops-data@psg.com; Sun, 27 Jul 2008 18:09:38 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNAgY-0008QF-L9 for v6ops@ops.ietf.org; Sun, 27 Jul 2008 18:09:36 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6RI9V1c003118 for ; Sun, 27 Jul 2008 21:09:31 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6RI9VeS003115 for ; Sun, 27 Jul 2008 21:09:31 +0300 Date: Sun, 27 Jul 2008 21:09:31 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops-nat64-pb-statement-req-00 comments Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.1/7840/Sun Jul 27 03:10:52 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: My high-level comment on the draft is that we IMHO need to give a brief description of the translation scenarios that the solution(s) should address. This gives much better context on the requirements and what's behind them. And I don't mean something like the list in Section 3.1 or Figure 2; those are so simplistic that are useless in a document like this. In Section 3.2: In addition, there is an architectural consideration, that we would be imposing v6-only nodes to support "NAT hacks" in order to enable communication with the v4 world, and that those modifications may stay forever, even when the need for communication with the v4-Internet is not so pressing. I'm not sure if I see this as a very convincing argument. If the "NAT hack" is not made on the v6-only host, it will be made in a translator in the network, which probably also may stay forever. Which of these two options is worse from architectural point of view? Putting it in a host gives the host a potential to have insight in how the hack works; in the network, this would likely be essentially a black box. 4. Requirements for new generation of v4-v6 translation mechanisms This list of requirements basically should contain all the aspects that should be considered when designing a new generation of translation mechanisms. This begs the question, "can we describe the scenarios where these translation mechanisms would be deployed?". And I'm not interested in a list like shown in Section 3.1. What I would be very interested in seeing is a concrete example of deployment cases (e.g. about 1-2 paragraphs of concise text per case). This would ground this work in reality and given much better context to what problems we are actually trying to solve. I think folks have been discussing about 2-4 applicable scenarios that should be covered by this document. Section 4.1 R5 "IPv6 routing should not be affected in any way". Some mandatory requirements use uppercases, some don't. The practise should probably be made uniform one way or the other. Section 4.1 R9 "MUST not result in a significantly vulnerable Internet" -- compared to what? What we currently have? Do we have that described or defined somewhere? This will be prone to arguments later on if this is not clear enough now. editorial --------- Section 2.1.3 "translated forwarded" -- is something missing here? Section 2.1.3 talks about embedding in "a "privacy address". I have no idea what this means. RFC4941 certainly doesn't consider any kind of embedding like this. Section 2.2 says: "Some are turning off IPv4 immediately, at least as a customer service." -- this seems like an overly broad statement, requiring at least a reference. I haven't seen anyone mentioning which network/ISP/whatever would go this far, or even plan to do it? Section 3.1: s/distcntion/distinction/ Section 3.2: s/f other/if other/, s/e modified/be modified/. Section 3.4: s/NAT4/NAT46/ ? Section 4.1 R3 s/wich/which/, R8 s/suport/support/. Section 4.1 and 4.2 in general could use a proofreading and making sure each sentence ends to a dot :-). Section 4.2 I1 is missing, is it intentional? Section 4.2 I2 IMHO implies that the NAT box wouldn't even need to be on the (regular) forwarding path, is this interpretation correct? Section 6: R10 on DNSSEC also strongly relates to security issues. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 11:45:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF9D3A6803 for ; Sun, 27 Jul 2008 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbsyc4dNxuud for ; Sun, 27 Jul 2008 11:45:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C898E3A68A0 for ; Sun, 27 Jul 2008 11:45:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNBDO-000CSv-6A for v6ops-data@psg.com; Sun, 27 Jul 2008 18:43:30 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNBDL-000CS0-7m for v6ops@ops.ietf.org; Sun, 27 Jul 2008 18:43:28 +0000 Received: from leon.remlab.net (unknown [IPv6:2001:df8:0:16:219:d2ff:fe07:5de5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 2AA8859 for ; Sun, 27 Jul 2008 20:43:26 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: v6ops@ops.ietf.org Subject: Re: draft-durand-dual-stack-lite-00 general comments Date: Sun, 27 Jul 2008 21:43:24 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807272143.24375.rdenis@simphalempin.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sunday 27 July 2008 20:25:15 Pekka Savola, you wrote: > Nit: It's not clear why Section 4.1 suggests using 0.0.0.1 as source > address. The CPE box is going to have some address on the LAN > interface and it could just as well use that. By the way, my Ubuntu PC refuses to accept 0.0.0.1 as a valid address. I=20 reckon the same operating system is found in certain CPEs. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From owner-v6ops@ops.ietf.org Sun Jul 27 14:24:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6E73A6818 for ; Sun, 27 Jul 2008 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.6 X-Spam-Level: **** X-Spam-Status: No, score=4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wf6bsUMfS2j for ; Sun, 27 Jul 2008 14:24:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4D383A65A6 for ; Sun, 27 Jul 2008 14:24:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNDfT-0004YI-U6 for v6ops-data@psg.com; Sun, 27 Jul 2008 21:20:39 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNDfQ-0004XP-Q5 for v6ops@ops.ietf.org; Sun, 27 Jul 2008 21:20:38 +0000 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9320147; Sun, 27 Jul 2008 17:20:07 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 17:20:08 -0400 Received: from 130.129.64.64 ([130.129.64.64]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Jul 2008 21:20:07 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sun, 27 Jul 2008 17:19:49 -0400 Subject: Re: draft-durand-dual-stack-lite-00 general comments From: Alain Durand To: =?ISO-8859-1?B?UultaQ==?= Denis-Courmont , Message-ID: Thread-Topic: draft-durand-dual-stack-lite-00 general comments Thread-Index: AcjwGwDe8wNMwF0qS/KCqy74er+GQwAE39UO In-Reply-To: <200807272143.24375.rdenis@simphalempin.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Jul 2008 21:20:08.0045 (UTC) FILETIME=[8B8C51D0:01C8F02E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/27/08 2:43 PM, "R=E9mi Denis-Courmont" wrote: > On Sunday 27 July 2008 20:25:15 Pekka Savola, you wrote: >> Nit: It's not clear why Section 4.1 suggests using 0.0.0.1 as source >> address. The CPE box is going to have some address on the LAN >> interface and it could just as well use that. >=20 > By the way, my Ubuntu PC refuses to accept 0.0.0.1 as a valid address. I > reckon the same operating system is found in certain CPEs. This address is mainly used in the case a device -that-is-not-behind-a-CPE- wants to initiate the tunnel. In this mode of operation, dual-stack lite is a very simple alternative to NAT-PT. Now, I suggested 0.0.0.1, but this may not be the best choice. I will probably end up asking IANA to reserve an address for this. - Alain. From owner-v6ops@ops.ietf.org Sun Jul 27 14:26:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B183A68E4 for ; Sun, 27 Jul 2008 14:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.45 X-Spam-Level: **** X-Spam-Status: No, score=4.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-x4PcDopnGi for ; Sun, 27 Jul 2008 14:26:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 985EB3A68C8 for ; Sun, 27 Jul 2008 14:26:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNDkp-0005M0-29 for v6ops-data@psg.com; Sun, 27 Jul 2008 21:26:11 +0000 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNDkl-0005LU-Tu for v6ops@ops.ietf.org; Sun, 27 Jul 2008 21:26:09 +0000 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48635706; Sun, 27 Jul 2008 17:25:50 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 17:25:51 -0400 Received: from 130.129.64.64 ([130.129.64.64]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Jul 2008 21:25:50 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sun, 27 Jul 2008 17:25:48 -0400 Subject: Re: draft-durand-dual-stack-lite-00 general comments From: Alain Durand To: Pekka Savola , Message-ID: Thread-Topic: draft-durand-dual-stack-lite-00 general comments Thread-Index: AcjwEXL/2NJKQxJKS8e8wuiN789z/wAHeMsB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jul 2008 21:25:51.0214 (UTC) FILETIME=[5817C0E0:01C8F02F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/27/08 1:25 PM, "Pekka Savola" wrote: > The description of the proposal seems somewhat on the lengthy side. > Essentially, it seems that the proposal essentially requires the > following: > > [...] > > 3) either (unspecified in this document): > a) a method to figure out which customers support this approach (a > significant issue?) and turn off v4 DHCP on those customer links; > b) a change in the client code to first obtain v6 address and tunnel > endpoint information, and if that is obtained, not get a DHCPv4 > lease; or > c) change from providing public v4 addresses to private v4 > addresses (i.e. worsening existing service to make a new > offering more lucrative) > > [...] > > Given the difficulty of 3), it seems that the approach is basically > only suitable in deployments where the users can only connect to the > ISP using a CPE device provided by the ISP. Users' own CPE boxes or > cable/DSL cards attached to a host operating system (e.g. USB sticks) > would be a challenge. From my perspective, "you must use our CPE > device (and pay dearly for it!)" service provisioning is rather rare > and not necessarily a desirable approach from the user POV. As such > if 3) can't be solved in a generic fashion, the solution has only > limited applicability. I do not expect that this technology will be turned on automatically by any ISP on its customers without their knowledge, but rather be part of a different service offering. The DHCP server already has some logic to decide how to handle different customers. The same logic can be extended to decide which customer get an IPv4 address and which one don't but benefit from this tunneled connectivity. This can be done with ISP provided home gateway as well as with retail ones. - Alain. From owner-v6ops@ops.ietf.org Sun Jul 27 14:52:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BF53A6956 for ; Sun, 27 Jul 2008 14:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUFjcgqWnQBy for ; Sun, 27 Jul 2008 14:52:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC3483A6804 for ; Sun, 27 Jul 2008 14:52:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNE9A-00081X-48 for v6ops-data@psg.com; Sun, 27 Jul 2008 21:51:20 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNE8V-0007wu-Qv for v6ops@ops.ietf.org; Sun, 27 Jul 2008 21:50:41 +0000 Received: from [172.16.9.89] (guestroom-nat.meeting.ietf.org [130.129.64.64]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6RLoB2p037505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jul 2008 23:50:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "teemu.savolainen@nokia.com" , "'IPv6 Operations'" Message-Id: <86E8999A-35B7-4594-B793-446B2E1C18FB@muada.com> From: Iljitsch van Beijnum To: marcelo bagnulo braun In-Reply-To: <4889E7AF.6080903@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01 Date: Sun, 27 Jul 2008 22:50:22 +0100 References: <4889E7AF.6080903@it.uc3m.es> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 25 jul 2008, at 15:48, marcelo bagnulo braun wrote: > o a dual stack system connected to a IPv6 domain that is connecting > to an IPv4 system. Point of terminology: Could we please all agree on what "dual stack" means? The way I've always used the term is "a system that has both IPv4 and IPv6 connectivity, which is global in nature unless explicitly stated that it's only local or site-local". However, the above seems to use it in the sense "a system that is capable of using both IPv4 and IPv6". The set of systems conforming to the former definition is obviously a subset of those conforming to the latter. I contend that in 99% of all our discussions, it's useless to make the distinction between systems that have certain reachability for operational reasons and systems that have certain reachability because they don't support both IP versions. Using my definition of "dual stack" avoid wasting time in that 99% of cases. Note also that the use case cited above is based on an unstated assumption, which is that if a host supports the second definition of dual stack, it must therefore be connected to the IPv4 internet. The situation we want to reach is where hosts can have just IPv6 connectivity and still be fully functional. From owner-v6ops@ops.ietf.org Sun Jul 27 14:59:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8670A3A6809 for ; Sun, 27 Jul 2008 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx9mRF135Wzh for ; Sun, 27 Jul 2008 14:59:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C9F63A6906 for ; Sun, 27 Jul 2008 14:59:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNEGg-0008oG-0m for v6ops-data@psg.com; Sun, 27 Jul 2008 21:59:06 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNEGc-0008nd-MX for v6ops@ops.ietf.org; Sun, 27 Jul 2008 21:59:04 +0000 Received: from [172.16.9.89] (guestroom-nat.meeting.ietf.org [130.129.64.64]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6RLwKFO037618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jul 2008 23:58:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: marcelo bagnulo braun , Jari Arkko , Dave Thaler , "'IPv6 Operations'" , Brian E Carpenter Message-Id: <7DC3D9D2-8787-4834-9933-31D09B6737C9@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200807251911.16835.rdenis@simphalempin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not? Date: Sun, 27 Jul 2008 22:58:30 +0100 References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 25 jul 2008, at 17:11, R=E9mi Denis-Courmont wrote: >> So, the question is: is a dual stack host a v6 host (i.e. changes are >> acceptable) or is it a v4 host (i.e. changes are not acceptable)? > Regardless of the current requirements, I would argue it is not =20 > acceptable > that dual-stack nodes need to be modified, for the exact same reason =20= > as it is > not acceptable that IPv4-only nodes need to be modified: deployment =20= > would be > highly impractical. Note that these issues aren't necessarily binary. If a dual stack host is presented with synthetic AAAA records along =20 with A records, the host will try to use translated connectivity when =20= it could have used native connectivity. The requirements require that =20= this is avoided. One way to avoid this is to upgrade hosts so they =20 automatically prefer real A records over synthetic AAAA records. This =20= is rather inconvenient, bu there are only 10 - 20 operating systems in =20= the world. Another way to avoid this situation is to make sure that =20 dual stack hosts are never served by a recursive nameserver with DNS64 =20= functionality. However, there are many thousands of ISPs and hundreds =20= of thousands of organizations running significant networks in the =20 world, which would all have to do this. So yes, requiring host modifications is bad, but imposing operational =20= restrictions has the potential to be much worse in time and money. On =20= the other hand, everyone can change their own network, while few =20 people can change their OS.= From owner-v6ops@ops.ietf.org Sun Jul 27 15:03:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04D83A67F5 for ; Sun, 27 Jul 2008 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r-JzxHhVjqL for ; Sun, 27 Jul 2008 15:03:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 00DE53A67DB for ; Sun, 27 Jul 2008 15:03:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNEKQ-0009E8-8G for v6ops-data@psg.com; Sun, 27 Jul 2008 22:02:58 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNEKO-0009Dd-CX for v6ops@ops.ietf.org; Sun, 27 Jul 2008 22:02:57 +0000 Received: from [172.16.9.89] (guestroom-nat.meeting.ietf.org [130.129.64.64]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6RM2Olg037681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jul 2008 00:02:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: marcelo bagnulo braun , v6ops@ops.ietf.org Message-Id: <783EB7C1-1261-49BA-9E48-AC0742840603@muada.com> From: Iljitsch van Beijnum To: Thomas Narten In-Reply-To: <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6ops-nat64-pb-statement-req: DNSSEC requirement Date: Sun, 27 Jul 2008 23:02:32 +0100 References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 25 jul 2008, at 13:22, Thomas Narten wrote: > DNSSEC is about e2e security. The recipient of the data (the DNS > querier), using DNSSEC, is able to verify that the data has not been > modified. This is no longer true in the solution outline you proposed > above. I assume you mean NAT64/DNS64. Actually it works as designed: someone in the middle changes the DNS records and the DNS records no longer validate. If you want to use DNSSEC and NAT64 together, either DNSSEC or DNS64 must be changed to be aware of the other. Yes, this is inconvenient but then again, not being able to connect to the 99% of the internet that's still on IPv4 when your ISP can't give you an IPv4 address anymore is also quite inconvenient. From owner-v6ops@ops.ietf.org Sun Jul 27 23:53:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A20928C195 for ; Sun, 27 Jul 2008 23:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jquBt-0JfN-A for ; Sun, 27 Jul 2008 23:53:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A93D328C188 for ; Sun, 27 Jul 2008 23:53:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMWq-0009os-49 for v6ops-data@psg.com; Mon, 28 Jul 2008 06:48:20 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMWm-0009oL-Jv for v6ops@ops.ietf.org; Mon, 28 Jul 2008 06:48:18 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6S6m20V016335; Mon, 28 Jul 2008 09:48:02 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6S6m1kY016325; Mon, 28 Jul 2008 09:48:01 +0300 Date: Mon, 28 Jul 2008 09:48:01 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Thomas Narten , marcelo bagnulo braun , v6ops@ops.ietf.org Subject: effect of v4 runout [Re: v6ops-nat64-pb-statement-req: DNSSEC requirement] In-Reply-To: <783EB7C1-1261-49BA-9E48-AC0742840603@muada.com> Message-ID: References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> <783EB7C1-1261-49BA-9E48-AC0742840603@muada.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7856/Mon Jul 28 02:22:55 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 27 Jul 2008, Iljitsch van Beijnum wrote: > If you want to use DNSSEC and NAT64 together, either DNSSEC or DNS64 must be > changed to be aware of the other. (This is a side note wrt the subject change..) Well, you could make the v6-hosts query A records, and synthethize themselves based on NAT64 prefix information they have. Not sure if you count this in either of your categories above. > Yes, this is inconvenient but then again, > not being able to connect to the 99% of the internet that's still on IPv4 > when your ISP can't give you an IPv4 address anymore is also quite > inconvenient. This is a belief that needs debunking. Many drafts, this included, make the assumption that there is major incentive to deploy v6 before IANA's v4 space runs out. Some longer sighted ISPs may see it so especially if the IETF and vendors can provide tools to assist them; others won't. The ISP will just provide the users private address space and do NAT. This has been commonplace in many 2G/3G deployments, and it will become the norm in residential connectivity as well. So the scenario we must compare NAT64 etc. against is ISP-provided v4 private space, not no v4 at all. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 27 23:53:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BDC28C195 for ; Sun, 27 Jul 2008 23:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtRe-ZRgdCaP for ; Sun, 27 Jul 2008 23:53:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F99728C194 for ; Sun, 27 Jul 2008 23:53:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMbj-000AKO-DA for v6ops-data@psg.com; Mon, 28 Jul 2008 06:53:23 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMbg-000AJr-TY for v6ops@ops.ietf.org; Mon, 28 Jul 2008 06:53:22 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6S6r55g024420; Mon, 28 Jul 2008 09:53:06 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 09:52:50 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 09:52:43 +0300 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 Subject: RE: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01 Date: Mon, 28 Jul 2008 09:52:41 +0300 Message-ID: In-Reply-To: <86E8999A-35B7-4594-B793-446B2E1C18FB@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01 Thread-Index: AcjwMs7oLs78duH7Qn+5BeKqWl11BwASRNJw References: <4889E7AF.6080903@it.uc3m.es> <86E8999A-35B7-4594-B793-446B2E1C18FB@muada.com> From: To: , Cc: X-OriginalArrivalTime: 28 Jul 2008 06:52:43.0180 (UTC) FILETIME=[88CDE6C0:01C8F07E] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >The situation we want to reach is where hosts can have just=20 >IPv6 connectivity and still be fully functional. Assuming all applications are supporting IPv6, or also including cases where host may be running IPv4-only apps? What I'm wondering is that if a translation solution is designed to assume fully IPv6-capable host (including all random third party softwares), then it might be less usable in near future than tunneling based solutions. I mean if for v4-only applications host needs to anyway find a way to provide IPv4-connectivity, for what purpose it would need translation services? For IPv6-only applications? I would assume it takes quite a while before all applications are IPv6-capable, and that all devices behind a host (such as gaming consoles etc) are also IPv6-capable. Or can we assume applications to be IPv6-capable in timeframe operator would be interested to provide IPv6-only connectivity? Or should a host internally implement v4->v6 translation, thus making a host look like fully IPv6-capable towards network? Teemu From owner-v6ops@ops.ietf.org Mon Jul 28 00:05:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5053A694E for ; Mon, 28 Jul 2008 00:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.437 X-Spam-Level: X-Spam-Status: No, score=-108.437 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxwYuz3EJWhu for ; Mon, 28 Jul 2008 00:05:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 767753A6826 for ; Mon, 28 Jul 2008 00:05:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMmn-000BJ9-Kn for v6ops-data@psg.com; Mon, 28 Jul 2008 07:04:49 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNMmh-000BI5-Pd for v6ops@ops.ietf.org; Mon, 28 Jul 2008 07:04:46 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.251.2; Mon, 28 Jul 2008 00:04:43 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.240.5; Mon, 28 Jul 2008 00:04:43 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Mon, 28 Jul 2008 00:04:42 -0700 From: Dave Thaler To: marcelo bagnulo braun CC: "v6ops@ops.ietf.org" Date: Mon, 28 Jul 2008 00:04:42 -0700 Subject: comments on draft-ietf-v6ops-nat64-pb-statement-req-00 Thread-Topic: comments on draft-ietf-v6ops-nat64-pb-statement-req-00 Thread-Index: Acjvw8HQtkDGp4sFTXSH796iDzGD9A== Message-ID: 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_E9CACA3D8417CE409FE3669AAE1E5A4F0458A939C9NAEXMSGW601wi_" MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --_000_E9CACA3D8417CE409FE3669AAE1E5A4F0458A939C9NAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1: The taxonomy is missing several unfortunately common cases. a) What if a human types in the address? b) What about a URL with an IP literal that you get in email or an ins= tant message? c) What about apps that "hard code" addresses (e.g., in a config file= )? In the paragraph on referrals, I think "nodes" should be "applications" tho= ughout. Section 3.2 Re "... it seems unlikely that v4-only nodes will have a strong need to communicate with v6- only nodes (at least at the initial stages of v6 deployment)." It depends on what you mean by v6-only. If it's a dual-stack node that can= 't get a public IPv4 address, that doesn't seem unlikely. Typo "or f other" Typo "need to e modified" Re "NAT64 box internally. The last case, where the v4 node has public address and the NAT64 box has a private address seems harder to justify though." Just put a normal (carrier grade) NAT between the NAT64 and the internet and you have this case starting from the Public v4/Public v4 case. Section 4.1 Re "unless explicitly stated in the particular requirement. The translation mechanism MAY require changes to v6-only nodes." Clarify. What does v6-only node mean? Not IPv4-capable? Connected to an IPv6-only network? -Dave --_000_E9CACA3D8417CE409FE3669AAE1E5A4F0458A939C9NAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.1:

The taxonomy is missing several unfortunately common c= ases.

a)&n= bsp;     What if a human types in the address?

b)&n= bsp;     What about a URL with an IP literal that you get in email or an instant message?

c)&n= bsp;      What about apps that “hard code” addres= ses (e.g., in a config file)?

 

In the paragraph on referrals, I think “nodes= 221; should be “applications” thoughout.

 

Section 3.2

Re “… it seems unlikely

that v4-only nodes will have a strong need to communic= ate with v6-

only nodes (at least at the initial stages of v6 deployment).”

It depends on what you mean by v6-only.  If it= 217;s a dual-stack node that can’t get

a public IPv4 address, that doesn’t seem unlikel= y.

 

Typo “or f other”

Typo “need to e modified”

 

Re “NAT64 box internally.  The last case, w= here the v4 node has public

address and the NAT64 box has a private address seems = harder to

justify though.”

Just put a normal (carrier grade) NAT between the NAT6= 4 and the internet

and you have this case starting from the Public v4/Pub= lic v4 case.

 

Section 4.1

Re “unless explicitly stated in the particular requirement.  The

translation mechanism MAY require changes to v6-only n= odes.”

Clarify.  What does v6-only node mean?  Not = IPv4-capable?

Connected to an IPv6-only network?

 

-Dave

 

--_000_E9CACA3D8417CE409FE3669AAE1E5A4F0458A939C9NAEXMSGW601wi_-- From owner-v6ops@ops.ietf.org Mon Jul 28 00:47:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF393A681C for ; Mon, 28 Jul 2008 00:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.912 X-Spam-Level: X-Spam-Status: No, score=0.912 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M++dbR0OFCn for ; Mon, 28 Jul 2008 00:47:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6817C3A69F6 for ; Mon, 28 Jul 2008 00:47:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNNR0-000FpT-Js for v6ops-data@psg.com; Mon, 28 Jul 2008 07:46:22 +0000 Received: from [74.53.155.170] (helo=wibble.focb.co.nz) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNNQx-000Fot-KF for v6ops@ops.ietf.org; Mon, 28 Jul 2008 07:46:21 +0000 Received: (qmail 23849 invoked by uid 509); 28 Jul 2008 07:46:16 -0000 Received: from 130.129.64.64 by wibble.focb.co.nz (envelope-from , uid 89) with qmail-scanner-2.01 (clamdscan: 0.93.3/7858. spamassassin: 3.2.5. Clear:RC:1(130.129.64.64):. Processed in 0.065176 secs); 28 Jul 2008 07:46:16 -0000 Received: from guestroom-nat.meeting.ietf.org (HELO [10.0.1.2]) (130.129.64.64) by 0 with SMTP; Mon, 28 Jul 2008 02:46:16 -0500 Cc: "Hemant Singh (shemant)" , "Stark, Barbara" , "Alain Durand" , v6ops@ops.ietf.org Message-Id: <21D940F3-1DB5-4CCD-81BC-E0A09DDD82A0@thetiger.com> From: David Miles To: EricLKlein@softhome.net In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 28 Jul 2008 08:46:13 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In addition to any dnsext work we should include unicast DNS Btw, one limitation with mDNS (in its current form) is that it is link- local scope - if we anticipate a routed home network we may need to feed into the dnsext wg to explore the practicality of service discovery across router boundaries. I'd like me iTunes to work within the IPv6 home network of the future -d On 25/07/2008, at 7:29 PM, EricLKlein@softhome.net wrote: > Hemant Singh (shemant) writes: >> Folks, If every CPE Router has a unique ULA that is mapped to >> something like >> http://homerouter.local via mDNS (as per zeroconf) standards, does >> that >> work for you? If Barbara doesn't want to even look at the device >> manual >> for the named URL, then should every device vendor use the same URL >> which can then be specified in our draft or any other zeroconfg >> draft? >> Just some thoughts. > Does this not go back to the known name issue. > I do not have a problem with it, all I want is a consistent solution > that will work prior to having an ISP assigned IP address available > or a DHCP address pool defined. > Eric > From owner-v6ops@ops.ietf.org Mon Jul 28 01:40:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FBAC3A6A0D for ; Mon, 28 Jul 2008 01:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08OhFyNSf1Lp for ; Mon, 28 Jul 2008 01:40:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 480AF3A6989 for ; Mon, 28 Jul 2008 01:40:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNOFa-000L7p-HP for v6ops-data@psg.com; Mon, 28 Jul 2008 08:38:38 +0000 Received: from [209.85.146.176] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNOFY-000L7U-C8 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 08:38:37 +0000 Received: by wa-out-1112.google.com with SMTP id j37so2932250waf.23 for ; Mon, 28 Jul 2008 01:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=agOYRriZ57YUhZj7VMIujKkVTjq03kc+6s+kp6uZL88=; b=SkOz+E0sHFVnU1n+S1608gV7Pf9SWYcEdLrYA75HKHaTJkc9ZrieMDHHNPv+QWF34F Bi6V5FrAvDAbx27n/FjS2m1i4u+xqLrzIAwcf8sCRT3tdLznfQ4TE571gPA39Uvp+yWM uKyKon8fNYxByEJmLbLNoqkuwBUbtVsejMcSM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=nnh+hH7V76Z8RDhrXZQNw/KPbex+8FsFdFbjotsE1ZDeYDsk/9HvWQ/gmbbWXoGGWd 8jkcaY0SLBaOQWF6C91PQ0cH/mrrFe0bwlWxrOwOsmdVG4wfc68FPa2YlLzndOBH/8Pu Jqtaw6q7g5hS1RNOIA7Ebi15ytgV/pCiMGLFM= Received: by 10.114.150.1 with SMTP id x1mr4603800wad.71.1217234315651; Mon, 28 Jul 2008 01:38:35 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id m40sm19620931wag.50.2008.07.28.01.38.33 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 01:38:35 -0700 (PDT) Message-ID: <488D8585.4000503@gmail.com> Date: Mon, 28 Jul 2008 20:38:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola CC: Iljitsch van Beijnum , Thomas Narten , marcelo bagnulo braun , v6ops@ops.ietf.org Subject: Re: effect of v4 runout [Re: v6ops-nat64-pb-statement-req: DNSSEC requirement] References: <200807222120.m6MLKAnL010018@cichlid.raleigh.ibm.com> <48873AC0.5090401@it.uc3m.es> <200807232029.m6NKTPx2004828@cichlid.raleigh.ibm.com> <488833F7.7030606@it.uc3m.es> <200807251222.m6PCMEjV017212@cichlid.raleigh.ibm.com> <783EB7C1-1261-49BA-9E48-AC0742840603@muada.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-28 18:48, Pekka Savola wrote: > On Sun, 27 Jul 2008, Iljitsch van Beijnum wrote: >> If you want to use DNSSEC and NAT64 together, either DNSSEC or DNS64 >> must be changed to be aware of the other. > > (This is a side note wrt the subject change..) Well, you could make the > v6-hosts query A records, and synthethize themselves based on NAT64 > prefix information they have. Not sure if you count this in either of > your categories above. I think some of us have been calling this a "lying resolver" that transforms A replies into AAAA replies. The resolver could extend its lie, by validating the A reply and pretending that the synthetic AAAA was validated. However, that requires the IPv6 resolver to be modified, i.e. a host modification. Brian From owner-v6ops@ops.ietf.org Mon Jul 28 03:37:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52E83A68FA for ; Mon, 28 Jul 2008 03:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-GRSpvDTj7l for ; Mon, 28 Jul 2008 03:37:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 91A4F3A6839 for ; Mon, 28 Jul 2008 03:37:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNQ3A-0007Uw-0V for v6ops-data@psg.com; Mon, 28 Jul 2008 10:33:56 +0000 Received: from [209.85.146.179] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNQ37-0007UO-CN for v6ops@ops.ietf.org; Mon, 28 Jul 2008 10:33:54 +0000 Received: by wa-out-1112.google.com with SMTP id j37so2977261waf.23 for ; Mon, 28 Jul 2008 03:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6uyzxwGFJPQvWRv+wHTuqiRAdPvohT6kWRotRkhoxTc=; b=BRIvB2u8d+efmZ3Q7FQQpPe3Xka9ZC7k70iYCSFYy9opQJKsHJlMjyVZtp4H6fPf08 yLofAOzJpdgJy/bBtZ6X1gBRELN4kXWYf0aLJ5BZwuA3zm09pXb3hmmtxIR61tqnmdEj cVW+EqVROJV0ULNuRGOG5//U4jHB6a8So+5ig= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZDPQjhmVKHuPrHTAuA+sm32bDK856+aXkQg7WvHY1kPCW8fiqpFFNvFmxFY6yJ4TJJ yEwj5zTwqe89zvmSp2Xt7vHu/d2oLS09BbnX8t0k2A1toTKqhJ/Ylr/BUt9I+IIPexrf CEsdTqdaCRYuVjIEv7G2+FQVek9/nYhjOmZPg= Received: by 10.114.58.6 with SMTP id g6mr4685758waa.68.1217241232830; Mon, 28 Jul 2008 03:33:52 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id n37sm21683523wag.43.2008.07.28.03.33.51 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 03:33:52 -0700 (PDT) Message-ID: <488DA08B.8010201@gmail.com> Date: Mon, 28 Jul 2008 22:33:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Alain Durand Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: There wasn't time in the meeting today for me to ask this: Where is the open issues list for this draft, so that we can identify the non-consensus items and drive them to a resolution? Brian From owner-v6ops@ops.ietf.org Mon Jul 28 03:37:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B513A6890 for ; Mon, 28 Jul 2008 03:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.729 X-Spam-Level: X-Spam-Status: No, score=-108.729 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKujwiynNF16 for ; Mon, 28 Jul 2008 03:37:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331543A6839 for ; Mon, 28 Jul 2008 03:37:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNQ6o-0007wo-HL for v6ops-data@psg.com; Mon, 28 Jul 2008 10:37:42 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNQ6m-0007wS-AP for v6ops@ops.ietf.org; Mon, 28 Jul 2008 10:37:41 +0000 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.251.2; Mon, 28 Jul 2008 03:37:39 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.1.240.5; Mon, 28 Jul 2008 03:37:39 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Mon, 28 Jul 2008 03:37:39 -0700 From: Dave Thaler To: "Hemant Singh (shemant)" , "Wes Beebee (wbeebee)" CC: "v6ops@ops.ietf.org" Date: Mon, 28 Jul 2008 03:37:38 -0700 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAq1ZcoA= Message-ID: References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@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 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'd suggest also looking at Microsoft's (and any other vendor's) requirements for IPv6 home routers, since there's already market incentives for meeting such requirements, similar to the CableLabs pressure for DSL routers. Microsoft's are at: http://www.microsoft.com/whdc/device/network/IPv6_IGD.mspx -Dave > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Hemant Singh (shemant) > Sent: Monday, July 14, 2008 8:35 PM > To: v6ops@ops.ietf.org > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee) > Subject: New (-02) version of IPv6 CPE Router draft is available for > review > > Folks, > > Before IETF locks down any new I-D submission today for IETF Dublin, we > thought we'd submit this new copy since we had completed new sections > for PPP over IPv6 and Softwires to accommodate DSL folks. Other minor > review comments have been taken care of as well. Please refer to Change > Log for complete change details. > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router- > 02.txt > > > Hemant & Wes. > > From owner-v6ops@ops.ietf.org Mon Jul 28 06:11:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C223A6A03 for ; Mon, 28 Jul 2008 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B79vZflFAfal for ; Mon, 28 Jul 2008 06:11:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9B53A69DE for ; Mon, 28 Jul 2008 06:11:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNSRx-000PVG-M6 for v6ops-data@psg.com; Mon, 28 Jul 2008 13:07:41 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNSRq-000PUF-T2 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 13:07:39 +0000 X-IronPort-AV: E=Sophos;i="4.31,265,1215388800"; d="scan'208";a="15715756" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2008 13:07:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SD7Xpo019749; Mon, 28 Jul 2008 09:07:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6SD7X6X028338; Mon, 28 Jul 2008 13:07:33 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 09:07:33 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Mon, 28 Jul 2008 09:07:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjhecT2bKvlNqzgQEWL+sshOyZxqQEblMpAAq1ZcoAABT4qIA== References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@gmail.com> From: "Hemant Singh (shemant)" To: "Dave Thaler" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 28 Jul 2008 13:07:33.0327 (UTC) FILETIME=[E5F9FDF0:01C8F0B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1699; t=1217250453; x=1218114453; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Dave=20Thaler=22=20,=0A=20=20=20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee)=22= 20; bh=4Mx3/ENxGiz8plAL40uJnveXZYVg0n0YyxEzNbjYF/0=; b=a/zhvZ4dMNpof8YL5w1uSuqjluA3vOn3K8lfR7rtWn43uj5ouOqBJr8ltI /9Bs9/SLNt4+TVKakKvx+1jw6+aLxXk8Q4oCDMLCs7RiQonlkmIJc7Kj06l3 esc4IzM7lZ; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dave, Thanks for this reference - I do know about the URL but haven't gone thru the text. We will totally sift thru Microsoft's requirements and present a list to this mailer to summarize what we gleaned from it that is not already included in our draft. =20 Hemant -----Original Message----- From: Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 Sent: Monday, July 28, 2008 11:38 AM To: Hemant Singh (shemant); Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review I'd suggest also looking at Microsoft's (and any other vendor's) requirements for IPv6 home routers, since there's already market incentives for meeting such requirements, similar to the CableLabs pressure for DSL routers. Microsoft's are at: http://www.microsoft.com/whdc/device/network/IPv6_IGD.mspx -Dave > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On=20 > Behalf Of Hemant Singh (shemant) > Sent: Monday, July 14, 2008 8:35 PM > To: v6ops@ops.ietf.org > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee) > Subject: New (-02) version of IPv6 CPE Router draft is available for=20 > review > > Folks, > > Before IETF locks down any new I-D submission today for IETF Dublin,=20 > we thought we'd submit this new copy since we had completed new=20 > sections for PPP over IPv6 and Softwires to accommodate DSL folks.=20 > Other minor review comments have been taken care of as well. Please=20 > refer to Change Log for complete change details. > > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router- > 02.txt > > > Hemant & Wes. > > From owner-v6ops@ops.ietf.org Mon Jul 28 06:12:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FEC3A689A for ; Mon, 28 Jul 2008 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4+l55H3+4Y8 for ; Mon, 28 Jul 2008 06:12:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD6763A6A11 for ; Mon, 28 Jul 2008 06:12:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNSW1-000PkR-Gm for v6ops-data@psg.com; Mon, 28 Jul 2008 13:11:53 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNSVy-000Pja-5K for v6ops@ops.ietf.org; Mon, 28 Jul 2008 13:11:51 +0000 X-IronPort-AV: E=Sophos;i="4.31,265,1215388800"; d="scan'208";a="15718078" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2008 13:08:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SD8kUA022749; Mon, 28 Jul 2008 09:08:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6SD8kmn006255; Mon, 28 Jul 2008 13:08:46 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 09:08:46 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Mon, 28 Jul 2008 09:08:46 -0400 Message-ID: In-Reply-To: <488DA08B.8010201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjwngdwTPTeQf83SUu2RuE/9LmlawAFOUMg References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , Cc: "Alain Durand" X-OriginalArrivalTime: 28 Jul 2008 13:08:46.0607 (UTC) FILETIME=[11A7A1F0:01C8F0B3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=616; t=1217250527; x=1218114527; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=20; bh=uYk9KcIMo65dvJEgY5c7K/phCIzsbw4Wcmm1iG8gWYg=; b=gKLBirlHWKAc/cgrrxvVYtniTPtt2fzQWWsZgBMmqVxdzpEDAiNrQFDQ0x +5P5KIUiaX234khlo2HKynQiZMN23ADjDtJZV/wgu5qRAxK9NA0tX2XpOfzQ C6HqyBqlQj; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brain, I and Wes will try and present such a list by sometime tomorrow. Thanks. Hemant=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 28, 2008 11:34 AM To: v6ops@ops.ietf.org Cc: Alain Durand Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] There wasn't time in the meeting today for me to ask this: Where is the open issues list for this draft, so that we can identify the non-consensus items and drive them to a resolution? Brian From owner-v6ops@ops.ietf.org Mon Jul 28 06:53:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C073A67BD for ; Mon, 28 Jul 2008 06:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnBUADNHsuPB for ; Mon, 28 Jul 2008 06:53:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F1423A67A5 for ; Mon, 28 Jul 2008 06:53:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNT8a-0004Uj-VN for v6ops-data@psg.com; Mon, 28 Jul 2008 13:51:44 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNT8S-0004TD-9F for v6ops@ops.ietf.org; Mon, 28 Jul 2008 13:51:42 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6SDpWEG025657 for ; Mon, 28 Jul 2008 16:51:32 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6SDpV90025653 for ; Mon, 28 Jul 2008 16:51:32 +0300 Date: Mon, 28 Jul 2008 16:51:31 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6-v4 transition scenarios, take 1 Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.1/7856/Mon Jul 28 02:22:55 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In my comments and on the mike on draft-ietf-v6ops-nat64-pb-statement-req, I've asked to describe the transition scenarios we're talking of in a bit more detail so we have better context on what we're actually considering. Below is my attempt to identify the high-level transition scenarios. If you have a major case you're thinking of that's not listed here, feel free to describe it on- or off-list and I'll consider adding it or rephrasing. Text suggestions are also welcome. As an observation after writing this, I'm focusing pretty much only on client-server type applications because I've yet to see p2p or other _inter-domain_ applications that are business critical. Another reason may be that I don't know them in detail, and that will likely require application-specific transition scenarios, not just ALG extensions. But I'm willing to be convinced otherwise... 1. ISP offers IPv6-only provisioning as a new service offering using translation or tunneling Due to IPv4 exhaustion (public or private space), due to alleged O&M simplicity, an ISP prefers to provision a futuristic green field deployment or residential or small enterprises only with global v6 addresses. This requires customers to move voluntarily from old service offering to a new one because withdrawing IPv4 completely would break customers' internal use badly enough to cause outrage. The ISP may or may not be in control of the CPE device. Almost all nodes in the edge network are dual stack capable and may even use IPv4 private addresses in the internal network. Because the vast majority of content is still available only with IPv4, the service provider must provide a translator service at least for IPv6-initiated short local handle -type applications. In this scenario, IPv4->IPv6 initiated communication is not required. Because the change in service offering is voluntary, some reconfiguration in customer's equipment is acceptable; host upgrades should be avoided if possible. An alternative to translation strategy is akin to simplified DSTM (ie. Alain Durand's tunneling approach). The tunneling approach is easier to deploy but it does not take IPv6 deployment much further as the edges still keep using IPv4. 2. ISP provides IPv6 as an additional option to v4 private addressing + NAT but does not offer translation Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses through DHCP to its residential, SOHO and small enterprise customers. Instead, it provides only private IPv4 addresses and NATs these. The change is involuntary, and the customer needs to pay a premium rate if it wants to continue getting public v4 address space. This causes some problems with some customers' internal networks which use overlapping private address space, but the ISP's troubleshooting guides give instructions on renumbering the internal network to a different private address space. In addition, the ISP starts providing IPv6 service to the customers as a way to show the users this is actually "the good thing for the continued health of Internet". IPv6->IPv4 NAT service is not generally provided because IPv4 private addressing + NAT is still a workable service. However, on the longer term, the ISP may be interested in piloting a similar v6->v4 NAT solution as above. 3. A greenfield IPv6 deployment needs to provide services to the rest of Internet Due to IPv4 exhaustion or due to alleged O&M simplicity, a futuristic enterprise, ISP, content provider or similar deploys its internal infrastructure using only IPv6. However, it still seeks to provide the services to IPv4 users in Internet; those users which have IPv6 connectivity are able to use them over IPv6. IPv4 users must either be translated near the user or the service provider. As such, v4-initiated local handle -type applications must be supported. (Due to need to apply software updates, etc. the hosts at the site may also need to communicate with the v4 internet, but that is already covered in previous cases.) It is unreasonable to expect that IPv4 sites would provide this transition service, so the service provider (or a subcontractor, e.g. its upstream ISP) to provide IPv4 version of these services. This can be done e.g. using TCP/UDP proxy (an inverse of RFC3142) or a more advanced translator if ALGs or ICMP support is required. An alternative that does not require translation or proxying is to build an IPv4-over-IPv6 tunnel from service-providing hosts (e.g. web servers) to some point in the topology (e.g. the service provider or its upstream) and assign addresses over that link either permantly or temporarily (this is the original DSTM concept). Addresses can be assigned with IPv4 /32 netmask which ensures efficient address usage. Because deploying these services requires the same amount of public IPv4 addresses no matter whether translation or tunneling is used, it seems easier to employ tunneling or similar other deployment strategies to avoid the problem in the first place. It could also be argued whether the IETF needs to support these kind of deployment choices (at this point) because it's difficult to find a compelling reason why this scenario needs to be created in the first place. 4. Nearing 2015, ISP wants to ensure its users can reach all the services in Internet, and deploys a v4-to-v6 NAT Enterprises, content providers, etc. may have problems obtaining enough IPv4 addresses to provide their services over IPv4 even if they wanted to. During the next 5 years, this is not going to be a major obstacle because existing IP address usage can be made more efficient with some O&M expense (and more addresses freed e.g. by moving client-only users behind NATs). However, some years after the IANA free pool has been exhausted this may become a problem, depending on how much money the content provider is willing to use to obtain public v4 addresses. Sometime in 2015-2020 range it may be that the pain of providing IPv4 services becomes so big that some significant content providers want to stick to just IPv6 (and don't even want to pay for someone else to deal with this problem for them as in scenario 3) above). Around the time when this happens, even those ISPs which have wanted to ignore IPv6 as long as they could, may decide that they will need to do something. (Or the case could be that the ISP still has customers with only v4 capabilities.) The possible fixes to this problem are to a) deploy v6 to customers (if v4-only customers is rare enough) or b) to provide a v4->v6 translation service for v4-initiated short local handle -type applications. 5. Explicitly not considered scenarios a) Deployment being so far that a reasonable content provider might decide to deploy the service using only IPv6 and require that non-IPv6 capable users either upgrade or have their connectivity translated for them. (Somewhat similar to case 4) above). b) Such complex services (e.g. SIP, possibly p2p apps) which are not easily translateable or proxyable that if users exist in both IP versions, communication between these is a major challenge and requires application-specific proxying mechanisms or an accelerated IPv6 deployment. IPv4 exhaustion is not causing major problems for these applications as these already have a pretty good NAT traversal mechanisms and those mechanisms are likely to get better over time. App developers (esp. p2p) also have an incentive to add IPv6 support to overcome the NAT traversal problems if uPNP, NAT-PMP, and manual hole punching becomes less and less practical due to NAT functionality moving into ISP-controlled NAT. From owner-v6ops@ops.ietf.org Mon Jul 28 06:54:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72D43A67A5 for ; Mon, 28 Jul 2008 06:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ0zPrCWHcaL for ; Mon, 28 Jul 2008 06:54:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC9DD3A67BD for ; Mon, 28 Jul 2008 06:54:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTAs-0004pe-C2 for v6ops-data@psg.com; Mon, 28 Jul 2008 13:54:06 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTAk-0004oY-AA for v6ops@ops.ietf.org; Mon, 28 Jul 2008 13:54:00 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 2F5F3D0097; Mon, 28 Jul 2008 03:53:57 -1000 (HST) Date: Mon, 28 Jul 2008 03:53:56 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" , "Wes Beebee (wbeebee)" cc: "v6ops@ops.ietf.org" Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review In-Reply-To: Message-ID: References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@gmail.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The -02 draft states: 'Querier Election rules as described in section 7.6.2 of [RFC3810] do not apply to the CPE Router since the home network has only one router. Therefore, the CPE Router must always act as an MLD querier on its LAN interface(s).' This is not a good assumption considering there's already been discussion of cascading these routers. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Mon Jul 28 06:58:19 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246BE3A67DB for ; Mon, 28 Jul 2008 06:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vE-8pDbocZ5 for ; Mon, 28 Jul 2008 06:58:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 787C43A68DE for ; Mon, 28 Jul 2008 06:58:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTEU-0005NR-PC for v6ops-data@psg.com; Mon, 28 Jul 2008 13:57:50 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTEP-0005Mc-Ek for v6ops@ops.ietf.org; Mon, 28 Jul 2008 13:57:48 +0000 Received: (qmail 24345 invoked by uid 417); 28 Jul 2008 13:57:39 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 28 Jul 2008 13:57:39 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 28 Jul 2008 07:57:39 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: v6ops@ops.ietf.org, " "@SoftHome.net Subject: Public talking abouit 6to4 (was comments on draft-ietf-v6ops-nat64-pb-statement-req-00) Date: Mon, 28 Jul 2008 07:57:39 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [212.143.69.97] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Slightly off topic, but I just came cross 2 articles that try to explain to the public what the v6-to-v4 issue is about and seem to indicate that this will be very big in Dublin: Take a look at these, they are both very heavy with quotes (or are written by) people involved with v6 but not this discussion. After staunch resistance, NAT may come to IPv6 after all By Iljitsch van Beijnum - http://arstechnica.com/news.ars/post/20080722-after-staunch-resistance-nat-m ay-come-to-ipv6-after-all.html Much-maligned feature being added to IPv6 Standards body weighs network address translators for next-gen Internet By Carolyn Duffy Marsan - http://www.networkworld.com/news/2008/072108-ipv6nat.html (quotes Fred Baker) IETF Chair Russ Housley says NATs are "necessary for a smooth transition from IPv4 to IPv6." These seems to be saying that v6NAT will be added, but if you read through both articles it is more of the 6to4 issue with a bad marketing slant. We need to watch this or we will be fighting inappropriate expectations. Eric From owner-v6ops@ops.ietf.org Mon Jul 28 07:46:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C3D3A695C for ; Mon, 28 Jul 2008 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55jTYIehPfBL for ; Mon, 28 Jul 2008 07:46:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B5703A6892 for ; Mon, 28 Jul 2008 07:46:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTvn-000BTo-Om for v6ops-data@psg.com; Mon, 28 Jul 2008 14:42:35 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNTvi-000BSc-Tz for v6ops@ops.ietf.org; Mon, 28 Jul 2008 14:42:33 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 01DBA198711; Mon, 28 Jul 2008 17:42:30 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 78A001986D6; Mon, 28 Jul 2008 17:42:29 +0300 (EEST) Message-ID: <488DDAD8.5020206@piuha.net> Date: Mon, 28 Jul 2008 15:42:32 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: v6-v4 transition scenarios, take 1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I think the practically relevant cases that we should worry about now are scenarios 1 and 2. Scenario 3 IMHO is not a problem until much later, and as you mention scenario 4 is also far in the future. However, I think you are bundling in scenario multiple different situations. For instance, there is the original Alain Durand business case, where the operator network is made to be IPv6-only. This is very different from making the customers IPv6-only. Jari Pekka Savola wrote: > In my comments and on the mike on > draft-ietf-v6ops-nat64-pb-statement-req, > I've asked to describe the transition scenarios we're talking of in a bit > more detail so we have better context on what we're actually considering. > > Below is my attempt to identify the high-level transition scenarios. > If you have a major case you're thinking of that's not listed here, > feel free to describe it on- or off-list and I'll consider adding it > or rephrasing. Text suggestions are also welcome. > > As an observation after writing this, I'm focusing pretty much only on > client-server type applications because I've yet to see p2p or other > _inter-domain_ applications that are business critical. Another > reason may be that I don't know them in detail, and that will likely > require application-specific transition scenarios, not just ALG > extensions. But I'm willing to be convinced otherwise... > > 1. ISP offers IPv6-only provisioning as a new service offering using > translation or tunneling > > Due to IPv4 exhaustion (public or private space), due to alleged O&M > simplicity, an ISP prefers to provision a futuristic green field > deployment or residential or small enterprises only with global v6 > addresses. This requires customers to move voluntarily from old > service offering to a new one because withdrawing IPv4 completely > would break customers' internal use badly enough to cause outrage. The > ISP may or may not be in control of the CPE device. Almost all nodes > in the edge network are dual stack capable and may even use IPv4 > private addresses in the internal network. > > Because the vast majority of content is still available only with > IPv4, the service provider must provide a translator service at least > for IPv6-initiated short local handle -type applications. In this > scenario, IPv4->IPv6 initiated communication is not required. Because > the change in service offering is voluntary, some reconfiguration in > customer's equipment is acceptable; host upgrades should be avoided if > possible. > > An alternative to translation strategy is akin to simplified DSTM (ie. > Alain Durand's tunneling approach). The tunneling approach is easier > to deploy but it does not take IPv6 deployment much further as the > edges still keep using IPv4. > > 2. ISP provides IPv6 as an additional option to v4 private addressing > + NAT but does not offer translation > > Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses > through DHCP to its residential, SOHO and small enterprise customers. > Instead, it provides only private IPv4 addresses and NATs these. The > change is involuntary, and the customer needs to pay a premium rate if > it wants to continue getting public v4 address space. This causes > some problems with some customers' internal networks which use > overlapping private address space, but the ISP's troubleshooting > guides give instructions on renumbering the internal network to a > different private address space. > > In addition, the ISP starts providing IPv6 service to the customers as > a way to show the users this is actually "the good thing for the > continued health of Internet". IPv6->IPv4 NAT service is not > generally provided because IPv4 private addressing + NAT is still a > workable service. However, on the longer term, the ISP may be > interested in piloting a similar v6->v4 NAT solution as above. > > 3. A greenfield IPv6 deployment needs to provide services to the rest > of Internet > > Due to IPv4 exhaustion or due to alleged O&M simplicity, a futuristic > enterprise, ISP, content provider or similar deploys its internal > infrastructure using only IPv6. However, it still seeks to provide > the services to IPv4 users in Internet; those users which have IPv6 > connectivity are able to use them over IPv6. IPv4 users must either > be translated near the user or the service provider. As such, > v4-initiated local handle -type applications must be supported. (Due > to need to apply software updates, etc. the hosts at the site may also > need to communicate with the v4 internet, but that is already covered > in previous cases.) > > It is unreasonable to expect that IPv4 sites would provide this > transition service, so the service provider (or a subcontractor, e.g. > its upstream ISP) to provide IPv4 version of these services. This can > be done e.g. using TCP/UDP proxy (an inverse of RFC3142) or a more > advanced translator if ALGs or ICMP support is required. > > An alternative that does not require translation or proxying is to > build an IPv4-over-IPv6 tunnel from service-providing hosts (e.g. web > servers) to some point in the topology (e.g. the service provider or > its upstream) and assign addresses over that link either permantly or > temporarily (this is the original DSTM concept). Addresses can be > assigned with IPv4 /32 netmask which ensures efficient address usage. > > Because deploying these services requires the same amount of public > IPv4 addresses no matter whether translation or tunneling is used, it > seems easier to employ tunneling or similar other deployment > strategies to avoid the problem in the first place. It could also be > argued whether the IETF needs to support these kind of deployment > choices (at this point) because it's difficult to find a compelling > reason why this scenario needs to be created in the first place. > > 4. Nearing 2015, ISP wants to ensure its users can reach all the > services in Internet, and deploys a v4-to-v6 NAT > > Enterprises, content providers, etc. may have problems obtaining > enough IPv4 addresses to provide their services over IPv4 even if they > wanted to. During the next 5 years, this is not going to be a major > obstacle because existing IP address usage can be made more efficient > with some O&M expense (and more addresses freed e.g. by moving > client-only users behind NATs). > > However, some years after the IANA free pool has been exhausted this > may become a problem, depending on how much money the content provider > is willing to use to obtain public v4 addresses. > > Sometime in 2015-2020 range it may be that the pain of providing IPv4 > services becomes so big that some significant content providers want > to stick to just IPv6 (and don't even want to pay for someone else to > deal with this problem for them as in scenario 3) above). > > Around the time when this happens, even those ISPs which have wanted > to ignore IPv6 as long as they could, may decide that they will need > to do something. (Or the case could be that the ISP still has > customers with only v4 capabilities.) The possible fixes to this > problem are to a) deploy v6 to customers (if v4-only customers is rare > enough) or b) to provide a v4->v6 translation service for v4-initiated > short local handle -type applications. > > 5. Explicitly not considered scenarios > > a) Deployment being so far that a reasonable content provider might > decide to deploy the service using only IPv6 and require that non-IPv6 > capable users either upgrade or have their connectivity translated for > them. (Somewhat similar to case 4) above). > > b) Such complex services (e.g. SIP, possibly p2p apps) which are not > easily translateable or proxyable that if users exist in both IP > versions, communication between these is a major challenge and > requires application-specific proxying mechanisms or an accelerated > IPv6 deployment. > > IPv4 exhaustion is not causing major problems for these applications > as these already have a pretty good NAT traversal mechanisms and those > mechanisms are likely to get better over time. App developers (esp. > p2p) also have an incentive to add IPv6 support to overcome the NAT > traversal problems if uPNP, NAT-PMP, and manual hole punching becomes > less and less practical due to NAT functionality moving into > ISP-controlled NAT. > > > > From owner-v6ops@ops.ietf.org Mon Jul 28 07:56:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494F03A6AB4 for ; Mon, 28 Jul 2008 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeMmu4jcUY4J for ; Mon, 28 Jul 2008 07:56:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E59473A6892 for ; Mon, 28 Jul 2008 07:56:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNU8B-000DFe-Ou for v6ops-data@psg.com; Mon, 28 Jul 2008 14:55:23 +0000 Received: from [209.85.146.183] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNU82-000DDa-N9 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 14:55:21 +0000 Received: by wa-out-1112.google.com with SMTP id j37so3046456waf.23 for ; Mon, 28 Jul 2008 07:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wB8M/cjHxZRKDaPANIJ71RQ4mbIVgm53eDu8hnT3v5E=; b=UcD/itDXndSfp0lyktjSseYNbXSSaFR4VrgycLntCX8IhzVeoo4/i1ovzWgam7q2H8 3JO86jlGTRVG6EH3MHYA4/J84lCm+VeBBwxaHFGQpOCezieW1Q7ZYkP3PI27K5EnyII2 3YBewWZdto2EZwbasW2fAuu3LyTcapUYgR23E= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=bnDt0NlWyKYWwYRk+TZo2Cjy3UGPNW8+UWPKoEpnBLLIqobH/6QcZVWQl3q1XXKqJz pWvKAte6SHDizDkRljHpMA4GYCzzX1z+7GncmZ3rSe4AAhNCD1LMAW5KpTSh4kzYTvY8 qhIUHJSpoulOSgXEoXoL1SwOwauAwaiteXE1w= Received: by 10.114.196.1 with SMTP id t1mr5055588waf.80.1217256913876; Mon, 28 Jul 2008 07:55:13 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id m31sm18403021wag.21.2008.07.28.07.54.26 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 07:55:13 -0700 (PDT) Message-ID: <488DDD9B.7050007@gmail.com> Date: Tue, 29 Jul 2008 02:54:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: EricLKlein@softhome.net CC: v6ops@ops.ietf.org Subject: Re: Public talking abouit 6to4 (was comments on draft-ietf-v6ops-nat64-pb-statement-req-00) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Eric, please don't use the abbreviation "6to4" except for RFC 3056, otherwise people will get very confused. Frankly we can't expect headline writers at the trade rags to capture the subtleties of this debate. All the actual quotes from Russ in Carolyn's article seem fine, and obviously what Iljitsch writes is correct. Brian On 2008-07-29 01:57, EricLKlein@softhome.net wrote: > Slightly off topic, but I just came cross 2 articles that try to explain > to the public what the v6-to-v4 issue is about and seem to indicate that > this will be very big in Dublin: > Take a look at these, they are both very heavy with quotes (or are > written by) people involved with v6 but not this discussion. > After staunch resistance, NAT may come to IPv6 after all By Iljitsch van > Beijnum - > http://arstechnica.com/news.ars/post/20080722-after-staunch-resistance-nat-m > ay-come-to-ipv6-after-all.html > > Much-maligned feature being added to IPv6 > Standards body weighs network address translators for next-gen Internet > By Carolyn Duffy Marsan - > http://www.networkworld.com/news/2008/072108-ipv6nat.html (quotes Fred > Baker) IETF Chair Russ Housley says NATs are "necessary for a smooth > transition from IPv4 to IPv6." > These seems to be saying that v6NAT will be added, but if you read > through both articles it is more of the 6to4 issue with a bad marketing > slant. > We need to watch this or we will be fighting inappropriate expectations. > Eric > > From owner-v6ops@ops.ietf.org Mon Jul 28 07:57:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA613A6A0D for ; Mon, 28 Jul 2008 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSn-uvKQAGVr for ; Mon, 28 Jul 2008 07:57:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0C533A69DE for ; Mon, 28 Jul 2008 07:57:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNUA8-000DeE-BA for v6ops-data@psg.com; Mon, 28 Jul 2008 14:57:24 +0000 Received: from [209.85.146.181] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNUA3-000Dd6-D5 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 14:57:21 +0000 Received: by wa-out-1112.google.com with SMTP id j37so3047016waf.23 for ; Mon, 28 Jul 2008 07:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wB8M/cjHxZRKDaPANIJ71RQ4mbIVgm53eDu8hnT3v5E=; b=HLyEOu/avs7LUu40K045wVrJo9ZvXmZ3JC5TFeSraR6mXHTWz97Jmg4RED3cAc4T3F ZX9Ah16jEqgKEAQx4Ee2FvcbnagtJfv9Q7QJ/kN/nhrRcMSpD+ULYjVwdzkJKRedzf7v M+ABWDEOYgO6hWf1zPLtXI7XJafZqEqJObUSE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=toQcL4BLT4L9kZCD2mrkHfTYZ4ZHyqpuVomkgzx0NOHku6Qr19KcAGyDG7WwnKY522 1x+PHYyOPjuFK2A/9y0c4zIftbjdHzdfmQ5Cmkrjvlpml0TJJSXiGSNsvdulxG7EMIbU YTrmb1yx0wobk58tqmC8k0BidYqUst4OKapa0= Received: by 10.115.89.1 with SMTP id r1mr5060678wal.12.1217257036278; Mon, 28 Jul 2008 07:57:16 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id n6sm18296504wag.2.2008.07.28.07.57.09 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 07:57:15 -0700 (PDT) Message-ID: <488DDE3E.6000503@gmail.com> Date: Tue, 29 Jul 2008 02:57:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: EricLKlein@softhome.net CC: v6ops@ops.ietf.org Subject: Re: Public talking abouit 6to4 (was comments on draft-ietf-v6ops-nat64-pb-statement-req-00) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Eric, please don't use the abbreviation "6to4" except for RFC 3056, otherwise people will get very confused. Frankly we can't expect headline writers at the trade rags to capture the subtleties of this debate. All the actual quotes from Russ in Carolyn's article seem fine, and obviously what Iljitsch writes is correct. Brian On 2008-07-29 01:57, EricLKlein@softhome.net wrote: > Slightly off topic, but I just came cross 2 articles that try to explain > to the public what the v6-to-v4 issue is about and seem to indicate that > this will be very big in Dublin: > Take a look at these, they are both very heavy with quotes (or are > written by) people involved with v6 but not this discussion. > After staunch resistance, NAT may come to IPv6 after all By Iljitsch van > Beijnum - > http://arstechnica.com/news.ars/post/20080722-after-staunch-resistance-nat-m > ay-come-to-ipv6-after-all.html > > Much-maligned feature being added to IPv6 > Standards body weighs network address translators for next-gen Internet > By Carolyn Duffy Marsan - > http://www.networkworld.com/news/2008/072108-ipv6nat.html (quotes Fred > Baker) IETF Chair Russ Housley says NATs are "necessary for a smooth > transition from IPv4 to IPv6." > These seems to be saying that v6NAT will be added, but if you read > through both articles it is more of the 6to4 issue with a bad marketing > slant. > We need to watch this or we will be fighting inappropriate expectations. > Eric > > From owner-v6ops@ops.ietf.org Mon Jul 28 08:23:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA2928C183 for ; Mon, 28 Jul 2008 08:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECMR0fNQCSfx for ; Mon, 28 Jul 2008 08:23:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E6A728C194 for ; Mon, 28 Jul 2008 08:23:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNUYI-000Hjv-H9 for v6ops-data@psg.com; Mon, 28 Jul 2008 15:22:22 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNUYF-000Hj7-5r for v6ops@ops.ietf.org; Mon, 28 Jul 2008 15:22:20 +0000 Received: (qmail 24121 invoked by uid 417); 28 Jul 2008 15:22:07 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 28 Jul 2008 15:22:07 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 28 Jul 2008 09:22:07 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: v6ops@ops.ietf.org Subject: Public awareness of v6 & NAT (was comments on draft-ietf-v6ops-nat64-pb-statement-req-00) Date: Mon, 28 Jul 2008 09:22:07 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Slightly off topic, but I just came cross 2 articles that try to explain to the public what the v6-to-v4 issue is about and seem to indicate that this will be very big in Dublin: Take a look at these, they are both very heavy with quotes (or are written by) people involved with v6 but not this discussion. After staunch resistance, NAT may come to IPv6 after all By Iljitsch van Beijnum - http://arstechnica.com/news.ars/post/20080722-after-staunch-resistance-nat-m ay-come-to-ipv6-after-all.html Much-maligned feature being added to IPv6 Standards body weighs network address translators for next-gen Internet By Carolyn Duffy Marsan - http://www.networkworld.com/news/2008/072108-ipv6nat.html (quotes Fred Baker) IETF Chair Russ Housley says NATs are "necessary for a smooth transition from IPv4 to IPv6." These seems to be saying that v6NAT will be added, but if you read through both articles it is more of the 6to4 issue with a bad marketing slant. We need to watch this or we will be fighting inappropriate expectations. Eric From owner-v6ops@ops.ietf.org Mon Jul 28 10:33:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05DF28C260 for ; Mon, 28 Jul 2008 10:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB0jHoWx5ynv for ; Mon, 28 Jul 2008 10:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC15928C20F for ; Mon, 28 Jul 2008 10:33:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWXS-0007St-Go for v6ops-data@psg.com; Mon, 28 Jul 2008 17:29:38 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWXL-0007RX-VU for v6ops@ops.ietf.org; Mon, 28 Jul 2008 17:29:35 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6SHTR28030863 for ; Mon, 28 Jul 2008 20:29:27 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6SHTR3S030856 for ; Mon, 28 Jul 2008 20:29:27 +0300 Date: Mon, 28 Jul 2008 20:29:27 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6-v4 transition scenarios, take 2 In-Reply-To: <488DDAD8.5020206@piuha.net> Message-ID: References: <488DDAD8.5020206@piuha.net> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7856/Mon Jul 28 02:22:55 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Jari spotted a confusion and suggested another scenario (new item 3); here's take 2. ========== In my comments and on the mike on draft-ietf-v6ops-nat64-pb-statement-req, I've asked to describe the transition scenarios we're talking of in a bit more detail so we have better context on what we're actually considering. Below is my attempt to identify the high-level transition scenarios. If you have a major case you're thinking of that's not listed here, feel free to describe it on- or off-list and I'll consider adding it or rephrasing. Text suggestions are also welcome. As an observation after writing this, I'm focusing pretty much only on client-server type applications because I've yet to see p2p or other _inter-domain_ applications that are business critical. Another reason may be that I don't know them in detail, and that will likely require application-specific transition scenarios, not just ALG extensions. But I'm willing to be convinced otherwise... 1. ISP offers IPv6-only provisioning as a new service w/ translation Due to IPv4 exhaustion (public or private space), due to alleged O&M simplicity, an ISP prefers to provision a futuristic green field deployment or residential or small enterprises only with global v6 addresses. This requires customers to move voluntarily from old service offering to a new one because withdrawing IPv4 completely would break customers' internal use badly enough to cause outrage. The ISP may or may not be in control of the CPE device. Almost all nodes in the edge network are dual stack capable and may even use IPv4 private addresses in the internal network. Because the vast majority of content is still available only with IPv4, the service provider must provide a translator service at least for IPv6-initiated short local handle -type applications. In this scenario, IPv4->IPv6 initiated communication is not required. Because the change in service offering is voluntary, some reconfiguration in customer's equipment is acceptable; host upgrades should be avoided if possible. 2. ISP moves customers from v4 public to rfc1918, may provide v6 Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses through DHCP to its residential, SOHO and small enterprise customers. Instead, it provides only private IPv4 addresses and NATs these. The change is involuntary, and the customer needs to pay a premium rate if it wants to continue getting public v4 address space. This causes some problems with some customers' internal networks which use overlapping private address space, but the ISP's troubleshooting guides give instructions on renumbering the internal network to a different private address space. In addition, the ISP may start providing IPv6 service to the customers as a way to show the users this is actually "the good thing for the continued health of Internet". IPv6->IPv4 NAT service is not generally provided because IPv4 private addressing + NAT is still a workable service. However, on the longer term, the ISP may be interested in piloting a similar v6->v4 NAT solution as above. 3. ISP aims at an IPv6-dominant network but customers keep on using v4 Due to alleged O&M simplicity, political/publicity incentives, or minimizing the number of public IPv4 addresses, etc., an ISP wants to move to an IPv6-dominant infrastructure, eliminating IPv4 where using it can be avoided. Customers may or may not be provided with IPv6 addresses and connectivity. Given that customers and local hosts will continue to use IPv4, IPv4 must be tunneled or translated either at PE routers, CPE routers and/or end hosts. Tunneling at PE routers gives significant benefit mainly only if tunneling is done at layer 2 (and as a result PE routers can be IPv6-only). Tunneling from CPE devices and/or end hosts requires that this is offered to customers voluntarily as a new service offering. At the same time, some customers' IPv4 addresses may be changed to use private rather than public addresses, further reducing the IPv4 address usage. Customers' IPv4 connecitivity is provided by tunneling IPv4 over IPv6 to either an aggregating router (when the customer uses public v4 addresses) or to a NAT device (customer is using private v4 addresses; NAT implementation may require minor modifications), from where it is further encapsulated or forwarded to other, e.g., border routers. Practically it's simplest to leave the ISP's backbone network dual-stack at least initially, though. Most ISP's own systems will likely require some v4 connectivity (tunneled or translated) for external connectivity (e.g. software patches) for some time. Likewise, some systems will provide IPv4 services to the rest of the Internet and/or the customers and will require untranslated v4 connectivity. Final stage of ISP's infrastructure evolution is described in the next scenario. 4. A greenfield IPv6 deployment needs to provide services to the rest of Internet Due to IPv4 exhaustion or due to alleged O&M simplicity, a futuristic enterprise, ISP, content provider or similar deploys its internal infrastructure using only IPv6. However, it still seeks to provide the services to IPv4 users in Internet; those users which have IPv6 connectivity are able to use them over IPv6. IPv4 users must either be translated near the user or the service provider. As such, v4-initiated local handle -type applications must be supported. (Due to need to apply software updates, etc. the hosts at the site may also need to communicate with the v4 internet, but that is already covered in previous cases.) It is unreasonable to expect that IPv4 sites would provide this transition service, so the service provider (or a subcontractor, e.g. its upstream ISP) to provide IPv4 version of these services. This can be done e.g. using TCP/UDP proxy (an inverse of RFC3142) or a more advanced translator if ALGs or ICMP support is required. An alternative that does not require translation or proxying is to build an IPv4-over-IPv6 tunnel from service-providing hosts (e.g. web servers) to some point in the topology (e.g. the service provider or its upstream) and assign addresses over that link either permantly or temporarily (this is the original DSTM concept). Addresses can be assigned with IPv4 /32 netmask which ensures efficient address usage. Because deploying these services requires the same amount of public IPv4 addresses no matter whether translation or tunneling is used, it seems easier to employ tunneling or similar other deployment strategies to avoid the problem in the first place. It could also be argued whether the IETF needs to support these kind of deployment choices (at this point) because it's difficult to find a compelling reason why this scenario needs to be created in the first place. 5. Nearing 2015, ISP wants to ensure its users can reach all the services in Internet, and deploys a v4-to-v6 NAT Enterprises, content providers, etc. may have problems obtaining enough IPv4 addresses to provide their services over IPv4 even if they wanted to. During the next 5 years, this is not going to be a major obstacle because existing IP address usage can be made more efficient with some O&M expense (and more addresses freed e.g. by moving client-only users behind NATs). However, some years after the IANA free pool has been exhausted this may become a problem, depending on how much money the content provider is willing to use to obtain public v4 addresses. Sometime in 2015-2020 range it may be that the pain of providing IPv4 services becomes so big that some significant content providers want to stick to just IPv6 (and don't even want to pay for someone else to deal with this problem for them as in scenario 4) above). Around the time when this happens, even those ISPs which have wanted to ignore IPv6 as long as they could, may decide that they will need to do something. (Or the case could be that the ISP still has customers with only v4 capabilities.) The possible fixes to this problem are to a) deploy v6 to customers (if v4-only customers is rare enough) or b) to provide a v4->v6 translation service for v4-initiated short local handle -type applications. 6. Explicitly not considered scenarios a) Deployment being so far that a reasonable content provider might decide to deploy the service using only IPv6 and require that non-IPv6 capable users either upgrade or have their connectivity translated for them. (Somewhat similar to case 4) above). b) Such complex services (e.g. SIP, possibly p2p apps) which are not easily translateable or proxyable that if users exist in both IP versions, communication between these is a major challenge and requires application-specific proxying mechanisms or an accelerated IPv6 deployment. IPv4 exhaustion is not causing major problems for these applications as these already have a pretty good NAT traversal mechanisms and those mechanisms are likely to get better over time. App developers (esp. p2p) also have an incentive to add IPv6 support to overcome the NAT traversal problems if uPNP, NAT-PMP, and manual hole punching becomes less and less practical due to NAT functionality moving into ISP-controlled NAT. -- $Id: scenarios.txt,v 1.2 2008/07/28 17:26:41 pekkas Exp $ From owner-v6ops@ops.ietf.org Mon Jul 28 10:42:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC0328C228 for ; Mon, 28 Jul 2008 10:42:20 -0700 (PDT) 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=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+KVoBk4ieZY for ; Mon, 28 Jul 2008 10:42:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F0AA28C1AD for ; Mon, 28 Jul 2008 10:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWid-0008wA-Tn for v6ops-data@psg.com; Mon, 28 Jul 2008 17:41:11 +0000 Received: from [80.12.242.27] (helo=smtp20.orange.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWia-0008vb-NR for v6ops@ops.ietf.org; Mon, 28 Jul 2008 17:41:10 +0000 Received: from ordinateur-de-remi-despres.local (unknown [130.129.65.158]) by mwinf2009.orange.fr (SMTP Server) with ESMTP id 8B1911C000A6 for ; Mon, 28 Jul 2008 19:41:05 +0200 (CEST) X-ME-UUID: 20080728174107569.8B1911C000A6@mwinf2009.orange.fr Message-ID: <488E047B.3080308@free.fr> Date: Mon, 28 Jul 2008 19:40:11 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: v6ops Subject: APBP informal discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: As a follow-on of v6ops this morning, here are the where and when of the informal meeting to work on the address+ports borrowing protocol: Day: Tuesday (tomorrow) Time: 17:20 (Beverage and snack break) Place: Kingswood Suite (1st floor from the terrasse) We should get a table at the back of the room to be confortable. If you are interested, and have not told me so, please let me know. Regards. Rémi Després From owner-v6ops@ops.ietf.org Mon Jul 28 10:43:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F047928C26E for ; Mon, 28 Jul 2008 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKJP3z54jkBF for ; Mon, 28 Jul 2008 10:43:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABE1928C1AD for ; Mon, 28 Jul 2008 10:43:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWkO-0009Db-N8 for v6ops-data@psg.com; Mon, 28 Jul 2008 17:43:00 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWkI-0009CE-PM for v6ops@ops.ietf.org; Mon, 28 Jul 2008 17:42:57 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6SHgNl2058277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jul 2008 19:42:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org Message-Id: From: Iljitsch van Beijnum To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 1 Date: Mon, 28 Jul 2008 18:42:39 +0100 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 28 jul 2008, at 14:51, Pekka Savola wrote: > As an observation after writing this, I'm focusing pretty much only > on client-server type applications because I've yet to see p2p or > other _inter-domain_ applications that are business critical. > Another reason may be that I don't know them in detail, and that > will likely require application-specific transition scenarios, not > just ALG extensions. But I'm willing to be convinced otherwise... VoIP in general and Skype in particular are rapidly becoming business critical for many people. Peer to peer downloading isn't "business" critical but you're sure going to hear from users if you break this. (Don't forget that web and mail doesn't sell 20 Mbps ADSL2 connections, that stuff works fine on 1 Mbps, many users buy faster links because of the peer to peer stuff, it's bad business for ISPs to break this.) > 1. ISP offers IPv6-only provisioning as a new service offering using > translation or tunneling > Due to IPv4 exhaustion (public or private space), due to alleged O&M > simplicity, an ISP prefers to provision a futuristic green field > deployment or residential or small enterprises only with global v6 > addresses. This requires customers to move voluntarily from old > service First rule of ISP operations: never, EVER make your users migrate to something new, this costs a fortune in support calls. I would assume all of this only applies to new customers, addresses for existing customers won't disappear. > Because the vast majority of content is still available only with > IPv4, the service provider must provide a translator service at > least for IPv6-initiated short local handle -type applications. In > this scenario, IPv4->IPv6 initiated communication is not required. > Because the change in service offering is voluntary, some > reconfiguration in customer's equipment is acceptable; host upgrades > should be avoided if possible. Ok... > An alternative to translation strategy is akin to simplified DSTM > (ie. Alain Durand's tunneling approach). The tunneling approach is > easier to deploy but it does not take IPv6 deployment much further > as the edges still keep using IPv4. Right, the advantage of NAT64 is that it breaks the no eyeballs on v6 - > no content on v6 -> no eyeballs on v6 cycle. The advantage of dual stack light is that you can continue to run IPv4 stuff. > 2. ISP provides IPv6 as an additional option to v4 private addressing > + NAT but does not offer translation > Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses > through DHCP to its residential, SOHO and small enterprise > customers. Instead, it provides only private IPv4 addresses and NATs > these. > In addition, the ISP starts providing IPv6 service to the customers > as a way to show the users this is actually "the good thing for the > continued health of Internet". Or they don't, because they are too busy keeping all the different instances of the same RFC 1918 addresses straight... That would be bad. > 3. A greenfield IPv6 deployment needs to provide services to the rest > of Internet > Due to IPv4 exhaustion or due to alleged O&M simplicity, a > futuristic enterprise, ISP, content provider or similar deploys its > internal infrastructure using only IPv6. However, it still seeks to > provide the services to IPv4 users in Internet; those users which > have IPv6 connectivity are able to use them over IPv6. IPv4 users > must either be translated near the user or the service provider. As > such, v4-initiated local handle -type applications must be supported. The big question here is on whom the burden of the translation falls. If it's the job of the greenfield people, then it's easy because they can just get an IPv4 address (perhaps even just a port for each service on a shared address), publish the IPv4 address and set up a static mapping. If on the other hand the IPv4 clients must arrange for their own translation, this means a generic IPv4-to-IPv6 NAT (NAT46), which is much tougher than the other way around. > 4. Nearing 2015, ISP wants to ensure its users can reach all the > services in Internet, and deploys a v4-to-v6 NAT Is it a given that NAT is the appropriate option in this case? Many protocols support proxies, where the name-to-address translation happens at the proxy so if the proxy supports IPv6, the client doesn't have to. (I don't think it's a good idea to mention dates, though. It's only recently that people have stopped whining "you IETF guys said we'd be out of IPv6 addresses by 2005 and it didn't happen".) > Sometime in 2015-2020 range it may be that the pain of providing > IPv4 services becomes so big that some significant content providers > want to stick to just IPv6 (and don't even want to pay for someone > else to deal with this problem for them as in scenario 3) above). Right. I've found myself say to customers "this would be easy with IPv6" regularly in recent years. I expect once the IPv6 ball gets rolling people will start turning off IPv4 surprisingly fast. > b) Such complex services (e.g. SIP, possibly p2p apps) which are not > easily translateable or proxyable that if users exist in both IP > versions, communication between these is a major challenge and > requires application-specific proxying mechanisms or an accelerated > IPv6 deployment. Note that ICE can apply to IPv6 as well as IPv4, and even though we don't plan on having NAT in IPv6 itself, we probably still need ICE for firewall traversal so I expect to see ICE in more and more peer to peer applications. BitTorrent-like applications that don't require each peer to be reachable for every other peer have a very easy transition path: as long as you have at least 10% or so dual stack peers it works without trouble. > IPv4 exhaustion is not causing major problems for these applications > as these already have a pretty good NAT traversal mechanisms and > those mechanisms are likely to get better over time. Many of the currently used NAT traversal techniques don't work well with multiple layers of NAT, and with more users behind an IP address it will be harder for users to open up ports to host incoming sessions. So I don't think this is necessarily true. From owner-v6ops@ops.ietf.org Mon Jul 28 10:46:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705DA28C285 for ; Mon, 28 Jul 2008 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaEunxUakCk7 for ; Mon, 28 Jul 2008 10:46:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19C1F28C275 for ; Mon, 28 Jul 2008 10:46:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWng-0009kj-53 for v6ops-data@psg.com; Mon, 28 Jul 2008 17:46:24 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWnZ-0009iF-5x for v6ops@ops.ietf.org; Mon, 28 Jul 2008 17:46:21 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6SHjmq6058348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jul 2008 19:45:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org, alain_durand@cable.comcast.com Message-Id: <081F1634-F2A9-4B28-8624-9ADCBCA402AB@muada.com> From: Iljitsch van Beijnum To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: draft-durand-dual-stack-lite-00 general comments Date: Mon, 28 Jul 2008 18:46:04 +0100 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 27 jul 2008, at 18:25, Pekka Savola wrote: > 1) modifications to decapsulating NAT to look into inner v4 header for > multiplexing purposes (and not just v6 header). Requires > colocating > the decapsulator with NAT. Right. Note that this is pretty much the same functionality as a NAT64 provides. > 4) TCP MSS rewriting on edge devices and NAT box to better cope with > lowered > effective maximum packet size OR a way to use a higher MTU on the > path > between the edge device and the tunnel box. IPv6 routers could advertise a reduced MTU. On the other hand, that has the downside that end-to-end IPv6 traffic now also has to use the smaller MTU. From owner-v6ops@ops.ietf.org Mon Jul 28 10:49:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D514D28C284 for ; Mon, 28 Jul 2008 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqIs1w9VviEE for ; Mon, 28 Jul 2008 10:49:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B06728C270 for ; Mon, 28 Jul 2008 10:49:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWqC-000A8A-4f for v6ops-data@psg.com; Mon, 28 Jul 2008 17:49:00 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWq7-000A74-Ql for v6ops@ops.ietf.org; Mon, 28 Jul 2008 17:48:57 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6SHmWlE058383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jul 2008 19:48:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Message-Id: From: Iljitsch van Beijnum To: Alain Durand In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: draft-durand-dual-stack-lite-00 general comments Date: Mon, 28 Jul 2008 18:48:48 +0100 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 27 jul 2008, at 22:19, Alain Durand wrote: >> By the way, my Ubuntu PC refuses to accept 0.0.0.1 as a valid >> address. I >> reckon the same operating system is found in certain CPEs. > This address is mainly used in the case a device -that-is-not-behind- > a-CPE- > wants to initiate the tunnel. In this mode of operation, dual-stack > lite is > a very simple alternative to NAT-PT. > Now, I suggested 0.0.0.1, but this may not be the best choice. I will > probably end up asking IANA to reserve an address for this. The right choice would be something in the RFC 1918 space so applications that inspect their source address know they're behind NAT and change their behavior accordingly. In the MNAT-PT draft from seven months ago there's text about creating a source address in the 172.31/16 range where the lower 16 bits are chosen such that they compensate for the checksum difference between IPv4 and IPv6 so there's no need to recalculate the checksums. From owner-v6ops@ops.ietf.org Mon Jul 28 11:01:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9412128C15A for ; Mon, 28 Jul 2008 11:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcAFBBa53dzQ for ; Mon, 28 Jul 2008 11:01:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15BD828C1C6 for ; Mon, 28 Jul 2008 11:01:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNX1H-000CTy-3e for v6ops-data@psg.com; Mon, 28 Jul 2008 18:00:27 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNX1C-000CTM-TV for v6ops@ops.ietf.org; Mon, 28 Jul 2008 18:00:25 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6SHxrRb058626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jul 2008 19:59:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: , Message-Id: <8F9447CA-56A4-4237-872A-2EF581FCE71F@muada.com> From: Iljitsch van Beijnum To: "" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01 Date: Mon, 28 Jul 2008 19:00:10 +0100 References: <4889E7AF.6080903@it.uc3m.es> <86E8999A-35B7-4594-B793-446B2E1C18FB@muada.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 28 jul 2008, at 7:52, wrote: >> The situation we want to reach is where hosts can have just >> IPv6 connectivity and still be fully functional. > Assuming all applications are supporting IPv6, or also including cases > where host may be running IPv4-only apps? Well obviously we don't want to support IPv4-only apps until the end of time. But we will have to in the short term. > What I'm wondering is that if a translation solution is designed to > assume fully IPv6-capable host (including all random third party > softwares), then it might be less usable in near future than tunneling > based solutions. If the host knows the prefix for the translator, it can easily internally make IPv4 API calls create IPv6 packets that will be translated to IPv4 by the remote translator. One approach is to simply create IPv4 packets and encapsulate those in IPv6, but the extra IPv4 header provides no actual functionality so we can probably optimize it away without too much trouble. So the NAT464 translation scenario and the dual stack light scenario are pretty much the same thing. In the case of a CPE handling internal hosts that actually create IPv4 packets the tradeoff between encapsulation and translation may be somewhat different. > for what purpose it would need > translation services? For IPv6-only applications? I would assume it > takes quite a while before all applications are IPv6-capable, and that > all devices behind a host (such as gaming consoles etc) are also > IPv6-capable. Don't forget that higher level APIs hide the differences between IPv4 and IPv6, so very many applications can work over IPv6 without having specifically be designed to do so. > Or can we assume applications to be IPv6-capable in timeframe operator > would be interested to provide IPv6-only connectivity? I'm not familiar with cellular operations, but I would assume that running IPv4 and IPv6 over the cellular network concurrently is far from ideal, just providing IPv6 and then use an IP layer mechanism to let the applications talk to the IP world would be helpful. > Or should a host internally implement v4->v6 translation, thus > making a > host look like fully IPv6-capable towards network? I think in many cases that makes sense, yes. From owner-v6ops@ops.ietf.org Mon Jul 28 11:20:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258A33A67FD for ; Mon, 28 Jul 2008 11:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sj5EoO+WFFH for ; Mon, 28 Jul 2008 11:20:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A4053A679C for ; Mon, 28 Jul 2008 11:20:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXJi-000Fyr-HO for v6ops-data@psg.com; Mon, 28 Jul 2008 18:19:30 +0000 Received: from [209.85.146.177] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXJe-000FyF-V1 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 18:19:28 +0000 Received: by wa-out-1112.google.com with SMTP id j37so3098553waf.23 for ; Mon, 28 Jul 2008 11:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=is1+0i+LFCmsFXMF0FK0RSXA6YfLr3NR+Wl1Xa85g4Y=; b=XdsGK+wc/QE4z55+gPekwiw8b6KjSl9iimSDFr69mwRfZSS++ttytDXvDHvtOnTVFw PIq7d0NUoVZYzzBlbFepKJZ7R6xty8DsZVACK3N1fro3c6NrCHYbpFhlVl5u1jekf0RU I9h/thfcqsNDBcSHV6shQgcHPLyHTirCaGyUI= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=MkLb5OGSFA8nO2nabDarJLda9/8hked5aOBXM2RfqtZCGW7mFDFHDGiZ6u6FYKxsNV ijK5inorIPnsiIM1OT20NAZYyNJmFoemppAEMjqZ3j+xK0fFqXh4C6tMFKf8AWHt2taK 3cDdl0stvRAHOPpB7rZM0qbRDC/YVQALZH07E= Received: by 10.114.202.15 with SMTP id z15mr5347695waf.88.1217269166267; Mon, 28 Jul 2008 11:19:26 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id n32sm23905907wag.47.2008.07.28.11.19.23 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 11:19:25 -0700 (PDT) Message-ID: <488E0DA6.70803@gmail.com> Date: Tue, 29 Jul 2008 06:19:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: v6-v4 transition scenarios, take 1 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-29 05:42, Iljitsch van Beijnum wrote: > On 28 jul 2008, at 14:51, Pekka Savola wrote: > >> As an observation after writing this, I'm focusing pretty much only on >> client-server type applications because I've yet to see p2p or other >> _inter-domain_ applications that are business critical. Another >> reason may be that I don't know them in detail, and that will likely >> require application-specific transition scenarios, not just ALG >> extensions. But I'm willing to be convinced otherwise... > > VoIP in general and Skype in particular are rapidly becoming business > critical for many people. Peer to peer downloading isn't "business" > critical but you're sure going to hear from users if you break this. > (Don't forget that web and mail doesn't sell 20 Mbps ADSL2 connections, > that stuff works fine on 1 Mbps, many users buy faster links because of > the peer to peer stuff, it's bad business for ISPs to break this.) FYI, there's at least one proposal in the oh-so-serious ITU discussion of IPTV for a P2P based IPTV delivery mechanism. There are already P2P based video on demand solutions in the wild. I don't think you can assume that P2P is not of business interest. My guess is that dual stack nodes in a mixed v4/v6 P2P network would become hot spots, with the v4-only and v6-only nodes using them as convertors. I'd expect P2P networks to be rather successful in routing around connectivity gaps due to v4/v6. Brian From owner-v6ops@ops.ietf.org Mon Jul 28 11:20:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F3B3A679F for ; Mon, 28 Jul 2008 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1d8IGccM-LV for ; Mon, 28 Jul 2008 11:20:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F34AF3A6A8D for ; Mon, 28 Jul 2008 11:20:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXKH-000G6f-DV for v6ops-data@psg.com; Mon, 28 Jul 2008 18:20:05 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXKC-000G51-O0 for v6ops@ops.ietf.org; Mon, 28 Jul 2008 18:20:03 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6SIJpib032306; Mon, 28 Jul 2008 21:19:51 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6SIJpxB032303; Mon, 28 Jul 2008 21:19:51 +0300 Date: Mon, 28 Jul 2008 21:19:51 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: v6ops@ops.ietf.org Subject: Re: v6-v4 transition scenarios, take 1 In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.1/7856/Mon Jul 28 02:22:55 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 28 Jul 2008, Iljitsch van Beijnum wrote: >> As an observation after writing this, I'm focusing pretty much only on >> client-server type applications because I've yet to see p2p or other >> _inter-domain_ applications that are business critical. Another reason may >> be that I don't know them in detail, and that will likely require >> application-specific transition scenarios, not just ALG extensions. But >> I'm willing to be convinced otherwise... > > VoIP in general and Skype in particular are rapidly becoming business > critical for many people. Peer to peer downloading isn't "business" critical > but you're sure going to hear from users if you break this. (Don't forget > that web and mail doesn't sell 20 Mbps ADSL2 connections, that stuff works > fine on 1 Mbps, many users buy faster links because of the peer to peer > stuff, it's bad business for ISPs to break this.) AFAIK, p2p protocols, at least downloading, are smart enough to work through a NAT box that doesn't support any ALG, UPNP, port redirection, etc. I have personal experience with this :-). So, does this require special casing in NAT64 techniques or are such approaches enough client-server -like? > >> 1. ISP offers IPv6-only provisioning as a new service offering using >> translation or tunneling > >> Due to IPv4 exhaustion (public or private space), due to alleged O&M >> simplicity, an ISP prefers to provision a futuristic green field deployment >> or residential or small enterprises only with global v6 addresses. This >> requires customers to move voluntarily from old service > > First rule of ISP operations: never, EVER make your users migrate to > something new, this costs a fortune in support calls. > > I would assume all of this only applies to new customers, addresses for > existing customers won't disappear. So, the ISP may do as they do in Finland: only provide support in a 0.39 EUR/min phone number. As a result, they're able to downsize their support departments. Think about the revenue opportunities! :-) The text talks about both new customers, or old ones migrating to a new type of service voluntarily. >> In addition, the ISP starts providing IPv6 service to the customers as a >> way to show the users this is actually "the good thing for the continued >> health of Internet". > > Or they don't, because they are too busy keeping all the different instances > of the same RFC 1918 addresses straight... That would be bad. Sure. Actually I added conditionals that take care of this in take 2. > The big question here is on whom the burden of the translation falls. If it's > the job of the greenfield people, then it's easy because they can just get an > IPv4 address (perhaps even just a port for each service on a shared address), > publish the IPv4 address and set up a static mapping. > > If on the other hand the IPv4 clients must arrange for their own translation, > this means a generic IPv4-to-IPv6 NAT (NAT46), which is much tougher than the > other way around. Agree that this is an issue, but not probably in practise. Let me try to phrase it differently.. "I strongly encourage all my competitors to start providing their services as v6-only". So I don't think there should be a big question about which approach is viable and which isn't. >> 4. Nearing 2015, ISP wants to ensure its users can reach all the >> services in Internet, and deploys a v4-to-v6 NAT > > Is it a given that NAT is the appropriate option in this case? > > Many protocols support proxies, where the name-to-address translation happens > at the proxy so if the proxy supports IPv6, the client doesn't have to. > > (I don't think it's a good idea to mention dates, though. It's only recently > that people have stopped whining "you IETF guys said we'd be out of IPv6 > addresses by 2005 and it didn't happen".) Maybe I should have used s/NAT/translator/, that was certainly the intent. However, in practise given that the intent is to support weird v4 hosts and apps in "end-game" situation, it seems improbable that an app-specific proxying would be enough. Wrt dates, I wanted to emphasize that this won't be happening any time soon. > I expect once the IPv6 ball gets rolling people will start turning off IPv4 > surprisingly fast. Personally I doubt it -- a lot. Or we have a different things in mind when we talk about "IPv6 ball gets rolling". I wouldn't turn off v4 on any service I have association with until at least 90% and hopefully more than 99% of the user base (or potential user base) could reach it. >> IPv4 exhaustion is not causing major problems for these applications as >> these already have a pretty good NAT traversal mechanisms and those >> mechanisms are likely to get better over time. > > Many of the currently used NAT traversal techniques don't work well with > multiple layers of NAT, and with more users behind an IP address it will be > harder for users to open up ports to host incoming sessions. So I don't think > this is necessarily true. I guess you're referring to NAT traversal mechanisms such as uPNP, NAT-PMP etc. -- I don't count those as NAT traversal because they require modifications in NATs. Teredo and similar tunneling mechanisms which require no NAT modifications are the true traversal mechanisms. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jul 28 12:37:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D94E3A67A4 for ; Mon, 28 Jul 2008 12:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7jRs6XGDNqO for ; Mon, 28 Jul 2008 12:37:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A96CA3A6845 for ; Mon, 28 Jul 2008 12:37:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNYUV-000Opz-NW for v6ops-data@psg.com; Mon, 28 Jul 2008 19:34:43 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNYUS-000OpX-4u for v6ops@ops.ietf.org; Mon, 28 Jul 2008 19:34:41 +0000 Received: (qmail 980 invoked by uid 417); 28 Jul 2008 19:34:22 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 28 Jul 2008 19:34:22 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Mon, 28 Jul 2008 13:34:22 -0600 References: In-Reply-To: From: EricLKlein@softhome.net To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: v6-v4 transition scenarios, take 1 Date: Mon, 28 Jul 2008 13:34:22 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Pekka Savola writes: >>> 4. Nearing 2015, ISP wants to ensure its users can reach all the >>> services in Internet, and deploys a v4-to-v6 NAT >> >> Is it a given that NAT is the appropriate option in this case? >> >> Many protocols support proxies, where the name-to-address translation >> happens at the proxy so if the proxy supports IPv6, the client doesn't >> have to. >> >> (I don't think it's a good idea to mention dates, though. It's only >> recently that people have stopped whining "you IETF guys said we'd be out >> of IPv6 addresses by 2005 and it didn't happen".) > > Maybe I should have used s/NAT/translator/, that was certainly the intent. > However, in practise given that the intent is to support weird v4 hosts > and apps in "end-game" situation, it seems improbable that an app-specific > proxying would be enough. > > Wrt dates, I wanted to emphasize that this won't be happening any time > soon. Given the rate that Operating systems are being forced on end users, what is the likelihood that non-dual stack systems will be very common by that point? I can see a need to take v6 customers to v4 servers, but I do not expect that you will have a large percent of users on v4 only hardware or operating systems 7 years from now. Now you may have v4 only ISPs or other businesses providing services but that is a different issue. >> I expect once the IPv6 ball gets rolling people will start turning off >> IPv4 surprisingly fast. > > Personally I doubt it -- a lot. Or we have a different things in mind > when we talk about "IPv6 ball gets rolling". > > I wouldn't turn off v4 on any service I have association with until at > least 90% and hopefully more than 99% of the user base (or potential user > base) could reach it. This makes senses Eric From owner-v6ops@ops.ietf.org Tue Jul 29 00:53:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1124E3A6AB3 for ; Tue, 29 Jul 2008 00:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAInV9SZlY8u for ; Tue, 29 Jul 2008 00:53:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB0E03A67F7 for ; Tue, 29 Jul 2008 00:53:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjwn-000JJZ-DJ for v6ops-data@psg.com; Tue, 29 Jul 2008 07:48:41 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjwi-000JIy-Jx for v6ops@ops.ietf.org; Tue, 29 Jul 2008 07:48:39 +0000 X-IronPort-AV: E=Sophos;i="4.31,271,1215388800"; d="scan'208";a="15850269" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jul 2008 07:48:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6T7mXw3031376; Tue, 29 Jul 2008 03:48:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6T7mX3m023946; Tue, 29 Jul 2008 07:48:33 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 03:48:32 -0400 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 Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review Date: Tue, 29 Jul 2008 03:48:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New (-02) version of IPv6 CPE Router draft is available for review Thread-Index: AcjwuYHs4+tEEThcQCiIr0f38wsrhwAlDsuQ References: <20080630153001.52D673A6AC3@core3.amsl.com> mid:100 <48743999.7070808@gmail.com> From: "Hemant Singh (shemant)" To: "Antonio Querubin" , "Wes Beebee (wbeebee)" Cc: X-OriginalArrivalTime: 29 Jul 2008 07:48:32.0972 (UTC) FILETIME=[7FD958C0:01C8F14F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1288; t=1217317713; x=1218181713; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20New=20(-02)=20version=20of=20IPv6=20CPE =20Router=20draft=20is=20available=20for=20review |Sender:=20 |To:=20=22Antonio=20Querubin=22=20,=0A=20=20 =20=20=20=20=20=20=22Wes=20Beebee=20(wbeebee)=22=20; bh=EPQSuC8RRMmjADEtHQLvXIPMOtgif3I2YwFozF9c24g=; b=OxroeoILgAFT4nuPjatzIKE6bANcDao1/jDM9H04hLXVsW8jHZgYCvxCTo NF+6PZ15Puya+Z7bwSS2TVymepRSJL1Rf/mE+XfyvBE+BM2z7+1gowAowukq cjlhVb+wxE; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Even in a cascade there is only one CPE Router that directly faces the SP upstream router. This is the router that will proxy MLD reports to the SP. This will work if the first CPE Router in the cascade (facing the SP) is configured for lowest IP address (section 3 of RFC4605). We are working on changing our mcast section in the draft to reference RFC4605 since Remi pointed to us we were re-inventing MLD proxy when an RFC existed on the subject. We need to work out the details for mcast in the cascade and propose a smallest common denominator for mcast in the cascade. Hemant -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net]=20 Sent: Monday, July 28, 2008 2:54 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee) Cc: v6ops@ops.ietf.org Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review The -02 draft states: 'Querier Election rules as described in section 7.6.2 of [RFC3810] do not apply to the CPE Router since the home network has only one router. Therefore, the CPE Router must always act as an MLD querier on its LAN interface(s).' This is not a good assumption considering there's already been discussion of cascading these routers. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Tue Jul 29 01:31:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4453A67F8 for ; Tue, 29 Jul 2008 01:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfi7TpbEsrs3 for ; Tue, 29 Jul 2008 01:31:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B37993A6923 for ; Tue, 29 Jul 2008 01:31:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNkao-000NKD-8R for v6ops-data@psg.com; Tue, 29 Jul 2008 08:30:02 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNkak-000NJF-Bw for v6ops@ops.ietf.org; Tue, 29 Jul 2008 08:30:00 +0000 X-IronPort-AV: E=Sophos;i="4.31,271,1215388800"; d="scan'208";a="15831955" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2008 08:29:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6T8Tv0W030173; Tue, 29 Jul 2008 04:29:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6T8Tvv9001597; Tue, 29 Jul 2008 08:29:57 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 04:29:57 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Tue, 29 Jul 2008 04:29:56 -0400 Message-ID: In-Reply-To: <488DA08B.8010201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjwngdwTPTeQf83SUu2RuE/9LmlawAtVMDQ References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , Cc: "Alain Durand" X-OriginalArrivalTime: 29 Jul 2008 08:29:57.0210 (UTC) FILETIME=[4891FBA0:01C8F155] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1623; t=1217320197; x=1218184197; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=20; bh=6LfkFQRPfUN77oC/2hBaaJ8/Yg899DWu76kYZFHcXZc=; b=fk3bEoOvSrWrjsZWbDWp+RWN5xGHvkVr87NnwfhHwWydCYtibZYDVEOMJV B/9Yv/Uye1ua7L957mAYfi9qcfRSvSo1FAZVEKooTiy/OQ9c2olff6d/1xVO FssOMeiCCP; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian, I and Wes can recall only two issues that have not reached consensus. =20 The big one was Addressing of the CPE Router WAN interface because NTT, AT&T, a few folks from the DSL Forum were not in complete agreement - I and Wes are working this one and this is close to closure. We talked with NTT yesterday and David Miles who works in the DSL Forum. We will send email on this closure sometime today. Next one is use of ULA for the home network on the LAN interface(s) of the CPE Router. What we have in mind ULA lasts on the device till the next reboot (ULA will not be renumbered on the device acquiring a GUA) upon which the same ULA or a different ULA may be generated by the device. We are saying the LAN interface(s) will use ULA for the lifetime of the CPE Router till the router reboots. Alain is one person who would like to renumber the ULA on the LAN interface acquiring a GUA. I didn't see enough justification from him to change the draft in the ULA regard. Remi has also replied to Alain's concerns and claimed they are non-issues. =20 Thanks. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 28, 2008 11:34 AM To: v6ops@ops.ietf.org Cc: Alain Durand Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] There wasn't time in the meeting today for me to ask this: Where is the open issues list for this draft, so that we can identify the non-consensus items and drive them to a resolution? Brian From owner-v6ops@ops.ietf.org Tue Jul 29 02:49:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CF428C119 for ; Tue, 29 Jul 2008 02:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud530Ji4g8I9 for ; Tue, 29 Jul 2008 02:49:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B80328C24D for ; Tue, 29 Jul 2008 02:49:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNlmX-0004Nk-Uk for v6ops-data@psg.com; Tue, 29 Jul 2008 09:46:13 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNlmP-0004Mw-IH for v6ops@ops.ietf.org; Tue, 29 Jul 2008 09:46:11 +0000 X-IronPort-AV: E=Sophos;i="4.31,271,1215388800"; d="scan'208";a="15835762" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2008 09:43:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6T9h31c017574; Tue, 29 Jul 2008 05:43:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6T9h3aY015022; Tue, 29 Jul 2008 09:43:03 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 05:43:03 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Tue, 29 Jul 2008 05:43:02 -0400 Message-ID: In-Reply-To: <488DA08B.8010201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjwngdwTPTeQf83SUu2RuE/9LmlawAvBJaQ References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , Cc: "Alain Durand" X-OriginalArrivalTime: 29 Jul 2008 09:43:03.0650 (UTC) FILETIME=[7F179C20:01C8F15F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2016; t=1217324583; x=1218188583; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=20; bh=gKvQPkuvm5vOYmReFVNzU4SphigbsoWt3z7bazWHuTU=; b=KbeA4uDJAyhfyyG4CUCdu5n25Sgzn2aWu9mN4CtcDxi/pWBzF0G0g7Zit2 flRSyiGVVj03psTDojGp/4YhlHancbbWBUmvjFhxyddblNvA+Qngb/G9KyRk FXsdcr/XFj; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Here is the closure on the Addressing issue for the WAN interface of the CPE Router. We could not understand Shin's emails to the mailer, so we had left it to meeting him at this IETF. He told us yesterday, in the NTT IPV6 DSL deployment, the home user uses a Windows PC running routing code and that PC is a CPE Router for them. That was the disconnect in our heads with him - we never thought the PC host he was referring to is a router. Once we learnt their CPE Router is a Windows PC, we obviously appreciate his concern if Windows Vista runs the strong host model - the PC terminates PPP that needs a GUA. =20 The following sentences were added to the end of the Unnumbered Model section to close with Shin and NTT. =20 [The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain broadband deployments where a device that uses the strong host model can operate as a CPE Router.] =20 Further, the first sentence of the Basic IPv6 Provisioning has been changed as to [The CPE Router MUST support at least one of two WAN interface models, one of which will be active on the CPE Router at any given time.] As for AT&T (Barbara), or David Miles who works in the DSL Forum, or Mikael A., they can use any one of our Numbered or Unnumbered model for their purpose. We need a new version of the draft to show to these three folks the latest sections for the two model. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 28, 2008 11:34 AM To: v6ops@ops.ietf.org Cc: Alain Durand Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] There wasn't time in the meeting today for me to ask this: Where is the open issues list for this draft, so that we can identify the non-consensus items and drive them to a resolution? Brian From owner-v6ops@ops.ietf.org Tue Jul 29 07:54:38 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEA73A688A for ; Tue, 29 Jul 2008 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiXhzMglGlCy for ; Tue, 29 Jul 2008 07:54:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EDC73A6B97 for ; Tue, 29 Jul 2008 07:54:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqXg-0009G0-Gv for v6ops-data@psg.com; Tue, 29 Jul 2008 14:51:12 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqXY-0009Eo-LN for v6ops@ops.ietf.org; Tue, 29 Jul 2008 14:51:07 +0000 X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="90842803" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2008 14:50:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TEottJ008295; Tue, 29 Jul 2008 07:50:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6TEosI1011506; Tue, 29 Jul 2008 14:50:54 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 10:50:54 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Tue, 29 Jul 2008 10:50:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjwngdwTPTeQf83SUu2RuE/9LmlawAvBJaQAAwErJA= References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Brian E Carpenter" , Cc: "Alain Durand" X-OriginalArrivalTime: 29 Jul 2008 14:50:54.0417 (UTC) FILETIME=[8086FC10:01C8F18A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2866; t=1217343055; x=1218207055; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20; bh=d12y5+4gfQcN3Zz9Pi8R25An0RvydHf1jtZvlUHgHeQ=; b=NpN7K+8Ol3vlR2Yuxg2I2lE+GLjUsxLIV4sTFaF6J1TTdnRviaLa67xbre DIftpCzd7W8OWJqx/sHC+jPDbBSzzHbkWSqNFGOgQrMZ+MfHWOHGQcEP8H/Y Niai2aMs7OkQR3ZGWZLc/8mmLQKB66jjHdwZ4DLZ4J8avPNfuDJ6Q=; Authentication-Results: sj-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, Shin reviewed our new text and asked for the word "broadband" be removed from the text so that the text relates to any deployment where such a device exists. So we have removed the word "broadband" from the text. New text is as follows: [The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain deployments where a device that uses the strong host model can operate as a CPE Router.] =20 Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, July 29, 2008 10:43 AM To: Brian E Carpenter; v6ops@ops.ietf.org Cc: Alain Durand Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Here is the closure on the Addressing issue for the WAN interface of the CPE Router. We could not understand Shin's emails to the mailer, so we had left it to meeting him at this IETF. He told us yesterday, in the NTT IPV6 DSL deployment, the home user uses a Windows PC running routing code and that PC is a CPE Router for them. That was the disconnect in our heads with him - we never thought the PC host he was referring to is a router. Once we learnt their CPE Router is a Windows PC, we obviously appreciate his concern if Windows Vista runs the strong host model - the PC terminates PPP that needs a GUA. =20 The following sentences were added to the end of the Unnumbered Model section to close with Shin and NTT. =20 [The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain broadband deployments where a device that uses the strong host model can operate as a CPE Router.] =20 Further, the first sentence of the Basic IPv6 Provisioning has been changed as to [The CPE Router MUST support at least one of two WAN interface models, one of which will be active on the CPE Router at any given time.] As for AT&T (Barbara), or David Miles who works in the DSL Forum, or Mikael A., they can use any one of our Numbered or Unnumbered model for their purpose. We need a new version of the draft to show to these three folks the latest sections for the two model. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 28, 2008 11:34 AM To: v6ops@ops.ietf.org Cc: Alain Durand Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] There wasn't time in the meeting today for me to ask this: Where is the open issues list for this draft, so that we can identify the non-consensus items and drive them to a resolution? Brian From owner-v6ops@ops.ietf.org Tue Jul 29 08:48:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A45A28C34F for ; Tue, 29 Jul 2008 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWN8E-Jt5lq3 for ; Tue, 29 Jul 2008 08:48:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B0F628C343 for ; Tue, 29 Jul 2008 08:48:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrQ9-000G2e-G1 for v6ops-data@psg.com; Tue, 29 Jul 2008 15:47:29 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrQ4-000G27-Pb for v6ops@ops.ietf.org; Tue, 29 Jul 2008 15:47:27 +0000 X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="15868240" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2008 15:47:21 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TFlL0b021661 for ; Tue, 29 Jul 2008 11:47:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6TFlLOi010358 for ; Tue, 29 Jul 2008 15:47:21 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 11:47:21 -0400 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 Subject: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 Date: Tue, 29 Jul 2008 11:47:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 Thread-Index: AcjwngdwTPTeQf83SUu2RuE/9LmlawAvBJaQAAwErJAAAclwQAAAPj0A From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 29 Jul 2008 15:47:21.0470 (UTC) FILETIME=[635E41E0:01C8F192] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3012; t=1217346441; x=1218210441; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20review=20for=20draft-kaippallimalil-v6ops-ipv6- bbnet-00 |Sender:=20 |To:=20; bh=GaRZpPptnBhPulk/HaK0Sn+ws4jHf44+xlU5Q8kNVjI=; b=q3cojX+/LJttFbzdsn/PSqntovit2ymeIgPWuYpPB5bY7FwItYOdIK1iH4 FPSsFa7KwXQPRsp7G+6g8OsXmwb3XqgoY0hnXwHd18nvP0Zo09WowB9zz+vF yKDQ56BflY; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I glanced thru this draft. Please see my comments below.=20 1. Is the draft for Standards Track, Informational, or a BCP? General comment. Cable wrote a draft to inform IETF of their IPv6 standards when cable was complete with their standards. Why is DSL giving an FYI to IETF via this draft when your IPv6 standards are clearly not completed? The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt. 2. Why not add the word "Fixed" to the title of the draft since the draft is=20 dealing with only fixed broadband deployments? 3. I have a problem with the word Broadband in the title of the draft. The draft should not speak for cable broadband deployment. We may want to add DSL/FTTH or what have you, so that the title is totally clear. Cable also does not need this draft because cable completed such standards for IPv6 two years back. 4. In the Introduction section, you say "aggregation networks". There is no RFC from IETF that defines what an aggregation broadband network is. The term used by IETF is access concentrator that is defined in RFC4388. 5. In section 3, 2nd para, what do you mean by the sentence: [In the case of a routed RG, the RG authenticates with the network on behalf of the (trusted) hosts behind it.]. If hosts in the home sit behind a router, the SP doesn't even see these hosts if hosts acquire IPv6 address using SLAAC. So where does the question arise for "on behalf of hosts"? Am I missing something? 6. This text from the same section seems to be disjoint: [In upcoming networks based on IPv6, nomadic or mobile clients that attach to such networks would find it easy to attach [RFC4779] describes IPv6 deployment options in a TR-059 architecture based on ATM access aggregation. ]. 7. Section 4.1: what do you mean by "high address assignment efficiency"? 8. I would rather that section 4.2 be a sub-section 4.1.2 - that's how the flow of the sub-sections seem to be going. Similarly, section 4.3 should be 4.1.3. 9. Section 4.2, around text that says: [In the routed RG case (1), RG1 configures its link local address and obtains a unique prefix in a router advertisement from the IP Edge. The address derived using this prefix is used in RG management traffic.] Why not use SLAAC or DHCPv6 for the management address? Also how is the address=20 derived - please explain? Same questions for the bridged RG case in ensuing paragraphs of this section. 10. Section 6. What is a sub-router? 11. Figure 7: This level of detail is not need in this draft. Refer to your TR DSL report=20 for such details.=20 12. Figure 9 : Why is there no NS DAD line after "7 DHCP Configuration"? One needs to perform NS DAD for the DHCPv6 address as well. The draft does say so in text after the figure, but if you bothered to draw a figure, the figure should be complete Hemant From owner-v6ops@ops.ietf.org Tue Jul 29 09:12:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD4A3A6ADF for ; Tue, 29 Jul 2008 09:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.895 X-Spam-Level: X-Spam-Status: No, score=-103.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0LabhsbvLDJ for ; Tue, 29 Jul 2008 09:12:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B5293A69D6 for ; Tue, 29 Jul 2008 09:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrmm-000IZU-3f for v6ops-data@psg.com; Tue, 29 Jul 2008 16:10:52 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrmi-000IYt-Fq for v6ops@ops.ietf.org; Tue, 29 Jul 2008 16:10:50 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id DEF65360EB4F; Tue, 29 Jul 2008 09:10:46 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id CAA3428097; Tue, 29 Jul 2008 09:10:46 -0700 (PDT) X-AuditID: 11807130-ae399bb000000ead-81-488f4104b031 Received: from [17.151.104.184] (unknown [17.151.104.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id E8B6328091; Tue, 29 Jul 2008 09:10:44 -0700 (PDT) Cc: IPv6 Operations Message-Id: <21FB5790-4C61-4B64-8541-93353DEE719B@apple.com> From: james woodyatt To: Fred Baker Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Fwd: New Version Notification for draft-ietf-v6ops-cpe-simple-security-03 Date: Tue, 29 Jul 2008 17:10:35 +0100 References: <20080729160419.E35C13A6BD9@core3.amsl.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 29, 2008 17:04:19 IST > To: jhw@apple.com > Subject: New Version Notification for draft-ietf-v6ops-cpe-simple- > security-03 > > > A new version of I-D, draft-ietf-v6ops-cpe-simple-security-03.txt > has been successfuly submitted by James Woodyatt and posted to the > IETF repository. > > Filename: draft-ietf-v6ops-cpe-simple-security > Revision: 03 > Title: Recommended Simple Security Capabilities in Customer > Premises Equipment for Providing Residential IPv6 Internet Service > Creation_date: 2008-07-29 > WG ID: v6ops > Number_of_pages: 32 > > Abstract: > This document makes specific recommendations to the makers of devices > that provide "simple security" capabilities at the perimeter of > local-area IPv6 networks in Internet-enabled homes and small offices. This revision is now ready for working group review. I know of no technical problems, and there is only one blocking editorial issue: whether to copy the heuristic from HOAGLAND or simply to make a reference to it. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Tue Jul 29 09:16:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E6B3A67B6 for ; Tue, 29 Jul 2008 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5NQs4YqUtAj for ; Tue, 29 Jul 2008 09:16:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFB963A6905 for ; Tue, 29 Jul 2008 09:16:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrrw-000JEo-Mc for v6ops-data@psg.com; Tue, 29 Jul 2008 16:16:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrrS-000JBO-3x for v6ops@ops.ietf.org; Tue, 29 Jul 2008 16:16:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 713833A6BBF; Tue, 29 Jul 2008 09:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080729161503.713833A6BBF@core3.amsl.com> Date: Tue, 29 Jul 2008 09:15:03 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-03.txt Pages : 32 Date : 2008-07-29 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-cpe-simple-security-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-29090419.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Tue Jul 29 10:23:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA093A6A4F for ; Tue, 29 Jul 2008 10:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgb8Ec+Ij3en for ; Tue, 29 Jul 2008 10:23:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B52803A6A5C for ; Tue, 29 Jul 2008 10:23:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNst0-0000lS-P7 for v6ops-data@psg.com; Tue, 29 Jul 2008 17:21:22 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNssw-0000kz-Ss for v6ops@ops.ietf.org; Tue, 29 Jul 2008 17:21:20 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4S00F8N2VHGM@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Tue, 29 Jul 2008 12:21:18 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4S00APX2VGNL@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Tue, 29 Jul 2008 12:21:17 -0500 (CDT) Date: Tue, 29 Jul 2008 12:21:16 -0500 From: Frank Xia Subject: Re: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 To: "Hemant Singh (shemant)" , v6ops@ops.ietf.org Message-id: <00a201c8f19f$828c8380$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Thank for your review, please check my inline reply.. BR Frank ----- Original Message ----- From: "Hemant Singh (shemant)" To: Sent: Tuesday, July 29, 2008 10:47 AM Subject: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 I glanced thru this draft. Please see my comments below. 1. Is the draft for Standards Track, Informational, or a BCP? Frank=>It is intended to be informational. General comment. Cable wrote a draft to inform IETF of their IPv6 standards when cable was complete with their standards. Why is DSL giving an FYI to IETF via this draft when your IPv6 standards are clearly not completed? Frank=>We would like to make full use of IETF expert resource when IPv6 depolyment is being discussed in DSL forum. The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt. Frank=>Cable network has many different characteristis from DSL network, and IMHO, it can't be applied to DSL network directly. 2. Why not add the word "Fixed" to the title of the draft since the draft is dealing with only fixed broadband deployments? Frank=>Sound reasonable, let us reconsider. 3. I have a problem with the word Broadband in the title of the draft. The draft should not speak for cable broadband deployment. We may want to add DSL/FTTH or what have you, so that the title is totally clear. Cable also does not need this draft because cable completed such standards for IPv6 two years back. Frank=>Now DSL forum has changed it's name to Broadband Forum. However, I still think you suggest is reasonable. 4. In the Introduction section, you say "aggregation networks". There is no RFC from IETF that defines what an aggregation broadband network is. The term used by IETF is access concentrator that is defined in RFC4388. Frank=>The terms are used in DSL network. The readers of the draft should be both DSL and IETF guys. Anyway, we should clarify them. 5. In section 3, 2nd para, what do you mean by the sentence: [In the case of a routed RG, the RG authenticates with the network on behalf of the (trusted) hosts behind it.]. If hosts in the home sit behind a router, the SP doesn't even see these hosts if hosts acquire IPv6 address using SLAAC. So where does the question arise for "on behalf of hosts"? Am I missing something? Frank=>You are right. We should correct it. 6. This text from the same section seems to be disjoint: [In upcoming networks based on IPv6, nomadic or mobile clients that attach to such networks would find it easy to attach [RFC4779] describes IPv6 deployment options in a TR-059 architecture based on ATM access aggregation. ]. Frank=>We will check further. 7. Section 4.1: what do you mean by "high address assignment efficiency"? Frank=>Due to scarcity of the IPv4 address, hosts share a subnet even though they are layer 2 seperated from each other. This priciple does not apply to IPv6, and each host thus can have a unique prefix. 8. I would rather that section 4.2 be a sub-section 4.1.2 - that's how the flow of the sub-sections seem to be going. Similarly, section 4.3 should be 4.1.3. Frank=> It looks no section 4.2 according to your opinion. 9. Section 4.2, around text that says: [In the routed RG case (1), RG1 configures its link local address and obtains a unique prefix in a router advertisement from the IP Edge. The address derived using this prefix is used in RG management traffic.] Why not use SLAAC or DHCPv6 for the management address? Also how is the address derived - please explain? Same questions for the bridged RG case in ensuing paragraphs of this section. Frank=>It means SLAAC for uptream interface address configuration. Please pay attention to the texts "obtains a unique prefix in a router advertisement from the IP Edge". In bridged RG case, we only illustrate SLAAC case. 10. Section 6. What is a sub-router? Frank=>It means subnet-router anycast address. It is a reserved address. 11. Figure 7: This level of detail is not need in this draft. Refer to your TR DSL report for such details. Frank=>We will consider to delete it. 12. Figure 9 : Why is there no NS DAD line after "7 DHCP Configuration"? One needs to perform NS DAD for the DHCPv6 address as well. The draft does say so in text after the figure, but if you bothered to draw a figure, the figure should be complete Frank=>OK. Hemant From owner-v6ops@ops.ietf.org Tue Jul 29 23:11:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997AF3A69F5 for ; Tue, 29 Jul 2008 23:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LegMCijRLhyt for ; Tue, 29 Jul 2008 23:11:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA04F3A68F8 for ; Tue, 29 Jul 2008 23:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO4pY-000NdP-39 for v6ops-data@psg.com; Wed, 30 Jul 2008 06:06:36 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO4pU-000NcM-Ie for v6ops@ops.ietf.org; Wed, 30 Jul 2008 06:06:34 +0000 Received: (qmail 20830 invoked by uid 417); 30 Jul 2008 06:05:44 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 30 Jul 2008 06:05:44 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Wed, 30 Jul 2008 00:05:44 -0600 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> In-Reply-To: From: EricLKlein@softhome.net To: "Hemant Singh (shemant)" Cc: v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 00:05:44 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [62.219.97.122] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant Singh (shemant) writes: > Folks, > > Shin reviewed our new text and asked for the word "broadband" be removed > from the text so that the text relates to any deployment where such a > device exists. So we have removed the word "broadband" from the text. > New text is as follows: > > [The unnumbered model is incompatible with the strong host model on the > CPE router. The unnumbered model may be inappropriate for use with > certain deployments where a device that uses the strong host model can > operate as a CPE Router.] I personally disagree with this. I think we need to be more specific rather than more general here. We need to specify that this is strictly for fixed broadband regardless of the underlying technology (DSL, Cable, ISDN, T1/T3, 802.16d WiMAX, etc. The rules for mobility based technologies have very different requirements and configurations as they are the device and they connect directly to the service provider network (no separate router and no LAN behind them). Eric From owner-v6ops@ops.ietf.org Tue Jul 29 23:51:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B9C3A69AB for ; Tue, 29 Jul 2008 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gyHwK1QeKsU for ; Tue, 29 Jul 2008 23:51:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 527543A6922 for ; Tue, 29 Jul 2008 23:51:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO5W1-0001h6-Ve for v6ops-data@psg.com; Wed, 30 Jul 2008 06:50:29 +0000 Received: from [66.249.90.176] (helo=ik-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO5Vy-0001gX-4M for v6ops@ops.ietf.org; Wed, 30 Jul 2008 06:50:28 +0000 Received: by ik-out-1112.google.com with SMTP id c21so326547ika.1 for ; Tue, 29 Jul 2008 23:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4mfHYunURO0XZbVzjofh0kykVE8MfbScoMzY37+Ykr8=; b=nx2xSzVQO2o4ATIWBlcQA2zDtM50ii1Ehcqj/Vj0VqTsSNix2aXSO1duaRMcf4Yk1R MTzDCqsfCkwCONxlRK3XIJUcMybESsfPwD/9UfpW1f4oCYh3R4pESg3ePwzcDU3fYGZg 4LQjdM3RjlIwI/tNEb0ub7leIbuK9po8yPhog= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=rNfSaHGKeCGyzMybbCDldCKS93DhxmjtMgiDU5S+2KVmv6KTWdTxwKCPYWZSIh0Df3 2WzAuaThJlo+73z6alk9eqvFi+zAE+T2CZ7Gn9rD87unYa4w3cIh/Zf+nWQG9eAM2CAt WQGNVsDvT83a+VgTMqQE7VJcDAe3j2L0tSYOM= Received: by 10.210.112.4 with SMTP id k4mr4708713ebc.111.1217400624949; Tue, 29 Jul 2008 23:50:24 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.65.55]) by mx.google.com with ESMTPS id q9sm1323136gve.5.2008.07.29.23.50.23 (version=SSLv3 cipher=RC4-MD5); Tue, 29 Jul 2008 23:50:24 -0700 (PDT) Message-ID: <48900F29.7040406@gmail.com> Date: Wed, 30 Jul 2008 18:50:17 +1200 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)" CC: v6ops@ops.ietf.org, Alain Durand Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks for following up on this. On 2008-07-29 20:29, Hemant Singh (shemant) wrote: > Brian, > > I and Wes can recall only two issues that have not reached consensus. ... > Next one is use of ULA for the home network on the LAN interface(s) of > the CPE Router. What we have in mind ULA lasts on the device till the > next reboot (ULA will not be renumbered on the device acquiring a GUA) > upon which the same ULA or a different ULA may be generated by the > device. We are saying the LAN interface(s) will use ULA for the > lifetime of the CPE Router till the router reboots. What about someone who prefers to have a permanent ULA so that devices such as printers have permanent addresses? I think that SHOULD be provided as a user-configurable option. > Alain is one person > who would like to renumber the ULA on the LAN interface acquiring a GUA. > I didn't see enough justification from him to change the draft in the > ULA regard. Remi has also replied to Alain's concerns and claimed they > are non-issues. I think there's a philosophical difference behind that. My personal view of ULAs has always been that their value lies in being provider- independent and stable, and being always available for intra-site communications. IMHO they are not temporary addresses for use during a boot phase or disconnected operation. Thanks Brian > Thanks. > > Hemant > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, July 28, 2008 11:34 AM > To: v6ops@ops.ietf.org > Cc: Alain Durand > Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router > draft is available for review] > > There wasn't time in the meeting today for me to ask this: > > Where is the open issues list for this draft, so that we can identify > the non-consensus items and drive them to a resolution? > > Brian > > From owner-v6ops@ops.ietf.org Wed Jul 30 00:25:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE4E3A6A99 for ; Wed, 30 Jul 2008 00:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A67uKO0CxONh for ; Wed, 30 Jul 2008 00:25:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BB2A3A684A for ; Wed, 30 Jul 2008 00:25:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO61D-0004da-GG for v6ops-data@psg.com; Wed, 30 Jul 2008 07:22:43 +0000 Received: from [66.249.90.179] (helo=ik-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO619-0004d0-Jt for v6ops@ops.ietf.org; Wed, 30 Jul 2008 07:22:41 +0000 Received: by ik-out-1112.google.com with SMTP id c21so343334ika.1 for ; Wed, 30 Jul 2008 00:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cm87McdtbPTHAGDAFrwUwcv4jBoE/CvjZtd1SceVPDg=; b=BBTsc3aZJakjMzEHh6ak5L2kUpPI4OPGW2Iw1bPEv5DHPWCcJ2u3baZ/fbOKVKqYKF z20W3UaFXGhKU9cxVeiVmQhvPNvjWz7SvKc7hi0LIcN5RSDgBt2CEGLZiZnOIGvDfwqb kitpKcKbznOD2e/0/wByVF8B2vkj7zW2y8DBw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=i/2e8okzJri9Qdyv23SwDs0aWTHkXwUFwuODBgNhOzz/UzFO2atlVr+reDlKgQbU1r Z5oJJrEWS1/haWlstfUM8GWcXVhZBnny1Blz1R4H75Dk8zIS7JG/Kd4HW3wimWOOAq3R vj7dxK24SfRPvsy59OBp4lQwkKSVu5W3XRRuU= Received: by 10.210.51.18 with SMTP id y18mr8742412eby.160.1217402558417; Wed, 30 Jul 2008 00:22:38 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.65.55]) by mx.google.com with ESMTPS id t2sm1396728gve.9.2008.07.30.00.22.36 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jul 2008 00:22:37 -0700 (PDT) Message-ID: <489016B7.2050602@gmail.com> Date: Wed, 30 Jul 2008 19:22:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: narten-ipv6-3177bis-48boundary: updating an IAB document References: <200807252015.m6PKFuRu011888@cichlid.raleigh.ibm.com> In-Reply-To: <200807252015.m6PKFuRu011888@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-26 08:15, Thomas Narten wrote: > There were some comments in earlier mail and at the Philly session > saying essentially: 3177 is an IAB document (actually it was a joint > IAB/IESG document) and therefore the IAB needs to change it and the WG > shouldn't (or can't) be the one to do this. > > I've had some informal conversations with I* members about this and > the impression I got was they'd actually prefer this be a WG > document. If it is a regular IETF document, both the IESG/IAB will > have a chance to review and have input. But there is no need for those > organizations to initiate the document or be the primary drivers for > it. > > If the IAB ends up wanting its name on the document or have some other > text included (i.e, to somehow give it the weight needed to updated > 3177), we can have that discussion later. But I think first and > foremost, this document should be an IETF document, since it is > intended to be an IETF recommendation. That means having it come up > through a WG is just fine. > > Having said all that, I will raise the issue again to see if anything > has changed in how best to process this document. > Note that 3177 actually says: "3. Address Delegation Recommendations The IESG and the IAB recommend ..." However, as we've now got more clarity on the various RFC streams, and probably a clearer relationship with IANA than in 2001, I don't think there's much doubt that this should be handled as a regular IETF document. The draft doesn't list an intended status. Are you thinking of anything stronger than Informational? Brian From owner-v6ops@ops.ietf.org Wed Jul 30 00:30:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883DA3A6A90 for ; Wed, 30 Jul 2008 00:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+9a0IvOyRuY for ; Wed, 30 Jul 2008 00:30:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 904AC3A6A99 for ; Wed, 30 Jul 2008 00:30:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO68p-0005OU-Dt for v6ops-data@psg.com; Wed, 30 Jul 2008 07:30:35 +0000 Received: from [66.249.90.180] (helo=ik-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO683-0005Ib-4x for v6ops@ops.ietf.org; Wed, 30 Jul 2008 07:30:23 +0000 Received: by ik-out-1112.google.com with SMTP id c21so346860ika.1 for ; Wed, 30 Jul 2008 00:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pURrG7/o5MATJ38XIvG4ZqLBY/UhdTR2tY5yJybfx30=; b=OSDA1j3gk7imOJihDZ1AFfKslXcFZWTZAJFTytwrN6LFeRnSEnrXDIkNjBHKao3sIk FDCFEb24LTEwkjB/pNfy9wfcgruyWbMidgIx0msnAmnglnJL7LtYln0KQAebZPUt+o2i b9rMFGOeRcKHdr2h2MaKuKkBDAjl/S+ClKINI= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=oJCzVpWYBHfxOys4zEzx4oUuRcjW5ZY4E3wGcVcjmtVVrzGDTFQydjkuDL2OSBE3rw ivxtEGDvE8C9UtCH8iZJw9j2AwKw5IP+p2FGz6iQEw8PGXKvI73/ksJSUL3YRa/nNGDb f3d5YABf0cyc/6jvteV/lFZ0tk1lyS3vE3bSU= Received: by 10.210.87.14 with SMTP id k14mr8872454ebb.60.1217402985956; Wed, 30 Jul 2008 00:29:45 -0700 (PDT) Received: from ?172.16.14.110? ( [130.129.65.55]) by mx.google.com with ESMTPS id f13sm1415261gvd.2.2008.07.30.00.29.44 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jul 2008 00:29:45 -0700 (PDT) Message-ID: <48901862.7020602@gmail.com> Date: Wed, 30 Jul 2008 19:29:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten CC: v6ops@ops.ietf.org Subject: Re: narten-ipv6-3177bis-48boundary: technical justification References: <200807252014.m6PKEA86011871@cichlid.raleigh.ibm.com> In-Reply-To: <200807252014.m6PKEA86011871@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-26 08:14, Thomas Narten wrote: > At the Philly meeting, Bob Hinden raised the following issue (my > summary of his words): > >> completely agree with HD ratio. not in favor of this document in >> current form. 1. I've not seen any analysis that the current /48 >> will result in running out of /48s. there was some analysis with >> previous HD ration. But after changing HD ratio, would like to see >> justification other than just "its too big". would like to see >> technical analysis that there is a problem. > >> wants to see technical justification that the number needs to be >> changed. unless there is technical problem to fix, no need to >> change. > > IMO, this question gets back to "should we change the policy", i.e., > where should the actual boundary be. That is not an IETF question, > that is for the RIRs to decide. I'm also not trying to make the case > that it NEEDS to be changed in this document. (It is true that the > RIRs have already changed the policy, because its members didn't like > a /48 for everyone and also didn't like a one-size-fits all approach, > regardless of what that default value would be). > > One of the "problems" that I'd like to see fixed is the IETF seeming > to be on record as saying that a /48 is necessary and is part of the > architecure. That is how RFC 3177 is being intepreted by some. I.e., > in RIR discussions about the boundary, it is fairly common for some > folk to say "but the IETF said a /48 was necessary, therefore I don't > think we should change it." I agree. I think the IETF needs to get out of the road here. However, I wonder if we can strengthen the wording about /64 a bit, to make a clearer technical recommendation that /64 is too long in most circumstances. Also, I wonder whether we should have a few words for IANA, e.g. 7. IANA Considerations This document makes no specific requests to IANA. However, in setting its policy for delegating IPv6 address space to registries, IANA should allow for the fact that the normal allocation to subscribers will be a prefix shorter than /64. I know that they know that, but it does no harm to be clear that I can see. Brian From owner-v6ops@ops.ietf.org Wed Jul 30 01:16:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF273A6910 for ; Wed, 30 Jul 2008 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfsGqQqmgVYu for ; Wed, 30 Jul 2008 01:16:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C4E23A687A for ; Wed, 30 Jul 2008 01:16:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO6ot-0009I4-QP for v6ops-data@psg.com; Wed, 30 Jul 2008 08:14:03 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO6oq-0009HV-4N for v6ops@ops.ietf.org; Wed, 30 Jul 2008 08:14:01 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6U8D672030557; Wed, 30 Jul 2008 03:13:55 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 11:13:48 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 11:13:47 +0300 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 11:13:47 +0300 Message-ID: In-Reply-To: <48900F29.7040406@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjyEcfvqkh45FK+R2ahqw93E+A3nwACR3Hw References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <48900F29.7040406@gmail.com> From: To: , Cc: , X-OriginalArrivalTime: 30 Jul 2008 08:13:47.0851 (UTC) FILETIME=[313349B0:01C8F21C] X-Nokia-AV: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> Alain is one person >> who would like to renumber the ULA on the LAN interface=20 >acquiring a GUA. >> I didn't see enough justification from him to change the=20 >draft in the=20 >> ULA regard. Remi has also replied to Alain's concerns and claimed=20 >> they are non-issues. > >I think there's a philosophical difference behind that. My=20 >personal view of ULAs has always been that their value lies in=20 >being provider- independent and stable, and being always=20 >available for intra-site communications. IMHO they are not=20 >temporary addresses for use during a boot phase or=20 >disconnected operation. In a use case where WAN connection dynamically changes without (P)MIP support, should the ULAs be used in LAN, the local connectivity would not be disrupted by WAN address changes, right? I.e. the ULA would remain constant, while the global prefix advertised in LAN would experience sudden renumbering (or perhaps controlled, but still quick, renumbering could be possible if WAN change is done with help of two radios (make before break)). The WAN address change can also happen if WAN connection is for any reason disrupted and re-establishment does not result in same global prefix being allocated -> thus immediate renumbering for LAN is required. Best regards, Teemu From owner-v6ops@ops.ietf.org Wed Jul 30 01:30:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E76A28C22D for ; Wed, 30 Jul 2008 01:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JApbn0Z-6lIK for ; Wed, 30 Jul 2008 01:30:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84A473A687A for ; Wed, 30 Jul 2008 01:30:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO72f-000Ael-Iq for v6ops-data@psg.com; Wed, 30 Jul 2008 08:28:17 +0000 Received: from [209.85.200.169] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO72c-000AeP-0h for v6ops@ops.ietf.org; Wed, 30 Jul 2008 08:28:15 +0000 Received: by wf-out-1314.google.com with SMTP id 26so291023wfd.32 for ; Wed, 30 Jul 2008 01:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bh2ESLsCQs1EHB/HcqBYKQw8IuH26YaeWxNCRLm+t2A=; b=USNfLVV8M6f0BOZug7AqlrQaRr8h5ecQTc3XJq0MGKBFI76qKQwDtSEj99jKfqRU60 dSEKZk+/QHZT3VrPySZOVXyjx12fVwaHeNYGNjEbRzIBbAkcbU/tpz8lDLKKC7JCUX0o cnxb3Py8LIac6ipz12Ye3DLBperWQAII9lxak= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=TXaM1L+XFmDuSSw6yLUFWPShBb65oCU+dWdDzUAPxWoLnt7lVuDICELbaWexGR7R+m xsiP3JnKz1HjEEJhqWw60V/AGR8lCNlZ4QCcquTaLn0alvZ3httAUBpvQtT6iWVHDJZi eXmHllnTVhCMNvwsysJbshS0fkaGx06ylLOuY= Received: by 10.143.42.3 with SMTP id u3mr2544285wfj.148.1217406493777; Wed, 30 Jul 2008 01:28:13 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id 27sm1276906wff.3.2008.07.30.01.28.11 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jul 2008 01:28:13 -0700 (PDT) Message-ID: <4890260D.3070105@gmail.com> Date: Wed, 30 Jul 2008 20:27:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com CC: shemant@cisco.com, v6ops@ops.ietf.org, alain_durand@cable.comcast.com Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <48900F29.7040406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-30 20:13, teemu.savolainen@nokia.com wrote: >>> Alain is one person >>> who would like to renumber the ULA on the LAN interface >> acquiring a GUA. >>> I didn't see enough justification from him to change the >> draft in the >>> ULA regard. Remi has also replied to Alain's concerns and claimed >>> they are non-issues. >> I think there's a philosophical difference behind that. My >> personal view of ULAs has always been that their value lies in >> being provider- independent and stable, and being always >> available for intra-site communications. IMHO they are not >> temporary addresses for use during a boot phase or >> disconnected operation. > > In a use case where WAN connection dynamically changes without (P)MIP > support, should the ULAs be used in LAN, the local connectivity would > not be disrupted by WAN address changes, right? I.e. the ULA would > remain constant, while the global prefix advertised in LAN would > experience sudden renumbering (or perhaps controlled, but still quick, > renumbering could be possible if WAN change is done with help of two > radios (make before break)). > > The WAN address change can also happen if WAN connection is for any > reason disrupted and re-establishment does not result in same global > prefix being allocated -> thus immediate renumbering for LAN is > required. Correct. Sessions open to the outside world will break if that happens, but not internal sessions using the ULA. Brian From owner-v6ops@ops.ietf.org Wed Jul 30 05:23:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B72C3A68EA for ; Wed, 30 Jul 2008 05:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohmFPkuv9CG1 for ; Wed, 30 Jul 2008 05:23:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D2483A68C4 for ; Wed, 30 Jul 2008 05:23:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAd5-0009rg-Rh for v6ops-data@psg.com; Wed, 30 Jul 2008 12:18:07 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAd0-0009qa-PD for v6ops@ops.ietf.org; Wed, 30 Jul 2008 12:18:05 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UCHZll003083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 14:17:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: v6ops@ops.ietf.org Message-Id: From: Iljitsch van Beijnum To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: v6-v4 transition scenarios, take 1 Date: Wed, 30 Jul 2008 13:17:53 +0100 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 28 jul 2008, at 19:19, Pekka Savola wrote: > AFAIK, p2p protocols, at least downloading, are smart enough to work > through a NAT box that doesn't support any ALG, UPNP, port > redirection, etc. I have personal experience with this :-) The ones that I've used depend heavily on UPnP (or NAT-PMP) or manual port mappings. If you can't receive incoming sessions, it still works because most other peers can. But you'll see a marked increase in download speeds when you enable incoming sessions because you can now connect to a larger set of peers. > So, does this require special casing in NAT64 techniques or are such > approaches enough client-server -like? For the BitTorrent-like stuff you probably don't really have to do anything: peers behind NAT64 wouldn't be able to receive incoming sessions from IPv4 peers, but they can still have outgoing sessions to many IPv4 peers and they should also be able to talk to IPv6 peers in both directions. (Although IPv6 firewalls get in the way, but you can disable those.) For SIP ICE should work, especially with endpoint independent mapping in the NAT64 box. Other protocols could be upgraded to use ICE as well, but for things like BitTorrent this would require significant changes to the signaling protocol. >> I expect once the IPv6 ball gets rolling people will start turning >> off IPv4 surprisingly fast. > Personally I doubt it -- a lot. Or we have a different things in > mind when we talk about "IPv6 ball gets rolling". > I wouldn't turn off v4 on any service I have association with until > at least 90% and hopefully more than 99% of the user base (or > potential user base) could reach it. Right, I was thinking of the client side. There are basically two things that I regularly do that I can't do when I run IPv6-only now: printing and VoIP. This will only get better over time. (Or I use a much smaller set of apps than most people.) >> Many of the currently used NAT traversal techniques don't work well >> with multiple layers of NAT, and with more users behind an IP >> address it will be harder for users to open up ports to host >> incoming sessions. So I don't think this is necessarily true. > I guess you're referring to NAT traversal mechanisms such as uPNP, > NAT-PMP etc. Yes. From owner-v6ops@ops.ietf.org Wed Jul 30 05:26:18 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2C03A6BD4 for ; Wed, 30 Jul 2008 05:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTt8N-D8BYsa for ; Wed, 30 Jul 2008 05:26:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF9DF3A68C4 for ; Wed, 30 Jul 2008 05:26:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAkc-000AQS-Cd for v6ops-data@psg.com; Wed, 30 Jul 2008 12:25:54 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAkX-000APh-L3 for v6ops@ops.ietf.org; Wed, 30 Jul 2008 12:25:52 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UCONno003212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 14:24:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Brian E Carpenter" , , "Alain Durand" Message-Id: <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 13:24:40 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 29 jul 2008, at 9:29, Hemant Singh (shemant) wrote: > Next one is use of ULA for the home network on the LAN interface(s) of > the CPE Router. What we have in mind ULA lasts on the device till the > next reboot (ULA will not be renumbered on the device acquiring a GUA) Note that "GUA" isn't a widely understood term... I'm somewhat concerned that these ULA addresses will do bad stuff to existing IPv6 implementations which may or may not use ULA source addresses towards public destinations when ULAs have been advertised. ULAs are only really needed with nested CPEs, because if there's only a single CPE you can use link locals. It may also be good to wait a short amount of time for global addresses before advertising an ULA prefix. I would suggest some experimentation with this, both in the bad effects of ULAs and how workable configuration usin link locals is, and only put requirements one way or the other in the document when we know more. From owner-v6ops@ops.ietf.org Wed Jul 30 05:28:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1AC28C1B0 for ; Wed, 30 Jul 2008 05:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoRwdocxxamL for ; Wed, 30 Jul 2008 05:28:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C00E928C2B6 for ; Wed, 30 Jul 2008 05:28:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAmp-000AhH-Ur for v6ops-data@psg.com; Wed, 30 Jul 2008 12:28:11 +0000 Received: from [69.147.75.95] (helo=web62503.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAml-000AgY-Tl for v6ops@ops.ietf.org; Wed, 30 Jul 2008 12:28:09 +0000 Received: (qmail 62988 invoked by uid 60001); 30 Jul 2008 12:28:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=yq3STgNPRL7SWQZzjmWkWIpS/sp+oYtJKxXA3lR8sSJ2Dove4NYJutdN0vxj5sjaamhMNDkiEr4zAXEEs858UY7shYfoDzaXMrrjXR1pq/IObYR8+hOwHxKF2DanAbOMNw00mKQT29GGBiNwr10oboyVWw5+BGqFdtdKDflIn2E=; Received: from [193.49.124.107] by web62503.mail.re1.yahoo.com via HTTP; Wed, 30 Jul 2008 05:28:05 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Wed, 30 Jul 2008 05:28:05 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org, "Hemant Singh \(shemant\)" , "Wes Beebee \(wbeebee\)" Cc: Brian E Carpenter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <259191.61303.qm@web62503.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: What consideration about MLD snooping [RFC4541] on the LAN bridge ? Without it, a multicast flow will flood all segments on all ports. Significant bandwidth can be wasted by flooding. +------------------------+ | Routing CPE w/ bridge | | +------+ +------+ | Port1-|-| | | | | | |Bridge|-----|Router|--|----WAN Port2-|-| | LAN| | | | +------+ +------+ | +------------------------+ (David's reference for a routing CPE with internal MAC bridge) Francois-Xavier --- On Tue, 7/29/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] > To: "Brian E Carpenter" , v6ops@ops.ietf.org > Cc: "Alain Durand" > Date: Tuesday, July 29, 2008, 4:29 AM > Brian, > > I and Wes can recall only two issues that have not reached > consensus. > > The big one was Addressing of the CPE Router WAN interface > because NTT, > AT&T, a few folks from the DSL Forum were not in > complete agreement - I > and Wes are working this one and this is close to closure. > We talked > with NTT yesterday and David Miles who works in the DSL > Forum. We will > send email on this closure sometime today. > > Next one is use of ULA for the home network on the LAN > interface(s) of > the CPE Router. What we have in mind ULA lasts on the > device till the > next reboot (ULA will not be renumbered on the device > acquiring a GUA) > upon which the same ULA or a different ULA may be generated > by the > device. We are saying the LAN interface(s) will use ULA > for the > lifetime of the CPE Router till the router reboots. Alain > is one person > who would like to renumber the ULA on the LAN interface > acquiring a GUA. > I didn't see enough justification from him to change > the draft in the > ULA regard. Remi has also replied to Alain's concerns > and claimed they > are non-issues. > > Thanks. > > Hemant > > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, July 28, 2008 11:34 AM > To: v6ops@ops.ietf.org > Cc: Alain Durand > Subject: Open issues list? [Re: New (-02) version of IPv6 > CPE Router > draft is available for review] > > There wasn't time in the meeting today for me to ask > this: > > Where is the open issues list for this draft, so that we > can identify > the non-consensus items and drive them to a resolution? > > Brian From owner-v6ops@ops.ietf.org Wed Jul 30 05:30:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1576028C2D5 for ; Wed, 30 Jul 2008 05:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikonWsg5HX5Q for ; Wed, 30 Jul 2008 05:30:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 346CE28C32D for ; Wed, 30 Jul 2008 05:30:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAp7-000B0L-UG for v6ops-data@psg.com; Wed, 30 Jul 2008 12:30:33 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOAp3-000AzW-8g for v6ops@ops.ietf.org; Wed, 30 Jul 2008 12:30:31 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UCTw2n003310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 14:29:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Brian E Carpenter" , , "Alain Durand" Message-Id: <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> From: Iljitsch van Beijnum To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 13:30:15 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 29 jul 2008, at 10:43, Hemant Singh (shemant) wrote: > [The unnumbered model is incompatible with the strong host model on > the > CPE router. The unnumbered model may be inappropriate for use with > certain broadband deployments where a device that uses the strong host > model can operate as a CPE Router.] (Can anyone point me to the place where the strong / weak models are described? I can never remember what those are, and the names don't really help...) > [The CPE Router MUST support at least one of two WAN interface models, > one of which will be active on the CPE Router at any given time.] Do you still use a loopback interface with a global address? From owner-v6ops@ops.ietf.org Wed Jul 30 05:58:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954D83A6C01 for ; Wed, 30 Jul 2008 05:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YidEdxJnyWfS for ; Wed, 30 Jul 2008 05:58:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95E603A6953 for ; Wed, 30 Jul 2008 05:58:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOBFM-000Eqo-Fe for v6ops-data@psg.com; Wed, 30 Jul 2008 12:57:40 +0000 Received: from [69.147.75.107] (helo=web62515.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOBFI-000Epk-2d for v6ops@ops.ietf.org; Wed, 30 Jul 2008 12:57:38 +0000 Received: (qmail 11979 invoked by uid 60001); 30 Jul 2008 12:57:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=GCaZ7EepeWwOUri9dkJ88amMt71of8RcIto2tN2oygrEiiEk5dtgBjzObY/7KMJYVYPaYhxk95MtRFiIIJ72W10YqbkAFmPcMwy1gpeN0l4Q8UpxwJcRAT6CxhaDhFHcvX8n/+lWjovgC1aVhTvNb54aPjXcyCDM4JhobTUxaZM=; Received: from [193.49.124.107] by web62515.mail.re1.yahoo.com via HTTP; Wed, 30 Jul 2008 05:57:34 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Wed, 30 Jul 2008 05:57:34 -0700 (PDT) From: Francois-Xavier Le Bail Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: Hemant Singh , Iljitsch van Beijnum Cc: Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand In-Reply-To: <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <256390.11934.qm@web62515.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Strong/weak model : RFC 1122 Francois-Xavier --- On Wed, 7/30/08, Iljitsch van Beijnum wrote: > From: Iljitsch van Beijnum > Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] > To: "Hemant Singh" > Cc: "Brian E Carpenter" , v6ops@ops.ietf.org, "Alain Durand" > Date: Wednesday, July 30, 2008, 8:30 AM > On 29 jul 2008, at 10:43, Hemant Singh (shemant) wrote: > > > [The unnumbered model is incompatible with the strong > host model on > > the > > CPE router. The unnumbered model may be inappropriate > for use with > > certain broadband deployments where a device that uses > the strong host > > model can operate as a CPE Router.] > > (Can anyone point me to the place where the strong / weak > models are > described? I can never remember what those are, and the > names don't > really help...) > > > [The CPE Router MUST support at least one of two WAN > interface models, > > one of which will be active on the CPE Router at any > given time.] > > Do you still use a loopback interface with a global > address? From owner-v6ops@ops.ietf.org Wed Jul 30 07:23:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17D83A6AA9 for ; Wed, 30 Jul 2008 07:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je73EGIbUKG7 for ; Wed, 30 Jul 2008 07:23:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F19F3A6ABD for ; Wed, 30 Jul 2008 07:23:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOCXL-000OJO-2o for v6ops-data@psg.com; Wed, 30 Jul 2008 14:20:19 +0000 Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOCXA-000OHj-PC for v6ops@ops.ietf.org; Wed, 30 Jul 2008 14:20:16 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1KOCX4-0000Uo-E5 for v6ops@ops.ietf.org; Wed, 30 Jul 2008 14:20:02 +0000 Received: from mkb-128-158-209-82.3.cust.bredband2.com ([82.209.158.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jul 2008 14:20:02 +0000 Received: from mc by mkb-128-158-209-82.3.cust.bredband2.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jul 2008 14:20:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: v6ops@ops.ietf.org From: Michael Widerkrantz Subject: Client side for RDNSS option in RA (RFC 5006) Date: Wed, 30 Jul 2008 16:02:46 +0200 Organization: Temple of the Moby Hack Lines: 24 Message-ID: <868wvjbhbt.fsf@tim.hack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mkb-128-158-209-82.3.cust.bredband2.com User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) Cancel-Lock: sha1:FAGepK7d9ZBKMymBUvewoXyIF0Y= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, I thought it might interest the list that I have implemented the client side of RFC 5006, "IPv6 Router Advertisement Option for DNS Configuration". It's released under a two-clause BSD license. You can find the source here: http://hack.org/mc/hacks/radns-0.5.tar.gz See the README file for more information. The program is released in the interest of making RFC 5006 more commonly used in some classes of networks. Big thanks to my employer, Stickybit AB, for agreeing to release this quick and ugly hack. See http://www.stickybit.se/ for more about them. Comments welcome, but I guess they are better kept off-list. If anyone wants to speak about this face to face I'm at the IETF 72 in Dublin until Friday. -- M.C. Widerkrantz http://hack.org/mc/ From owner-v6ops@ops.ietf.org Wed Jul 30 07:39:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914AD3A6B76 for ; Wed, 30 Jul 2008 07:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZCYBKBOxK8Q for ; Wed, 30 Jul 2008 07:39:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 891EE3A6783 for ; Wed, 30 Jul 2008 07:39:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOCoJ-0000IO-Bb for v6ops-data@psg.com; Wed, 30 Jul 2008 14:37:51 +0000 Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOCo7-0000Hg-Jl for v6ops@ops.ietf.org; Wed, 30 Jul 2008 14:37:45 +0000 Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id DE65084B4B; Wed, 30 Jul 2008 16:37:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Kyu49mhMLwTd; Wed, 30 Jul 2008 16:37:35 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 3F9BE84B53; Wed, 30 Jul 2008 16:37:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 3E63A84B4D; Wed, 30 Jul 2008 16:37:35 +0200 (CEST) Date: Wed, 30 Jul 2008 16:37:35 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Michael Widerkrantz cc: v6ops@ops.ietf.org Subject: Re: Client side for RDNSS option in RA (RFC 5006) In-Reply-To: <868wvjbhbt.fsf@tim.hack.org> Message-ID: <20080730163714.X85867@mignon.ki.iif.hu> References: <868wvjbhbt.fsf@tim.hack.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Cool! Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 30 Jul 2008, Michael Widerkrantz wrote: > Hello, > > I thought it might interest the list that I have implemented the client > side of RFC 5006, "IPv6 Router Advertisement Option for DNS > Configuration". It's released under a two-clause BSD license. You can > find the source here: > > http://hack.org/mc/hacks/radns-0.5.tar.gz > > See the README file for more information. > > The program is released in the interest of making RFC 5006 more > commonly used in some classes of networks. > > Big thanks to my employer, Stickybit AB, for agreeing to release this > quick and ugly hack. See http://www.stickybit.se/ for more about them. > > Comments welcome, but I guess they are better kept off-list. If anyone > wants to speak about this face to face I'm at the IETF 72 in Dublin > until Friday. > > -- > M.C. Widerkrantz > http://hack.org/mc/ > > > From owner-v6ops@ops.ietf.org Wed Jul 30 07:55:07 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B793A69F7 for ; Wed, 30 Jul 2008 07:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DuC7BQK7RTD for ; Wed, 30 Jul 2008 07:55:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E11B63A68C7 for ; Wed, 30 Jul 2008 07:55:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOD3r-0002Fa-Gm for v6ops-data@psg.com; Wed, 30 Jul 2008 14:53:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOD3j-0002Er-Mu for v6ops@ops.ietf.org; Wed, 30 Jul 2008 14:53:53 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6UEqbw5022748; Wed, 30 Jul 2008 17:52:37 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6UEqa1l022744; Wed, 30 Jul 2008 17:52:36 +0300 Date: Wed, 30 Jul 2008 17:52:36 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> Message-ID: References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7882/Tue Jul 29 22:06:54 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 30 Jul 2008, Iljitsch van Beijnum wrote: > ULAs are only really needed with nested CPEs, because if there's only a > single CPE you can use link locals. The first part of the sentence is debatable. The last part is wrong. Many applications just don't work if you use link-local addresses. (As a side point, could one CPE even reliably know if there are other CPEs?) FWIW, my belief is that the link-local addresses should never need to be used by humans who can't describe the TCP connection establishment procedure. The implication of what you suggest would imply otherwise. The pain with multi-interface hosts and making apps deal with scope indexes is just too great. I personally don't care for ULA that much myself, but if the alternative is to try to use v6 w/ link-local addresses, ULA at least on surface seems like a better approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 30 08:06:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF9428C2FA for ; Wed, 30 Jul 2008 08:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y54rEbuTcTzE for ; Wed, 30 Jul 2008 08:06:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9DA528C2CD for ; Wed, 30 Jul 2008 08:06:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODF5-0003Gv-9z for v6ops-data@psg.com; Wed, 30 Jul 2008 15:05:31 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODEd-0003DB-6Z for v6ops@ops.ietf.org; Wed, 30 Jul 2008 15:05:18 +0000 Received: from leon.remlab.net (unknown [IPv6:2001:df8:0:16:219:d2ff:fe07:5de5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 393E5191 for ; Wed, 30 Jul 2008 17:05:02 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: v6ops@ops.ietf.org Subject: Re: Client side for RDNSS option in RA (RFC 5006) Date: Wed, 30 Jul 2008 18:05:00 +0300 User-Agent: KMail/1.9.9 References: <868wvjbhbt.fsf@tim.hack.org> In-Reply-To: <868wvjbhbt.fsf@tim.hack.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807301805.00305.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wednesday 30 July 2008 17:02:46 Michael Widerkrantz, you wrote: > I thought it might interest the list that I have implemented the client > side of RFC 5006, "IPv6 Router Advertisement Option for DNS > Configuration". It's released under a two-clause BSD license. You can > find the source here: > > http://hack.org/mc/hacks/radns-0.5.tar.gz ndisc6 has had support for this for a while. I imagine however that dual-st= ack=20 integration considerations will push this to higher-level network=20 connection "manager" applications. Also, on Debian/Ubuntu et al, people can= =20 get RFC5006 working today, with: # apt-get install rdnssd Regards, =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Jul 30 08:13:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BC13A6C0C for ; Wed, 30 Jul 2008 08:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA3C3qihSDmT for ; Wed, 30 Jul 2008 08:13:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 148853A68C7 for ; Wed, 30 Jul 2008 08:13:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODLy-0004CC-Kv for v6ops-data@psg.com; Wed, 30 Jul 2008 15:12:38 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODLu-0004BV-Fc for v6ops@ops.ietf.org; Wed, 30 Jul 2008 15:12:36 +0000 Received: from leon.remlab.net (unknown [IPv6:2001:df8:0:16:219:d2ff:fe07:5de5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 7E8CB192; Wed, 30 Jul 2008 17:12:33 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: Pekka Savola Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 18:12:31 +0300 User-Agent: KMail/1.9.9 Cc: Iljitsch van Beijnum , Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand References: <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807301812.32113.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wednesday 30 July 2008 17:52:36 Pekka Savola, you wrote: > On Wed, 30 Jul 2008, Iljitsch van Beijnum wrote: > > ULAs are only really needed with nested CPEs, because if there's only a > > single CPE you can use link locals. > > The first part of the sentence is debatable. The last part is wrong. > Many applications just don't work if you use link-local addresses. > (As a side point, could one CPE even reliably know if there are other > CPEs?) > > FWIW, my belief is that the link-local addresses should never need to > be used by humans who can't describe the TCP connection establishment > procedure. The implication of what you suggest would imply otherwise. > The pain with multi-interface hosts and making apps deal with scope > indexes is just too great. I personally don't care for ULA that much > myself, but if the alternative is to try to use v6 w/ link-local > addresses, ULA at least on surface seems like a better approach. I am in total agreement here. =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Jul 30 08:15:41 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04363A69D6 for ; Wed, 30 Jul 2008 08:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.594 X-Spam-Level: X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQWUXDT9Gnpo for ; Wed, 30 Jul 2008 08:15:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9679E28C373 for ; Wed, 30 Jul 2008 08:14:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODNz-0004TW-Gy for v6ops-data@psg.com; Wed, 30 Jul 2008 15:14:43 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODNu-0004Sd-JD for v6ops@ops.ietf.org; Wed, 30 Jul 2008 15:14:40 +0000 X-IronPort-AV: E=Sophos;i="4.31,279,1215388800"; d="scan'208";a="16017277" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2008 15:14:35 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6UFEZHk031358; Wed, 30 Jul 2008 11:14:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UFEYD6012742; Wed, 30 Jul 2008 15:14:35 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 11:14:33 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 11:14:32 -0400 Message-ID: In-Reply-To: <259191.61303.qm@web62503.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjyP9J3xObnVTeIR+2SDppOlESTEAAFp4jw References: <259191.61303.qm@web62503.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" , , "Wes Beebee (wbeebee)" Cc: "Brian E Carpenter" X-OriginalArrivalTime: 30 Jul 2008 15:14:33.0303 (UTC) FILETIME=[F8A98E70:01C8F256] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3374; t=1217430875; x=1218294875; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=20,=0A=20=20=20=20=20=20=20=20=22 Wes=20Beebee=20(wbeebee)=22=20; bh=DF0rLjaQRUszgCzb2UIkn7+KOugFclokg98TkEsR8YE=; b=r/4cjNoUWl4m5pZ/S5Y0fr581jQOWFJOa9oyWI968c5Tpkbj4/3RubO8fz //rwXlFF2Ml8p0fY/5pyawS7yJzS2IohRHrHQA8UbY4glHBfsd2qMtQPOgj+ te5sSj2lZK; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Of course, if there is a bridge to the LAN, then MLD snooping is required. But a CPE Router may not include a bridge to the LAN in which case no MLD snooping is required. Our new mcast section, that essentially references RFC4605, will add such a statement. Hemant=20 -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Wednesday, July 30, 2008 1:28 PM To: v6ops@ops.ietf.org; Hemant Singh (shemant); Wes Beebee (wbeebee) Cc: Brian E Carpenter Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] What consideration about MLD snooping [RFC4541] on the LAN bridge ? Without it, a multicast flow will flood all segments on all ports. Significant bandwidth can be wasted by flooding. +------------------------+ | Routing CPE w/ bridge | | +------+ +------+ | Port1-|-| | | | | | |Bridge|-----|Router|--|----WAN Port2-|-| | LAN| | | | +------+ +------+ | +------------------------+ (David's reference for a routing CPE with internal MAC bridge) Francois-Xavier --- On Tue, 7/29/08, Hemant Singh (shemant) wrote: > From: Hemant Singh (shemant) > Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE=20 > Router draft is available for review] > To: "Brian E Carpenter" ,=20 > v6ops@ops.ietf.org > Cc: "Alain Durand" > Date: Tuesday, July 29, 2008, 4:29 AM > Brian, >=20 > I and Wes can recall only two issues that have not reached consensus. >=20 > The big one was Addressing of the CPE Router WAN interface because=20 > NTT, AT&T, a few folks from the DSL Forum were not in complete=20 > agreement - I and Wes are working this one and this is close to=20 > closure. > We talked > with NTT yesterday and David Miles who works in the DSL Forum. We=20 > will send email on this closure sometime today. >=20 > Next one is use of ULA for the home network on the LAN > interface(s) of > the CPE Router. What we have in mind ULA lasts on the device till the > next reboot (ULA will not be renumbered on the device acquiring a GUA) > upon which the same ULA or a different ULA may be generated by the=20 > device. We are saying the LAN interface(s) will use ULA for the=20 > lifetime of the CPE Router till the router reboots. Alain is one=20 > person who would like to renumber the ULA on the LAN interface=20 > acquiring a GUA. > I didn't see enough justification from him to change the draft in the=20 > ULA regard. Remi has also replied to Alain's concerns and claimed=20 > they are non-issues. >=20 > Thanks. >=20 > Hemant >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, July 28, 2008 11:34 AM > To: v6ops@ops.ietf.org > Cc: Alain Durand > Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router=20 > draft is available for review] >=20 > There wasn't time in the meeting today for me to ask > this: >=20 > Where is the open issues list for this draft, so that we can identify=20 > the non-consensus items and drive them to a resolution? >=20 > Brian =20 From owner-v6ops@ops.ietf.org Wed Jul 30 08:33:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E4E3A6820 for ; Wed, 30 Jul 2008 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhCHyXDrj646 for ; Wed, 30 Jul 2008 08:32:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 940053A694D for ; Wed, 30 Jul 2008 08:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODck-0006Vq-8e for v6ops-data@psg.com; Wed, 30 Jul 2008 15:29:58 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODca-0006UY-OF for v6ops@ops.ietf.org; Wed, 30 Jul 2008 15:29:52 +0000 X-IronPort-AV: E=Sophos;i="4.31,279,1215388800"; d="scan'208";a="15999952" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2008 15:29:47 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6UFTlVM007224; Wed, 30 Jul 2008 11:29:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6UFTlVM010404; Wed, 30 Jul 2008 15:29:47 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 11:29:47 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 11:29:47 -0400 Message-ID: In-Reply-To: <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjyQAysD4jk0ftPTK2ghTOJYooWtQAFzG8w References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "Brian E Carpenter" , , "Alain Durand" X-OriginalArrivalTime: 30 Jul 2008 15:29:47.0576 (UTC) FILETIME=[199C8B80:01C8F259] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=907; t=1217431787; x=1218295787; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20; bh=57KerZYnCmWv0y7EdykAQ7boXu3oF6EeW4xW0zaxV8k=; b=rk7dV2KZMusmLRFO++vkRRD1RBO64w5xd7OSrnkbqJlzNvbYHQ4b9h73+u ofnNBeHA0YaG72d8ozYMh3Ct5HtgLyK70piE/QmI5jFUZ5uVGKC1JIEvbD9f qKC7l2G61o; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > (Can anyone point me to the place where the strong / weak models are described? I can never remember what those are, and the names don't really help...) http://en.wikipedia.org/wiki/Host_model > Do you still use a loopback interface with a global address? If the WAN interface has acquired a global address, then a loopback interface is not needed with a global address to source WAN packets. However, the Loopback interface has other uses. Please see the slide titled "Routing Domains and Address assignments" from our v6ops presentation and see that the Loopback interface in the picture is being used with an anycast address for ICMP health check (as per RFC4241). Also read the latest addressing behavior in the bullets of the same slide. You see, a Loopback interface is always available on a router. One can always use the Loopback interface on the router. =20 Hemant From owner-v6ops@ops.ietf.org Wed Jul 30 08:39:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADB73A6903 for ; Wed, 30 Jul 2008 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni8uHQGMbOZ9 for ; Wed, 30 Jul 2008 08:39:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C01593A6946 for ; Wed, 30 Jul 2008 08:39:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODkz-0007TR-8p for v6ops-data@psg.com; Wed, 30 Jul 2008 15:38:29 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KODkv-0007Sy-1Y for v6ops@ops.ietf.org; Wed, 30 Jul 2008 15:38:27 +0000 X-IronPort-AV: E=Sophos;i="4.31,279,1215388800"; d="scan'208";a="59455389" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Jul 2008 15:37:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6UFbr2Q027103; Wed, 30 Jul 2008 08:37:53 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6UFbqlt015162; Wed, 30 Jul 2008 15:37:53 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 11:37:43 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 11:37:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjyVBnXxJhbO2I1Sy6YDRr0WbLr3wABVF/w References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> From: "Hemant Singh (shemant)" To: "Pekka Savola" , "Iljitsch van Beijnum" Cc: "Brian E Carpenter" , , "Alain Durand" X-OriginalArrivalTime: 30 Jul 2008 15:37:43.0479 (UTC) FILETIME=[35459470:01C8F25A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1860; t=1217432273; x=1218296273; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20; bh=vj9EpegIqRvj8UreyTwZUysA2p7b3lIq/U5doYJ4Onk=; b=FGXDFe7+8eYIIeeGG49ZlUoYtW3Bzves2ptlFuSHwJPUCnUn29T5v7/Jap PjMSjClfoD2S86X/szS8a4T+CaPijt2avcK676UwnVck7awlubHr6VpTri7p w0402bSyfL; Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Pekka is correct. It has been discussed in this mailer during discussion of this draft that link-local's will never work in all cases for every app. A CPE Router, say rtr1, can detect another CPE Router, rtr2, cascaded behind it, if the DHCPv6 server on rt1 receives a DHCPv6 message for IA_PD. Since the domain is a home, a rouge router in the home can spoof such behavior, in which case the detection may be unreliable. Hemant -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Wednesday, July 30, 2008 3:53 PM To: Iljitsch van Beijnum Cc: Hemant Singh (shemant); Brian E Carpenter; v6ops@ops.ietf.org; Alain Durand Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] On Wed, 30 Jul 2008, Iljitsch van Beijnum wrote: > ULAs are only really needed with nested CPEs, because if there's only=20 > a single CPE you can use link locals. The first part of the sentence is debatable. The last part is wrong.=20 Many applications just don't work if you use link-local addresses.=20 (As a side point, could one CPE even reliably know if there are other CPEs?) FWIW, my belief is that the link-local addresses should never need to be used by humans who can't describe the TCP connection establishment procedure. The implication of what you suggest would imply otherwise.=20 The pain with multi-interface hosts and making apps deal with scope indexes is just too great. I personally don't care for ULA that much myself, but if the alternative is to try to use v6 w/ link-local addresses, ULA at least on surface seems like a better approach. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 30 09:30:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC9728C379 for ; Wed, 30 Jul 2008 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvoipGJTWD-n for ; Wed, 30 Jul 2008 09:30:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF7BA28C374 for ; Wed, 30 Jul 2008 09:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEXr-000DoC-Gn for v6ops-data@psg.com; Wed, 30 Jul 2008 16:28:59 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEXn-000DnO-Fy for v6ops@ops.ietf.org; Wed, 30 Jul 2008 16:28:57 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UGSFjB007418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 18:28:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand Message-Id: From: Iljitsch van Beijnum To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 17:28:33 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 30 jul 2008, at 15:52, Pekka Savola wrote: >> ULAs are only really needed with nested CPEs, because if there's >> only a single CPE you can use link locals. > The first part of the sentence is debatable. The last part is > wrong. Many applications just don't work if you use link-local > addresses. It's not impossible to provide an application that will work with link- locals. But it shouldn't be too difficult to get the browser vendors on board with this once we hammer out how this should work. I do agree that link local literarls are unworkable, there would have to be some discovery / name resolution in place. But look at Apple, they've been doing this for some years now wih their airport base stations, although they of course use a special configuration utility, not a web interface. > (As a side point, could one CPE even reliably know if there are > other CPEs?) Of course, because it will see their DHCPv6 PD requests. > The pain with multi-interface hosts and making apps deal with scope > indexes is just too great. Trying to set up two CPEs by connecting them both to different interfaces isn't really a good idea... I would agree if the ULA approach was painfree, but it isn't, users may end up having to reboot to get rid of them in order to gain reliable IPv6 connectivity. IF we use ULAs for configuration this has to be very carefully limited and controlled to limit these side effects. From owner-v6ops@ops.ietf.org Wed Jul 30 09:33:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB28428C374 for ; Wed, 30 Jul 2008 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw2938IVhGys for ; Wed, 30 Jul 2008 09:33:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4645A28C0F5 for ; Wed, 30 Jul 2008 09:33:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEb7-000EDK-Uq for v6ops-data@psg.com; Wed, 30 Jul 2008 16:32:21 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEb0-000ECI-R6 for v6ops@ops.ietf.org; Wed, 30 Jul 2008 16:32:20 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UGVjfk007461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 18:31:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: "Brian E Carpenter" , , "Alain Durand" Message-Id: From: Iljitsch van Beijnum To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 17:32:03 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 30 jul 2008, at 16:29, Hemant Singh (shemant) wrote: >> http://en.wikipedia.org/wiki/Host_model Thanks (and the earlier RFC 1122 reference, too). >> Do you still use a loopback interface with a global address? > If the WAN interface has acquired a global address, then a loopback > interface is not needed with a global address to source WAN packets. > However, the Loopback interface has other uses. But can't these uses be accommodated through the address of a LAN interface? If ISPs end up skimping on address space, using up a /64 for a loopback interface would be highly undesirable. If the LAN interface isn't fully functional, it could still be ok to present ISPs with the tradeoff to either forego the functions provided by the always reachable address, or require them to provide a WAN address. From owner-v6ops@ops.ietf.org Wed Jul 30 09:36:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610828C385 for ; Wed, 30 Jul 2008 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEyzRxgEeEOO for ; Wed, 30 Jul 2008 09:36:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05CC728C388 for ; Wed, 30 Jul 2008 09:36:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEej-000Ejk-5Q for v6ops-data@psg.com; Wed, 30 Jul 2008 16:36:05 +0000 Received: from [69.147.75.102] (helo=web62510.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEef-000Ej2-6j for v6ops@ops.ietf.org; Wed, 30 Jul 2008 16:36:03 +0000 Received: (qmail 27063 invoked by uid 60001); 30 Jul 2008 16:35:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=UugrNxW3dfO+huCV0XkQWTMMu/d8YKCI98/EqOzdsUIZgkMmeFJN3+dGHLxjlsKDwRZqofUVVzTvmIzlP2QRPP0xpxVMk6VP29/EwUR7Es6UeIeI0pEDoAIhv0WKbRTcKYVEjDLW5jfMP9JjOhxoNo3BkAJyCULhi3HZhrJ0wLQ=; Received: from [193.49.124.107] by web62510.mail.re1.yahoo.com via HTTP; Wed, 30 Jul 2008 09:35:59 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Wed, 30 Jul 2008 09:35:59 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org, "Wes Beebee \(wbeebee\)" , "Hemant Singh \(shemant\)" Cc: Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <752595.25732.qm@web62510.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Wed, 7/30/08, Hemant Singh (shemant) wrote: > Of course, if there is a bridge to the LAN, then MLD > snooping is required. > [...] > Our new mcast section, that essentially references RFC4605, > will add such a statement. Good, Francois-Xavier > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Wednesday, July 30, 2008 1:28 PM > To: v6ops@ops.ietf.org; Hemant Singh (shemant); Wes Beebee > (wbeebee) > Cc: Brian E Carpenter > Subject: RE: Open issues list? [Re: New (-02) version of > IPv6 CPE Router > draft is available for review] > > What consideration about MLD snooping [RFC4541] on the LAN > bridge ? > Without it, a multicast flow will flood all segments on all > ports. > Significant bandwidth can be wasted by flooding. > > +------------------------+ > | Routing CPE w/ bridge | > | +------+ +------+ | > Port1-|-| | | | | > | |Bridge|-----|Router|--|----WAN > Port2-|-| | LAN| | | > | +------+ +------+ | > +------------------------+ > (David's reference for a routing CPE with internal MAC > bridge) > > Francois-Xavier From owner-v6ops@ops.ietf.org Wed Jul 30 09:46:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4C828C120 for ; Wed, 30 Jul 2008 09:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzIBGe2+i1KO for ; Wed, 30 Jul 2008 09:46:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2762728C311 for ; Wed, 30 Jul 2008 09:46:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEna-000FxK-3p for v6ops-data@psg.com; Wed, 30 Jul 2008 16:45:14 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOEnQ-000FuE-0v for v6ops@ops.ietf.org; Wed, 30 Jul 2008 16:45:08 +0000 X-IronPort-AV: E=Sophos;i="4.31,280,1215388800"; d="scan'208";a="39306708" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 30 Jul 2008 16:45:00 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UGj0NS027812; Wed, 30 Jul 2008 09:45:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6UGimOd013671; Wed, 30 Jul 2008 16:45:00 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 12:44:56 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 12:44:56 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjyYdosj6g9TKnaRMmfUqEf9DsJxwAAUSnQ References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <405F8B12-CBFF-4A79-B49A-1ECAA151B060@muada.com> From: "Hemant Singh (shemant)" To: "Iljitsch van Beijnum" Cc: "Brian E Carpenter" , , "Alain Durand" X-OriginalArrivalTime: 30 Jul 2008 16:44:56.0545 (UTC) FILETIME=[992A9D10:01C8F263] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=624; t=1217436300; x=1218300300; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20; bh=7Ljm38twwxzptkigrOsj03ACV/YLwvxJSkg3vaea2lA=; b=tzU92kULTpV3yTIca0FFKdv4vXfYF+b44xHoA2EsCVUm8JTPWmxaLxc3xz AK56Jjzp7o6G7blWiJJGuM79oo/IESoqErwcg/5hN28yvYbIWAvuntKKrOae sqkT/DsctvKhvp+0Mn3/FsE3kxAVptkwTA66wFsJdCPQ/2S9SxFkU=; Authentication-Results: sj-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > But can't these uses be accommodated through the address of a LAN interface? > If ISPs end up skimping on address space, using up a /64 for a loopback interface would be highly undesirable. See my email reply to David Miles who asked for use of a LAN GUA to source WAN traffic out to the SP. Yes, it is possible. BTW, I am also replying to your other email on our use of GUA. We have defined the acronym in the document before using it. So it's use is very clear. However, I do appreciate your point. If there is another better known acronym used by the community, we will change GUA to that. Hemant From owner-v6ops@ops.ietf.org Wed Jul 30 10:13:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCE73A6C28 for ; Wed, 30 Jul 2008 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aucnMNg0a9bH for ; Wed, 30 Jul 2008 10:13:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2407B3A6C26 for ; Wed, 30 Jul 2008 10:13:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFEA-000Jrx-6l for v6ops-data@psg.com; Wed, 30 Jul 2008 17:12:42 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFE6-000JrJ-Fh for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:12:40 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 7AA5834AFE28 for ; Wed, 30 Jul 2008 10:12:09 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 5FF0D464002 for ; Wed, 30 Jul 2008 10:12:09 -0700 (PDT) X-AuditID: 11807135-acd1cbb00000652c-03-4890a0e82bdd Received: from [17.66.43.108] (unknown [17.66.43.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id D849F420009 for ; Wed, 30 Jul 2008 10:12:08 -0700 (PDT) Message-Id: From: james woodyatt To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: draft-durand-dual-stack-lite Date: Wed, 30 Jul 2008 18:12:06 +0100 X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: everyone-- This draft describes a scenario where the public IPv4 address mapped to any particular CPE host is assigned to a carrier-grade NAT device located in the service provider network. To that end, I'd like to see more text that talks about port-mapping protocols like UPnP IGD and NAT-PMP than simply a naked statement that they "may or may not be supported" by the NAT. If these protocols are to be supported by a NAT located in the service provider network, regardless of whether the dual-stack-lite architecture is used vs. the multiple-layers of NAT, there is the issue that NAT-PMP and/or UPnP needs to be proxied by the local CPE gateway on behalf of the NAT. This is where the dual-stack-lite architecture may be inferior to multiple-layers of NAT, but it's not clear from the draft. Let me explain... In the dual-stack-lite architecture, it's not clear to me that all the IPv4 hosts behind the CPE router-- using RFC1918 addresses, which I hesitate to call private addresses because they are *not* private in this architecture-- will be assigned NAT mappings for the same public IPv4 address. If they do not, then NAT-PMP cannot be proxied by the CPE router. The reason is that the single public IPv4 address used by the NAT-PMP server is multicast in the announcement packets to all the hosts in the RFC 1918 subnet. This deficiency in the dual-stack-lite architecture could be addressed by making an explicit guarantee that all the nodes behind a single IPv6 tunnel to the NAT will be mapped to a single public IPv4 address. I also have concerns about hairpinning in the dual-stack-lite architecture. Not only must the NAT exhibit proper hairpinning behavior, it must hairpin properly between multiple overlapping customer address realms. I see no mention of hairpinning at all in this draft. If it's out of scope, I'd like to see a reference to the documents for which it *is* in scope. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Jul 30 10:31:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96313A6C3D for ; Wed, 30 Jul 2008 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP9+wDMjOONW for ; Wed, 30 Jul 2008 10:31:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B86783A65A5 for ; Wed, 30 Jul 2008 10:31:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFVT-000MDJ-QF for v6ops-data@psg.com; Wed, 30 Jul 2008 17:30:35 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFVP-000MCh-9l for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:30:33 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 05C5E34B081F; Wed, 30 Jul 2008 10:30:31 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id DBECD464002; Wed, 30 Jul 2008 10:30:30 -0700 (PDT) X-AuditID: 11807135-acd1cbb00000652c-4f-4890a535ec00 Received: from [17.66.43.108] (unknown [17.66.43.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id 680A7420006; Wed, 30 Jul 2008 10:30:29 -0700 (PDT) Cc: Pekka Savola , Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand Message-Id: <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> From: james woodyatt To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 18:30:27 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 30, 2008, at 17:28, Iljitsch van Beijnum wrote: > > But look at Apple, they've been doing this for some years now wih > their airport base stations, although they of course use a special > configuration utility, not a web interface. Apple uses IPv6 link-local transport for a wide variety of user application protocols, e.g. AirTunes, iTunes library sharing, iPhoto sharing, Time Machine w/ Time Capsule, etc. The big win for us is that we don't have any address realm conflicts with IPv6 link-local when hosts are attached as a bastion between their ethernet and Wi-fi interfaces. If it weren't for the utility of IPv6 link-local in preventing address realm conflicts, I don't think very many Mac OS X users would today be seeing any real-world benefit *at* *all* to having their IPv6 stacks enabled. Indeed, many users are now turning *off* their IPv6 stacks altogether to workaround the usual problems caused by it and they're finding that the address realm conflict avoidance feature is not something they miss all that much. Still, we remain committed to using IPv6 link-local in this fashion for the foreseeable future. To that extent, we have begun explaining to our network interface chipset vendors that hardware support for IPv6 checksum calculation/verification and TCP segment offloading is one of our considerations when evaluating their products for use in our supply chain. I mention all this to surface the importance of us all getting over this bizarre aversion to the idea that link-local scope IPv6 addresses are not required for use once there is a global scope prefix advertised on the link. Some of the unique local address arguments we are seeing here are red herrings. Unique local address prefixes are only really useful when the CPE LAN is segmented into more than one link without any bridges between them, but they still within the same administrative domain and routing policy must be used to separate them. These topologies are... rare... in residential networks. (I don't know how rare, but I'd be surprised if they account for more than a tenth of a percent of all deployments.) -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Jul 30 10:42:14 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9463B28C3A2 for ; Wed, 30 Jul 2008 10:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzszH6Z8OHnT for ; Wed, 30 Jul 2008 10:42:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E45B28C39C for ; Wed, 30 Jul 2008 10:42:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFew-000N3q-1w for v6ops-data@psg.com; Wed, 30 Jul 2008 17:40:22 +0000 Received: from [2001:1af8:2:5::23] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFek-000Mzb-Hf for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:40:18 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UHcGK0008524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 19:38:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: IPv6 Operations Message-Id: <748F7F6F-353B-4F95-9101-0CF40CAEDED5@muada.com> From: Iljitsch van Beijnum To: james woodyatt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: draft-durand-dual-stack-lite Date: Wed, 30 Jul 2008 18:38:33 +0100 References: X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 30 jul 2008, at 18:12, james woodyatt wrote: > This deficiency in the dual-stack-lite architecture could be > addressed by making an explicit guarantee that all the nodes behind > a single IPv6 tunnel to the NAT will be mapped to a single public > IPv4 address. > I also have concerns about hairpinning in the dual-stack-lite > architecture. Not only must the NAT exhibit proper hairpinning > behavior, it must hairpin properly between multiple overlapping > customer address realms. I see no mention of hairpinning at all in > this draft. If it's out of scope, I'd like to see a reference to > the documents for which it *is* in scope. Please have a look at the NAT64 draft. Apart from the presence of IPv4 headers, the specification of the behavior of the NAT64 translator can also apply to Alain's carrier grade NAT. In the NAT64 draft we specify conformance to the BEHAVE requirements, so ICE will get you through the NAT. I may be mistaken, but I think it should be doable to make a UPnP/NAT- PMP to STUN "translator" and get incoming stuff to the hosts like this. From owner-v6ops@ops.ietf.org Wed Jul 30 10:45:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DA03A6876 for ; Wed, 30 Jul 2008 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.34 X-Spam-Level: ** X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5YNvpkhPu4I for ; Wed, 30 Jul 2008 10:45:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9291828C3AE for ; Wed, 30 Jul 2008 10:45:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFjF-000Nes-JB for v6ops-data@psg.com; Wed, 30 Jul 2008 17:44:49 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFjA-000NdC-CK for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:44:47 +0000 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9666518; Wed, 30 Jul 2008 13:44:14 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:44:14 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.77]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Jul 2008 17:43:14 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 30 Jul 2008 18:43:11 +0100 Subject: Re: draft-durand-dual-stack-lite From: Alain Durand To: james woodyatt , IPv6 Operations Message-ID: Thread-Topic: draft-durand-dual-stack-lite Thread-Index: Acjya7wG+ItmDo1KQk6sSqpj4eUTew== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jul 2008 17:44:14.0551 (UTC) FILETIME=[E1E73E70:01C8F26B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: James, Thank you very much for those very good comments. Many of them have been discussed during this week, either privately or during one of the meetings. We are going to merge the dual-stack-lite and SNAT drafts in the softwire wg and we will include text to address those points. - Alain. On 7/30/08 6:12 PM, "james woodyatt" wrote: > everyone-- > > This draft describes a scenario where the public IPv4 address mapped > to any particular CPE host is assigned to a carrier-grade NAT device > located in the service provider network. To that end, I'd like to see > more text that talks about port-mapping protocols like UPnP IGD and > NAT-PMP than simply a naked statement that they "may or may not be > supported" by the NAT. > > If these protocols are to be supported by a NAT located in the service > provider network, regardless of whether the dual-stack-lite > architecture is used vs. the multiple-layers of NAT, there is the > issue that NAT-PMP and/or UPnP needs to be proxied by the local CPE > gateway on behalf of the NAT. > > This is where the dual-stack-lite architecture may be inferior to > multiple-layers of NAT, but it's not clear from the draft. Let me > explain... > > In the dual-stack-lite architecture, it's not clear to me that all the > IPv4 hosts behind the CPE router-- using RFC1918 addresses, which I > hesitate to call private addresses because they are *not* private in > this architecture-- will be assigned NAT mappings for the same public > IPv4 address. If they do not, then NAT-PMP cannot be proxied by the > CPE router. The reason is that the single public IPv4 address used by > the NAT-PMP server is multicast in the announcement packets to all the > hosts in the RFC 1918 subnet. > > This deficiency in the dual-stack-lite architecture could be addressed > by making an explicit guarantee that all the nodes behind a single > IPv6 tunnel to the NAT will be mapped to a single public IPv4 address. > > I also have concerns about hairpinning in the dual-stack-lite > architecture. Not only must the NAT exhibit proper hairpinning > behavior, it must hairpin properly between multiple overlapping > customer address realms. I see no mention of hairpinning at all in > this draft. If it's out of scope, I'd like to see a reference to the > documents for which it *is* in scope. > > > -- > james woodyatt > member of technical staff, communications engineering > > > > From owner-v6ops@ops.ietf.org Wed Jul 30 10:46:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130783A6876 for ; Wed, 30 Jul 2008 10:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxzzXzI39NiN for ; Wed, 30 Jul 2008 10:46:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 186C728C3B0 for ; Wed, 30 Jul 2008 10:46:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFkV-000Nrk-Lf for v6ops-data@psg.com; Wed, 30 Jul 2008 17:46:07 +0000 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFkR-000Nr3-Cw for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:46:05 +0000 Received: from [IPv6:2001:df8::16:21b:63ff:fe02:3c13] ([IPv6:2001:df8:0:16:21b:63ff:fe02:3c13]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6UHjRgt008659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2008 19:45:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Cc: Pekka Savola , Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand Message-Id: <33D6F021-57A1-4028-8236-D1ED31D80DEA@muada.com> From: Iljitsch van Beijnum To: james woodyatt In-Reply-To: <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 18:45:44 +0100 References: <7582BC68E4994F4ABF0BD4723975C3FA0A004E31@crexc41p> <488DA08B.8010201@gmail.com> <8B58C5C9-B230-4E41-87EB-D6EDA9F0EC8B@muada.com> <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 30 jul 2008, at 18:30, james woodyatt wrote: > Unique local address prefixes are only really useful when the CPE > LAN is segmented into more than one link without any bridges between > them, but they still within the same administrative domain and > routing policy must be used to separate them. These topologies > are... rare... in residential networks. (I don't know how rare, but > I'd be surprised if they account for more than a tenth of a percent > of all deployments.) Hm, I've seen the situation where people daisy chain two (or more) NAT boxes, for instance, an Airport Extreme doing NAT connecting to an ISP- provided ADSL modem doing NAT. In IPv6 I expect the multi-subnet configuration to become more common over time as more and more service providers want to put networked devices in the home, and paranoid users will want to split their home network into a semi-public part and a private part where they don't have to worry about being spied upon by their refrigirator. Especially if service providers take it upon themselves to build such a solution on behalf of the users, for instance, to make sure the user doesn't mess with the IPTV connectivity. Since unlike with v4 NAT, you can't do multisubnet with v6 without help from the other box and the ISP, it's important that we accommodate this use case. From owner-v6ops@ops.ietf.org Wed Jul 30 10:55:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01E83A68AF for ; Wed, 30 Jul 2008 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-1DTFZqS6oJ for ; Wed, 30 Jul 2008 10:55:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC2643A6AA4 for ; Wed, 30 Jul 2008 10:55:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFsf-000PAN-TT for v6ops-data@psg.com; Wed, 30 Jul 2008 17:54:33 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFsc-000P9q-GL for v6ops@ops.ietf.org; Wed, 30 Jul 2008 17:54:32 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 280F034B1587; Wed, 30 Jul 2008 10:54:30 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 1465F28094; Wed, 30 Jul 2008 10:54:30 -0700 (PDT) X-AuditID: 11807130-adb98bb000000ead-8c-4890aad5ce2b Received: from [17.66.43.108] (unknown [17.66.43.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 6C16A28091; Wed, 30 Jul 2008 10:54:29 -0700 (PDT) Cc: IPv6 Operations Message-Id: From: james woodyatt To: Iljitsch van Beijnum In-Reply-To: <748F7F6F-353B-4F95-9101-0CF40CAEDED5@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: draft-durand-dual-stack-lite Date: Wed, 30 Jul 2008 18:54:27 +0100 References: <748F7F6F-353B-4F95-9101-0CF40CAEDED5@muada.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 30, 2008, at 18:38, Iljitsch van Beijnum wrote: > > Please have a look at the NAT64 draft. Apart from the presence of > IPv4 headers, the specification of the behavior of the NAT64 > translator can also apply to Alain's carrier grade NAT. Not unless the carrier grade NAT offers the guarantee I mentioned in my previous message. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Jul 30 11:15:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87A43A6972 for ; Wed, 30 Jul 2008 11:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L5iFAl7n3kc for ; Wed, 30 Jul 2008 11:15:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1B9F3A659B for ; Wed, 30 Jul 2008 11:15:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGBb-0001nq-B4 for v6ops-data@psg.com; Wed, 30 Jul 2008 18:14:07 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGBV-0001mU-66 for v6ops@ops.ietf.org; Wed, 30 Jul 2008 18:14:03 +0000 Received: from leon.remlab.net (unknown [IPv6:2001:df8:0:16:219:d2ff:fe07:5de5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id D4D0D192; Wed, 30 Jul 2008 20:13:59 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Remlab.net To: james woodyatt Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Wed, 30 Jul 2008 21:13:52 +0300 User-Agent: KMail/1.9.9 Cc: Iljitsch van Beijnum , Pekka Savola , Hemant Singh , Brian E Carpenter , v6ops@ops.ietf.org, Alain Durand References: <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> In-Reply-To: <6AEA0383-C702-4BDE-AF60-9F2165BC2C17@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807302113.53305.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Posting as the maintainer of the VLC media player network components... On Wednesday 30 July 2008 20:30:27 james woodyatt, you wrote: > Apple uses IPv6 link-local transport for a wide variety of user > application protocols, e.g. AirTunes, iTunes library sharing, iPhoto > sharing, Time Machine w/ Time Capsule, etc. The big win for us is > that we don't have any address realm conflicts with IPv6 link-local > when hosts are attached as a bastion between their ethernet and Wi-fi > interfaces. My experience is that programming with link-local *is* painful. You need to= =20 carry the scope all over the place. As long as you stick to the sockaddr_in= 6,=20 you're fine. However: If you ever parse an address from string, boom. There is not even a standar= d=20 to note scope into a numerical IPv6 address. If you copy the address from a binary-formatted content (packet), boom. If a DNS lookup yields a link-local address, scope is zero, boom. Even more stupid, if getnameinfo() returns a link-local scope, it appends t= he=20 non-standard "%eth0" at the end. And if you're not careful when you paste t= he=20 address through a text-protocol, you're unwilling violating the protocol an= d=20 sending non-sense to your peer. VLC happens to use SAP as its "native" zero-configuration/multicast discove= ry=20 protocol. That embeds addresses (as ASCII string). There is no sane way to= =20 carry the scope there; it would not make sense anyway. This can be worked=20 around by taking the scope of the interface the packet was received from, b= ut=20 it *is* painful for the programmer, and tends to break across application=20 interface layers. The software I am talking about has had IPv6 support for= =20 many years, with lots of skilled engineers looking at that over time (as yo= u=20 may know, VLC is frequently used in Computer networking R&D depts...). I=20 think we finally got link-local mostly right - but what about "normal"=20 software? I am highly reluctant to recommending link-local for normal applications. =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Wed Jul 30 22:51:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4676D3A68DB for ; Wed, 30 Jul 2008 22:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1tR3+nIleKE for ; Wed, 30 Jul 2008 22:51:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6EEB3A6A2C for ; Wed, 30 Jul 2008 22:51:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOR00-000Kdo-Pi for v6ops-data@psg.com; Thu, 31 Jul 2008 05:46:52 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOQzp-000Kcp-0m for v6ops@ops.ietf.org; Thu, 31 Jul 2008 05:46:42 +0000 X-IronPort-AV: E=Sophos;i="4.31,284,1215388800"; d="scan'208";a="59750566" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 05:46:37 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6V5kbCv023591; Thu, 31 Jul 2008 01:46:37 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6V5kbpP029182; Thu, 31 Jul 2008 05:46:37 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 01:46:37 -0400 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 Subject: RE: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 Date: Thu, 31 Jul 2008 01:46:36 -0400 Message-ID: In-Reply-To: <00a201c8f19f$828c8380$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 Thread-Index: Acjxn4WtuKTU9BgUQ8Sl0QHwfRepxwBL0plA References: <00a201c8f19f$828c8380$5c0c7c0a@china.huawei.com> From: "Hemant Singh (shemant)" To: "Frank Xia" , X-OriginalArrivalTime: 31 Jul 2008 05:46:37.0290 (UTC) FILETIME=[CC305CA0:01C8F2D0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1265; t=1217483197; x=1218347197; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20review=20for=20draft-kaippallimalil-v6o ps-ipv6-bbnet-00 |Sender:=20 |To:=20=22Frank=20Xia=22=20,=20; bh=8R1arxn1HV0+jf+fk2fIvoz8V3PxrWmj/CViSdlPRJQ=; b=AfXDn8twkQuFoQI6RyKWDH0pl4Ztq9J6BK3DqJkCdDB65GNEZj07fM+IiH bvPddDG/Q5jXLr3W4aVnJgYca9TZIoFQt2z4tcq0tMenVYZN3GQcGWEUx/HY an25fPxGqV; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt. >Frank=3D>Cable network has many different characteristis from >DSL network, and IMHO, it can't be applied to DSL network directly. I only gave the reference to cable draft to show which one it was. I wasn't saying to use it for DSL. =20 > 1. Is the draft for Standards Track, Informational, or a BCP? >Frank=3D>It is intended to be informational.=20 So please fix the draft to say it's Informational. In general, if DSL needs IETF help, be prepared to have your DSL standards take a long time. IETF deals with more generalized devices and their process can more lengthy than a focused cable standards or DSL standards body. I would rather DSL gets experts from routing and general data networking product companies and also get folks who know IPv6 cold to work in the DSL Forum directly. Cable added IPv6 to its docsis 3.0 standards because we had router and IPv6 folks from Cisco and Juniper involved in the standards, also cable savvy folks from Cisco, and DHCPv6 experts like Ralph Droms and Bernie Volz. That is how specific deployment standards get done. Anyhow, your document is not even ready to be picked up by any IETF WG right now. =20 Hemant From owner-v6ops@ops.ietf.org Thu Jul 31 00:34:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B633A6C57 for ; Thu, 31 Jul 2008 00:34:22 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2fvSxzlyL8X for ; Thu, 31 Jul 2008 00:34:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4AB93A6C55 for ; Thu, 31 Jul 2008 00:34:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSdb-0005lf-1i for v6ops-data@psg.com; Thu, 31 Jul 2008 07:31:51 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSdW-0005ke-DI for v6ops@ops.ietf.org; Thu, 31 Jul 2008 07:31:48 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34B9DADADD; Thu, 31 Jul 2008 09:31:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A059ADAD9 for ; Thu, 31 Jul 2008 09:31:45 +0200 (CEST) Date: Thu, 31 Jul 2008 09:31:45 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: <259191.61303.qm@web62503.mail.re1.yahoo.com> Message-ID: References: <259191.61303.qm@web62503.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 30 Jul 2008, Francois-Xavier Le Bail wrote: > Significant bandwidth can be wasted by flooding. I would just like to highlight a scenario that everybody should be aware of, sorry if this is obvious to everybody here, I know not enough people in other places are aware of it. With most ATA/VOIP boxes, the uplink interface is 10/half. A multicast stream SDTV might be 6-8 megabit/s, so when channel zapping, there might be a short while (100ms) where two streams are being sent out on the local segment. If the L2 switch connecting the devices doesn't do IGMP/MLD snooping, the ATA box port will be take more than 10 meg of potential traffic for the duration of the burst, which hurts voice quality (since this will most likely cause packet loss). Since most cheaper L2 devices also do not have per-port buffers, but instead have shared buffers, it means that this problem might hurt traffic on other ports as well, incurring packet loss there also. So, what I like about IPv6 and DHCPv6-PD is that these kind of low-speed devices that should never get multicast traffic, can be put on another L2 domain and have L3 separation from the devices that actually need to listen to the multicast. I don't know how this might fit into the CPE router draft, but my recommendation for CPE router is that it should have at least 4 LAN ports and it should be possible for these 4 LAN ports to be 4 separate routed interfaces to enable L3 separation between different devices. This can also be solved by MLD snooping and personally I'd like to see both, but it might be cheaper for the CPE manufacturer to implement routed ports than to get a built in L2 switch that actually does MLD. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 31 00:40:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB7928C180 for ; Thu, 31 Jul 2008 00:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.139 X-Spam-Level: X-Spam-Status: No, score=0.139 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gF6wO3UKlIz for ; Thu, 31 Jul 2008 00:40:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA4593A6C55 for ; Thu, 31 Jul 2008 00:40:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSlV-0006m9-8O for v6ops-data@psg.com; Thu, 31 Jul 2008 07:40:01 +0000 Received: from [69.147.75.95] (helo=web62503.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSlQ-0006lZ-Um for v6ops@ops.ietf.org; Thu, 31 Jul 2008 07:39:59 +0000 Received: (qmail 18818 invoked by uid 60001); 31 Jul 2008 07:39:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=3MgOGPqnfXQ4Myfid7J+2qTxxfroryMMq+z7B677+XlO4XbL3i2v2R9AX5Z3UoDd6ZiLdoYOGJ+ypZVlAh2Zf4nQSdxCvhjjvss+zZGUJRqoooZf2qL++Fcl7wpV/nec0qieOrZMzJgnr1E02mG63idNQUCwhVaHaNP1Sx4xqKk=; Received: from [193.49.124.107] by web62503.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 00:39:55 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 00:39:55 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: "Hemant Singh \(shemant\)" Cc: Iljitsch van Beijnum , v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <988774.18345.qm@web62503.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Wed, 7/30/08, Hemant Singh (shemant) wrote: > However, the Loopback interface has other uses. Please see > the slide titled "Routing Domains and Address assignments" > from our v6ops presentation and see that the Loopback interface > in the picture is being used with an anycast address for ICMP health > check (as per RFC4241). The RFC4241 in his section 2.8. Connectivity Monitoring say: "The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage." But the APNIC ipv6-policy-280599 is obsolete and the actual policy (http://www.apnic.net/policy/ipv6-address-policy.html) dont have such "check address usage". So, the RFC4241 cannot be used as argument in favour of a loopback interface. Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 00:45:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC75128C1B1 for ; Thu, 31 Jul 2008 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZeEUOjsOoFV for ; Thu, 31 Jul 2008 00:45:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40FF13A6C1D for ; Thu, 31 Jul 2008 00:45:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSqD-0007M9-Tt for v6ops-data@psg.com; Thu, 31 Jul 2008 07:44:53 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSq9-0007LG-0m for v6ops@ops.ietf.org; Thu, 31 Jul 2008 07:44:51 +0000 X-IronPort-AV: E=Sophos;i="4.31,285,1215388800"; d="scan'208";a="16071882" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 07:44:39 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6V7idMj005390; Thu, 31 Jul 2008 03:44:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6V7idw9023810; Thu, 31 Jul 2008 07:44:39 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 03:44:39 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 03:44:38 -0400 Message-ID: In-Reply-To: <988774.18345.qm@web62503.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy4KYLXeHZYqFPRlqfEXDp2MkoxwAADkGw References: <988774.18345.qm@web62503.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 31 Jul 2008 07:44:39.0187 (UTC) FILETIME=[49541630:01C8F2E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1552; t=1217490279; x=1218354279; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20; bh=8PM7nxMaRe4PUMKwTArtm4a6/tLmdnRuvKPOu2RwX5I=; b=NyVwWhiFBQAD94LjUJo3USKUFmp4NrirYIGQBQtZcp5YcW2AEVMj0FvVct 0Oxcxu0Fwqv5y320gSzFlCpB1yX6Tlftdi207TVrfaLclGFjKZ08y6l5jpCM 1NgD6Uq2zB; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: During the presentation at IETF, it was clearly said, the picture is one addressing scheme. One may use some other addressing scheme as well. However, the bullets in that slide do reflect current CPE Router addressing plan. Forget RFC4241 for a moment - any router has a loopback interface. What one configures on the Loopback interface is left to the user. Hemant=20 -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Thursday, July 31, 2008 8:40 AM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] --- On Wed, 7/30/08, Hemant Singh (shemant) wrote: > However, the Loopback interface has other uses. Please see the slide=20 > titled "Routing Domains and Address assignments" > from our v6ops presentation and see that the Loopback interface in the > picture is being used with an anycast address for ICMP health check=20 > (as per RFC4241). The RFC4241 in his section 2.8. Connectivity Monitoring say: "The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage." But the APNIC ipv6-policy-280599 is obsolete and the actual policy (http://www.apnic.net/policy/ipv6-address-policy.html) dont have such "check address usage". So, the RFC4241 cannot be used as argument in favour of a loopback interface. Francois-Xavier =20 From owner-v6ops@ops.ietf.org Thu Jul 31 00:57:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FDB28C26D for ; Thu, 31 Jul 2008 00:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjP2vd+LazwP for ; Thu, 31 Jul 2008 00:57:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1520728C1F3 for ; Thu, 31 Jul 2008 00:57:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOT19-0008ts-WA for v6ops-data@psg.com; Thu, 31 Jul 2008 07:56:12 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOT11-0008rq-KL for v6ops@ops.ietf.org; Thu, 31 Jul 2008 07:56:06 +0000 X-IronPort-AV: E=Sophos;i="4.31,285,1215388800"; d="scan'208";a="16072227" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 07:56:02 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6V7u2XT007637; Thu, 31 Jul 2008 03:56:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6V7u2hH022389; Thu, 31 Jul 2008 07:56:02 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 03:56:02 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 03:56:01 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy4ABUNpmMcCW1R1qWeRQDX4HwrgAAmdmQ References: <259191.61303.qm@web62503.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 31 Jul 2008 07:56:02.0476 (UTC) FILETIME=[E099B6C0:01C8F2E2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2658; t=1217490962; x=1218354962; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Mikael=20Abrahamsson=22=20,=20< v6ops@ops.ietf.org>; bh=l9DdzHTbk8jbYw/8wItfYvVl/06OKRVeUiZAYgFvgR0=; b=L8nzT13H65d/fi6rp1B8VIF+nHnx3e5IvRLyVxa9HFxOOQffI479KPi8FM BffEMPZS6IJKSY3vZkM29+uicRwcRKR9kZWzF56avNGS3J7Bsvh/XGAgqyNr S/tGGOZFh2; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The CPE Router will NOT mandate how many LAN ports does the device have - it's left to a vendor. Further, we have left it to the vendor as well for LAN interface(s) to be bridged, switched, or routed ports. See the definition in our Terminology section. [LAN interface(s) - a set of network interfaces on the CPE Router that are used to connect hosts in the home. This set of ports could be switched, bridged, or routed.]=20 Please rest your case. That's the most the CPE Router will specify. Please talk to CPE Router vendors, not authors of this draft. Hemant=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, July 31, 2008 8:32 AM To: v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] On Wed, 30 Jul 2008, Francois-Xavier Le Bail wrote: > Significant bandwidth can be wasted by flooding. I would just like to highlight a scenario that everybody should be aware of, sorry if this is obvious to everybody here, I know not enough people in other places are aware of it. With most ATA/VOIP boxes, the uplink interface is 10/half. A multicast stream SDTV might be 6-8 megabit/s, so when channel zapping, there might be a short while (100ms) where two streams are being sent out on the local segment. If the L2 switch connecting the devices doesn't do IGMP/MLD snooping, the ATA box port will be take more than 10 meg of potential traffic for the duration of the burst, which hurts voice quality (since this will most likely cause packet loss). Since most cheaper L2 devices also do not have per-port buffers, but instead have shared buffers, it means that this problem might hurt traffic on other ports as well, incurring packet loss there also. So, what I like about IPv6 and DHCPv6-PD is that these kind of low-speed devices that should never get multicast traffic, can be put on another L2 domain and have L3 separation from the devices that actually need to listen to the multicast. I don't know how this might fit into the CPE router draft, but my recommendation for CPE router is that it should have at least 4 LAN ports and it should be possible for these 4 LAN ports to be 4 separate routed interfaces to enable L3 separation between different devices. This can also be solved by MLD snooping and personally I'd like to see both, but it might be cheaper for the CPE manufacturer to implement routed ports than to get a built in L2 switch that actually does MLD. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 31 01:11:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A766F3A67D8 for ; Thu, 31 Jul 2008 01:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNx53wtSdcaA for ; Thu, 31 Jul 2008 01:11:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C835F3A6780 for ; Thu, 31 Jul 2008 01:11:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTF5-000Aju-Sx for v6ops-data@psg.com; Thu, 31 Jul 2008 08:10:35 +0000 Received: from [69.147.75.104] (helo=web62512.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTF1-000AjC-W1 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:10:33 +0000 Received: (qmail 30281 invoked by uid 60001); 31 Jul 2008 08:10:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=vPQOxnRV2pNH+6tzBmMtk8J7htWqBwOspoK4mTuJm0NUOVLCnxS0ZEIzLvmfuxGMTB0zYo9y27nA1AY21C8+se4hJqUlyG9SMxsM7oFpeedQyDES3hywIcWcJvIdH8MqhkNiOd+lfEERIG5h5VClAq6MBXUnMqM0gPPwtdzwnBs=; Received: from [193.49.124.107] by web62512.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 01:10:27 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 01:10:27 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: "Hemant Singh \(shemant\)" Cc: Iljitsch van Beijnum , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <948787.28567.qm@web62512.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Hemant Singh (shemant) wrote: > any router has a loopback. It is not true. In a previous e-mail, you wrote: "I agree with you that Loopback interfaces are not common to home Linksys-like routers." Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 01:15:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183133A6A3F for ; Thu, 31 Jul 2008 01:15:21 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFH3xr0SUrHg for ; Thu, 31 Jul 2008 01:15:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F3DB3A69F7 for ; Thu, 31 Jul 2008 01:15:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTJ8-000BBm-HL for v6ops-data@psg.com; Thu, 31 Jul 2008 08:14:46 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTJ4-000BAm-Nu for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:14:44 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34337ADAE7; Thu, 31 Jul 2008 10:14:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2906DADAE6 for ; Thu, 31 Jul 2008 10:14:41 +0200 (CEST) Date: Thu, 31 Jul 2008 10:14:41 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: Message-ID: References: <259191.61303.qm@web62503.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: > The CPE Router will NOT mandate how many LAN ports does the device have I didn't ask for "mandate". I just thought the scenario is not an obvious one and would make sense to have it in some kind of informational section or separate document, but you seem very adamant that it doesn't apply... > Please rest your case. That's the most the CPE Router will specify. Well then. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 31 01:16:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3488D3A6A3F for ; Thu, 31 Jul 2008 01:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.526 X-Spam-Level: X-Spam-Status: No, score=-4.526 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47X8LRG6PlFM for ; Thu, 31 Jul 2008 01:16:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4479F3A680F for ; Thu, 31 Jul 2008 01:16:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTKJ-000BN9-S6 for v6ops-data@psg.com; Thu, 31 Jul 2008 08:15:59 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTKG-000BML-26 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:15:57 +0000 X-IronPort-AV: E=Sophos;i="4.31,285,1215388800"; d="scan'208";a="133872611" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2008 08:15:55 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6V8Ft7f028013; Thu, 31 Jul 2008 04:15:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6V8Fs95029448; Thu, 31 Jul 2008 08:15:54 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 04:15:54 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 04:15:54 -0400 Message-ID: In-Reply-To: <948787.28567.qm@web62512.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy5OesipV3W9FkSmmC/cf856HJ9AAAH58Q References: <948787.28567.qm@web62512.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Francois-Xavier Le Bail" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 31 Jul 2008 08:15:54.0784 (UTC) FILETIME=[A7457A00:01C8F2E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=739; t=1217492155; x=1218356155; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20; bh=V0GRFjhRXIrG/U1gr1Nv2dQ2OZJRojBUk+MxCPnSssg=; b=HQKeegKoJMYfUGGT12iqPgZENi63cRs/WGdpFuYhE4j07/tHxz/Gp9ITan YJqXEBIQknkZ36oRBNxQEnRV5hC3s3KJUspDDnnOo1kKHT3Dii6nhP+3LCGg Hyyu27Tz3l; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: It's because Linksys does not configure it or expose the Loopback interface to the user! Any router has a Loopback interface!=20 Hemant=20 -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Thursday, July 31, 2008 9:10 AM To: Hemant Singh (shemant) Cc: Iljitsch van Beijnum; v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] --- On Thu, 7/31/08, Hemant Singh (shemant) wrote: > any router has a loopback. It is not true. In a previous e-mail, you wrote: "I agree with you that Loopback interfaces are not common to home Linksys-like routers." Francois-Xavier =20 From owner-v6ops@ops.ietf.org Thu Jul 31 01:45:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9963A689E for ; Thu, 31 Jul 2008 01:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2waFqxqj+pTn for ; Thu, 31 Jul 2008 01:45:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DE9D3A68AE for ; Thu, 31 Jul 2008 01:45:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTkz-000F9y-02 for v6ops-data@psg.com; Thu, 31 Jul 2008 08:43:33 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTku-000F9T-Ud for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:43:30 +0000 X-IronPort-AV: E=Sophos;i="4.31,285,1215388800"; d="scan'208";a="16073859" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 08:43:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6V8hRte020444; Thu, 31 Jul 2008 04:43:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6V8hR63003660; Thu, 31 Jul 2008 08:43:27 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 04:43:27 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 04:43:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy5doJR/TGJpZbTi+K40GWlYO8RgAAx/zg References: <259191.61303.qm@web62503.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 31 Jul 2008 08:43:27.0825 (UTC) FILETIME=[808F8410:01C8F2E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1027; t=1217493807; x=1218357807; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Mikael=20Abrahamsson=22=20,=20< v6ops@ops.ietf.org>; bh=j1IFZO+qYoQDB5O9FVhvzfRO+OdFO/KCbaiOpBWPPqM=; b=bxk7pMQuADaLd0/fOxOZH60VYM4lkno1buu2KwP9iAwhkGWCl2vlw4UXp+ pOXNA5p55I+XWPIjdAGZmK/6ckDe8QZOACXiUw97uUPlL3o3krCXBh92w2m5 ObNolAo/CE; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sorry, didn't mean to sound adamant. There are several other cases in home deployments that deserve to be mentioned, but our draft is not in the business of mentioning such example cases.=20 Thanks. Hemant =20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, July 31, 2008 9:15 AM To: v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: > The CPE Router will NOT mandate how many LAN ports does the device=20 > have I didn't ask for "mandate". I just thought the scenario is not an obvious one and would make sense to have it in some kind of informational section or separate document, but you seem very adamant that it doesn't apply... > Please rest your case. That's the most the CPE Router will specify. Well then. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 31 01:48:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563663A692F for ; Thu, 31 Jul 2008 01:48:13 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vlwYlE5lkQu for ; Thu, 31 Jul 2008 01:48:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72AC23A63EC for ; Thu, 31 Jul 2008 01:48:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTpE-000Fjn-2Q for v6ops-data@psg.com; Thu, 31 Jul 2008 08:47:56 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTpA-000FjJ-C4 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:47:54 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86FD6ADAE7; Thu, 31 Jul 2008 10:47:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74C5DADAE6; Thu, 31 Jul 2008 10:47:51 +0200 (CEST) Date: Thu, 31 Jul 2008 10:47:51 +0200 (CEST) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" cc: v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: Message-ID: References: <259191.61303.qm@web62503.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: > Sorry, didn't mean to sound adamant. There are several other cases in > home deployments that deserve to be mentioned, but our draft is not in > the business of mentioning such example cases. So, I do feel it's important information to explain how a home network might look like for triple play services to work well. Would it make sense to create a new document outlining deployment scenarios? Is there already a document where this information might fit? -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Jul 31 01:57:16 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31ED3A67EC for ; Thu, 31 Jul 2008 01:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhT-8dWK+95e for ; Thu, 31 Jul 2008 01:57:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D73D3A6780 for ; Thu, 31 Jul 2008 01:57:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTx9-000GrA-7D for v6ops-data@psg.com; Thu, 31 Jul 2008 08:56:07 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTx2-000Goc-CJ for v6ops@ops.ietf.org; Thu, 31 Jul 2008 08:56:05 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id 5FE01D0084; Wed, 30 Jul 2008 22:55:57 -1000 (HST) Date: Wed, 30 Jul 2008 22:55:57 -1000 (HST) From: Antonio Querubin To: "Hemant Singh (shemant)" cc: Francois-Xavier Le Bail , Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: Message-ID: References: <948787.28567.qm@web62512.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: > It's because Linksys does not configure it or expose the Loopback > interface to the user! Any router has a Loopback interface! Can we please not go down this rabbit hole again? It's the observable behaviour that matters. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Thu Jul 31 02:07:57 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991763A6A1C for ; Thu, 31 Jul 2008 02:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBZfLhJPuPP0 for ; Thu, 31 Jul 2008 02:07:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0D7E3A69D2 for ; Thu, 31 Jul 2008 02:07:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOU7i-000ILk-OQ for v6ops-data@psg.com; Thu, 31 Jul 2008 09:07:02 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOU7f-000ILF-71 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 09:07:00 +0000 Received: by yw-out-2324.google.com with SMTP id 9so279414ywe.71 for ; Thu, 31 Jul 2008 02:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+u+H4N0zgkV5FsEa1iosdt+xuebns0arQLpuicetb0g=; b=h2e/bkNyxc/UnUanPctTFyLbEe9/ZGLrRSUqYE8jza7kGl7A305dmqgANUBibEEFb1 lyk3rWI6hp7NxpISy7uuvnhJJX16dpSl4QGPjZwaDMyJVM8iVGzdD2+VhnzKnW/2vz2K ELx7rbVlcRxHJEXtjKdT5OVCXTU8BGjD+Ef3A= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=W5Q53gam6AxhqN4GCz5OnZC98Pjc+VhtxmG6PHkEpQvb4r5BNWRMZQSwtj+ymwbJtr PH9F7v8vAZBjbV0LA5OduRYc7va50/rwZbZo43zITuqmYcYnz5J6mKY4dMFZjTdxD96+ CTCJHpz9WlrVLOTg/T07obGs/YYiKwQ3qdtp8= Received: by 10.150.133.17 with SMTP id g17mr852280ybd.196.1217495218118; Thu, 31 Jul 2008 02:06:58 -0700 (PDT) Received: from ?130.129.23.42? ( [130.129.23.42]) by mx.google.com with ESMTPS id k47sm3926374rnd.2.2008.07.31.02.06.57 (version=SSLv3 cipher=RC4-MD5); Thu, 31 Jul 2008 02:06:57 -0700 (PDT) Message-ID: <489180AC.404@gmail.com> Date: Thu, 31 Jul 2008 21:06:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson CC: v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] References: <259191.61303.qm@web62503.mail.re1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-07-31 20:14, Mikael Abrahamsson wrote: > On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: > >> The CPE Router will NOT mandate how many LAN ports does the device have > > I didn't ask for "mandate". I just thought the scenario is not an > obvious one and would make sense to have it in some kind of > informational section or separate document, but you seem very adamant > that it doesn't apply... > >> Please rest your case. That's the most the CPE Router will specify. > > Well then. Actually, if this is to become a WG draft, it will specify whatever the WG consensus turns out to be. fwiw, my view is that Hemant is correct, and it isn't for the IETF to specify how many ports a vendor might choose to include in their product. (Of course, if it's going to be an independent submission, the draft can say whatever its authors want.) Brian From owner-v6ops@ops.ietf.org Thu Jul 31 02:16:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7035C3A6A1C for ; Thu, 31 Jul 2008 02:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw2dvgDFwQ0c for ; Thu, 31 Jul 2008 02:16:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B6763A692F for ; Thu, 31 Jul 2008 02:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUGg-000JaH-Rq for v6ops-data@psg.com; Thu, 31 Jul 2008 09:16:18 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUGc-000JZd-UF for v6ops@ops.ietf.org; Thu, 31 Jul 2008 09:16:16 +0000 X-IronPort-AV: E=Sophos;i="4.31,285,1215388800"; d="scan'208";a="16074657" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 09:16:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6V9GDvd011779; Thu, 31 Jul 2008 05:16:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6V9GDCm010303; Thu, 31 Jul 2008 09:16:13 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 05:16:13 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 05:16:13 -0400 Message-ID: In-Reply-To: <489180AC.404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy7QRQmTS0oM+gRMiM8481Ej+UEgAAB+lg References: <259191.61303.qm@web62503.mail.re1.yahoo.com> <489180AC.404@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , "Mikael Abrahamsson" Cc: X-OriginalArrivalTime: 31 Jul 2008 09:16:13.0532 (UTC) FILETIME=[143699C0:01C8F2EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1707; t=1217495773; x=1218359773; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20,=0A=20=20=20=20=20=20=20=20=22Mikael=20Abrahamsson=2 2=20; bh=fsa27L7i8ju8TV+A8OdHEwSN/t9Czt4K7tMao2dA654=; b=Rd1evaeS0F5tl0QymWBSDwwZyPUcsK0ozFn/cSBflALXQLsNny6EFgUV4d 0yZajt8Or8jUjg2Hg9RVibAleW/3LXDPUuUytQEC4QntU9dDUtx7CJ9zgrlB ZWQxLGzDZI; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: As usual, I have to thank Brian for another email. I am also planning for the day when one day this document becomes a WG document. Folks should realize we'll thrash forever soon as someone proposes including 4 ports on the CPE Router, someone else will say 5 or 6 - even specifying "at least" 4 ports is the same slippery slope. The number of LAN ports is best left to the vendors to differentiate their products in any way they want.=20 Thanks. Hemant=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, July 31, 2008 10:07 AM To: Mikael Abrahamsson Cc: v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] On 2008-07-31 20:14, Mikael Abrahamsson wrote: > On Thu, 31 Jul 2008, Hemant Singh (shemant) wrote: >=20 >> The CPE Router will NOT mandate how many LAN ports does the device=20 >> have >=20 > I didn't ask for "mandate". I just thought the scenario is not an=20 > obvious one and would make sense to have it in some kind of=20 > informational section or separate document, but you seem very adamant=20 > that it doesn't apply... >=20 >> Please rest your case. That's the most the CPE Router will specify. >=20 > Well then. Actually, if this is to become a WG draft, it will specify whatever the WG consensus turns out to be. fwiw, my view is that Hemant is correct, and it isn't for the IETF to specify how many ports a vendor might choose to include in their product. (Of course, if it's going to be an independent submission, the draft can say whatever its authors want.) Brian From owner-v6ops@ops.ietf.org Thu Jul 31 03:56:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16ABE3A69D1 for ; Thu, 31 Jul 2008 03:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUsRRof1YGkg for ; Thu, 31 Jul 2008 03:56:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8CD43A6A24 for ; Thu, 31 Jul 2008 03:56:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVlw-0006RP-W8 for v6ops-data@psg.com; Thu, 31 Jul 2008 10:52:40 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVlt-0006Qz-F1 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 10:52:39 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 275E834C9550; Thu, 31 Jul 2008 03:52:37 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 0B88028087; Thu, 31 Jul 2008 03:52:37 -0700 (PDT) X-AuditID: 1180711d-a6fffbb000000ece-b6-489199739751 Received: from A17-66-41-78.apple.com (vpn1p068.euro.apple.com [17.66.41.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 1DF1E28085; Thu, 31 Jul 2008 03:52:35 -0700 (PDT) Cc: IPv6 Operations Message-Id: From: james woodyatt To: Hemant Singh (shemant) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 11:52:33 +0100 References: <259191.61303.qm@web62503.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 31, 2008, at 08:56, Hemant Singh (shemant) wrote: > > The CPE Router will NOT mandate how many LAN ports does the device > have > - it's left to a vendor. Further, we have left it to the vendor as > well > for LAN interface(s) to be bridged, switched, or routed ports. See > the > definition in our Terminology section. > > [LAN interface(s) - a set of network interfaces on the CPE Router that > are used to connect hosts in the home. This set of ports could be > switched, bridged, or routed.] > > Please rest your case. That's the most the CPE Router will specify. > Please talk to CPE Router vendors, not authors of this draft. The sentence at the end of section 1, Introduction, which reads, "Each LAN interface is Ethernet encapsulated," should be elided altogether. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Jul 31 06:19:48 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B573A6A97 for ; Thu, 31 Jul 2008 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhovSWz4Ohcr for ; Thu, 31 Jul 2008 06:19:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEF963A69CA for ; Thu, 31 Jul 2008 06:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOY0j-000Nsm-MP for v6ops-data@psg.com; Thu, 31 Jul 2008 13:16:05 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOY0Y-000Npy-9A for v6ops@ops.ietf.org; Thu, 31 Jul 2008 13:16:03 +0000 Received: (qmail 14870 invoked by uid 1007); 31 Jul 2008 13:15:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=fl7ifc3m/uzmFEIhM36jJ5vfPUpw2Z88XFMqukIrPvy9PGQ2iqMC+5wVRfRqsHSU ; Date: Thu, 31 Jul 2008 15:15:52 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Cc: Francois-Xavier Le Bail , Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Message-ID: <20080731131552.GY11038@Space.Net> References: <948787.28567.qm@web62512.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, Jul 31, 2008 at 04:15:54AM -0400, Hemant Singh (shemant) wrote: > It's because Linksys does not configure it or expose the Loopback > interface to the user! Any router has a Loopback interface! "could have" If not configured, all my Cisco routers do *not* have Loopback interfaces. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 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 owner-v6ops@ops.ietf.org Thu Jul 31 06:26:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365263A6C71 for ; Thu, 31 Jul 2008 06:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-YF1zlmxlsn for ; Thu, 31 Jul 2008 06:26:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E72E63A6783 for ; Thu, 31 Jul 2008 06:26:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYAm-000PCy-Q2 for v6ops-data@psg.com; Thu, 31 Jul 2008 13:26:28 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYAh-000PBh-RC for v6ops@ops.ietf.org; Thu, 31 Jul 2008 13:26:26 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6VDQCxD018621; Thu, 31 Jul 2008 16:26:12 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6VDQCx2018618; Thu, 31 Jul 2008 16:26:12 +0300 Date: Thu, 31 Jul 2008 16:26:12 +0300 (EEST) From: Pekka Savola To: Gert Doering cc: "Hemant Singh (shemant)" , Francois-Xavier Le Bail , Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: <20080731131552.GY11038@Space.Net> Message-ID: References: <948787.28567.qm@web62512.mail.re1.yahoo.com> <20080731131552.GY11038@Space.Net> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.1/7894/Wed Jul 30 20:26:14 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Gert Doering wrote: > If not configured, all my Cisco routers do *not* have Loopback interfaces. If you ping 127.0.0.1, does the router respond? Which interface has that address? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 31 06:31:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3372E28C182 for ; Thu, 31 Jul 2008 06:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7eZFD-RwWCm for ; Thu, 31 Jul 2008 06:31:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B4043A696E for ; Thu, 31 Jul 2008 06:31:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYEw-000Pmu-SU for v6ops-data@psg.com; Thu, 31 Jul 2008 13:30:46 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYEo-000Pm3-D3 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 13:30:44 +0000 Received: (qmail 21817 invoked by uid 1007); 31 Jul 2008 13:30:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=qjRbE9qc/14w2rLQ31qBKomn09ZzIPKadNs/vOUKC85P0gRtVkY1hnbMle4mvrzP ; Date: Thu, 31 Jul 2008 15:30:37 +0200 From: Gert Doering To: Pekka Savola Cc: Gert Doering , "Hemant Singh \(shemant\)" , Francois-Xavier Le Bail , Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Message-ID: <20080731133037.GB11038@Space.Net> References: <948787.28567.qm@web62512.mail.re1.yahoo.com> <20080731131552.GY11038@Space.Net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvhdYgrQe8UD0JDN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --RvhdYgrQe8UD0JDN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 31, 2008 at 04:26:12PM +0300, Pekka Savola wrote: > On Thu, 31 Jul 2008, Gert Doering wrote: > >If not configured, all my Cisco routers do *not* have Loopback interface= s. >=20 > If you ping 127.0.0.1, does the router respond?=20 No. > Which interface has that address? None. Cisco>ping 127.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 127.0.0.1, timeout is 2 seconds: =2E.... Success rate is 0 percent (0/5) Cisco>sh ip route 127.0.0.1 % Network not in table (I know that some Cisco boxes use 127.0.0.x for internal communication between blades in a multi-CPU-chassis, like the catalyst 5xxx/6xxx=20 switches - but that's very much *not* a loopback thing) Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 128645 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 --RvhdYgrQe8UD0JDN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBSJG+fakuBuNlUUl1AQIkkQP+IzCaMVm89OE8E2q+6xVh/w7i2BBbTcaG DDcmRY8BAY/ZAe+h+53UuVyPgjUrUfyjbylDRXoGYqbghAWNnyotrXP0j7DrXA6p 42OUGglr2isQR/dkuRcsUMsRhDeMFdr/fsqTon17jUYxQQnS1878cGQyFbbB633Y 8W7ETo3FL70= =ijeW -----END PGP SIGNATURE----- --RvhdYgrQe8UD0JDN-- From owner-v6ops@ops.ietf.org Thu Jul 31 06:45:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9273A681C for ; Thu, 31 Jul 2008 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN-SeBpXVV8O for ; Thu, 31 Jul 2008 06:45:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 470493A696E for ; Thu, 31 Jul 2008 06:44:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYRW-0001ZF-2T for v6ops-data@psg.com; Thu, 31 Jul 2008 13:43:46 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYRQ-0001YR-H3 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 13:43:43 +0000 X-IronPort-AV: E=Sophos;i="4.31,286,1215388800"; d="scan'208";a="16094708" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 13:43:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VDhdLc031706; Thu, 31 Jul 2008 09:43:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VDhd0o013175; Thu, 31 Jul 2008 13:43:39 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 09:43:39 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 09:43:38 -0400 Message-ID: In-Reply-To: <20080731131552.GY11038@Space.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzD52O9iP8Nb12RLOUwkf5OyPsywAA8uWQ References: <948787.28567.qm@web62512.mail.re1.yahoo.com> <20080731131552.GY11038@Space.Net> From: "Hemant Singh (shemant)" To: "Gert Doering" Cc: "Francois-Xavier Le Bail" , "Iljitsch van Beijnum" , X-OriginalArrivalTime: 31 Jul 2008 13:43:39.0056 (UTC) FILETIME=[70174300:01C8F313] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1040; t=1217511819; x=1218375819; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Gert=20Doering=22=20; bh=/AulVfXO/Fd93dXIWLC/3YaEbgiXiy1Rlo6w6gBg05U=; b=OAJfsya4czD0+h0Lz08SBWLwlS7bP855oX9wc8nA/TcMAggCDBMP6H5DV3 cPnGpQkbHYh1vnGP6KUb0BYaUnxd+AwHV8ElvTMixU0PfCUknR1fqcF8ZggV PDLqBr74tH; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Agreed, Gert. Hemant=20 -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Thursday, July 31, 2008 2:16 PM To: Hemant Singh (shemant) Cc: Francois-Xavier Le Bail; Iljitsch van Beijnum; v6ops@ops.ietf.org Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Hi, On Thu, Jul 31, 2008 at 04:15:54AM -0400, Hemant Singh (shemant) wrote: > It's because Linksys does not configure it or expose the Loopback=20 > interface to the user! Any router has a Loopback interface! "could have" If not configured, all my Cisco routers do *not* have Loopback interfaces. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 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 owner-v6ops@ops.ietf.org Thu Jul 31 07:18:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094353A6978 for ; Thu, 31 Jul 2008 07:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKX8j98XJWvz for ; Thu, 31 Jul 2008 07:18:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 258453A6923 for ; Thu, 31 Jul 2008 07:18:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYxU-0006G4-42 for v6ops-data@psg.com; Thu, 31 Jul 2008 14:16:48 +0000 Received: from [69.147.75.103] (helo=web62511.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOYxM-0006FL-Tw for v6ops@ops.ietf.org; Thu, 31 Jul 2008 14:16:45 +0000 Received: (qmail 52816 invoked by uid 60001); 31 Jul 2008 14:16:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=yxuzfOVQElXr7hdgn14DSpSNy1jZJuRo7zah0Jh5FnTqYcf6UMAeYyIvL0Z3t3OPNfMi5YWqfnFlevI7brLt0fsRghXdmQIFvrHl3lokM/p7FXfknvctBICBhzAWnj9OSvQ9gQU66KJSu8oo+kle74sIeHXEjSImCtlonEw+V9U=; Received: from [193.49.124.107] by web62511.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 07:16:39 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 07:16:39 -0700 (PDT) From: Francois-Xavier Le Bail Subject: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <688269.50340.qm@web62511.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Another requirement: The CPE should install a discard (null) or unreachable route for the delegated prefix. Without, a packet to an unused subnet (belonging to the delegated prefix) will loop between the CPE (default route to the Edge Router) and the Edge Router (route for the delegated prefix to the CPE). The only difference between the two options is: with unreachable route the CPE return ICMPv6 "Destination Unreachable/no route to destination" message to the source address instead of only silently discard the packet. Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 07:52:22 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6E33A6C93 for ; Thu, 31 Jul 2008 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q3wGvs8OLuj for ; Thu, 31 Jul 2008 07:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E18D13A6BFF for ; Thu, 31 Jul 2008 07:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZUR-000B2t-0l for v6ops-data@psg.com; Thu, 31 Jul 2008 14:50:51 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZUN-000B2N-Ak for v6ops@ops.ietf.org; Thu, 31 Jul 2008 14:50:49 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4V00EWAL8MGJ@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Thu, 31 Jul 2008 09:50:46 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4V002CIL8LDX@usaga04-in.huawei.com> for v6ops@ops.ietf.org; Thu, 31 Jul 2008 09:50:46 -0500 (CDT) Date: Thu, 31 Jul 2008 09:50:45 -0500 From: Frank Xia Subject: Re: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 To: "Hemant Singh (shemant)" , v6ops@ops.ietf.org Message-id: <00fc01c8f31c$d0522f60$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00a201c8f19f$828c8380$5c0c7c0a@china.huawei.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: hello Hemant Please check my reply... BR Frank ----- Original Message ----- From: "Hemant Singh (shemant)" To: "Frank Xia" ; Sent: Thursday, July 31, 2008 12:46 AM Subject: RE: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00 >The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt. >Frank=>Cable network has many different characteristis from >DSL network, and IMHO, it can't be applied to DSL network directly. I only gave the reference to cable draft to show which one it was. I wasn't saying to use it for DSL. > 1. Is the draft for Standards Track, Informational, or a BCP? >Frank=>It is intended to be informational. So please fix the draft to say it's Informational. Frank=>sure. In general, if DSL needs IETF help, be prepared to have your DSL standards take a long time. IETF deals with more generalized devices and their process can more lengthy than a focused cable standards or DSL standards body. I would rather DSL gets experts from routing and general data networking product companies and also get folks who know IPv6 cold to work in the DSL Forum directly. Cable added IPv6 to its docsis 3.0 standards because we had router and IPv6 folks from Cisco and Juniper involved in the standards, also cable savvy folks from Cisco, and DHCPv6 experts like Ralph Droms and Bernie Volz. That is how specific deployment standards get done. Frank=>IETF 16NG working group had been working on rfc5121"Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks" . This document is the basic IPv6 document for WiMAX. Of course, some WiMAX experts were involved in the activity. As for our draft, we also presented the draft in DSL Forum, and will discuss in the coming DSL meeting. Anyhow, your document is not even ready to be picked up by any IETF WG right now. Hemant From owner-v6ops@ops.ietf.org Thu Jul 31 07:55:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05813A69C0 for ; Thu, 31 Jul 2008 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T6cNQBqP3Gg for ; Thu, 31 Jul 2008 07:55:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03CE33A6817 for ; Thu, 31 Jul 2008 07:55:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZYV-000Bbg-EG for v6ops-data@psg.com; Thu, 31 Jul 2008 14:55:03 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZYP-000BaQ-Cu for v6ops@ops.ietf.org; Thu, 31 Jul 2008 14:55:01 +0000 X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16104561" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 14:54:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6VEsuoh023940; Thu, 31 Jul 2008 10:54:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VEsuL5008912; Thu, 31 Jul 2008 14:54:56 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 10:54:55 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 10:54:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy+6KMB31F2qiRSKu/wNPzK3n8ZgAIXVoQ References: <259191.61303.qm@web62503.mail.re1.yahoo.com> From: "Hemant Singh (shemant)" To: "james woodyatt" Cc: "IPv6 Operations" X-OriginalArrivalTime: 31 Jul 2008 14:54:55.0786 (UTC) FILETIME=[653878A0:01C8F31D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1373; t=1217516096; x=1218380096; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20Open=20issues=20list?=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22james=20woodyatt=22=20; bh=ji8p5s2K0haWl/BX7RAte52WB6r4akAqIhsBB7uq4BI=; b=dxqEGJUxV75LlupmLAXdGO7x5ek45IXsLdKgYZMjxgnTi8J6OFQzzIgJlf kCwVyUXDAfCmUiDuWdlQ6mdUFtcFEvbU8UyhhJhrQ56Ry5ov6XzdM+GO9eJ2 pvGfD013Fl; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: James, Thanks for this catch. We will remove the sentence you asked to be nuked.=20 We missed the fact that some LAN interfaces may be USB or some new LAN port types. Hemant=20 -----Original Message----- From: james woodyatt [mailto:jhw@apple.com]=20 Sent: Thursday, July 31, 2008 11:53 AM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] On Jul 31, 2008, at 08:56, Hemant Singh (shemant) wrote: > > The CPE Router will NOT mandate how many LAN ports does the device=20 > have > - it's left to a vendor. Further, we have left it to the vendor as=20 > well for LAN interface(s) to be bridged, switched, or routed ports. =20 > See the definition in our Terminology section. > > [LAN interface(s) - a set of network interfaces on the CPE Router that > are used to connect hosts in the home. This set of ports could be=20 > switched, bridged, or routed.] > > Please rest your case. That's the most the CPE Router will specify. > Please talk to CPE Router vendors, not authors of this draft. The sentence at the end of section 1, Introduction, which reads, "Each LAN interface is Ethernet encapsulated," should be elided altogether. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Thu Jul 31 07:57:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B1E28C11F for ; Thu, 31 Jul 2008 07:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwEi5kq+IRQa for ; Thu, 31 Jul 2008 07:57:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65ACE28C11E for ; Thu, 31 Jul 2008 07:57:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZaK-000BsH-5I for v6ops-data@psg.com; Thu, 31 Jul 2008 14:56:56 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZaE-000Bqv-Lm for v6ops@ops.ietf.org; Thu, 31 Jul 2008 14:56:53 +0000 X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16104846" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 14:56:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VEunn0011992; Thu, 31 Jul 2008 10:56:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VEunJA009691; Thu, 31 Jul 2008 14:56:49 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 10:56:49 -0400 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 Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 10:57:24 -0400 Message-ID: In-Reply-To: <688269.50340.qm@web62511.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzGISfINySjxGQS36ntiZOh4nwaQABFtUA From: "Wes Beebee (wbeebee)" To: "Francois-Xavier Le Bail" , X-OriginalArrivalTime: 31 Jul 2008 14:56:49.0336 (UTC) FILETIME=[A8E6D380:01C8F31D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1350; t=1217516209; x=1218380209; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=20; bh=ZLxG5hV7lPLLbkewjZohwSP7WiYaO73wkbM97fgmRY8=; b=b/e8MtgKfFBXm/mVGbnpC+RpJG9nrToEAyjjKNPdJJmBNuPJPl2ElXzGhZ 0ENs0rRD/EFa2PEPgJpbnZh0dordXWTp6jAxmPs/Oko8mlLceCewnN6xn1Ji 2JUd3vHYa6; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The route should go to the LAN ports (for the delegate prefix). If the LAN ports happen to not be up, doesn't this cause the packet to be dropped? If the destination matches a loopback, then the packets can be serviced by the loopback. If there is no LAN port (# of LAN ports =3D = 0), and if the device still does DHCPv6 PD (for other addresses), then a null route may be appropriate as long as the other addresses get serviced at a higher priority. - Wes -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Francois-Xavier Le Bail Sent: Thursday, July 31, 2008 10:17 AM To: v6ops@ops.ietf.org Subject: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Another requirement: The CPE should install a discard (null) or unreachable route for the delegated prefix. Without, a packet to an unused subnet (belonging to the delegated prefix) will loop between the CPE (default route to the Edge Router) and the Edge Router (route for the delegated prefix to the CPE). The only difference between the two options is: with unreachable route the CPE return ICMPv6 "Destination Unreachable/no route to destination" message to the source address instead of only silently discard the packet. Francois-Xavier =20 From owner-v6ops@ops.ietf.org Thu Jul 31 08:12:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AC63A68C2 for ; Thu, 31 Jul 2008 08:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPAjr7HtPQmz for ; Thu, 31 Jul 2008 08:12:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 664E13A689E for ; Thu, 31 Jul 2008 08:12:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZp0-000EDZ-JC for v6ops-data@psg.com; Thu, 31 Jul 2008 15:12:06 +0000 Received: from [69.147.75.104] (helo=web62512.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZov-000EAq-Um for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:12:04 +0000 Received: (qmail 1084 invoked by uid 60001); 31 Jul 2008 15:12:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=L6D4z8jlhjHemlkVaIUyx71QOa5tHvC5ssGR4/0bN5/02dd8i2rQ7IPN3J1VDCohDQyWrb9Xq6ptWuZjE4mMK9qbxiPYQnbiSNfWVCeWG7NyWa5fXr2PizLITHCH0IWFoE1YnijvtJOPOR8GtGOaZPGaw86rabsdPqoHqeTG2pw=; Received: from [193.49.124.107] by web62512.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 08:11:59 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 08:11:59 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org, "Wes Beebee \(wbeebee\)" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <16781.96734.qm@web62512.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > The route should go to the LAN ports (for the delegate > prefix). If the LAN ports happen to not be up, doesn't this > cause the packet to be > dropped? If the destination matches a > loopback, then the packets can be > serviced by the loopback. If there is no LAN port (# of > LAN ports = 0), > and if the device still does DHCPv6 PD (for other > addresses), then a > null route may be appropriate as long as the other > addresses get > serviced at a higher priority. For example, if the delegated prefix is a /56 and the CPE use a /64 prefix for a subnet on a LAN Bridge and another /64 for a subnet on another LAN interface outside the bridge, there are many prefix/subnet not used. Packet to theses unused prefix/subnet will loop without a discard or unreachable route. Francois-Xavier > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Francois-Xavier Le Bail > Sent: Thursday, July 31, 2008 10:17 AM > To: v6ops@ops.ietf.org > Subject: Another requirement [Re: New (-02) version of IPv6 > CPE Router > draft is available for review] > > Another requirement: > > The CPE should install a discard (null) or unreachable > route for the > delegated prefix. > > Without, a packet to an unused subnet (belonging to the > delegated > prefix) will loop between the CPE (default route to the > Edge Router) and > the Edge Router (route for the delegated prefix to the > CPE). > > The only difference between the two options is: with > unreachable route > the CPE return ICMPv6 "Destination Unreachable/no > route to destination" > message to the source address instead of only silently > discard the > packet. > > Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 08:20:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8693A6ABA for ; Thu, 31 Jul 2008 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNfXOWxbOSDf for ; Thu, 31 Jul 2008 08:20:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A67AF3A6921 for ; Thu, 31 Jul 2008 08:20:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZvi-000FDV-Cp for v6ops-data@psg.com; Thu, 31 Jul 2008 15:19:02 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZve-000FCo-Ce for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:19:00 +0000 X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16128446" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2008 15:18:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VFIvGV025266; Thu, 31 Jul 2008 11:18:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VFIvZh016544; Thu, 31 Jul 2008 15:18:57 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:18:57 -0400 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 Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 11:19:32 -0400 Message-ID: In-Reply-To: <16781.96734.qm@web62512.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzH9XFP5AeUphIT0uDLWQd1cm2ZwAAMI6w From: "Wes Beebee (wbeebee)" To: "Francois-Xavier Le Bail" , X-OriginalArrivalTime: 31 Jul 2008 15:18:57.0291 (UTC) FILETIME=[C06CADB0:01C8F320] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2290; t=1217517537; x=1218381537; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=20; bh=CLjnA0J34Qkg4c0Y5GKXLn0cqP+2OriVPm7KkpT8m+w=; b=aOlguoOxPSQs7V7tSg4A2GTU1tClhlJyef1pIOhR/2OxEZ2TKDKCxFNapD gFsQtkvpfHXMOdYnWzgtl1Y7JE9pFBOj8SMd8aDPjmCbp8FauVGDU03erOn+ hjH6lYXG5G; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Agreed. Perhaps a low precedence route (when all else but the default route fails to match) that's a null route would be desirable.. - Wes=20 -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Thursday, July 31, 2008 11:12 AM To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > The route should go to the LAN ports (for the delegate prefix). If=20 > the LAN ports happen to not be up, doesn't this cause the packet to be > > dropped? If the destination matches a loopback, then the packets=20 > can be serviced by the loopback. If there is no LAN port (# of LAN=20 > ports =3D 0), and if the device still does DHCPv6 PD (for other=20 > addresses), then a null route may be appropriate as long as the other=20 > addresses get serviced at a higher priority. For example, if the delegated prefix is a /56 and the CPE use a /64 prefix for a subnet on a LAN Bridge and another /64 for a subnet on another LAN interface outside the bridge, there are many prefix/subnet not used. Packet to theses unused prefix/subnet will loop without a discard or unreachable route. Francois-Xavier > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Francois-Xavier Le Bail > Sent: Thursday, July 31, 2008 10:17 AM > To: v6ops@ops.ietf.org > Subject: Another requirement [Re: New (-02) version of IPv6 CPE Router > draft is available for review] >=20 > Another requirement: >=20 > The CPE should install a discard (null) or unreachable route for the=20 > delegated prefix. >=20 > Without, a packet to an unused subnet (belonging to the delegated > prefix) will loop between the CPE (default route to the Edge Router)=20 > and the Edge Router (route for the delegated prefix to the CPE). >=20 > The only difference between the two options is: with unreachable route > the CPE return ICMPv6 "Destination Unreachable/no route to=20 > destination" > message to the source address instead of only silently discard the=20 > packet. >=20 > Francois-Xavier =20 From owner-v6ops@ops.ietf.org Thu Jul 31 08:34:10 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AB63A6CD9 for ; Thu, 31 Jul 2008 08:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rkg7D2FzdqQL for ; Thu, 31 Jul 2008 08:34:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31B923A6CDD for ; Thu, 31 Jul 2008 08:34:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOa9V-000HG0-Ng for v6ops-data@psg.com; Thu, 31 Jul 2008 15:33:17 +0000 Received: from [69.147.75.93] (helo=web62501.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOa9S-000HFc-0v for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:33:15 +0000 Received: (qmail 54145 invoked by uid 60001); 31 Jul 2008 15:33:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=nYREO2x1PWUU5hb164ifnBnHS5VnnMZE0lYGutV2xVXmM7rZN+/FK11m1nOnwKGUE78hd65lzCvGRRSwxqoM8l7a9uEL1jhzfgGI9QIsGHbUHLctr2tQuQ3FSCVFn1htIOKFe6ZFBnVPxRcQUNLV2Nt5LBTAlmvO9j8Ct//MpjE=; Received: from [193.49.124.107] by web62501.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 08:33:13 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 08:33:13 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org, "Wes Beebee \(wbeebee\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <266119.50345.qm@web62501.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > Agreed. Perhaps a low precedence route (when all else but > the default > route fails to match) that's a null route would be > desirable.. Yes, and with the Good Old "Longest prefix match", no problem of precedence. Francois-Xavier > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Thursday, July 31, 2008 11:12 AM > To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: RE: Another requirement [Re: New (-02) version of > IPv6 CPE > Router draft is available for review] > > --- On Thu, 7/31/08, Wes Beebee (wbeebee) > wrote: > > The route should go to the LAN ports (for the delegate > prefix). If > > the LAN ports happen to not be up, doesn't this > cause the packet to be > > > > dropped? If the destination matches a loopback, > then the packets > > can be serviced by the loopback. If there is no LAN > port (# of LAN > > ports = 0), and if the device still does DHCPv6 PD > (for other > > addresses), then a null route may be appropriate as > long as the other > > addresses get serviced at a higher priority. > > For example, if the delegated prefix is a /56 and the CPE > use a /64 > prefix for a subnet on a LAN Bridge and another /64 for a > subnet on > another LAN interface outside the bridge, there are many > prefix/subnet > not used. > > Packet to theses unused prefix/subnet will loop without a > discard or > unreachable route. > > Francois-Xavier > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On > > Behalf Of Francois-Xavier Le Bail > > Sent: Thursday, July 31, 2008 10:17 AM > > To: v6ops@ops.ietf.org > > Subject: Another requirement [Re: New (-02) version of > IPv6 CPE Router > > > draft is available for review] > > > > Another requirement: > > > > The CPE should install a discard (null) or unreachable > route for the > > delegated prefix. > > > > Without, a packet to an unused subnet (belonging to > the delegated > > prefix) will loop between the CPE (default route to > the Edge Router) > > and the Edge Router (route for the delegated prefix to > the CPE). > > > > The only difference between the two options is: with > unreachable route > > > the CPE return ICMPv6 "Destination Unreachable/no > route to > > destination" > > message to the source address instead of only silently > discard the > > packet. > > > > Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 08:45:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FD53A6872 for ; Thu, 31 Jul 2008 08:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ZU4Ho83OoU for ; Thu, 31 Jul 2008 08:45:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 602D43A6CD6 for ; Thu, 31 Jul 2008 08:44:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaK4-000Icj-Qk for v6ops-data@psg.com; Thu, 31 Jul 2008 15:44:12 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaK1-000Ibx-9L for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:44:10 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6VFhl4d010961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 08:43:47 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6VFhk1R023409; Thu, 31 Jul 2008 08:43:46 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6VFhbsS022990; Thu, 31 Jul 2008 08:43:46 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 08:43:45 -0700 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 Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 08:43:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104C6B60A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <16781.96734.qm@web62512.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzI0s2A8Rs5HHpS+ySeL8o8ShP7QAABI7Q References: <16781.96734.qm@web62512.mail.re1.yahoo.com> From: "Templin, Fred L" To: "Francois-Xavier Le Bail" , , "Wes Beebee (wbeebee)" X-OriginalArrivalTime: 31 Jul 2008 15:43:45.0296 (UTC) FILETIME=[37583900:01C8F324] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: =20 >-----Original Message----- >From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 >Sent: Thursday, July 31, 2008 8:12 AM >To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) >Subject: RE: Another requirement [Re: New (-02) version of=20 >IPv6 CPE Router draft is available for review] > >--- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: >> The route should go to the LAN ports (for the delegate >> prefix). If the LAN ports happen to not be up, doesn't this=20 >> cause the packet to be > dropped? If the destination matches a=20 >> loopback, then the packets can be >> serviced by the loopback. If there is no LAN port (# of >> LAN ports =3D 0), >> and if the device still does DHCPv6 PD (for other >> addresses), then a >> null route may be appropriate as long as the other >> addresses get >> serviced at a higher priority. > >For example, if the delegated prefix is a /56 and the CPE use >a /64 prefix for a subnet on a LAN Bridge and another /64 for a >subnet on another LAN interface outside the bridge, >there are many prefix/subnet not used. > >Packet to theses unused prefix/subnet will loop without a discard=20 >or unreachable route. But is this so surprising? Any requesting router that is delegated a prefix is implicitly responsible for proper stewardship of the prefix; this is not specific to just the CPE router case. So, is any additional specification needed and (if so) should it be done here or within a broader context? =20 Fred fred.l.templin@boeing.com > >Francois-Xavier > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Francois-Xavier Le Bail >> Sent: Thursday, July 31, 2008 10:17 AM >> To: v6ops@ops.ietf.org >> Subject: Another requirement [Re: New (-02) version of IPv6 >> CPE Router >> draft is available for review] >>=20 >> Another requirement: >>=20 >> The CPE should install a discard (null) or unreachable >> route for the >> delegated prefix. >>=20 >> Without, a packet to an unused subnet (belonging to the >> delegated >> prefix) will loop between the CPE (default route to the >> Edge Router) and >> the Edge Router (route for the delegated prefix to the >> CPE). >>=20 >> The only difference between the two options is: with >> unreachable route >> the CPE return ICMPv6 "Destination Unreachable/no >> route to destination" >> message to the source address instead of only silently >> discard the >> packet. >>=20 >> Francois-Xavier > > > =20 > > From owner-v6ops@ops.ietf.org Thu Jul 31 08:49:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5775028C14C for ; Thu, 31 Jul 2008 08:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iprjeTXPYNJo for ; Thu, 31 Jul 2008 08:49:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC0DF3A63D2 for ; Thu, 31 Jul 2008 08:49:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaOk-000JF2-6O for v6ops-data@psg.com; Thu, 31 Jul 2008 15:49:02 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaOf-000JEO-RT for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:49:00 +0000 X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16111536" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 15:48:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VFmuMq009178; Thu, 31 Jul 2008 11:48:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VFmnKg027610; Thu, 31 Jul 2008 15:48:56 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:48:54 -0400 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 Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 11:49:29 -0400 Message-ID: In-Reply-To: <266119.50345.qm@web62501.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzItHbwKx7zUqVRqmBv+45AnZbJAAAeD9g From: "Wes Beebee (wbeebee)" To: "Francois-Xavier Le Bail" , X-OriginalArrivalTime: 31 Jul 2008 15:48:54.0369 (UTC) FILETIME=[EF910510:01C8F324] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3256; t=1217519336; x=1218383336; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20 |To:=20=22Francois-Xavier=20Le=20Bail=22=20,=20; bh=bebcVLxEoDIC0jZ6gZ7zzvTbyMqHRKJIUZKMf5lBLU4=; b=ADrQHz2zDOX2Pvqa36vOF5rIPowplaN+B304HmaVafsC/DQJ+a0TTaaqJk mVOghoECUKSrEpmuOQKZ96M1QY8xXHEQH0o/OVg/1OM+mWPlIefmMo/XQKzr Qu7nJ2FyN7; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: There may be problem with precedence if the PD is a /64 and there is one LAN port that's a /64, you'd have to make sure that the null route was lower precedence than the LAN port otherwise you might not have connectivity. So yes, we do need to specify that the null route is lower=20 precedence than other routes except for the default route. - Wes -----Original Message----- From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20 Sent: Thursday, July 31, 2008 11:33 AM To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > Agreed. Perhaps a low precedence route (when all else but the default > route fails to match) that's a null route would be desirable.. Yes, and with the Good Old "Longest prefix match", no problem of precedence. Francois-Xavier > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Thursday, July 31, 2008 11:12 AM > To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: RE: Another requirement [Re: New (-02) version of > IPv6 CPE > Router draft is available for review] >=20 > --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > > The route should go to the LAN ports (for the delegate > prefix). If > > the LAN ports happen to not be up, doesn't this > cause the packet to be >=20 > > > dropped? If the destination matches a loopback, > then the packets > > can be serviced by the loopback. If there is no LAN > port (# of LAN > > ports =3D 0), and if the device still does DHCPv6 PD > (for other > > addresses), then a null route may be appropriate as > long as the other > > addresses get serviced at a higher priority. >=20 > For example, if the delegated prefix is a /56 and the CPE use a /64=20 > prefix for a subnet on a LAN Bridge and another /64 for a subnet on=20 > another LAN interface outside the bridge, there are many prefix/subnet > not used. >=20 > Packet to theses unused prefix/subnet will loop without a discard or=20 > unreachable route. >=20 > Francois-Xavier >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Francois-Xavier Le=20 > > Bail > > Sent: Thursday, July 31, 2008 10:17 AM > > To: v6ops@ops.ietf.org > > Subject: Another requirement [Re: New (-02) version of > IPv6 CPE Router >=20 > > draft is available for review] > >=20 > > Another requirement: > >=20 > > The CPE should install a discard (null) or unreachable > route for the > > delegated prefix. > >=20 > > Without, a packet to an unused subnet (belonging to > the delegated > > prefix) will loop between the CPE (default route to > the Edge Router) > > and the Edge Router (route for the delegated prefix to > the CPE). > >=20 > > The only difference between the two options is: with > unreachable route >=20 > > the CPE return ICMPv6 "Destination Unreachable/no > route to > > destination" > > message to the source address instead of only silently > discard the > > packet. > >=20 > > Francois-Xavier =20 From owner-v6ops@ops.ietf.org Thu Jul 31 08:59:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1413A69DE for ; Thu, 31 Jul 2008 08:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YXIDuFcKIX8 for ; Thu, 31 Jul 2008 08:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D45428C199 for ; Thu, 31 Jul 2008 08:59:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaX0-000KWe-1A for v6ops-data@psg.com; Thu, 31 Jul 2008 15:57:34 +0000 Received: from [69.147.75.107] (helo=web62515.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaWw-000KVz-8W for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:57:32 +0000 Received: (qmail 91043 invoked by uid 60001); 31 Jul 2008 15:57:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=WKLSlsQevKinduiDPJPYlygd+Sc4mq0efJgAs8IwGuZ+EFBvsSY2cgvL3xXpTfaZC+lWlM1Ja+lYAvKoCnd3gGDA3GIfLCRWj5ylUSXPebcO0agKDj1+5YTOwz+ZKSZvIf7vEB7CqjtFkoTIa/3R3Mov1lRJ4qujfQpVHLgzHVo=; Received: from [193.49.124.107] by web62515.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 08:57:27 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 08:57:27 -0700 (PDT) From: Francois-Xavier Le Bail Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: v6ops@ops.ietf.org, "Wes Beebee \(wbeebee\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <40238.90490.qm@web62515.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: > There may be problem with precedence if the PD is a /64 and > there is one > LAN port that's a /64, > you'd have to make sure that the null route was lower > precedence than > the LAN port otherwise > you might not have connectivity. So yes, we do need to > specify that the > null route is lower > precedence than other routes except for the default route. Agreed > -----Original Message----- > From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] > Sent: Thursday, July 31, 2008 11:33 AM > To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) > Subject: RE: Another requirement [Re: New (-02) version of > IPv6 CPE > Router draft is available for review] > > --- On Thu, 7/31/08, Wes Beebee (wbeebee) > wrote: > > Agreed. Perhaps a low precedence route (when all else > but the default > > > route fails to match) that's a null route would be > desirable.. > > Yes, and with the Good Old "Longest prefix > match", no problem of > precedence. > > Francois-Xavier > > > -----Original Message----- > > From: Francois-Xavier Le Bail > [mailto:fx.lebail@yahoo.com] > > Sent: Thursday, July 31, 2008 11:12 AM > > To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) > > Subject: RE: Another requirement [Re: New (-02) > version of > > IPv6 CPE > > Router draft is available for review] > > > > --- On Thu, 7/31/08, Wes Beebee (wbeebee) > wrote: > > > The route should go to the LAN ports (for the > delegate > > prefix). If > > > the LAN ports happen to not be up, doesn't > this > > cause the packet to be > > > > > > dropped? If the destination matches a > loopback, > > then the packets > > > can be serviced by the loopback. If there is no > LAN > > port (# of LAN > > > ports = 0), and if the device still does DHCPv6 > PD > > (for other > > > addresses), then a null route may be appropriate > as > > long as the other > > > addresses get serviced at a higher priority. > > > > For example, if the delegated prefix is a /56 and the > CPE use a /64 > > prefix for a subnet on a LAN Bridge and another /64 > for a subnet on > > another LAN interface outside the bridge, there are > many prefix/subnet > > > not used. > > > > Packet to theses unused prefix/subnet will loop > without a discard or > > unreachable route. > > > > Francois-Xavier > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of > Francois-Xavier Le > > > Bail > > > Sent: Thursday, July 31, 2008 10:17 AM > > > To: v6ops@ops.ietf.org > > > Subject: Another requirement [Re: New (-02) > version of > > IPv6 CPE Router > > > > > draft is available for review] > > > > > > Another requirement: > > > > > > The CPE should install a discard (null) or > unreachable > > route for the > > > delegated prefix. > > > > > > Without, a packet to an unused subnet (belonging > to > > the delegated > > > prefix) will loop between the CPE (default route > to > > the Edge Router) > > > and the Edge Router (route for the delegated > prefix to > > the CPE). > > > > > > The only difference between the two options is: > with > > unreachable route > > > > > the CPE return ICMPv6 "Destination > Unreachable/no > > route to > > > destination" > > > message to the source address instead of only > silently > > discard the > > > packet. > > > > > > Francois-Xavier From owner-v6ops@ops.ietf.org Thu Jul 31 09:00:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E248D3A6CE2 for ; Thu, 31 Jul 2008 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.81 X-Spam-Level: X-Spam-Status: No, score=-105.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOOoXnClLb-3 for ; Thu, 31 Jul 2008 09:00:03 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A16323A6C6F for ; Thu, 31 Jul 2008 08:59:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaXG-000KZ0-KZ for v6ops-data@psg.com; Thu, 31 Jul 2008 15:57:50 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOaXC-000KYN-N0 for v6ops@ops.ietf.org; Thu, 31 Jul 2008 15:57:48 +0000 X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="70967804" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2008 15:57:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VFvMjo008896; Thu, 31 Jul 2008 08:57:22 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6VFvIfu003174; Thu, 31 Jul 2008 15:57:22 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:57:20 -0400 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 Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 11:57:55 -0400 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104C6B60A@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: AcjzI0s2A8Rs5HHpS+ySeL8o8ShP7QAABI7QAACWg/A= From: "Wes Beebee (wbeebee)" To: "Templin, Fred L" , "Francois-Xavier Le Bail" , X-OriginalArrivalTime: 31 Jul 2008 15:57:20.0897 (UTC) FILETIME=[1D7B0F10:01C8F326] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3275; t=1217519842; x=1218383842; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20Another=20requirement=20[Re=3A=20New=20 (-02)=20version=20of=20IPv6=20CPE=20Router=20draft=20is=20av ailable=20for=20review] |Sender:=20; bh=Hn3dsER6VByj4W5JTyqJEwrHmkNwPc8EEmn7aQnhjrU=; b=RvPB8eflbvSXl7k5jtPxVpNp2/vPvAi+AgBCAFA618sxFip3jbMvMVrUQT zzpUQw/0Lo0d1rZSbEoK92VLeSsqz0gM8oG8Oked2muLXtjugqP5ZnFIBtwG SU+X4Pd8+lGizOVrdfAvh1QoihXz0ItOjMDsxX08DKitgiNVa1Gc0=; Authentication-Results: sj-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > So, is any additional specification needed and (if so) should it be done here or within a broader context? If someone writes some other document on proper population of routing tables/stewardship of prefixes, then the CPE Router document can reference that other document - but I think that we can address this specific issue with a single sentence in the CPE Router document. - Wes -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Thursday, July 31, 2008 11:44 AM To: Francois-Xavier Le Bail; v6ops@ops.ietf.org; Wes Beebee (wbeebee) Subject: RE: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] =20 >-----Original Message----- >From: Francois-Xavier Le Bail [mailto:fx.lebail@yahoo.com] >Sent: Thursday, July 31, 2008 8:12 AM >To: v6ops@ops.ietf.org; Wes Beebee (wbeebee) >Subject: RE: Another requirement [Re: New (-02) version of >IPv6 CPE Router draft is available for review] > >--- On Thu, 7/31/08, Wes Beebee (wbeebee) wrote: >> The route should go to the LAN ports (for the delegate prefix). If=20 >> the LAN ports happen to not be up, doesn't this cause the packet to=20 >> be > dropped? If the destination matches a loopback, then the=20 >> packets can be serviced by the loopback. If there is no LAN port (#=20 >> of LAN ports =3D 0), and if the device still does DHCPv6 PD (for = other=20 >> addresses), then a null route may be appropriate as long as the other >> addresses get serviced at a higher priority. > >For example, if the delegated prefix is a /56 and the CPE use a /64=20 >prefix for a subnet on a LAN Bridge and another /64 for a subnet on=20 >another LAN interface outside the bridge, there are many prefix/subnet=20 >not used. > >Packet to theses unused prefix/subnet will loop without a discard or=20 >unreachable route. But is this so surprising? Any requesting router that is delegated a prefix is implicitly responsible for proper stewardship of the prefix; this is not specific to just the CPE router case. So, is any additional specification needed and (if so) should it be done here or within a broader context? =20 Fred fred.l.templin@boeing.com > >Francois-Xavier > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Francois-Xavier Le Bail >> Sent: Thursday, July 31, 2008 10:17 AM >> To: v6ops@ops.ietf.org >> Subject: Another requirement [Re: New (-02) version of IPv6 CPE=20 >> Router draft is available for review] >>=20 >> Another requirement: >>=20 >> The CPE should install a discard (null) or unreachable route for the=20 >> delegated prefix. >>=20 >> Without, a packet to an unused subnet (belonging to the delegated >> prefix) will loop between the CPE (default route to the Edge Router)=20 >> and the Edge Router (route for the delegated prefix to the CPE). >>=20 >> The only difference between the two options is: with unreachable=20 >> route the CPE return ICMPv6 "Destination Unreachable/no route to=20 >> destination" >> message to the source address instead of only silently discard the=20 >> packet. >>=20 >> Francois-Xavier > > > =20 > > From owner-v6ops@ops.ietf.org Thu Jul 31 09:11:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B2B3A6BF2 for ; Thu, 31 Jul 2008 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CM-QHZ69GAH for ; Thu, 31 Jul 2008 09:11:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81DB23A6C6F for ; Thu, 31 Jul 2008 09:11:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOak5-000MbV-MW for v6ops-data@psg.com; Thu, 31 Jul 2008 16:11:05 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOak0-000MY5-MJ for v6ops@ops.ietf.org; Thu, 31 Jul 2008 16:11:03 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id ADC2CD012D; Thu, 31 Jul 2008 06:10:49 -1000 (HST) Date: Thu, 31 Jul 2008 06:10:49 -1000 (HST) From: Antonio Querubin To: Francois-Xavier Le Bail cc: v6ops@ops.ietf.org Subject: Re: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: <688269.50340.qm@web62511.mail.re1.yahoo.com> Message-ID: References: <688269.50340.qm@web62511.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Francois-Xavier Le Bail wrote: > Another requirement: > > The CPE should install a discard (null) or unreachable route for the > delegated prefix. > > Without, a packet to an unused subnet (belonging to the delegated prefix) > will loop between the CPE (default route to the Edge Router) and the Edge > Router (route for the delegated prefix to the CPE). > > The only difference between the two options is: with unreachable route > the CPE return ICMPv6 "Destination Unreachable/no route to destination" > message to the source address instead of only silently discard the packet. This would definately be a good idea for the first CPE router that gets delegated the big block of /56 or /48 (whatever) from the ISP. But what if it's one of the cascaded routers farther downstream? Some intelligent decisions would need to be made by the router - particularly the amount of address space to re-sub-delegate (if that's the right term) to downstream routers. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Thu Jul 31 09:28:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072533A6CDE for ; Thu, 31 Jul 2008 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7-t6GmakfUo for ; Thu, 31 Jul 2008 09:28:15 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 885A23A67EC for ; Thu, 31 Jul 2008 09:28:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOayN-000Oab-2Q for v6ops-data@psg.com; Thu, 31 Jul 2008 16:25:51 +0000 Received: from [2001:1888:0:1:230:48ff:fe5b:3b50] (helo=outgoing01.lava.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOayG-000OZk-9i for v6ops@ops.ietf.org; Thu, 31 Jul 2008 16:25:46 +0000 Received: from [2001:1888:0:a:206:5bff:fe02:d0af] (unknown [IPv6:2001:1888:0:a:206:5bff:fe02:d0af]) by outgoing01.lava.net (Postfix) with ESMTPS id AF470D016D; Thu, 31 Jul 2008 06:25:36 -1000 (HST) Date: Thu, 31 Jul 2008 06:25:36 -1000 (HST) From: Antonio Querubin To: Francois-Xavier Le Bail cc: v6ops@ops.ietf.org Subject: Re: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] In-Reply-To: Message-ID: References: <688269.50340.qm@web62511.mail.re1.yahoo.com> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Antonio Querubin wrote: > On Thu, 31 Jul 2008, Francois-Xavier Le Bail wrote: > >> Another requirement: >> >> The CPE should install a discard (null) or unreachable route for the >> delegated prefix. > This would definately be a good idea for the first CPE router that gets > delegated the big block of /56 or /48 (whatever) from the ISP. But what if > it's one of the cascaded routers farther downstream? Some intelligent Never mind - too early in the morning. The choice to reply with an unreachable or just silently discard for unused subnets/addresses within delegated prefix should be a vendor option though. Antonio Querubin whois: AQ7-ARIN From owner-v6ops@ops.ietf.org Thu Jul 31 10:38:31 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14D43A6D07 for ; Thu, 31 Jul 2008 10:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdvUBUI3UrQC for ; Thu, 31 Jul 2008 10:38:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59E323A68E0 for ; Thu, 31 Jul 2008 10:38:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOc4V-0007Xu-5L for v6ops-data@psg.com; Thu, 31 Jul 2008 17:36:15 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOc4R-0007XQ-6U for v6ops@ops.ietf.org; Thu, 31 Jul 2008 17:36:13 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1217525769!6658700!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 11973 invoked from network); 31 Jul 2008 17:36:09 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 31 Jul 2008 17:36:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6VHa7is010965; Thu, 31 Jul 2008 13:36:08 -0400 Received: from 01GAF5142010624.AD.BLS.COM ([139.76.131.91]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6VHa23T010850; Thu, 31 Jul 2008 13:36:03 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jul 2008 13:36:02 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jul 2008 13:36:01 -0400 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 Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Date: Thu, 31 Jul 2008 13:36:01 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0A005A6F@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review] Thread-Index: Acjy7FJVpJqzcyqFSvKq+h75NoHxKgAKfddg References: <948787.28567.qm@web62512.mail.re1.yahoo.com> From: "Stark, Barbara" To: "Antonio Querubin" , "Hemant Singh (shemant)" Cc: "Francois-Xavier Le Bail" , "Iljitsch van Beijnum" , X-OriginalArrivalTime: 31 Jul 2008 17:36:01.0977 (UTC) FILETIME=[E6B82A90:01C8F333] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >It's the observable behaviour that matters. > > Antonio Querubin I really agree with this statement, and wonder if it would be more useful to describe externally observable behavior, than to try to specify implementation (loopback interfaces and such). And identify what external stimuli the CPE router needs to be able to respond to, and what those responses are. I look at CPE routers as black boxes. Either they behave the way I want, or they don't. What they do on the inside to behave that way, doesn't really matter to me. I can't test that -- I can only test what I can observe. That is, when a CPE router's WAN interface is connected to the access network, the access network sees messages coming from the CPE router, and sends messages in return (router advertisements and such). Given that we appear to agree that the access network dictates whether stateful or stateless address assignment happens, and whether or not it hands out a global address (i.e., whether or not the access network uses the numbered or unnumbered model), the CPE router that expects to work on all types of access networks needs to be prepared to respond appropriately to all of these cases. A CPE router that is specifically designed to only operate on a particular network doesn't need to be prepared for all of these cases, but I'm not really interested in specifying that CPE router in the IETF. As I've stated before, my biggest concern are the retail CPE routers with Ethernet WAN ports. The non-network-specific CPE router must be prepared to act appropriately when it gets a GUA (through SLAAC or stateful DHCPv6). It must also be prepared to act appropriately (from the perspective of an external observer) when it does not. In my opinion, a non-network-specific CPE router must also boot with LAN coming up without dependency on the WAN (the LAN before WAN boot mode).=20 If the "loopback interface" somehow appears different to the access network, and the access network needs to know this, then this interface is relevant. If the access network (or the LAN, either) cannot tell that there is a loopback interface, or doesn't care, then such an implementation isn't relevant. What I do care about is the GUA that the CPE router uses when it initiates IP traffic to other global addresses (not within its assigned prefix). I think it should use an address from the prefix. If the access network didn't give it a GUA (unnumbered model), then I think it *must* use an address from the prefix. I don't really care how this is implemented internally, so long as there is agreement that it is possible and acceptable that this be able to occur. I don't care if this address is somehow connected to the "WAN interface", or not. So long as the router uses it. Barbara From owner-v6ops@ops.ietf.org Thu Jul 31 13:01:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554423A6AFB for ; Thu, 31 Jul 2008 13:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAAJKxpfJWzV for ; Thu, 31 Jul 2008 13:01:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DA153A6ABE for ; Thu, 31 Jul 2008 13:01:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOeHe-000PPf-5L for v6ops-data@psg.com; Thu, 31 Jul 2008 19:57:58 +0000 Received: from [69.147.75.102] (helo=web62510.mail.re1.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOeHa-000PP1-5p for v6ops@ops.ietf.org; Thu, 31 Jul 2008 19:57:56 +0000 Received: (qmail 22750 invoked by uid 60001); 31 Jul 2008 19:57:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=d3stZMNqHZvLK6vTXFZky2aF5cBXYRBCwK/GJsL62BwDcsNzrgmhbS/3B619VfmgJ3zzJ1z1acaoXfeDy1D77YtoxJSDnAHVOw2kTFBRatH7Odd++eMQcrHoyxqw/m90YGjZRQvfKuRw8t/ITKyOXAXHQyFdoxUS1SoU8n1upRc=; Received: from [90.31.190.229] by web62510.mail.re1.yahoo.com via HTTP; Thu, 31 Jul 2008 12:57:52 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 12:57:52 -0700 (PDT) From: Francois-Xavier Le Bail Subject: Re: Another requirement [Re: New (-02) version of IPv6 CPE Router draft is available for review] To: Antonio Querubin Cc: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <895136.22611.qm@web62510.mail.re1.yahoo.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --- On Thu, 7/31/08, Antonio Querubin wrote: > > On Thu, 31 Jul 2008, Francois-Xavier Le Bail wrote: > >> Another requirement: > >> The CPE should install a discard (null) or > >> unreachable route for the delegated prefix. > The choice to reply with an > unreachable or just silently discard for unused > subnets/addresses within > delegated prefix should be a vendor option though. Or setup option ? Or managed by the ISP ? Francois-Xavier